Blog, Công nghệ thông tin, Quality Assurance / Control
7 Nguyên tắc Kiểm thử Phần mềm (TESTING.VN)
Nguồn gốc của những Nguyên tắc Kiểm thử Phần mềm này
Những nguyên tắc kiểm thử này đã được đề xuất hơn 50 năm qua và nó cung cấp cho chúng ta những hướng dẫn chung về kiểm thử trong mọi lĩnh vực, bao gồm kiểm thử phần mềm. Nó giúp chúng ta hiểu được lý do đằng sau cách chúng ta áp dụng các hoạt động kiểm thử phần mềm. Các mô hình phát triển phần mềm như Agile cũng được phát triển dựa trên các nguyên tắc cơ bản này.
1. Kiểm thử chỉ ra sự hiện diện của lỗi
Principle 1. Testing shows the presence of defects, not their absence
Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, testing is not a proof of correctness.
Nguyên tắc 1. Kiểm thử chỉ cho thấy sự hiện diện của lỗi
Kiểm thử có thể cho thấy rằng phần mềm 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ử 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, thậm chí khi kiểm thử không phát hiện lỗi nào thì việc kiểm thử đó cũng không thể để chứng minh rằng phần mềm không có lỗi (sạch lỗi – bug free).
2. Kiểm thử mọi thứ là không thể
Principle 2. Exhaustive testing is impossible
Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Rather than attempting to test exhaustively, risk analysis, test techniques, and priorities should be used to focus test efforts.
Nguyên tắc 2. Kiểm thử mọi thứ là bất khả thi
Kiểm thử mọi thứ (tổ hợp tất cả điều kiện và các giá trị nhập đầu vào) là không thể thực hiện được, ngoại trừ một số trường hợp bình thường. Ví dụ, với một chức năng hay màn hình nào đó chỉ có vài drop down hoặc checkbox thì chúng ta hoàn toàn có thể kiểm thử vét cạn mọi trường hợp trong vài giờ. Thay vì kiểm thử toàn bộ, chúng ta nên dựa vào kết quả phân tích rủi ro, áp dụng các kỹ thuật kiểm thử, và độ ưu tiên để tập trung kiểm thử những nơi cần thiết sẽ hiệu quả hơn.
3. Kiểm thử sớm tiết kiệm thời gian và tiền bạc
Principle 3. Early testing saves time and money
To find defects early, both static and dynamic test activities should be started as early as possible in the software development lifecycle. Early testing is sometimes referred to as shift left. Testing early in the software development lifecycle helps reduce or eliminate costly changes
Nguyên tắc 3. Kiểm thử sớm tiết kiệm thời gian và tiền bạc
Để tìm được lỗi (defect, bug) sớm thì trong quá trình phát triển (vòng đời phát triển) phần mềm/hệ thống, các hoạt động kiểm thử bao gồm kiểm thử tĩnh và kiểm thử động nên bắt đầu càng sớm càng tốt. Kiểm thử sớm đôi khi còn được gọi là shift left (chuyển dịch các hoạt động kiểm thử sang bên trái – giai đoạn sớm hơn – trong quá trình phát triển phần mềm). Trong chu kỳ phát triển phần mềm, việc kiểm thử sớm giúp giảm hoặc loại bỏ những thay đổi tốn kém về sau.
4. Lỗi gom thành nhóm
Principle 4. Defects cluster together
A small number of modules usually contains most of the defects discovered during pre-release testing, or is responsible for most of the operational failures. Predicted defect clusters, and the actual observed defect clusters in test or operation, are an important input into a risk analysis used to focus the test effort
Nguyên tắc 4. Lỗi tập trung theo cụm
Một số lượng nhỏ các mô-đun (cụm chức năng) thường chứa hầu hết lỗi được phát hiện trong quá trình kiểm thử phần mềm trước khi phát hành, đưa nó đến tay người dùng. Hoặc các mô-đun này gây ra phần lớn các hỏng hóc trong quá trình vận hành. Vì vậy, các cụm lỗi được dự đoán hay được quan sát thực tế trong quá trình kiểm thử hoặc vận hành là thông tin quan trọng để phân tích rủi ro. Từ đó giúp bạn tập trung kiểm thử một cách phù hợp dựa vào mật độ lỗi của các mô-đun (như đã đề cập ở Nguyên tắc 2 ở trên).
5. Đề phòng nghịch lý thuốc trừ sâu
Principle 5. Beware of the pesticide paradox
If the same tests are repeated over and over again, eventually these tests no longer find any new defects. To detect new defects, existing tests and test data may need changing, and new tests may need to be written. (Tests are no longer effective at finding defects, just as pesticides are no longer effective at killing insects after a while.) In some cases, such as automated regression testing, the pesticide paradox has a beneficial outcome, which is the relatively low number of regression defects.
Nguyên tắc 5. Coi chừng nghịch lý thuốc trừ sâu
Nếu một bộ test case (các trường hợp kiểm thử) được sử dụng lặp đi lặp lại nhiều lần, thì cuối cùng những test case này sẽ không giúp tìm thấy bất kỳ lỗi nào mới nào nữa. Để khắc phục “nghịch lý thuốc trừ sâu” này, nghĩa là để tiếp tục tìm được lỗi mới thì bộ test case và test data (bao gồm các giá trị nhập vào và kết quả mong đợi trong test case) cần phải được rà soát (review) và cập nhật (thay đổi hoặc thêm mới) thường xuyên. Bộ test case của bạn không còn hiệu quả trong việc tìm ra lỗi mới, cũng như thuốc trừ sâu không còn hiệu quả để tiêu diệt côn trùng sau một thời gian nếu sử dụng cùng liều lượng và loại thuốc. Tuy nhiên, trong một số trường hợp như kiểm thử tự động, thì nghịch lý thuốc trừ sâu lại có kết quả có lợi, đó là số lượng lỗi hồi qui (regression bugs) ở mức tương đối thấp.
Ghi chú: regression bug là lỗi do code mới gây ra. Xem <thêm regression bug> (sẽ cập nhật sau)
6. Kiểm thử phụ thuộc vào ngữ cảnh
Principle 6. Testing is context dependent
Testing is done differently in different contexts. For example, safety-critical industrial control software is tested differently from an e-commerce mobile app. As another example, testing in an Agile project is done differently than testing in a sequential software development lifecycle project.
Nguyên tắc 6. Kiểm thử theo các ngữ cảnh độc lập
Quá trình kiểm thử sẽ được thực hiện khác nhau trong các ngữ cảnh khác nhau. Ví dụ, một phần mềm kiểm soát trong công nghiệp cần tính an toàn cao (safety-critical) thì được kiểm thử khác với việc kiểm thử một trang thương mại điện tử. Một ví dụ khác nữa là việc kiểm thử các dự án trong mô hình Agile sẽ được thực hiện khác so với quá trình kiểm thử trong các dự án áp dụng mô hình tuần tự, như mô hình thác nước hoặc chữ V (V-model).
Và đó là lý do tại sao khi đi phỏng vấn các bạn hay gặp câu hỏi: Bạn hãy cho biết các điểm khác nhau giữa kiểm thử một ứng dụng web (Web applications) và một phần mềm được vài trên Windows (Desktop applications).
7. Quan niệm sai về phần mềm không có lỗi
Principle 7. Absence-of-errors is a fallacy
Some organizations expect that testers can run all possible tests and find all possible defects, but principles 2 and 1, respectively, tell us that this is impossible. Further, it is a fallacy (i.e., a mistaken belief) to expect that just finding and fixing a large number of defects will ensure the success of a system. For example, thoroughly testing all specified requirements and fixing all defects found could still produce a system that is difficult to use, that does not fulfill the users’ needs and expectations, or that is inferior compared to other competing systems.
Nguyên tắc 7. Không có lỗi là một niềm tin sai lầm
Việc phát hiện và sửa chữa lỗi sẽ không giúp được gì nếu hệ thống đó không thể dùng được, hoặc không đáp ứng được nhu cầu và sự mong đợi của người dùng.
Một số công ty mong đợi tester có thể thực hiện mọi trường hợp kiểm thử (test case) có thể có và tìm ra tất cả lỗi có thể xảy ra, nhưng như đã đề cập, nguyên tắc 2 và 1 cho chúng ta biết rằng điều này là không thể. Hơn nữa, thật là sai lầm (đây là một niềm tin sai lầm) khi kỳ vọng rằng chỉ cần tìm và sửa chữa một số lượng lớn lỗi (bug, defect) sẽ đảm bảo sự thành công của một hệ thống phần mềm.
Ví dụ: việc kiểm tra kỹ lưỡng tất cả các yêu cầu cụ thể và sửa chữa tất cả những lỗi phát hiện được vẫn có thể có trường hợp phần mềm được làm ra khó sử dụng, không đáp ứng được nhu cầu và mong đợi của người dùng hoặc nó kém hơn so với phần mềm của các đối thủ cạnh tranh.
Cám ơn các bạn đã đọc bài này.
Nguồn: istqb.org | Biên dịch và giải thích tvn
