7 Nguyên tắc kiểm thử phần mềm, một cách nhìn khác (phần 1)

Nếu bạn là một QC hoặc là một người sắp làm QC, một trong những lý thuyết mà bắt buộc bạn phải biết đó là 7 nguyên tắc kiểm thử phần mềm. 7 nguyên tắc này là kim chỉ nam cho rất nhiều các lý thuyết khác của việc kiểm thử phần mềm. Tuy nhiên, có rất nhiều góc nhìn về 7 nguyên tắc này tuỳ theo từng kiểm thử viên, Hãy cùng, tìm hiểu với IT Learn về 7 nguyên tắc kiểm thử phần mềm này nhé.

1. Testing shows the presence of defects, not their absence (Kiểm thử chứng tỏ phần mềm có lỗi nhưng không chứng tỏ nó có không có lỗi)

Không có phần mềm nào là không có lỗi và quá trình kiểm thử chính là việc hạn chế việc xuất hiện lỗi của sản phẩm phần mềm trong quá trình sử dụng thực tế. Cho dù kết thúc quá trình kiểm thử và trong quá trình sử dụng, đội ngũ kiểm thử và người dùng không phát hiện thêm lỗi nữa thì cũng không thể cam đoan chắc chắn là sản phẩm đó không còn bất kỳ lỗi tiềm ẩn nào. Một số lỗi trong sản phẩm phần mềm chỉ có thể xẩy ra trong một hoàn cảnh đặc biệt và có thể sản phẩm chưa rơi vào trạng thái đó.

Trong thực tết có một số trường hợp xẩy ra mà bạn có thể áp dụng nguyên tắc này

• Nêu bạn bạn là QC và được hỏi về việc kiểm thử để sản phẩm không có lỗi, hãy thẳng thắn trả lời là điều đó không thể xẩy ra.
• Nếu PM (Project manager) hoặc PO (Product owner) yêu cầu bạn cam kết một sản phẩm không có lỗi, hãy từ chối và đưa ra cam kết hợp lý hơn. Ví dụ: sản phẩm sau delvier sẽ không còn lỗi nghiêm trọng (Từ mức high) trở lên trong điều kiện sử dụng thông thường.

2. Exhaustive testing is impossible (Kiểm thử mọi thứ là không thể)

Kiểm thử mọi trường hợp có thể xẩy ra với một phần mềm thì sẽ rất tốn thời gian, công sức và tiền bạc. Việc của kiểm thử viên không phải là căng sức ra để kiểm thử toàn bộ các tổ hợp đầu vào cũng như đầu ra thì cần chú trọng hơn vào việc phân tích nguy cơ, phân tích kỹ thuật test cần sử dụng, phân tích data test cần dùng … để bắt được nhiều lỗi hơn và hiệu quả hơn.

Nguyên tắc này còn được áp dụng khi thời gian kiểm thử bị rút ngắn và team QC muốn tập trung nguồn lực vào thực hiện các phần quan trọng hơn của hệ thống. Lúc đó, test lead sẽ cần phân tích tình hình lỗi hiện tại và đưa ra các quyết định xem cần ưu tiên kiểm thử phần nào trước, tính năng nào trước…

3. Early testing saves time and money (Kiểm thử từ sớm tiết kiệm thời gian và tiền bạc)

Việc kiểm thử sớm luôn mang lại lợi ích to lớn.

• Nếu một khách hàng có ý tưởng về một sản phẩm phần mềm và ý tưởng này có lỗi về mặt nghiệp vụ, lỗi này không được phát hiện và khách hàng đó vẫn tiếp tục phát triển phần mềm dựa trên nó. Mãi đến khi sản phẩm được đưa ra ngoài thị trường mới phát hiện ra lỗi. Lúc này việc khắc phục lỗi đó sẽ rất phiền toái vì nhiều khách hàng đã sử dụng sản phẩm. Ngoài việc tiêu tốn về tiền bạc hoặc công sức thì còn ảnh hưởng về uy tín của công ty đó.
• Giả sử lỗi đó được phát hiện sớm, thì việc khắc phục lỗi đó đôi khi chỉ là sửa lại một vài dòng văn bản, sẽ ít tốn kém hơn rất nhiều

Việc phát hiện lỗi sớm bằng cả phương pháp kiểm thử tĩnh (Static test) và kiểm thử động (Dynamic test) sẽ mang lại hiệu quả to lớn cho dự án. Việc đẩy sớm quá trình kiểm thử còn được gọi là “Shift left”, đẩy quá trình kiểm thử hoặc các hoạt động có mặt của QC càng sớm càng tốt trong quy trình phát triển phần mềm

Nguồn ISTQB Foundation

(còn tiếp)