Bài viết này Anh Tester sẽ tháo gỡ cho những bạn khỏi sự nhầm lẫn giữa những từ ngữ chuyên ngành, những khái niệm tựa như nhau trong kiểm thử ứng dụng .Đối với những từ ngữ chuyên ngành, đặc biệt quan trọng trong nghành nghề dịch vụ công nghệ thông tin, có rất nhiều từ đồng nghĩa tương quan với nhau. Đối với người mới học khóa học Tester kiểm thử ứng dụng, mới mở màn sự nghiệp, điều này càng khó khăn vất vả vì chỉ cần hiểu sai một chút ít bạn hoàn toàn có thể gây tác động ảnh hưởng không nhỏ tới một dự án Bất Động Sản hoàn toàn có thể lên đến cả tỉ đồng .
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 những 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ệ ngặt nghèo với nhau và khi tất cả chúng ta xem xét kỹ thì hoàn toàn có thể thấy nhiều lúc chúng còn có chung những hoạt động giải trí giống nhau trong một dự án Bất Động Sản. Tuy nhiên, chúng vẫn có những điểm khác nhau rất rõ ràng để hoàn toàn 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 hề 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 nổi bật để phân biệt được một cách xác nhận 3 khái niệm trên. Vậy tất cả chúng ta hãy cùng tìm hiểu và khám phá 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 ngặt nghèo, con người trong quy trình tăng trưởng ứng dụng hoàn toàn có thể gây ra error ở đâu đó dẫn đến trong mạng lưới hệ thống sẽ có những Fault phát sinh và khi người dùng cuối sử dụng thì có những 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à 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 .
Đây cũng là một thuật ngữ và hoàn toàn có thể giải nghĩa được. Test Strategy 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.
6. Sự khác biệt giữa Test Case và Test Script là gì?
Theo tôi, hai thuật ngữ này hoàn toàn có thể được sử dụng thay thế sửa chữa cho nhau. Vâng, tôi đang nói không có sự độc lạ. Test Case là một chuỗi những bước giúp chúng tôi triển khai một thử nghiệm nhất định trên ứng dụng. Test Script là điều tựa như .
Bây giờ, có một phe phái cho rằng Test Case là một thuật ngữ được sử dụng trong môi trường tự nhiên kiểm thử bằng tay thủ công và Test Script được sử dụng trong thiên nhiên và môi trường kiểm thử tự động hóa. Điều này đúng một phần, vì mức độ tự do của tester trong những nghành nghề dịch vụ tương ứng và cả về cách những công cụ tìm hiểu thêm những bài kiểm thử ( 1 số ít gọi là Test Case và số khác lại gọi là Test Script ). Vì vậy, trong thực tiễn, Test Case và Test Script đều là những bước được triển khai trên một ứng dụng để xác nhận công dụng của nó mặc dầu bằng tay hoặc trải qua tự động hóa .
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 khởi đầu, chuyển tiếp vào tiến trình phong cách thiết kế kiểm thử. Đây đa phần là một định nghĩa một dòng về Cái gì mà chúng tôi sẽ kiểm thử so với một tính năng nhất định. Thông thường, Test Scenario là một nguồn vào để tạo ra những test case. Trong những dự án Bất Động Sản agile, những Test Scenario là những đầu ra phong cách thiết kế kiểm thử duy nhất và không có test case nào được viết theo những ngữ cảnh này. Một Test Scenario hoàn toàn 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, đơn cử hơn. Nó hoàn toàn có thể được định nghĩa đại khái là tiềm năng / tiềm năng của một bài kiểm tra nhất định .
Ví dụ Test Condition :
Trong ví dụ trên, nếu tất cả chúng ta kiểm tra ngữ cảnh 1, tất cả chúng ta hoàn toàn có thể kiểm tra những điều kiện kèm theo 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, tài liệu đơn cử được diễn đạt và tiềm năng của bài kiểm thử đúng chuẩn hơn nhiều .
8. Sự khác biệt giữa Test Procedure và Test Suite là gì?
Test Procedure là sự tích hợp của những test case dựa trên một nguyên do logic nhất định, như thực thi một trường hợp từ đầu đến cuối hoặc một cái gì đó cho hiệu ứng đó. Thứ tự mà những Test Procedure sẽ được chạy là cố định và thắt chặt .
Ví dụ : nếu tôi kiểm thử việc gửi email từ Gmail. com, thứ tự những trường hợp kiểm thử mà tôi sẽ tích hợp để tạo thành một quá 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à list tổng thể những test case phải được triển khai như một phần của quy trình thử nghiệm hoặc quy trình tiến độ hồi quy, v.v. Không có nhóm logic dựa trên tính năng. Thứ tự trong đó những trường hợp kiểm thử cấu thành được thực thi hoàn toàn 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 đó hoàn toàn có thể đã có 1000 trường hợp kiểm thử trọn vẹn. Đối với phiên bản 2, có 500 trường hợp kiểm thử để chỉ kiểm tra công dụ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 gồm có cả hồi quy và tính năng mới. Bộ này cũng là một sự phối hợp, nhưng chúng tôi không nỗ lực đạt được tính năng đích .
Các Test Suite hoàn toàn có thể chứa 100 hoặc thậm chí còn 1000 test case .
