Trong kiểm thử phần mềm có 7 nguyên tắc kiểm thử. Những nguyên tắc chính là những quy định hoặc là luật mà chúng ta phải tuân theo. Rất nhiều người làm việc lâu năm trong lĩnh vực kiểm thử phần mềm nhưng vẫn không biết đến những nguyên tắc quan trọng này, và họ đã tốn rất nhiều thời gian, công sức truy lùng bug ẩn.
Đối với các bạn sinh viên, hoặc những bạn bước đầu đang tìm hiểu về kiểm thử phần mềm, hãy nhớ lấy 7 nguyên tắc quan trọng này, chúng cũng có thể được xem là kim chỉ nam cho bạn và theo suốt bạn trong quãng đời làm kiểm thử phần mềm.
1st Principle: Testing Shows Defects Are Present In The Software
(Kiểm thử đưa ra lỗi)
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. Kiểm thử được thực hiện bằng những kĩ thuật khác nhau. Kiểm thử làm giảm xác suất lỗi chưa tìm thấy vẫn còn trong phần mềm, ngay cả khi đã kiểm thử nghiêm ngặt phần mềm vẫn có thể còn lỗi. Vì vậy chúng ta phải tìm được càng nhiều lỗi càng tốt.
2nd Principle: Exhaustive Testing Is Not Practically Possible
(Kiểm thử toàn bộ là không thể)
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ể. Trừ khi sản phẩm được kiểm thử quá đơn giản cũng như không có nhiều giá trị đầu vào (chẳng hạn như “Hello World”) thì việc chứng minh sản phẩm không còn bug cho dù có kiểm thử nhiều đến đâu là không khả thi.
3rd Principle: Start Testing In Early Stage of SDLC
(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. Các hoạt động kiểm thử phần mềm từ giai đoạn đầu sẽ giúp phát hiện bug sớm hơn. Nó cho phép chuyển giao phần mềm theo yêu cầu đúng thời gian với chất lượng dự kiến.
Ngoài ra ai làm phần mềm cũng biết được rằng việc phát hiện lỗi càng trễ bao nhiêu thì chi phí để sửa lỗi càng cao bấy nhiêu.
4th Principle: Defects Clustering
(Lỗi thường được phân bố tập trung)
Thông thường, 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. Nếu 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ả. Đ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.
5th Principle: The Pesticide Paradox
(Nghịch lý thuốc trừ sâu)
Việc sử dụng lặp đi lặp lại cùng một loại thuốc trừ sâu để diệt côn trùng sẽ theo thời gian dẫn đến việc côn trùng phát triển tính kháng thuốc trừ sâu. Do đó, dùng thuốc trừ sâu để tiêu diệt côn trùng sẽ không còn hiệu quả. Áp dụng tương tự trong kiểm thử phần mềm. Nếu một bộ test cases được thực hiện lặp đi lặp lại nhiều lần sẽ không còn ý nghĩa trong việc phát hiện ra các lỗi mới. Để khắc phục điều này, các test cases cần phải được reviewed và sửa đổi thường xuyên, thêm các test cases mới để giúp tìm ra nhiều lỗi hơn. Testers phải liên tục cải thiện các phương pháp hiện có để kiểm thử được hiệu quả hơn. Nhưng ngay cả sau quá trình kiểm thử tốn nhiều công sức và thời gian, bạn không thể khẳng định sản phẩm của mình không có lỗi.
6th Principle: Testing is dependent on context
(Kiểm thử 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. Bạn có thể sử dụng một cách tiếp cận, phương pháp, kỹ thuật và loại kiểm thử khác nhau tùy thuộc vào loại ứng dụng. Đối với kiểm thử ví dụ, bất kỳ hệ thống POS nào tại cửa hàng bán lẻ sẽ khác với thử nghiệm máy ATM.
7th Principle: Absence of errors – fallacy
(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. Sự vắng mặt của Lỗi là sai lầm, tức là việc tìm và sửa lỗi không giúp ích gì nếu việc xây dựng hệ thống không sử dụng được và không đáp ứng nhu cầu và yêu cầu của người dùng.
Kết luận
Kiểm thử không phải chỉ đơn thuần là một hoạt động riêng lẻ mà là một loạt các hoạt động liên quan và bổ sung cho nhau và phức tạp.
Nguồn: itmscoaching
