7 Nguyên tắc cơ bản của Kiểm Thử Phần Mềm

Kiểm thử phần mềm là quá trình vận hành một chương trình nhằm tìm ra lỗi của nó. Một phần mềm được gọi là hoạt động tốt nhất, nó cần phải sạch lỗi. Và nếu kiểm thử phần mềm được thực hiện thành công, thì các lỗi không còn xuất hiện. Tuy nhiên, kiểm thử cũng như các công việc khác cũng có những nguyên tắc riêng của nó. Trong kiểm thử có 7 nguyên tắc kiểm thử quan trọng mà bạn cần tuân theo.

Kiểm thử chứng minh sự hiện diện của lỗi
Kiểm thử toàn bộ là không khả thi
Kiểm thử càng sớm càng tốt
Lỗi thường phân bổ tập trung
Nghịch lý thuốc trừ sâu
Kiểm thử phụ thuộc vào ngữ cảnh
Quan niệm sai lầm về việc “hết lỗi”

#1: Kiểm thử phần mềm chứng minh sự hiện diện của lỗi

Bằng việc kiểm thử, chúng ta có thể làm giảm lượng bugs khi áp dụng nhiều phương pháp kiểm thử lên phần mềm. Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thể chứng minh rằng phần mềm không có lỗi. Do đó, điều quan trọng là chúng ta phải thiết kế các trường hợp kiểm thử (test case) sao cho có thể tìm được càng nhiều lỗi càng tốt.

#2: Kiểm thử toàn bộ là không khả thi

Nguyên tắc này nói rằng kiểm tra mọi thứ trong phần mềm một cách trọn vẹn là không thể. Đúng vậy, 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. Các sản phẩm phần mềm hiện nay cực kỳ đa dạng và phức tạp, được phát triển trên nhiều nền tảng, thêm vào đó, ngày càng có nhiều công nghệ mới, khả năng kết nối dữ liệu lớn… khiến việc kiểm thử toàn bộ gần như là không thể. Thay vì cố gắng kiểm thử toàn bộ, hãy 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 hoặc gặp nhiều nguy cơ hơn.

#3: Kiểm thử càng sớm càng tốt

Nguyên tắc này yêu cầu bắt đầu thử nghiệm phần mềm trong giai đoạn đầu của vòng đời phát triển phần mềm. Vậy ở bước 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 bước đầu tiên như nghiên cứu yêu cầu (requirement) hay design. Phát hiện lỗi càng muộn, chi phí bỏ ra để xử lý càng cao. Vì vậy, việcthay đổi yêu cầu không đúng từ sớm sẽ khiến tốn ít chi phí để thay đổi tính năng hơn

#4: Lỗi thường được phân bố tập trung

Thông thường, phần lớn lỗi tập trung vào những module, thành phần chức năng chính của hệ thống. Điều này cũng thuận theo nguyên lý Pareto: 80% số lượng lỗi được tìm thấy trong 20% tính năng của hệ thống. Nếu bạn thành công xác định được điều này, bạn sẽ tập trung vào tìm kiếm lỗi quanh khu vực được xác định. Nó được coi là một trong những cách hiệu quả nhất để thực hiện kiểm tra hiệu quả

#5: Nghịch lý thuốc trừ sau (pesticide paradox)

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, khi lặp đi lặp lại một test case, thì xác suất tìm được lỗi là rất thấp. Nguyên nhân là hệ thống hoàn thiện hơn, lỗi tìm thấy đã được sửa theo test case cũ. Để 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 (regression test).

Thêm vào đó, QA/ Tester cũng không nên phụ thuộc quá nhiều vào các kỹ thuật test sẵn có. Bạn cần liên tục cải tiến các phương pháp có sẵn để làm việc kiểm thử hiệu quả hơn.

#6: Kiểm thử phần mềm phụ thuộc vào ngữ cảnh

Kiểm thử phụ thuộc vào ngữ cảnh, về cơ bản có nghĩa là cách bạn kiểm tra trang web thương mại điện tử sẽ khác với cách bạn kiểm tra quảng cáo ngoài ứng dụng. Tất cả các phần mềm được phát triển không giống nhau. Chiến lược để kiểm thử nên khác nhau và phụ thộc vào chính ứng dụng đó. Chiến lược cho test web application phải khác với ứng dụng android mobile.

#7: Quan niệm sai lầm về việc “hết lỗi”

Có thể phần mềm không có lỗi 99% vẫn không sử dụng được. Đây có thể là trường hợp nếu hệ thống được kiểm tra kỹ lưỡng cho các yêu cầu sai. Kiểm thử phần mềm không chỉ đơn thuần là tìm lỗi, mà còn để kiểm tra xem phần mềm có đáp ứng nhu cầu kinh doanh không.

Các nguyên tắc kiểm thử giúp tạo ra một chiến lược kiểm thử rõ ràng và tạo ra những trường hợp kiểm thử sát sao, dễ bắt được bug. Vì vậy, việc nguyên tắc kiểm thử không có tính ứng dụng thực tế là sai lầm.

Ngoài 7 nguyên tắc trên, còn một số nguyên tắc khác cũng đáng được quan tâm như:

Kiểm thử cần được làm bởi một bên độc lập: Kiểm thử không được thực thi bởi chính người hay đội làm ra sản phẩm đó vì họ thường “bảo vệ tính đúng đắn” của sản phẩm họ làm ra. Nói cách khác, kiểm thử cần thể hiện tính khách quan trong việc đánh giá chất lượng sản phẩm.
Kiểm thần cần được thực thi từ người có năng lực: Việc kiểm thử đòi hỏi sự sáng tạo cũng như tinh thần trách nhiệm cao do đó việc kiểm thử cần được thực thi bởi người có năng lực trong việc thiết kế, phân tích, thực thi các trường hợp kiểm thử. Nói cách khác, kiểm thử không phải là công việc thứ cấp và giao cho ai làm cũng được.
Kiểm thử cả input đầu vào đúng và sai: Chương trình phải đưa ra thông báo đúng khi input đầu vào không hợp lệ và chạy đúng khi input đầu vào hợp lệ.
Sản phẩm cần phải được “giữ nguyên hiện trạng”: Sản phẩm không được phép chỉnh sửa thay đổi trong suốt quá trìn thực thi các trường hợp kiểm thử nhằm đảm bảo kết quả kiểm thử được nhất quán và chính xác.
Cung cấp kết quả mong đợi (nếu có thể): Kết quả mong đợi là một phần không thể thiếu trong hoạt động kiểm thử. Việc biết được kết quả mong đợi sẽ giúp chúng ta đánh giá được kết quả kiểm thử.

Kết luận

Kiểm thử không phải là một hoạt động riêng lẻ mà là một chuỗi các hoạt động phức tạp có quan hệ với nhau, bổ sung cho nhau. Để đơn giản hóa công việc đó đồng thời nhìn nhận việc kiểm thử bao quát hơn, đánh giá hiệu quả của quá trình kiểm thử, việc ứng dụng 7 nguyên tắc kiểm thử kể trên sẽ cực kỳ có ích.

Bài viết được tham khảo từ nguồn:

FOUNDATIONS OF SOFTWARE TESTING
-- Nguồn Internet--