12/08/2018, 13:08

test specification step by step

Ace dev thường bị đánh giá rank thấp ở khoản QA/test, đợt review vừa rồi bị GL hỏi test specification là gì nên về quyết tâm tìm hiểu và viết bài này, hi vọng có thể giúp được các ace dev trong mục QA/test. 1.Test Specification (TS) là gì: Từng nghe QA leader tạo plan test,QA viết test case,thực ...

Ace dev thường bị đánh giá rank thấp ở khoản QA/test, đợt review vừa rồi bị GL hỏi test specification là gì nên về quyết tâm tìm hiểu và viết bài này, hi vọng có thể giúp được các ace dev trong mục QA/test.

1.Test Specification (TS) là gì: Từng nghe QA leader tạo plan test,QA viết test case,thực hiện test.. nhưng những giai đoạn này không trực tiếp làm việc với test Specification.Test Specification là loại tài liệu được define trước cả test plan nhằm định nghĩa các tiêu chí,nguyên tắc,phương pháp trong giai đoạn kiểm thử phần mềm.

2.Step by step:
Step1: xác định toàn bộ thời gian kiểm thử sẽ kéo dài bao lâu.Thời gian cho từng giai đoạn.
Screen Shot 2015-12-26 at 23.41.01.png Step2:Xác định Scope của việc kiểm thử trong đó phải bao gồm danh sách của group và các item cần được test , ex: List of screen,function....
Step3:Xác định chiến lược kiểm thử: có thể áp dụng một hoặc cùng lúc chiến lược sau tùy theo yêu cầu của dự án.
→Unit testing:mô tả những phần có thể gây ảnh hưởng lớn đến effort kiểm thử, mô tả cách chọn thành phần để viết Unit testcase cho phù hợp.ex:có thể viết UT-case theo từng màn hình hoặc theo từng function trong detail design.UT-case không bao gồm trong spec này.
→Integration testing: mô tả thứ tự tích hợp từng phần tương ứng với trình tự sẽ test phần tích hợp theo trình tự đó.Test-case không bao gồm trong spec này.
→Validation testing:mô tả trình tự để validate các chức năng trong hệ thống.Ex:cần validate login trước logout.
Step4: Xác định LifeTime cho quá trình test bao gồm: Nhãn và vòng đời của test task,nhãn và vòng đời của bug.
Screen Shot 2015-12-26 at 23.35.09.png


Step5: Xác định các loại tài liệu và Format của chúng.Đây là bước tiền đề để tiếp tục viết các tài liệu tiếp theo trong quá trình kiểm thử.Đã có những dự án do không mô tả version test nên khách hàng liên tục trả bug của những version trước đã được test gây tốn nhiều effort để check lại.Chỉ cần 1 item nhỏ định nghĩa trong mục này có thể sẽ giảm được nhiều công sức.
Step6: Định nghĩa các phương pháp và chuẩn sẽ được áp dụng trong các giai đoạn kiểm thử: blackbox, whitebox, C1, C2....
Step7: Mô tả ai, sẽ làm nhiệm vụ gì trong toàn bộ quá trình kiểm thử.Việc xác định resource về con người này liên quan đến khối lượng của toàn bộ việc kiểm thử do đó cần người có khả năng estimation chính xác.
Step8 Test record keeping: mô tả các ngưỡng cần đạt được khi kiểm thử, trong trường hợp vượt quá những ngưỡng này thì cần phải tìm được nguyên nhân phù hợp.ex:100 testcase/500 code line,cần pass 80/100test-case...
Step 9 Test environment:mô tả các tools, thiết bị, files và các tài nguyên sẽ được sử dụng trong quá trình kiểm thử.
3.Một số chú ý khi viết TestSpecification
+Test specification có thể được viết ở nhiều level dành cho những mức độ khác nhau của người sử dụng chúng.
+TS có thể bao gồm cả test plan, test-case files....


4.kết luận: để viết được test specification tốt bạn cần nắm vững các nội dung cần thiết, bám sát quá trình phát triển phần mềm, dự đoán được khối lượng, trình tự của công việc.Đây không phải là việc mà một QA ở level thấp có thể đảm đương được.Chúc ace nhanh chóng level-up.
5.Tham khảo:
https://courses.cs.washington.edu/courses/cse403/05sp/slides/Lecture23.pdf
http://csis.pace.edu/~marchese/SE616/testb.pdf
http://blogs.msdn.com/b/anutthara/archive/2006/03/28/563730.aspx

0