1. Kiểm thử chỉ ra được lỗi của phần mềm

Đây là nguyên tắc đầu tiên và cũng là nguyên tắc cơ bản nhất trong khâu kiểm thử phần mềm. Mỗi một phần mềm sau khi đã được xây dựng hoàn chỉnh sơ bộ và bước vào giai đoạn kiểm thử đều không thể tránh được lỗi. Phần mềm càng phức tạp, càng nhiều chức năng thì lại càng có nhiều lỗi tiềm ẩn.

Việc kiểm thử nhằm mục đích phát hiện ra những lỗi tiềm ẩn trong code hoặc các tính năng của phần mềm. Thậm chí có đôi khi trong những lần kiểm thử đầu tiên bạn sẽ không thể phát hiện ra lỗi nào từ phần mềm. Tuy nhiên, nếu chỉ như vậy mà bạn đã vội vàng khẳng định phần mềm không tồn tại lỗi nào thì bạn đã quá vội vàng.

Dân lập trình viên đều hiểu rõ một quy tắc đó là bất cứ phần mềm nào khi mới hoàn thành cũng sẽ tồn tại lỗi. Nếu kiểm thử chưa tìm ra lỗi thì chứng tỏ đó là lỗi ẩn rất nghiêm trọng.

2. Không thể kiểm thử tất cả mọi thứ

Đối với những phần mềm nhỏ chỉ có 1 hoặc một vài tính năng, để kiểm tra hết tất cả mọi trường hợp cũng cần tốn kém không ít thời gian. Mỗi tổ hợp các điều kiện và các loại giá trị đầu vào có thể được hoàn đổi linh hoạt để tạo ra rất nhiều trường hợp kiểm thử. Vì vậy khó có thể kiểm tra được hết tất cả các trường hợp. Chưa kể đến những phần mềm phức tạp hơn và có nhiều tính năng hơn.

Chính vì thế mà những người tester thường không cố gắng kiểm thử hết tất cả các trường hợp. Thay vào đó, họ ưu tiên áp dụng các kỹ thuật kiểm thử, tiến hành kiểm thử những trường hợp điển hình nhất và có mức độ rủi ro cao nhất. Như vậy sẽ hiệu quả hơn so với việc dành ra rất nhiều thời gian để kiểm thử lần lượt từng trường hợp.

3. Kiểm thử sớm không chỉ hiệu quả mà còn tiết kiệm thời gian

Bạn hình dung như thế nào về công việc của một tester? Họ sẽ chờ đội ngũ lập trình viên hoàn thiện, bàn giao phần mềm rồi sau đó kiểm thử? Nếu làm như vậy sẽ phải mất rất nhiều thời gian và công sức để kiểm thử phần mềm. Thay vào đó, tester thường áp dụng nguyên tắc kiểm thử sớm để tiết kiệm thời gian và công sức.

Chẳng hạn một phần mềm có nhiều chức năng, tester có thể kiểm thử ngay lập tức một chức năng sau khi chức năng đó được hoàn thiện. Như vậy việc kiểm thử không chỉ hiệu quả hơn (vì họ chỉ cần tập trung vào kiểm thử một chức năng) mà còn giúp tiết kiệm thời gian, chi phí và cả công sức. Hơn nữa, nếu phát hiện ra bug (lỗi) thì có thể yêu cầu lập trình viên sửa ngay. Lúc này việc sửa lỗi sẽ thuận tiện hơn vì họ đang làm việc với tính năng đó.

4. Lỗi thường tập trung thành từng cụm

Lỗi không xuất hiện dàn trải trong toàn bộ các module mà thường xuất hiện thành từng cụm và thường có mối quan hệ với nhau. Mỗi module như vậy thường tập trùng hầu hết các lỗi nghiêm trọng có ảnh hưởng đến hoạt động của phần mềm và cần được nhanh chóng khắc phục trước khi phần mềm được phát hành chính thức.

Các module này thường là các module chứa chức năng chính hoặc nằm trong bộ khung của chương trình. Chúng cũng là những module mà người tester có thể dự đoán được rằng có nhiều khả năng xuất hiện lỗi. Tester có kinh nghiệm sau khi hiểu rõ luồng và các thức hoạt động của phần mềm thì có thể dự đoán được đâu là module có thể xảy ra lỗi nhiều nhất.

