TÀI LIỆU KIỂM THỬ PHẦN MỀM – NHỮNG KIẾN THỨC CẦN BIẾT | CO-WELL Asia

Trước khi CO-WELL Asia realease một phần mềm nào đó, chúng đã phải trải qua một quá trình kiểm tra kỹ lưỡng để đảm bảo rằng phần mềm sẽ hoạt động mượt mà, ổn định theo đúng chức năng được thiết kế. Để quá trình kiểm thử diễn ra tốt nhất thì việc chuẩn bị các tài liệu kiểm thử phần mềm là không thể thiếu.

A. Vì sao bạn nên chuẩn bị tài liệu kiểm thử phần mềm

• Lý do chính đằng sau việc tạo tài liệu kiểm thử là để giảm hoặc loại bỏ bất kỳ những thông tin không chắc chắn về các hoạt động kiểm thử. Giúp loại bỏ sự mơ hồ thường phát sinh khi phân bổ nhiệm vụ
• Tài liệu không chỉ cung cấp cách tiếp cận có hệ thống để kiểm thử phần mềm, mà nó còn đóng vai trò là tài liệu đào tạo cho những người mới vào quy trình kiểm thử phần mềm
• Thể hiện một quy trình kiểm thử chuyên nghiệp.
• Tài liệu kiểm thử giúp bạn cung cấp một sản phẩm chất lượng cho khách hàng trong một giới hạn thời gian cụ thể.
•  Tài liệu kiểm thử cũng giúp xác định cấu hình hoặc thiết lập chương trình thông qua tài liệu cấu hình và hướng dẫn vận hành.
• Tài liệu kiểm thử giúp bạn nâng cao tính minh bạch với khách hàng.

Tuy nhiên, việc chuẩn bị tài liệu kiểm thử phần mềm cũng đem lại những hạn chế sau:

• Chi phí của tài liệu có thể vượt quá giá trị của nó vì khá tốn thời gian.
• Cập nhật các thay đổi theo yêu cầu của khách hàng mất nhiều thời gian và công sức
• Tài liệu chất lượng kém có thể dẫn tới sự hiểu lầm giữa khách hàng và công ty.

B. Các tài liệu kiểm thử phần mềm cần thiết

1. Yêu cầu đề bài (Requirement)

Requirement giải thích  nhu cầu phát triển phần mềm của khách hàng. Nếu không hiểu được yêu cầu thì không thể lập được test plan, test strategy, test case hay test script. Thông thường, team phát triển và team kiểm thử sẽ đọc hiểu các tài liệu như: Yêu cầu Hệ thống (System Requirement Specification – SRS), Yêu cầu Chức năng (Functional Requirement Specification – FRS), USE Case. Trong đó:

• SRS: Đây là tài liệu cung cấp thông tin về hành vi hoàn chỉnh của hệ thống phần mềm. Nó cung cấp thông tin về phần cứng, phần mềm, thiết bị trung gian, yêu cầu tổng quan về chức năng và phi chức năng.
• FRS: Đây là tài liệu cung cấp thông tin chi tiết về yêu cầu chức năng. Trong một số dự án, FRS sẽ bao gồm chính SRS.
• Use cases:  mô tả sự tương tác giữa người dùng và hệ thống với nhau, trong một môi trường cụ thể và vì một mục đích cụ thể.

Lưu ý: Đôi khi, hiểu rõ được yêu cầu của khách hàng là một điều không dễ bởi vì thông tin trong SRS, FRS, Use cases chưa đầy đủ hoặc không có sẵn các tài liệu đó. Để có thêm kiến thức về lĩnh vực của phần mềm (tài chính, bảo hiểm, viễn thông,…), bạn có thể đọc sách và tìm kiếm thêm trên internet.

2. Software Test Plan

TEST PLAN là một tài liệu chi tiết mô tả chiến lược kiểm thử, mục tiêu, lịch trình, ước tính và khả năng cung cấp và các nguồn lực cần thiết để kiểm thử. Test plan giúp tester xác định nỗ lực cần thiết để xác nhận chất lượng của ứng dụng đang được kiểm thử phần mềm.

Test plan đóng vai trò như một kế hoạch chi tiết để tiến hành các hoạt động kiểm thử phần mềm như một quy trình xác định, được giám sát và kiểm soát từng bước bởi người quản lý kiểm thử.

Test plan sẽ bao gồm:

