Phân biệt các khái niệm dễ nhầm lẫn trong kiểm thử phần mềm

Tiếp theo bài viết: Các định nghĩa và thuật ngữ trong kiểm thử phần mềm ( Link bài viết: https://viblo.asia/p/cac-dinh-nghia-va-thuat-ngu-trong-kiem-thu-phan-mem-phan-1-MJyGjQlqvPB https://viblo.asia/p/cac-dinh-nghia-va-thuat-ngu-trong-kiem-thu-phan-mem-phan-2-rQOvPKNAkYj )

Bài viết này sẽ giới thiệu là làm rõ một số thuật ngữ thường gây nhầm lẫn, khó phân biệt trong lĩnh vực kiểm thử phần mềm (software testing):

1. Error - Fault - Failure (Defect/Bug):

Error:

• Lỗi xảy ra khi có tác động lên sản phẩm gây ra một kết quả sai lệch. (A human action that produces an incorrect result)

Fault:

• Lỗi xảy ra khi làm sai các step, process, hoặc chuẩn bị dữ liệu. (An incorrect step, process, or data definition)

Failure:

• Lỗi khi có kết quả sai lệch so với yêu cầu đặc tả. (A behavioral deviation from user requirement or product specification)

Errors → Faults → Failures (Defect/Bug)

2. Verification - Validation:

Verification (xác nhận):

• Xác nhận xem việc thực thi sản phẩm (product) đúng theo yêu cầu đã được chỉ định hay chưa?
• Trả lời cho câu hỏi: "Did we build the system right?"
• Ví dụ: xác nhận theo SRS, design thực hiện ở giai đoạn code review trong team, unit test, integration and system test
  Validation (xác nhận):
• Xác nhận, kiểm tra xem chức năng (function) cần thiết và mong đợi của khách hàng đã có trong sản phẩm hiện tại hay chưa?
• Trả lời cho câu hỏi: "Did we build the right system, appropriate, fix for use?"
• Ví dụ: xác nhận theo SRS, Requirement prototype xác nhận theo SRS review bởi customer, acceptance test, beta test, hỗ trợ
  
  

3. Re-testing - Regression testing:

Re-testing (kiểm thử lại):

• Là hành động xảy ra sau khi lỗi (defect) đã được fix, cần re-test lại phần mền (software) để kiểm tra xem lỗi (defect) ban đầu đã được xóa bỏ thành công hay chưa?
• Hay còn gọi là xác nhận (confirmation). (Debug (tìm vị trí và fix lỗi (defect)) thuộc quá trình development, không nằm trong quá trình testing)

Regression testing (kiểm thử hồi quy):

• Là lặp lại việc kiểm thử trên một chương trình (program) đã được kiểm thử trước đó, sau khi chương trình (program) có sự thay đổi, để khám phá xem có bất cứ lỗi (defect) nào xảy ra sau khi thay đổi hay không?
• Lỗi (defect) xảy ra có thể là lỗi của phần mềm (software) đã kiểm thử trước đó, hoặc có thể thuộc một phần (software component) khác.
• Lỗi (defect) thường xảy ra khi phần mềm (software) hoặc môi trường bị thay đổi.
• Mức độ kiểm thử hồi quy (regression testing) dựa trên nguy cơ (risk) của lỗi (defect) trong phần mềm (software).
• Kiểm thử hồi quy (regression testing) được thực hiện ở mọi giai đoạn kiểm thử (test level), bao gồm cả chức năng (functional), phi chức năng (non-functional) và kiểm thử cấu trúc (structural).
• Bộ kiểm thử hồi quy được sử dụng nhiều lần nên có thể làm chậm quá trình phát triển, vì vậy, nên tối ưu bằng cách sử dụng automation.

4. Testing (Kiểm thử) - Quality assurance (QA - đảm bảo chất lượng):

Testing (Kiểm thử):

• Mục đích của testing là tìm ra lỗi, tìm thấy chúng sớm nhất có thể, và đảm bảo rằng chúng đã được sửa.

Quality assurance (QA - đảm bảo chất lượng):

• Trách nhiệm chính của người QA là tạo ra hoặc sử dụng các chuẩn đã có và bắt phần mềm phải tuân theo các tiêu chuẩn đó để cải tiến quy trình phát triển phần mềm và ngăn chặn các lỗi xuất hiện ở bất cứ giai đoạn nào.

5. Severity - Priority:

Severity (độ nghiêm trọng): Đánh giá mức độ ảnh hưởng của các bug đối với hệ thống, gồm các mức độ: Blocker:

• Bug gây cản trở việc kiểm thử hoặc gây ra gián đoạn khi đang sử dụng

Critical:

• Bug có nguy cơ gây ra mất một phần hoặc toàn bộ dữ liệu
• Bug gây ra crashes, rò rỉ bộ nhớ nghiêm trọng

High (Major/ Severe):

• Bug có hoạt động đi ngược lại hoàn toàn mong đợi nêu ra trong spec
• Bug về chức năng chính bị lỗi nhưng có thể thay thế bằng một biện pháp tạm thời
• Bug gây ảnh hưởng đến tiến độ lâu dài

Medium (Moderate/ Normal):

• Bug không đáp ứng được một số tiêu chí nhất định hoặc không thân thiện với người sử dụng Tuy nhiên, không làm ảnh hưởng đến các chức năng khác trên hệ thống

Low (Minor):

• Bug nhỏ không gây ảnh hưởng gì đến chức năng, nhưng vẫn là lỗi và vẫn cần được sửa chữa

Priority (độ ưu tiên): Xác định độ ưu tiên xử lý trước/ sau cho bug, gồm các mức độ:

Critical: (Bug cần được xứ lý trong vòng 24h)

• Bug gây cản trở việc kiểm thử hoặc gây ra gián đoạn khi đang sử dụng
• Bug có nguy cơ gây ra mất một phần hoặc toàn bộ dữ liệu
• Bug gây ra crashes, rò rỉ bộ nhớ nghiêm trọng

High: (Bug xử lý ngay sau các bug Critical)

• Bug liên quan đến chức năng cần được bàn giao theo plan đã định
• Bug gây ra lỗi chức năng, hoặc các vấn đề về môi trường

Medium:

• Bug đang thảo luận, chưa rõ yêu cầu cụ thể
• Bug liên quan đến error message (thỉnh thoảng)

Low:

• Bug không nằm trong plan bàn giao, có thể sửa trong lần bàn giao sau
• Bug về giao diện, sai text, ...
• Đề xuất cải tiến, nâng cao trải nghiệm người dùng ...

Nguồn tham khảo: giáo trình 1-istqbfoundationlevelsyllabus2011