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. 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.
3. 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.
4. 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.
5. 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.