Trong kiểm thử phần mềm, có 7 nguyên tắc mà các tester cần biết và nắm rõ. Hiểu và ứng dụng được những nguyên tắc này trong kiểm thử là rất quan trọng vì nó có thể giúp chung ta tiết kiệm thời gian và tối ưu hóa hiệu suất. Mà là nguyên tắc thì bất kỳ tester nào cũng cần phải tuân theo. Cùng xem 7 nguyên tắc Kiểm thử Phần mềm trong bài viết này nhé!

Nguyên lý 1: Kiểm thử cho thấy sự hiện diện của lỗi

Kiểm thử có thể cho thấy lỗi đang hiện diện, nhưng không thể chứng minh rằng không có lỗi.

Khi sản phẩm được đưa vào môi trường sử dụng thực tế, người dùng cuối cùng hoàn toàn có thể thấy nhiều lỗi mà tester không tìm thấy trong quá trình kiểm thử. Vì vậy, kiểm thử chứng minh được sản phẩm có lỗi nhưng không thể chứng minh rằng sản phẩm đó không còn lỗi. Điều này có nghĩa là, lỗi luôn xuất hiện trong phần mềm ngay cả khi tester không tìm thấy lỗi, nhưng cũng không đồng nghĩa với việc phần mềm đã đúng hoàn toàn.

Ví dụ: Tester tìm ra lỗi trong phần mềm bán hàng ở chức năng thêm sản phẩm vào giỏ hàng. Tức là có lỗi ở đây nhưng không ai chắc chắn rằng không có lỗi ở chức năng xóa sản phẩm khỏi giỏ hàng.

Nguyên lý 2: Kiểm thử toàn bộ là không thể

Kiểm thử mọi thứ là không khả thi, ngoại trừ một số trường hợp quá đơn giản. Rất khó để kiểm tra toàn bộ các module cũng như các tính năng, kết hợp với đầu vào và đầu ra trong suốt quá trình kiểm tra. 

Thay vì kiểm thử “vét cạn”, chúng ta nên tập trung vào phân tích, xác định mức độ quan trọng và độ ưu tiên của các module để kiểm thử những phần cần thiết hơn. 

Ví dụ: Một form nhập thông tin sản phẩm có textbox giá cho phép nhập từ 1 -> 1.000.000.000. 

Nếu để kiểm thử nhập liệu cho textbox này ta phải kiểm thử 1 tỷ lần, mỗi thao tác nhập cho là 1 giây, phép toán kiểm tra nhập liệu là 0.1 giây nữa thì ta phải mất rất rất nhiều thời gian để thực thi nó. Ngoài ra, còn rất nhiều đối tượng khác cho nên kiểm thử toàn bộ là không thể làm được. 

Nguyên lý 3: Kiểm thử sớm tiết kiệm thời gian và tiền bạc

Việc kiểm thử cần được thực hiện càng sớm càng tốt trong vòng đời phát triển phần mềm. Vậy kiểm thử khi nào thì được coi là sớm? Nguyên tắc này cho thấy ta cần phát hiện bug ngay từ các giai đoạn đầu tiên như phân tích & thu thập yêu cầu (requirement). 

Phát hiện lỗi càng muộn, chi phí bỏ ra để xử lý càng lớn. Vì vậy, việc chỉnh sửa lại yêu cầu không đúng từ sớm sẽ tốn ít chi phí để các giai đoạn sau phát triển đúng hướng và nhanh chóng hơn.

Ví dụ: Cho một phần mềm quản lý cửa hàng. Việc thu nhập yêu cầu không chính xác, nhưng không phát hiện và chỉnh sửa kịp thời. Sau đó, toàn bộ giai đoạn tiếp theo trong quá trình phát triển (desgin, build,…) vẫn làm theo những yêu cầu sai đó. Cuối cùng, sản phẩm đến tay khách hàng không được chấp nhận cho dù toàn bộ giai đoạn phát triển phía sau làm đúng nhưng lại theo yêu cầu đã sai ngay từ đầu.

Nguyên lý 4: Phân cụm lỗi cùng nhau

Nguyên lý về phân bố lỗi chỉ ra rằng, chỉ một số ít module chứa phần lớn số lỗi phát hiện được trong giai đoạn kiểm thử trước khi phát hành hoặc chịu trách nhiệm về hầu hết các hỏng hóc trong quá trình hoạt động. Những module này thường là những thành phần, chức năng chính của hệ thống. 

Điều này cũng đúng theo nguyên lý Pareto: 80 – 20. Nghĩa là 80% số lỗi tìm thấy ở chỉ 20% module. Chúng ta có thể xác định được những module có tính rủi ro và nhiều lỗi như vậy giúp tập trung tìm kiếm lỗi nhanh và hiệu quả hơn. 

Ví dụ: Ứng dụng máy tính đang bị lỗi ở phép tính cộng, thì có thể phép tính trừ, nhân chia cũng đang bị lỗi.

Nguyên lý 5: Nghịch lý “thuốc trừ sâu”

Trong trồng trọt, nếu người nông dân sử dụng lặp lại một liều trừ sâu, các loại sâu bệnh sẽ dần dần thích nghi và trở nên “nhờn” với loại thuốc trừ sâu đó. Tương tự với kiểm thử phần mềm, nếu cùng một tập các trường hợp kiểm thử được lặp đi lặp lại, thì xác suất tìm được lỗi là rất thấp.

Để xử lý hiệu ứng “thuốc trừ sâu” này, test case cần được thường xuyên xem lại và chỉnh sửa, thêm nhiều test case mới để tìm lỗi mới.

Nguyên lý 6: Kiểm thử phụ thuộc vào bối cảnh

Kiểm thử được thực hiện khác nhau trong các bối cảnh khác nhau vì các phần mềm đều được phát triển theo cách khác nhau. Và việc áp dụng chung một “cách giải” là sai lầm. Chúng ta cần sử dụng cách tiếp cận khác nhau, phương thức, kỹ thuật test khác nhau, loại test phụ thuộc vào loại phần mềm/ứng dụng/website.

Nguyên lý 7: Ảo tưởng về sự vắng mặt của lỗi

Từ nguyên lý 1 và nguyên lý 2 cho thấy việc thực hiện tất cả các bước kiểm thử để phát hiện ra mọi lỗi là điều không thể. Hơn nữa, sẽ thật sai lầm khi kỳ vọng việc tìm và sửa một lượng lỗi lớn sẽ đảm bảo sự thành công của hệ thống. 

Kiểm thử không chỉ để tìm ra lỗi, mà còn để kiểm tra xem phần mềm có đáp ứng được đúng nhu cầu hay không. Vì vậy, để kiểm thử hiệu quả và “fix đúng bug”, tester cần tuân thủ 7 nguyên tắc trên. Chúc các bạn thành công!

Bộ môn Ứng dụng phần mềm
Trường Cao đẳng FPT Mạng cá cược bóng đá cơ sở Hà Nội