NHỮNG KHÁI NIỆM DỄ NHẦM LẪN VỚI NHAU TRONG KIỂM THỬ PHẦN MỀM

1. QA, QC & Testing

Rất nhiều người trong ngành công nghệ thông tin còn đang rất mơ hồ và không có được sự phân biệt rõ ràng giữa 3 khái niệm: Quality Assurance (QA), Quality Control (QC) và Testing. Hi vọng bài viết này phần nào đó sẽ giúp các bạn hiểu rõ hơn về những khái niệm trên.

Có thể nói QA, QC và Testing có mối liên hệ chặt chẽ với nhau và khi chúng ta xem xét kỹ thì có thể thấy đôi khi chúng còn có chung những hoạt động giống nhau trong một dự án. Tuy nhiên, chúng vẫn có những điểm khác nhau rất rõ ràng để có thể chỉ ra được đâu là QA đâu là QC hay Testing:

2. Audit and Inspection

Audit: Đây là một quy trình bải bản với mục đích để cho việc kiểm thử thực tế được tiến hành trong tổ chức cũng như trong một team. Hoặc có thể nói đây là một quy trình kiểm tra độc lập có tính liên quan trong suốt quá trình kiểm thử phần mềm. Theo IEEE, đó là việc xem xét các quy trình được lập thành văn bản mà các tổ chức thực hiện và tuân theo. Các loại Audit đó là: Legal Compliance Audit, Internal Audit và System Audit.

Inspection: Đây là một kỹ thuật có iên quan đến việc review xác định ra các Error và GAP trong quá trình phát triển. Theo IEEE, inspection là một kỹ thuật đánh giá bài bản, đối tượng là các yêu cầu đặc tả phần mềm, các thiết kế cũng như các dòng lệnh sẽ được kiểm tra bởi một người hoặc nhóm người độc lập khác với tác giả của chúng để tìm ra các faults, các vi phạm đối với chuẩn khi phát triển phần mềm và các lỗi khác. Các cuộc họp kiểm tra chính thức có thể bao gồm các quy trình sau: Lập kế hoạch, Chuẩn bị tổng quan, Họp kiểm tra, Làm lại và Theo dõi.

3. Testing and Debugging

Testing: Là những hoạt động liên quan đến việc phát hiện ra bug/error/defect của phầm mềm không bao gồm việc sửa chúng. Thông thường các chuyên gia có kiến thức về QA sẽ tham gia trong quá trình tìm bugs. Testing sẽ được thực hiện ở Testing phase.

Debugging: Là những hoạt động liên quan đến việc tìm, phân tích và sửa các bugs. Các lập trình viên, những người phát triển phần mềm sẽ tham gia quá trình debugging khi gặp phải lỗi ở trong code. Debugging là một phần của White Box Testing hoặc Unit Testing. Debugging có thể được thực hiện ở development phase song song Unit Testing đang tiến hành hoặc trong giai đoạn sửa và báo cáo lỗi.

4. Error, Fault and Failure

Đây lại là một khái niệm nữa mà rất nhiều người trong ngành dễ nhầm lẫn hoặc không thể phân biệt được một cách rõ ràng, mạch lạc, không lấy được ví dụ nào điển hình để phân biệt được một cách xác thực 3 khái niệm trên. Vậy chúng ta hãy cùng tìm hiểu cặn kẽ chúng nhé.

Mối liên hệ giữa 3 khái niệm trên là vô cùng chặt chẽ, con người trong quá trình phát triển phần mềm có thể gây ra error ở đâu đó dẫn đến trong hệ thống sẽ có các Fault phát sinh và khi người dùng cuối sử dụng thì có các failure.

5. Sự khác biệt giữa kế hoạch kiểm thử (Test Plan) và chiến lược kiểm thử (Test Strategy) là gì?

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

Đây cũng là một thuật ngữ và có thể giải nghĩa được. Test Strategy phác thảo phương 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ự khác biệt rõ ràng nào.

Ví dụ: Test Plan cung cấp thông tin về người sẽ kiểm tra vào thời gian 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 thay thế X vì một số lý do, Test Plan phải được cập nhật.

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.

6. Sự khác biệt giữa Test Case và Test Script là gì?

Theo tôi, hai thuật ngữ này có thể được sử dụng thay thế cho nhau. Vâng, tôi đang nói không có sự khác biệt. Test Case là một chuỗi các bước giúp chúng tôi thực hiện một thử nghiệm nhất định trên ứng dụng. Test Script là điều tương tự.

