Nội dung bài học
Đố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 có thể lên đến cả tỉ đồng.
Bài viết này Anh Tester sẽ gỡ rối cho các bạn 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. 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:
| Quality Assurance (QA) | Quality Control (QC) | Testing |
|---|---|---|
| QA bao gồm những hoạt động để đảm bảo việc thực hiện các quy trình phát triển phần mềm một cách chính xác nhất, cũng như các phương pháp đang được sử dụng có chuẩn xác không, các tiêu chuẩn của nội dung cần xác nhận trong một phần mềm đã đúng chưa | QC bao gồm những hoạt động để đảm bảo việc phát triển phần mềm đúng với các yêu cầu trong các tài liệu đặc tả liên quan của phần mềm. | Testing bao gồm những hoạt động để đảm bảo việc tìm được các bugs/error/defects của phần mềm. |
| Chủ yếu là tập trung về mặt quy trình cũng như phương pháp hơn là các hoạt động kiểm thử thực tế trên hệ thống. | Tập trung vào việc kiểm thử thực tế hệ thống để tìm ra các bug/defect bằng cách áp dụng các quy trình cũng như các phương pháp kiểm thử. | Chỉ tập trung vào việc kiểm thử thực tế trên hệ thống. |
| Các hoạt động chủ yếu hướng tới quy trình. | Các hoạt động chủ yếu thực hiện trên sản phẩm. | Các hoạt động chủ yếu thực hiện trên sản phẩm. |
| Các hoạt động mang tính phòng ngừa. | Các hoạt động để phát hiện sau đó khắc phục. | Các hoạt động để phát hiện sau đó khắc phục. |
| Là một phần của vòng đời kiểm thử phần mềm. | QC có thể coi là một phần của QA. | Testing là một phần của QC. |
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é.
| Error | Fault | Failure |
|---|---|---|
| Xảy ra do hành động của con người dẫn đến việc phát sinh Error | 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ó | Là sự sai khác kết quả đầu ra giữa thực tế và mong đợi |
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ì?
.png)
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.
Zalo
Anh Tester
facebook.com/anhtester
Đường dẫu khó chân vẫn cần bước đi
Đời dẫu khổ tâm vẫn cần nghĩ thấu