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

PiraGo Staff -

Đối với các từ ngữ chuyên ngành, đặc biệt trong lĩnh vực công nghệ thông tin, có rất nhiều từ đồng nghĩa với nhau. Đối với người mới học khóa học Tester kiểm thử phần mềm, mới bắt đầu sự nghiệp, điều này càng khó khăn vì chỉ cần hiểu sai một chút bạn có thể gây ảnh hưởng không nhỏ tới một dự án.

Bài viết này sẽ giúp mọi người tránh khỏi sự nhầm lẫn giữa các từ ngữ chuyên ngành, các khái niệm tương tự 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.
  • 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.
  • Để phân biệt QA, QC và Tester là việc không hề dễ dàng kể cả những người có kinh nghiệm lâu năm. Nhưng việc phân biệt này cũng không quá quan trọng mà việc thủ sẵn kiến thức nền này cũng cho thấy sự chuyên nghiệp của bạn.
  • Tổng quan sự khác biệt giữa QA,QC & Testing:
2.  Audit & 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 & 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 & 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.

-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.

  • Error: Xảy ra do hành động của con người dẫn đến việc phát sinh Error
  • Fault: Là một lỗi ở trong hệ thống làm cho hệ thống không thực hiện được đúng chức năng và yêu cầu của nó
  • Failure: Là sự sai khác kết quả đầu ra giữa thực tế và mong đợi
5. Test plan & Test strategy
  • Test plan là tài liệu tổng quan về việc kiểm thử 1 project đặc tả: phạm vi dự án, hướng tiếp cận, quy trình kiểm thử, tài nguyên và nhân lực cần có, các tính năng cần được test và không cần phải test, các công cụ và môi trường test cần có. Test plan là cơ sở để test các sản phẩm, phần mềm trong một dự án.
  • Test strategy được định nghĩa là một tập các phương pháp thử nghiệm để giúp đạt được mục tiêu của test plan. Nó là một phần nhỏ nằm trong test plan. Trong quá trình phát triển một dự án có thể có nhiều chiến lược thử nghiệm được thay thế nhau cho phù hợp với hoàn cảnh của dự án để đem lại hiệu quả làm việc cao nhất.

-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. Test Case & Test Script
  • Theo wikipedia: Test case là “một tập hợp các thông số đầu vào kiểm thử, điều kiện thực thi, và kết quả mong đợi được phát triển cho một mục tiêu cụ thể, như thực hiện một chương trình cụ thể hay kiểm tra sự tuân thủ với một yêu cầu cụ thể.”
  • Test script:  là bản hướng dẫn chi tiết, viết bằng code (mã) để thực hiện automation testing (kiểm thử tự động). Ngoài ra, bạn cũng cần dùng phần mềm automation testing để thực thi test script. Một số phần mềm được sử dụng phổ biến hiện nay gồm có Selenium, UTF One (Micro Focus Unified Functional Testing), TestComplete, Cucumber,…

=> 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 & Test Condition
  • Test Scenario: là một tài liệu mà người kiểm thử tạo ra như một bước chuyển tiếp vào giai đoạn test design, là đầ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.

-Ví dụ Test Scenario:

  • 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.

  • 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 Độ  (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.
8. Test Procedure và Test Suite
  • Test procedure: là sự kết hợp của các trường hợp thử nghiệm dựa trên một lý do hợp lý nhất định. Thứ tự trong các trường hợp thử nghiệm khi chạy được cố định trước.

-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

  • 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ụ: 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.

Nguồn tham khảo: https://www.tutorialspoint.com/software_testing/software_testing_qa_qc_testing.htm