Bây giờ, có một trường phái cho rằng Test Case là một thuật ngữ được sử dụng trong môi trường kiểm thử thủ công và Test Script được sử dụng trong môi trường kiểm thử tự động. Điều này đúng một phần, vì mức độ thoải mái của tester trong các lĩnh vực tương ứng và cả về cách các công cụ tham khảo các bài kiểm thử (một số gọi là Test Case và số khác lại gọi là Test Script). Vì vậy, trong thực tế, Test Case và Test Script đều là các bước được thực hiện trên một ứng dụng để xác thực chức năng của nó cho dù bằng tay hoặc thông qua tự động.

7. Test Scenario và Test Condition khác nhau ở điểm nào?

Đây là một con trỏ một dòng mà tester tạo như một bước ban đầu, chuyển tiếp vào giai đoạn thiết kế kiểm thử. Đây chủ yếu là một định nghĩa một dòng về Cái gì mà chúng tôi sẽ kiểm thử đối với một tính năng nhất định. Thông thường, Test Scenario là một đầu vào để tạo ra các test case. Trong các dự án agile, các Test Scenario là các đầu ra thiết kế kiểm thử duy nhất và không có test case nào được viết theo các kịch bản này. Một Test Scenario có thể dẫn đến nhiều thử nghiệm.

Các Test Scenario ví dụ:

• Xác thực nếu Quản trị viên có thể thêm quốc gia mới
• Xác thực nếu một quốc gia hiện tại có thể bị xóa bởi quản trị viên
• Xác thực nếu một quốc gia hiện tại có thể được cập nhật

Test Condition, mặt khác, cụ thể hơn. Nó có thể được định nghĩa đại khái là mục tiêu / mục tiêu của một bài kiểm tra nhất định.

Ví dụ Test Condition:

Trong ví dụ trên, nếu chúng ta kiểm tra kịch bản 1, chúng ta có thể kiểm tra các điều kiện sau:

• Nhập tên quốc gia là Ấn Độ Ấn Độ (hợp lệ) và kiểm tra bổ sung quốc gia
• Nhập vào chỗ trống và kiểm tra xem quốc gia có được thêm không.

Trong mỗi trường hợp, dữ liệu cụ thể được mô tả và mục tiêu của bài kiểm thử chính xác hơn nhiều.

8. Sự khác biệt giữa Test Procedure và Test Suite là gì?

Test Procedure là sự kết hợp của các test case dựa trên một lý do logic nhất định, như thực hiện một tình huống từ đầu đến cuối hoặc một cái gì đó cho hiệu ứng đó. Thứ tự mà các Test Procedure sẽ được chạy là cố định.

Ví dụ: nếu tôi kiểm thử việc gửi email từ Gmail.com, thứ tự các trường hợp kiểm thử mà tôi sẽ kết hợp để tạo thành một quy trình kiểm thử sẽ là:

• Kiểm tra đăng nhập
• Bài kiểm thử soạn email
• Kiểm tra để đính kèm một / nhiều tệp đính kèm
• Định dạng email theo cách được yêu cầu bằng cách sử dụng các tùy chọn khác nhau
• Thêm địa chỉ liên hệ hoặc địa chỉ email vào các trường Đến, BCC, CC
• Gửi email và đảm bảo rằng nó đang hiển thị trong phần Thư đã gửi

Tất cả các trường hợp kiểm thử ở trên được nhóm lại để đạt được một mục tiêu nhất định vào cuối chúng. Ngoài ra, quy trình test có một vài trường hợp kiểm thử kết hợp tại bất kỳ thời điểm nào.

Mặt khác, Test Suite là danh sách tất cả các test case phải được thực hiện như một phần của chu trình thử nghiệm hoặc giai đoạn hồi quy, v.v. Không có nhóm logic dựa trên chức năng. Thứ tự trong đó các trường hợp kiểm thử cấu thành được thực thi có thể hoặc không quan trọng.

Ví dụ về Test Suite: Nếu một ứng dụng thì phiên bản hiện tại là 2.0. Phiên bản 1.0 trước đó có thể đã có 1000 trường hợp kiểm thử hoàn toàn. Đối với phiên bản 2, có 500 trường hợp kiểm thử để chỉ kiểm tra chức năng mới được thêm vào trong phiên bản mới. Vì vậy, Test Suite hiện tại sẽ là 1000 + 500 trường hợp thử nghiệm bao gồm cả hồi quy và chức năng mới. Bộ này cũng là một sự kết hợp, nhưng chúng tôi không cố gắng đạt được chức năng đích.

Các Test Suite có thể chứa 100 hoặc thậm chí 1000 test case.

Bài viết tham khảo

• https://www.tutorialspoint.com/software_testing/software_testing_qa_qc_testing.htm