Có thể thấy rằng, qua bài Kiểm thử phần mềm có cần thiết? – Girls Can Code. Kiểm thử đã giúp tìm ra những lỗi ngay trong quá trình phát triển và nâng cao chất lượng phần mềm. Tuy nhiên, câu hỏi đặt ra là làm sao để biết khi nào hoàn thành việc test? Chúng ta có những lựa chọn sau. Test tất cả mọi thứ, không test gì hoặc là test một vài phần của phần mềm. Trong nhiều trường hợp có lẽ “tất cả phải mọi cần phải được test”. Chúng ta không muốn sử dụng một phần mềm khi chưa hoàn tất các giai phát triển, bao gồm testing. Tuy nhiên, chúng ta cần phải xem xét kĩ lưỡng test tất cả mọi thứ và khi nào hoàn thành việc testing.
Overload trong testing
Hãy nhìn vào một ví dụ dưới đây:
Hãy lấy một ví dụ đơn giản về một hệ thống có 20 màn hình. Mỗi màn hình sẽ có 4 menu, mỗi menu sẽ có 3 option. Trung bình sẽ có khoảng 10 trường trên mỗi màn hình, có 2 kiểu input dữ liệu là date và number, như vậy có khoảng 100 trường hợp có thể xảy ra.
Vậy bài toán tính tổng số lần thử nghiệm sẽ là khoảng:
20 x 4 x 3 x 10 x 2 x 100 = 480,000 testes
Nếu trung bình mỗi một test chúng ta cần 1 giây. Vậy thì, để hoàn thành test chúng ta cần khoảng 8000 phút, tương đương với 133 giờ và tương đương với 17.7 ngày (con số này chưa tính đến những lần phải retest hoặc có bug và cần verify trong quá trình thực hiện test)
Nếu trung bình mỗi test cần 10 giây, chúng ta cần tới 34 tuần để hoàn thành.
Nếu trung bình mỗi test cần 1 phút, chúng ta cần 4 năm để hoàn thành.
….
Có thể thấy, qua ví dụ nhỏ này, số lượng các trường hợp cần test tăng lên theo cấp số nhân.
Số lượng này có thể tăng theo cấp số mũ nếu nhìn vào những ví dụ thực tế hơn. Ví dụ, các trường hợp test ở các môi trường khác nhau. Dẫn tới, mất rất nhiều thời gian để thực hiện hết toàn bộ tất cả các trường hợp có thể xảy ra.
Khi nào hoàn thành việc kiểm thử?
Có thể xác định được khi hoàn thành việc kiểm thử là khi các tester đã hoàn thành kiểm thử các trường hợp tiên quyết trong một khoảng thời gian cho phép. Điều đó có nghĩa là khi bạn tự tin rằng hệ thống của bạn có thể hoạt động đúng các chức năng của nó.
Ví dụ, bạn đang phát triển hệ thống hoàn tiền cho khách hàng khi đơn đặt hàng bị huỷ. Bạn cần tự tin rằng, phần mềm của bạn có thể hoàn tiền cho khách trong các trường hợp như: hàng bị huỷ bởi người giao hàng, không có người giao hàng nhận đơn, khách hàng đợi quá lâu,… Cần đảm bảo được phần mềm cần ít nhất thực hiện được đúng chức năng chính.
Cần thực hiện bao nhiêu kiểm thử là đủ?
Để xác định được bao nhiêu kiểm thử là đủ sẽ phụ thuộc rất nhiều vào những rủi ro của hệ thống. Có thể nói đến những rủi ro như sau:
- Rủi do bỏ sót những lỗi quan trọng của hệ thống
- Rủi do phát sinh thêm nhiều chi phí
- Rủi ro có thể releasing một số phần chưa được test hoặc under-test
- Rủi ro nguy cơ mất uy tín và thị phần
- Rủi ro bỏ lỡ mất thị trường
- Rủi ro về kiểm thử quá mức, không hiệu quả
- …
Có thể thấy, thời gian giành cho việc kiểm thử luôn luôn có giới hạn. Từ những rủi do có thể gặp phải ở trên, tester nên xác định được:
- Những phần nên test trước
- Những phần nên được kiểm tra nhiều nhất
- Đưa ra những chiến lược để test được từng phần hiệu quả nhất
- Những phần nào không nên giành quá nhiều thời gian trong thời điểm hiện tại
- Phân bổ thời gian hợp lý theo thự tự ưu tiên
Như vậy, việc thực hiện đánh giá rủi ro cần được thực hiện để việc đảm bảo chất lượng đạt được hiệu quả tốt. Đảm bảo chất lượng là để phòng tránh rủi ro và giảm thiểu lỗi xuống mức thấp nhất có thể. Tuy nhiên, do giới hạn về ngân sách, thời gian và trong quá trình kiểm thử, chúng ta cần quyết định và có chiến lược test để đạt hiệu quả tốt nhất.
Prioritise tests
so that,
whenever you stop testing,
you have done the best testing
in the time available.