Nguồn bài viết: 基本仕様書の書き方 テスト仕様書の書き方

Basic spec

Basic spec là gì

Là spec được viết vào thời điểm có thể phán đoán được rằng đã hầu như có đủ những yêu cầu cho hệ thống từ khách hàng. Nó quyết định schedule cũng như cấu trúc cơ bản của hệ thống sau khi đã định nghĩa lại những yêu cầu của khách hàng từ cái nhìn của developer. Hơn nữa trong khả năng có thể, vào thời điểm viết cũng cần làm rõ những mục hạn chế và những vấn đề có thể phát sinh trong quá trình thực hiện hệ thống bằng phương pháp đã định.

Nguyên tắc viết các đề mục

Dưới đây tôi sẽ giải thích phương pháp viết các đề mục nằm trong spec cơ bản.

Mục tiêu của dự án(WHY)

Mục này sẽ viết mục tiêu của việc phát triển hệ thống. Trong khả năng có thể hãy làm rõ hiệu quả đối với chi phí khi đưa hệ thống vào sử dụng dựa trên những con số cụ thể(tham khảo phía dưới). Khi việc phát triển tiến triển và hệ thống trở nên cụ thể hóa hơn thì (hầu như chắc chắn) chúng ta sẽ gặp phải vấn đề là không còn cách nào khác lngoài thay đổi các điều kiện và schedule. Khi ấy thì những nội dung được viết trong spec này sẽ trở thành kim chỉ nam quan trọng. Ví dụ x Đơn giản hóa những công việc tổng hợp => không OK ○ Cải thiện để công việc tổng hợp cần 2h hiện tại xuống còn trong khoảng 30 phút => OK

Phương châm cơ bản(HOW)

Đây là mục nêu những phương châm cơ bản trong phát triển hệ thống. Trong mục này nếu tổng hợp lại một lần thì phần lớn có thể sử dụng lại cho nhiều mục khác. Bởi vậy tôi sẽ bỏ qua phần giải thích và viết về trường hợp được lấy làm ví dụ cụ thể: “GUI application by Java”

Phương châm thiết kế:

Khi khởi động application thì màn hình chính là frame sẽ được mở ra và các chức năng sẽ được thực hiện trong frame đó.

Phương châm quản lí resource:

-Các message hoàn toàn bằng tiếng Nhật, thống nhất sử dụng kính ngữ. -Các yếu tố dùng để dừng xử lí(như các nút…) thống nhất viết bằng nhãn 「キャンセル」(cancel), trường hợp có nhiều lựa chọn thì đặt chúng ở tận cùng bên phải.

Phương châm thực hiện:

-Các class tổng hợp hàm số dạng tĩnh thì đặt tên là 「..Logic」hoặc「..Utilities」. -Class quản lí resource được chia sẻ trong toàn hệ thống thì đặt tên là 「..Context」

Phương châm test:

-Trong khả năng có thể thêm các testcase viết bằng JUnit. -Tổng hợp tất cả các testcase liên quan đến thao tác của user vào 「Test spec」, mỗi lần release và ngay sau những lần sửa đổi lớn cần thực hiện test lại toàn bộ. -Sau mỗi lần release thực hiện kiểm tra và xác nhận tính toàn vẹn thống nhất của hệ thống đối với user.

Phương châm cập nhật sau khi release:

Application được khởi động bằng hệ thống khởi động online sử dụng kĩ thuật JavaWebStart. Trong trường hợp phát sinh sửa chữa hệ thống sau khi release thì có thể cung cấp cho toàn bộ khách hàng những cập nhật dựa trên việc viết lại những dữ liệu thực hiện được đăng kí trên server.

Danh sách các chức năng (WHAT)

Đây là mục để viết chúng ta sẽ “tạo ra những gì”. Vì chi tiết sẽ được viết ở 「Detailed estimation」và「External design document」 nên ở đây chỉ nêu ra những outline cơ bản.

Sử dụng hệ thống:

Viết những giả định khi hệ thống được sử dụng.

Đối tượng user:

Viết những giả định về user sử dụng hệ thống cũng như môi trường(đại diện) mà những user đó sẽ sử dụng

Hardware:

Viết về hardware cấu thành hệ thống(server, network, những thiết bị liên quan khác) Ví dụ: Host: xxx xxx Router: yyy yyy

Software:

Viết về những software cần thiết cho hệ thống(bao gồm cả OS) Ví dụ： OS: Fedora 8(linux) Java: j2sdk1.6.0以上 Database: h2database 1.0.64

Mục tiêu về tính năng:

Nêu những tính năng cần đạt được

