Testing theory: acceptant test

Bách khoa toàn thư mở Wikipedia

Acceptance test

Có 3 chiến lược dành cho giai đoạn acceptance test, lựa chọn chiến lược nào phụ thuộc vào yêu cầu của hợp đồng, tổ chức hoặc phạm vi của ứng dụng.

o Formal acceptance test.

o Informal acceptance test.

o Beta test.


1.1. Formal acceptance test:

Mở rộng từ system test mà ra. Test được lập kế hoạch và thiết kế cẩn thận như là sytemtest. Test case được chọn là tập con của các chức năng trong system test. Trong một số tổ chức, formal acceptance test thường hoàn toàn là test tự động.

Các hoạt động và các công cụ thì giống như system test, trong một số nơi, các nhóm phát triển với các nhóm đại diện cho người dùng thi hành acceptance test, trong một số nơi khác, thì acceptance test hoàn toàn thi hành bởi tổ chứa người dùng luôn hoặc là một nhóm người được chọn ra từ người dùng cuối.

1.1.1. Lợi ích của chiến lược này:

o Chức năng và đặc tính được test đã được biết.

o Chi tiết cho việc test đã được biết và có thể đo lường.

o Có thể dùng test automation, vì có thể cho regression test nhiều lần.

o Sự tiến triển của việc test có thể đo được và kiểm tra được.

o Các tiêu chuẩn để có thể chấp nhận đã được biết.

1.1.2. Sự bất lợi của chiến lược này:

o Đòi hỏi đáng kể về tài nguyên và kế hoạch.

o Việc này có thể thực hiện lại việc của system test.

o Có thể không lộ ra được các lỗi chủ quan (tức là các use case hiếm xảy ra trong thực tế nhưng nó lại có lỗi và chỉ mong muốn tìm thấy lỗi mà mình muốn).


1.2. Informal acceptance test:

Thủ tục test cho việc thi hành test không có nghiêm khắc như khai báo trong formal acceptance test. Chức năng khảo sát được nhận dạng và tài liệu hoá. Nhưng không có test case cụ thể để thực hiện, các tester riêng lẻ phải tự quyết định mình phải làm gì. Không được quản lý như là formal testing, và dựa trên quan điểm cá nhân nhiều hơn.

Informal acceptance test thường được tiến hành bởi người dùng cuối.

1.2.1. Lợi ích :

o Chức năng và đặc tính cần test đã được biết.

o Tiến trình test có thể đo lường và kiểm tra.

o Các tiêu chuẩn để chấp nhận đã được biết.

o Bạn còn có thể bắt được các lỗi chủ quan nhiều hơn là formal acceptance test.

1.2.2. Sự bất lợi:

o Nguồn lực, lập kế hoạch, và quản lý chúng là điều cần thiết.

o Bạn không quản lý được các test case sẽ dùng.

o Người dùng có thể quen với cách làm việc của hệ thống và không nhìn thấy lỗi.

o Người dùng có thể tập trung vào so sánh hệ thống mới với hệ thống cũ hơn là cố tìm ra lỗi.

o Nguồn lực cho acceptance test không thể quản lý và có thể trở nên thui chột.


1.3. Beta test

Là thứ không thể quản lý được trong 3 chiến lược của acceptance test, trong beta testing, một số chi tiết, data, và cách tiếp cận thì hoàn toàn để cho tester quyết định. mỗi tester phải chịu trách nhiệm tạo môi trường cho riêng họ, lựa chọn data, và xác định chức năng nào, đặc tính hay tác vụ nào sẽ phải khảo sát. Mỗi tester có trách nhiệm nhận ra tiêu chuẩn dù chấp nhận system như trạng thái hiện tại hay không.

Beta testing thực hiện bởi người dùng cuối, thường là ít hoặc không có sự quản lý của nhóm phát triển. Beta testing hầu như là chủ đạo của các chiến lược trong acceptance test.

1.3.1. Lợi ích:

o Việc test thực hiện bởi người dùng cuối.

o Một tiềm lực nhân lực test dồi dào (khách hàng).

o Tăng sự thoả mản của khách hàng với những việc họ đang bị lôi cuốn vào.

o Bạn sẽ phát hiện ra nhiều lỗi chủ quan hơn so với informal acceptance testing.

1.3.2. Bất lợi:

o Chưa chắc tất cả chức năng và đặc tính có thể được test.

o Tiền trình test khó có thể đo lường được (không biềt đã tới đâu, chừng nào, xong cái gì).

o User có thể tập trung so sánh với hệ thống cũ (cách làm việc cũ) hơn là tìm ra thêm lỗi.

o Nguồn lực cho acceptance test không được sự quản lý bởi dự án và có thể thui chột.

o Tiêu chuẩn để chấp nhận không được biết.

o Bạn cần tăng nguồn lực hỗ trợ để quản lý các beta tester.

Nguồn tham khảo : RUP

Lampln

Ngôn ngữ khác