Nguyên tắc 1: Sự hiện diện của lỗi - Testing shows presence of defects
- Một phần mềm được hoàn thành luôn có lỗi tồn tại, dù đã qua quá trình kiểm tra thì vẫn có lỗi tiềm ẩn tồn tại trong phần mềm. Nổ lực để hạn chế lỗi với nhiều trường hợp kiểm thử khác nhau, càng nhiều càng tốt nhằm đảm bảo tỷ lệ lỗi khi đưa ra thị được là thấp nhất .
=> Đây là thực tế nhưng không phải là lý do để bao biện khi bị feedback hoặc để sót lỗi - Vẫn là lỗi ở người kiểm thử nếu nhận được feedback bug từ 1 người khác
Nguyên tắc 2: Kiểm tra càng sớm càng tốt - Early Testing
- Việc áp dụng kiểm thử phần mềm ở giai đoạn đầu giúp phát hiện ra bug sớm hơn. Giúp việc chuyển giao phần mềm sẽ đúng thời hạn và chất lượng dự án tốt hơn. Tiết kiệm được nguồn nhân lực và chi phí
- Thay vì chờ sản phẩm được hoàn thành mới bắt tay vào kiểm thử, viết testcase thì nên chia ra nhiều giai đoạn để kiểm thử nhằm đảm bảo được chất lượng của sản phẩm.
=>Tốt nhất nên bắt đầu hiểu từ khâu khảo sát yêu cầu và tìm lỗi ở ngay giai đoạn đầu: Phân tích yêu cầu từ B.A/ Product là tốt nhất
Nguyên tắc 3: Kiểm thử toàn bộ là không thể - Exhaustive Testing
- Không thể kiểm thử hết tất cả các trường hợp lỗi của phần mềm. Không có 1 sản phẩm nào hoàn hảo, ít chi phí, xong sớm mà không có lỗi. Trừ những phần mềm quá đơn giản như “hello world!”
=>Thay vì kiểm tra toàn bộ sản phẩm nên tập trung vào các phần quan trọng và ưu tiên của dự án theo từng giai đoạn, theo scope ban đầu đặt ra để tiết kiệm thời gian, nhân lực và không bị "bể" planning
Nguyên tắc 4: Lỗi được phân bố tập trung - Defect Clustering
- Bug thường tập trung ở một số module nhất định, nên khi phát hiện ra bug thuộc module nào thì nên test kỹ hơn ở module đó để đảm bảo tìm ra được nhiều bug tiềm ẩn nhất có thể
- Áp dụng 3 nguyên tắc:
2/ Nguyên tắc 80% - 20% (Pareto): 20% chức năng quan trọng của chương trình có thể gây ra 80% tổng số bug trong cả chương trình
3/ Tập trung tìm kiếm bug xung quanh những chức năng quan trọng
Nguyên tắc 5: Nguyên tắc nghịch lý thuốc trừ sâu - Pesticide Paradox
- Có người nói vui rằng kiểm thử là một nghệ thuật, đã là nghệ thuật thì phải có ý tưởng và cảm hứng, và đôi khi, cảm hứng cạn kiệt, không tìm thấy lỗi mới nào đối với những ca kiểm thử thông thường. Cũng giống như nếu ta cứ phun một loại thuốc trừ sâu với liều lượng như nhau thì một số loại sâu sẽ lờn thuốc, không được diệt sạch (nên được gọi là nghịch lý thuốc trừ sâu). Để khắc phục, ta phải thường xuyên làm phong phú bộ testcase và thực hiện nhiều trường hơp để tránh trường họp này
- Việc lặp đi lặp lại cùng 1 bộ test case sẽ khó có khả năng tìm ra lỗi mới hơn
- Khi 1 lỗi hay 1 tính năng được sửa hay thêm vào nên kiểm thử lại sản phẩm liên tục để đảm bảo việc lỗi hay tính năng thêm vào sẽ không ảnh hưởng đến các chức năng khác hiện có của sản phẩm
- Luôn thay đổi cách test để luôn tìm ra lỗi mới
=> Sự thất bại của 1 tester là test 10 - lần đều chỉ 1 bộ testcase mà không update hoặc thay đổi cách test. Khi ấy monkey testing / smoke test lại hiệu quả hơn là execute theo các testcase có sẵn nhàm chán
Nguyên tắc 6: Kiểm thử theo ngữ cảnh độc lập - Testing is context Dependent
- Việc kiểm thử phụ thuộc vào ngữ cảnh để có những trường hợp kiểm thử cho hợp lý.
- Không phải sản phẩm nào cũng dùng chung 1 trường hợp kiểm thử
Ví dụ: Kiểm thử cho một chương trình tính toán, nếu là cấp 1 thì chỉ cần test cho các trường họp cộng trừ nhân chia là đủ, Nếu là cấp 2 thì chú trọng đến số mũ, căn bậc 2, phương trinh. Cấp 3 thì test đạo hàm, tích phân...
Nguyên tắc 7: Quan niệm “hết lỗi” - Absence of error
- Phần mềm kiểm thử trong 1 giai đoạn không có lỗi không có nghĩa là cả phần mềm không có lỗi, có thể đưa ra thị trường ngay lập tức
- Kiểm thử phần mềm không phải chỉ là tìm hết lỗi của chương trình mà là kiểm tra xem phần mềm có đáp ứng được nhu cầu của khách hàng hay chưa. Cố gắng tìm hết lỗi của phần mềm mà không đáp ứng được nhu cầu của sản phẩm thì khi đưa ra thị trường cũng không có khách hàng sử dụng.
0 Comments:
Đăng nhận xét