Những mục hạn chế:

Nêu những mục hạn chế khi sử dụng hệ thống. Tất nhiên là không thể viết được hết những điều không thể, nhưng khi giả định việc sử dụng hệ thống thì trong khả năng có thể việc tìm ra càng nhiều càng tốt những trường hợp hệ thống không đáp ứng được là rất quan trọng. (Ví dụ như không thể khởi động được với Windows 98…)

Sự liên quan đối với các hệ thống khác(năng lực cạnh tranh) :

Trong trường hợp thay thế(hoặc thâu tóm) hệ thống đã có sẵn, cần nêu tính ưu việt và tính liên quan đến hệ thống đó. Nếu tồn tại hệ thống tương tự thì chúng ta nên viết cả quá trình cũng như lí do của sự cần thiết khi không sử dụng hệ thống đó mà lại làm mới lại.

Thể chế phát triển (WHO)

Mục này sẽ nêu ra vai trò của những người chịu trách nhiệm cho các công việc, component khác nhau, tùy theo quy mô của dự án mà có project manager, programmer, designer…Đối với những thành viên không chỉ liên quan đến một công việc thì chúng ta cần viết cả thời gian tham gia nữa. Không chỉ developer mà người dùng tham gia vào việc test hệ thống khi đang phát triển cũng cần được định nghĩa. Chúng ta nhờ khách hàng check spec từ giai đoạn thiết kế nhưng chỉ có vậy thôi thì không thể xác nhận 100% được. Để tránh việc phải quay trở lại ở giai đoạn cuối cùng thì việc để khách hàng trực tiếp sử dụng hệ thống ở các thời điểm cần thiết là vô cùng quan trọng.

Ví dụ -Project manager -Programer(chịu trách nhiệm component A, B) -Programer(chịu trách nhiệm component B, tham gia từ năm yyyy, tháng xx) -Người chịu trách nhiệm kiểm định tính hợp lí của spec

Schedule cho việc phát triển hệ thống(WHEN)

Định nghĩa thời kì bắt đầu làm, thời kì release, thời kì bắt đầu vận hành hệ thống. Tùy theo quy mô của dự án mà chia thời kì release thành phase 1, phase 2…Ở trường hợp dự án chú trọng tính làm mới thì “thời điểm bắt đầu vận hành” cũng được hiểu là “mục tiêu cho thời điểm bắt đầu vận hành”. Hơn nữa, điều quan trọng nhất ở đây không phải là “release=hoàn thành” mà là “release=khách hàng trực tiếp sử dụng thử hệ thống”. Giống như đã nói ở phần trên, việc kiểm tra 100% spec ở giai đoạn thiết kế là điều không thể. Có rất nhiểu sai sót thường tiềm ẩn ở những spec mâu thuẫn với mục tiêu.

Môi trường phát triển(WHERE)

Ngôn ngữ phát triển:

Nêu ngôn ngữ sử dụng để phát triển cũng như IDE và version của chúng.

Quan hệ phụ thuộc:

Nêu những library, framework và application phụ thuộc cũng như version của chúng. Vì library trong quá trình thực hiện có thể tăng giảm nên chỉ cần viết ởmức mục tiêu dự kiến là được. Còn về application thì ví dụ như ở trường hợp hệ thống có thể xuất ra các file excel và pdf thì ghi là 「Microsoft Excel」và「Acrobat Reader」.

Liên quan đến các hệ thống khác(phụ thuộc) :

Nêu toàn bộ các hệ thống ứng với các mục dưới đây: -Hệ thống hỗ trợ đón nhận dữ liệu -Hệ thống điều khiển(bị điều khiển) sự khởi động, thực hiện ※Excel bao gồm Macro được xem là hệ thống liên quan. Có nghĩa là không chỉ nêu 「Microsoft Excel」 ở mục application phụ thuộc mà cũng cần nêu ra ở đây .

Test spec

Test spec là gì

Là spec quyết định các bước kiểm tra hoạt động của hệ thống từ phía ngoài. Nó cần được viết từ từ từng chút một từ sau khi bắt đầu vận hành hệ thống(sẽ nêu sau ở phần scenario). Trong khả năng có thể cần làm rõ nội dung của công việc “xác nhận thao tác” thường mang ý nghĩa không rõ ràng. Mục đích của spec này là có thể thực hiện được test chính xác và nhanh chóng.

System test và unit test:

Spec này là về system test. Nó định nghĩa việc test các thao tác được thực hiện trực tiếp từ phía user trên môi trường production ngay sau khi hoàn thành cấu trúc hệ thống cũng như trên môi trường test giống với production. Unit test thực hiện đối với từng module(class, method) được định nghĩa ở cùng vị trí với repository của source code tương ứng với từng giai đoạn phát triển hệ thống nên không nằm trong spec này.

Phương châm viết các đề mục

Dưới đây tôi sẽ giải thích phương pháp viết các đề mục được bao gồm trong cả basic spec.

Khái quát

Phương châm test:

Nêu phương châm cơ bản của việc test. Tất cả những điều kiện tiền đề dùng cho quá trình test cũng như xử lí... cũng sẽ được viết ở đây.

Phương pháp tạo hoặc lấy dữ liệu test:

Nêu các phương pháp lấy thông tin giả định được sử dụng trong quá trình test nhập dữ liệu vào. Cần giả định các trường hợp như tạo dữ liệu bằng việc kết hợp script hoặc thao tác thủ công, hay mượn dữ liệu được sử dụng trong khi vận hành hệ thống thực tế từ khách hàng.

Môi trường test:

Nêu thông tin thiết bị cũng như host được sử dụng để test.

Môi trường production thực tế:

Nêu thông tin host được sử dụng trong môi trường production thực tế. Tùy từng trường hợp mà việc test trên môi trường này có thể thực hiện được, nhưng thông thường thì nếu thực hiện test ở đây chắc chắn sẽ xảy ra lỗi. Để phân biệt rõ ràng với môi trường test chúng ta nên thêm dấu hiệu gì đó để nhận biết (ví dụ như màu của form login thay đổi chẳng hạn)

Scenario

Định nghĩa các bước thực hiện(cũng như chuẩn bị) cho quá trình test. Cần nêu tên tóm tắt khái quát scenario, từng bước thực hiện cũng như kết quả mong đợi. Ví dụ, scenario để test cho các bước của thao tác “đặt tên cho file rồi lưu” sẽ như dưới đây

Tên scenario	Quá trình thực hiện	Kết quả mong đợi
1. Lưu file	Bấm nút 「保存..」(lưu)
	2.Nhập tên(foo.txt) vào dialog hiện ra rồi bấm 「OK」
	2-1.Trường hợp file đã được lưu rồi	Hiện dialog xác nhận viết đè lên
	2-1-1.Bấm「Yes」	Hiện message thông báo đã lưu
	2-1-2.Bấm 「No」	Xử lí bị dừng lại
	2-2.Trường hợp file chưa được lưu	Hiện message thông báo đã lưu

Scenario không được viết ngay một lúc mà được viết tuần tự theo quá trình test và được thêm vào spec.

Trước tiên nó được định nghĩa với mục tiêu là “làm cho user và các thành viên trong team developer hiểu được ý đồ của người thực hiện test”. Trong rất nhiều trường hợp, nếu đưa ra scenario trước khi thực hiện thì sẽ dễ dàng tìm ra được những mâu thuẫn cũng như lãng phí trong khi sử dụng. Người chịu thực hiện test cần tạo thói quen viết scenario cho những chức năng đã có được trong hiện tại cũng như sẽ có trong tương lai.

Tiếp theo, scenario được tạo ra với mục đích “xác nhận lỗi đã được fix” khi người chịu trách nhiệm test phát hiện ra các lỗi này. Người thực hiện (developer) sẽ sửa lại program để thỏa mãn scenario . Hơn nữa nó còn được sử dụng để tránh xảy ra lỗi tương tự sau này.

Cuối cùng, có những scenario được tạo ra để “lưu lại feedback từ user”. Có trường hợp sẽ xảy ra nhận thức sai về các hành động không thể liệt kê hết được ở basic spec hay external design document bởi vậy việc ghi lại các bước xử lí theo nhu cầu của user dưới dạng scenario sẽ dễ dàng cho việc chia sẻ thông tin trong toàn dự án.

Lưu lại quá trình thực hiện

Cho dù có viết được scenario hoàn hảo nhưng nếu scenario đó lại bị chôn vùi trong đống tài liệu giao cho khách hàng thì cũng không có ý nghĩa gì. “Scenario(test) nào được thực hiện bao nhiêu lần, kết quả như thế nào” cần được ghi lại thường xuyên. Trong trường hợp hệ thống được sử dụng nhiều lần, khi có lỗi xảy ra thì việc xác định rõ ràng được lỗi đó là hoàn toàn mới hay đã tồn tại rồi và nguyên nhân của nó là gì là rất quan trọng. Các nội dung dưới đây cần được lưu lại theo thứ tự thời gian: Ngày giờ thực hiện, người thực hiện, code, scenario, kết quả.