Thông qua công tác phân tích rủi ro, người tester sẽ tập trung kiểm thử những module có nhiều khả năng xuất hiện lỗi nhất để không mất quá nhiều thời gian kiểm thử một cách dàn trải mà không thực sự có hiệu quả.

5. Nghịch lý thuốc trừ sâu

Có thể bạn sẽ thắc mắc, nghịch lý thuốc trừ sâu thì có liên quan gì đến việc kiểm thử phần mềm. Tuy vậy, đây lại là nguyên tắc kiểm thử mà mọi tester cần nắm vững.

Cùng một loại thuốc trừ sâu, nếu sử dụng quá nhiều lần thì những con sâu bệnh sẽ sinh ra khả năng kháng thuốc và thuốc trừ sâu sẽ mất đi độ hiệu quả. Bây giờ bạn hãy tưởng tượng những test case mà bạn sử dụng cũng tương tự như thuốc trừ sâu vậy. Nếu bạn sử dụng lặp đi lặp lại quá nhiều lần thì chúng sẽ mất dần tác dụng và bạn sẽ không thể tìm ra được lỗi mới.

Nếu không ghi nhớ nguyên tắc này, kết quả kiểm thử của bạn có thể sẽ không chính xác. Để tránh điều này xảy ra, sau mỗi khoảng thời gian nhất định hoặc số lần sử dụng nhất định, bạn nên làm mới bộ test case. Hơn nữa bạn còn cần làm việc này khá thường xuyên.

Tuy nhiên, nguyên lý này không nên áp dụng với kiểm thử tự động. Thay vào đó, chính nghịch lý thuốc trừ sâu lại mang đến lợi ích cho bạn trong trường hợp này. Biểu hiện rõ ràng nhất đó là lỗi hồi quy sẽ được ghi nhận ở mức độ thấp hơn.

6. Dựa trên nhiều ngữ cảnh độc lập để kiểm thử

Ngữ cảnh được đề cập đến ở đây phải đặc biệt phù hợp với nội dung và chức năng của phần mềm. Hơn nữa, phần mềm có chức năng khác nhau phải được kiểm thử trong những ngữ cảnh độc lập với nhau. Chẳng hạn, một phần mềm ship hàng phải được kiểm tra trong ngữ cảnh khác biệt hoàn toàn với một phần mềm học tập. Hoặc khi bạn kiểm thử một phần mềm được cài đặt trên máy tính Windows thì cần một ngữ cảnh khác hoàn toàn so với khi kiểm thử một ứng dụng web.

7. Không có phần mềm nào là không có lỗi

Nguyên tắc này có phần tương tự như nguyên tắc đầu tiên và bổ sung thêm cho nguyên tắc đầu tiên.

Mục đích cuối cùng của việc kiểm thử và sửa lỗi đó là khiến cho mọi chức năng của phần mềm hoạt động một cách hoàn hảo, đáp ứng được nhu cầu của người dùng hoặc khách hàng khi sử dụng phần mềm. Bởi vậy việc kiểm thử và sửa lỗi phải mang lại hiệu quả tích cực trong thực tế chứ không phải trên lý thuyết.

Ai cũng mong muốn có thể kiểm thử và phát hiện ra mọi lỗi sai, tuy nhiên điều này hầu như không khả thi. Bạn không thể kiểm thử tất cả các trường hợp và cũng không thể phát hiện ra được tất cả các lỗi sai. Hơn nữa, kể cả bạn có thể tìm ra và sửa lại khá nhiều lỗi sai thì cũng không thể đảm bảo rằng phần mềm sẽ hoạt động hiệu quả, đáp ứng được những gì mà người sử dụng kỳ vọng.

Trên đây, bài viết đã giới thiệu đến bạn đọc 7 nguyên tắc kiểm thử phần mềm mà bất cứ một người tester nào cũng cần phải nắm vững. Bộ 7 nguyên tắc trên không chỉ được áp dụng trong kiểm thử phần mềm mà còn có thể mở rộng hơn, áp dụng trong nhiều lĩnh vực khác nữa.