Những khái niệm dễ nhầm lẫn trong kiểm thử

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

Error: Là hành động của con người dẫn đến kết quả sai.

Ví dụ: Developer đặt tên biến cho 1 function sai cú pháp, dẫn đến khi gọi biến này thì không ra kết quả.

Fault: Lỗi xảy ra khi làm sai các step, process, hoặc chuẩn bị dữ liệu.

Ví dụ: khi bạn test API, bạn muốn login thành công vào 1 app thì sẽ luôn có 1 token được trả về từ server.

Fault => Server không có token trả về, và bạn vẫn login thành công.

Failure: Lỗi khi có kết quả sai lệch so với yêu cầu đặc tả, là sự khác biệt giữa kết quả thực tế trên màn hình và kết quả mong đợi của một thành phần, hệ thống hoặc service nào đó.

Ví dụ: khách hàng yêu cầu server có thể hoạt động tốt khi có 1000 user.

Tuy nhiên trên thực tế server chỉ có thể hoạt động tốt khi có 900 user.

Note: Không phải 100% failure là do bug gây ra, trong quá trình test cấu hình sai, test sai môi trường hoặc làm thiếu bước có thể dẫn đến failure

BUG: Là một khiếm khuyết trong một thành phần hoặc hệ thống mà nó có thể làm cho thành phần hoặc hệ thống này không thực hiện đúng chức năng yêu cầu của nó, ví dụ như thông báo sai hoặc định nghĩa dữ liệu không đúng.

Một bug, nếu gặp phải trong quá trình hệ thống hoạt động, có thể gây ra failure trong thành phần hoặc hệ thống đó.

DEFECT: Lỗi trong quá trình phát triển hoặc lỗi logic(coding or logic) làm cho chương trình hoạt động sai yêu cầu đề ra.(Về cơ bản là giống định nghĩa bug).

Ví dụ: Trong quá trình coding, developer nên get data từ A để hiển thị lên màn hình, tuy nhiên developer hiểu sai logic và get data từ C để hiển thị lên màn hình, dẫn đến bug hiển thị sai data

Tóm lại: con người gây ra error, mistake trong code, tài liệu,... => dẫn đến có bug, defect hoặc fault trong code, tài liệu => khi thực thi chương trình thì bắt gặp failure.

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. Test plan - Test stragery

Test Plan ( Kế hoạch kiểm thử )

Là một thuật ngữ và hoàn toàn có thể giải nghĩa được. Nó là tài liệu miêu tả khoanh vùng phạm vi, cách tiếp cận, nguồn lực và lịch trình của những hoạt động giải trí thử nghiệm dự kiến. Nó xác lập trong số những mục kiểm tra khác, những tính năng được kiểm tra, những trách nhiệm kiểm tra, ai sẽ triển khai từng trách nhiệm, mức độ độc lập của người kiểm tra, môi trường tự nhiên kiểm tra, kỹ thuật phong cách thiết kế kiểm tra và tiêu chuẩn nguồn vào và lối ra được sử dụng, và cơ sở nguyên do cho chúng sự lựa chọn và bất kể rủi ro đáng tiếc nào cần lập kế hoạch dự trữ. Nó là một bản ghi của quy trình lập kế hoạch kiểm tra .

Test Strategy ( Chiến lược kiểm thử )

Phác thảo giải pháp kiểm thử và mọi thứ khác xung quanh nó. Nó khác với Test Plan, theo nghĩa là Test Strategy chỉ là một tập hợp con của Test Plan. Ngoài ra còn có một cuộc tranh luận về mức độ mà Plan hoặc Strategy được sử dụng – nhưng tôi thực sự không thấy bất kể sự độc lạ rõ ràng nào .

Ví dụ : Test Plan phân phối thông tin về người sẽ kiểm tra vào thời hạn nào. Ví dụ, module 1 sẽ được kiểm thử bởi thử nghiệm X của X. Nếu người kiểm tra Y sửa chữa thay thế X vì 1 số ít nguyên do, Test Plan phải được update .

Ngược lại, một Test Strategy sẽ có các chi tiết như – Các module riêng lẻ sẽ được kiểm thử bởi các thành viên trong nhóm tester. Trong trường hợp này, không quan trọng ai đang thử nghiệm nó – vì vậy, nó chung chung và sự thay đổi trong thành viên nhóm không nhất thiết phải cập nhật.

Tài liệu tham khảo:https://blogchiase247.net/test-procedure-la-gi-1644514180/