Nội dung bài học
- 1. Kiểm thử chỉ giúp phát hiện lỗi
- 2. Kiểm thử phải có sàng lọc
- 3. Kiểm thử sớm giúp tiết kiệm thời gian, ngân sách
- 4. Tester nên tập trung tìm các cụm lỗi
- 5. Tester cần đề phòng “nghịch lý thuốc trừ sâu”
- 6. Tester phải kiểm thử đúng kỹ thuật, đúng thời điểm
- 7. Cái bẫy khó lường của kiểm thử
1. Kiểm thử chỉ giúp phát hiện lỗi
Nhiệm vụ, vai trò của việc test là chỉ ra các lỗi đang có trong phần mềm. Tuy vậy, kiểm thử không phải là bằng chứng cho việc sản phẩm không có lỗi. Software testing chỉ giúp hạn chế lỗi tiềm ẩn chứ không thể triệt tiêu xác suất phát sinh lỗi.
2. Kiểm thử phải có sàng lọc
Mỗi test case là một tổ hợp input (dữ liệu đầu vào) và precondition (điều kiện tiên quyết) khác nhau. Chỉ cần thay đổi input hoặc precondition là dự án đã có thêm một test case mới hoàn toàn. Do vậy, dù cần thiết hay không, tester vẫn có thể tạo ra rất nhiều test case khi kiểm thử.
Với phần mềm có kiến trúc phức tạp, lượng test case có thể lên đến hàng nghìn hoặc nhiều hơn. Vì rất tốn thời gian và tài nguyên, kiểm thử viên không nên và không thể test toàn bộ chúng. Thay vào đó, tester nên phân tích rủi ro, mức ưu tiên và kỹ thuật kiểm thử của test case. Bước tiếp theo là giới hạn số lượng test case để ước tính chính xác quy mô test.
3. Kiểm thử sớm giúp tiết kiệm thời gian, ngân sách
Trong vòng đời phát triển phần mềm, việc thực hiện kiểm thử nên được bắt đầu càng sớm càng tốt. Nhờ vậy, chúng ta sẽ sớm tìm và vá được lỗi, giảm bớt gánh nặng thời gian lẫn tiền bạc. Việc thực hiện test từ sớm còn được gọi là Shift-left Testing. Cái tên này ám chỉ hướng di chuyển sang trái của việc kiểm thử trên dòng thời gian dự án.
4. Tester nên tập trung tìm các cụm lỗi
Trên thực tế, một số module (mô-đun) thường chứa nhiều lỗi xuất hiện trong lúc test trước khi phát hành. Một vài module khác còn chịu trách nhiệm cho hầu hết các lỗi xuất hiện khi vận hành sản phẩm. Những module này được xem là các cụm lỗi. Khi thấy một hạng mục phần mềm có vài lỗi, tester nên kiểm thử thêm các phần có liên quan.
Bên cạnh đó, kiểm thử viên cũng nên test những hạng mục khác ở gần nó để có thể tìm ra thêm lỗi. Tuy nhiên, tester không được bỏ qua các phần còn lại của sản phẩm hay những lỗi tiềm ẩn khác. Ngoài ra, việc phân tích rủi ro cũng dựa trên số cụm lỗi mà bạn dự đoán hay tìm được.
5. Tester cần đề phòng “nghịch lý thuốc trừ sâu”
Giống như thuốc trừ sâu, test case sẽ không tìm ra lỗi mới khi đã bị dùng quá nhiều lần. Đây chính là “nghịch lý thuốc trừ sâu” – khi thuốc trừ sâu không diệt được sâu bọ. Để phát hiện các lỗi mới, tester phải cập nhật thường xuyên test case cũ và viết test case mới. Tuy nhiên, đôi khi nghịch lý này có thể cung cấp những kết quả có lợi cho việc kiểm thử. Ví dụ: khi chạy automated regression testing (kiểm thử hồi quy tự động) thì lỗi hồi quy tương đối ít.
6. Tester phải kiểm thử đúng kỹ thuật, đúng thời điểm
Mỗi ngữ cảnh kiểm thử sẽ có quy trình, kỹ thuật kiểm thử tương ứng. Do đó, tester phải xem xét ngữ cảnh khi test để quyết định chính xác cách thực hiện kiểm thử. Ví dụ: phần mềm diệt virus sẽ cần kỹ thuật test mà ứng dụng vẽ trên điện thoại không cần.
7. Cái bẫy khó lường của kiểm thử
Nhiều người cho rằng đã test thì phải dùng mọi test case có thể để không bỏ sót lỗi. Đây là quan điểm hoàn toàn sai lầm. Hai nguyên tắc đầu tiên đã chứng minh rằng tester không thể và không nên làm điều đó.
Hơn nữa, kiểm thử sẽ trở nên vô nghĩa nếu phần mềm không thể vận hành được như yêu cầu. Thành công của dự án phụ thuộc nhiều tiêu chí khác nhau chứ không phải vá hết lỗi là được. Dù không có lỗi nhưng nếu sản phẩm không phù hợp với khách hàng thì nó là một thất bại.
Anh Tester đã chia sẻ đến với bạn 7 nguyên tắc trong kiểm thử phần mềm, hy vọng bạn hiểu được và áp dụng thành công nhé !!!
Zalo
Anh Tester
facebook.com/anhtester
Đường dẫu khó chân vẫn cần bước đi
Đời dẫu khổ tâm vẫn cần nghĩ thấu