• Phân tích sản phẩm
• Thiết kế chiến lược kiểm thử
• Xác định mục tiêu kiểm thử
• Xác định tiêu chí kiểm thử
• Hoạch định nguồn lực
• Lên kế hoạch môi trường kiểm thử (Test Environment)
• Lịch trình & Dự toán
• Xác định sản phẩm kiểm thử

3. Test Strategy

Test Strategy (chiến lược kiểm thử) là một kế hoạch để xác định phương pháp kiểm thử và nó trả lời cho các câu hỏi: bạn muốn thực hiện những gì và làm cách nào để bạn thực hiện nó. Đây là một tài liệu quan trọng  đối với bất kỳ nhóm tester nào trong kiểm thử phần mềm và để viết tài liệu này một cách hiệu quả đòi hỏi phải là một Tester có kỹ năng, kinh nghiệm..

Các thành phần của chiến lược kiểm thử bao gồm: mục tiêu và phạm vi, định dạng các tài liệu, quy trình kiểm thử, cấu trúc báo cáo của nhóm, chiến lược communication với khách hàng, vv…

4. Test Case

Test case (Kịch bản kiểm thử) là test – kiểm tra các case – tình huống có thể xảy ra giúp Tester xác định một ứng dụng, hệ thống phần mềm hay một chứng năng ứng dụng có hoạt động đúng hay không. test case mô tả dữ liệu đầu vào (input), hành động (action) hoặc sự kiện (event) và một kết quả mong đợi (expected response).

Tùy vào từng ngữ cảnh của dự án và quy mô công ty sản xuất phần mềm mà các bộ test case được viết chi tiết khác nhau. Một bộ test case thường bao gồm: mã test case, tên test case, mục đích thực hiện test, dữ liệu đầu vào, các bước thực hiện và các kết quả mong đợi. Hiểu một cách đơn giản, test case là một tình huống để kiểm tra đối tượng có thỏa mãn những yêu cầu đặt ra hay không.

5.  Test Data

Mọi tổ chức như: bệnh viện, cơ quan chính phủ, ngân hàng, v.v… khi thực hiện việc kiểm thử đều cần dữ liệu để test. Tuy nhiên, những cơ quan này thường có nhiều dữ liệu nhạy cảm hay thông tin bảo mật, hoặc họ sở hữu một khối lượng data cực lớn và sẽ gây ra nhiều phiền toái cho việc test. Trong những trường hợp như vậy, các kỹ sư sẽ phải sử dụng đến Test Data.

Nói một cách dễ hiểu, Test Data là những dữ liệu được tạo ra, hoặc được thu thập với mục đích kiểm thử phần mềm. Test Data có thể được chia làm hai loại cơ bản:

Test Data dùng cho positive testing

Đây là một hình thức kiểm thử được dùng để xem phần mềm có cho ra phản hồi như đã tính toán khi có sẵn đầu vào hay không.

Test Data dùng cho negative testing

Ngược lại với phía trên, đây là một hình thức kiểm thử phản hồi của phần mềm trong trường hợp những dữ liệu đầu vào bất thường.

6. Test Script

Có thể nói, 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,…

7. Requirement Traceability Matrix (RTM)

Trong chu kỳ phát triển phần mềm, có những yêu cầu liên quan đến việc release, thiết kế, phát triển và thử nghiệm. Các yêu cầu mới sẽ được tạo mới và cập nhật. Requirement Traceability Matrix, hay còn gọi là ma trận truy xuất nguồn gốc các requirement sẽ nắm bắt tất cả các yêu cầu do khách hàng hoặc nhóm developer đề xuất và khả năng truy xuất nguồn gốc trong một tài liệu được đưa ra khi kết thúc vòng đời. Nói cách khác, đó là một tài liệu ánh xạ và theo dõi yêu cầu của người dùng với các test cases. Mục đích chính của RTM là để thấy rằng tất cả các test cases được đảm bảo không có chức năng nào bị bỏ lỡ trong khi thực hiện kiểm thử phần mềm.

Một mẫu RTM phổ biến

8. Test Execution Report

Test Execution Report là tài liệu kiểm thử báo cáo  về việc triển khai các test case.

• Có bao nhiêu test case đã được thực hiện?
• Có bao nhiêu test case đã được thông qua?
• Có bao nhiêu test case đã thất bại?
• Bao nhiêu test case đã bị chặn?
• Có bao nhiêu test case bị lỗi?

Nguồn tham khảo: http://learndatamodeling.com/blog/software-testing-documentation/

Xem thêm: