Mẫu test case cho form đăng ký excel

Test cases là đơn vị nhỏ nhất trong kế hoạch kểm thử, mô tả các hành động và thông số cần thiết để xác minh hoạt động của một chức năng cụ thể. Vậy một Test Case Template chuẩn có cấu trúc như thế nào? Bao gồm những trường nào quan trọng? Từng trường trong Test Case Template có ý nghĩa như thế nào? Hãy đọc bài viết này để hiểu rõ hơn về Test Case nhé.

Bài viết này được đăng tại freetuts.net, không được copy dưới mọi hình thức.

1. Các trường quan trọng trong Test Case Template

Test Case Template có cách trình bày tốt giúp duy trì tính nhất quán của kiểm thử cho nhóm kiểm thử và giúp tất cả các bên liên quan dễ dàng hiểu được Test Cases. Viết Test Cases trong một định dạng chuẩn làm giảm effort kiểm thử và giảm tỷ lệ lỗi. Định dạng Test Cases sẽ chuẩn hơn nếu bạn tham khảo Test Cases từ các chuyên gia.

Test Case Template được chọn cho dự án phụ thuộc vào chính sách kiểm thử. Nhiều tổ chức tạo các Test Cases từ Microsoft Excel trong khi một số tổ chức tạo Test cases từ Microsoft Word. Một số tổ chức sử dụng các công cụ quản lý kiểm thử như HP ALM để ghi lại các Test Cases.

✓ Test case là một trường hợp cần kiểm thử, nó bao gồm các thao tác/hành động trên hệ thống, điều kiện cần (tiên quyết), các giá trị đầu vào, và kết quả mong đợi. Một test case thì nên chỉ kiểm tra một trường hợp, một khía cạnh cụ thể nào đó chứ đừng lan man – Tham khảo định nghĩa của ISTQB Glossary.

Test case là tiếng Anh, dịch sang tiếng Việt là “trường hợp kiểm thử” hoặc “ca kiểm thử.” Test case thường có 2 loại chính: test case chi tiết và test case cơ bản. Sẽ được trình bày chi tiết bên dưới. Bài viết này sẽ hướng dẫn bạn cách viết và sắp xếp test case hiệu quả bảo đảm độ bao phủ yêu cầu tốt.

Nguyên văn định nghĩa trên trang  https://glossary.istqb.org

A set of preconditions, inputs, actions (where applicable), expected results and postconditions, developed based on test conditions.

Test case gồm những gì

Trong thực tế test case được trình bày theo nhiều định dạng khác nhau, có thể sử dụng MS Excel hoặc công cụ nào đó để quản lý test case như TestLink hoặc TestRail. Dù test case được trình bày theo dạng nào, thì thành phần chính của test case cũng bao gồm các thông tin sau:

• Test case ID: Để dễ dàng xác định và phân biệt test case với nhau
• Test summary: Để mô tả tóm tắt trường hợp cần kiểm thử. Còn gọi là test objective.
• Test precondition: Điều kiện tiên quyết, điều kiện cần để test case này chạy được
• Test steps: Các bước thực hiện test case
• Expected result: Kết quả mong đợi, điều bạn muốn chương trình/màn hình/API/… đó thực hiện, thường dựa vào tài liệu mô tả để xác định kết quả mong đợi này.
• Test result: Ghi kết quả của test case, thường là OK (đạt), và NG (không đạt)

Ngoài ra còn có các thông tin khác giúp mình quản lý test case tốt hơn, giúp mình biết được test case này là viết cho yêu cầu nào, user story nào,… thì mình sẽ thêm cột Test requirement,… để quản lý.

Xem thêm Cấu trúc test case ở đây nhé.

Test case mẫu

Một ví dụ test case mẫu trình bày bằng MS Excel

Quy trình viết test case

Tuỳ vào loại test case, mức kiểm thử, hoặc chương trình bạn đang viết test case thì sẽ có các bước, trình tự khác nhau để viết test case, nhưng nhìn chung thì quy trình viết test case sẽ gồm các bước cơ bản sau:

1. Tìm hiểu hệ thống cần kiểm thử
2. Viết test case
3. Sắp xếp test case

Tìm hiểu hệ thống đang được kiểm thử

Bạn phải đọc tài liệu SRS (software requirement specification) hay spec (specification) và những loại tài liệu khác, bao gồm user story (hay viết tắt là US) để hiểu về hệ thống. Thậm chí bạn phải sử dụng thử các phiên bản hiện có, hoặc phiên bản khác như web (trong lúc bạn viết test case cho bản mobile – đang được phát triển). Có khi bạn phải tìm hiểu các ứng dụng tương tự trên thị trường, sản phẩm của đối thủ cạnh tranh,… nếu dự án của bạn không  có tài liệu mô tả yêu cầu.

Phân tích tài liệu thường gặp như user story, SRS hay use case (không phải là user case nha) là cần thiết khi bạn áp dụng kỹ thuật thiết kế test case hộp đen (black-box test techniques) để viết test case. Còn nếu bạn đang áp dụng kỹ thuật hộp trắng (white-box testing) thì phải cần có source code, tài liệu mô tả thiết kế chi tiết như ERD, sequence diagram, v.v…

Viết test case

Áp dụng các kỹ thuật thiết kế test case như phân vùng tương đương, phân tích giá trị biên, bảng quyết định, v.v… để xác định các trường hợp cần kiểm thử và viết nó ra. Quan trọng là bạn phải nghĩ ra được những trường hợp cần kiểm thử, còn việc trình bày thì theo mẫu (format) của dự án bạn đang tham gia thôi. Mỗi dự án, công ty, hay khách hàng khác nhau họ sẽ sử dụng các định dạng (format) test case và công cụ (tool) quản lý test khác nhau.

“Viết test case sao cho bao phủ đủ?” là một câu hỏi thường gặp nhưng khó trả lời. Để xác định “như thế nào là đủ” sẽ còn phụ thuộc vào mong muốn của khách hàng, mục tiêu kiểm thử của bạn là gì? (mục tiêu của bạn test để làm gì), và bạn có bao nhiêu tester tham gia, bao nhiêu thời gian để viết và thực thi test case? Nếu viết nhiều mà không có thời gian để chạy hết thì viết nhiều để làm gì? Viết nhiều mà bao phủ các trường hợp ở trong cùng 1 vùng tương đương thì liệu có hiệu quả không?

Sắp xếp test case

Sau khi bạn viết case xong thì nên xem lại và sắp xếp test case trước sau theo một trình tự để khi thực thi cho hiệu quả. Thường test case sẽ được sắp xếp dựa vào độ ưu tiên, loại test case, và sự phụ thuộc lẫn nhau.

• Độ ưu tiên: Test case cho các chức năng ưu tiên cao (P1 – priority 1) thì được để trên (để thực hiện/chạy trước) và test case của màn hình có ưu tiên thấp hơn (P2, P3) thì để sau.
• Loại test case: Test case để kiểm tra UI thường để sau test case để kiểm tra chức năng hoặc UI nằm trước tuỳ dự án ưu tiên UI hay chức năng. Positive test case (happy case) thì nên nằm trước negative test case (unhappy case). Test case cho mục đích regression testing (kiểm thử hồi quy thì nên để sau cùng).
• Sự phụ thuộc: Test case cho các màn hình/chức năng phụ thuộc vào chức năng/màn hình khác thì phải để sau. Ví dụ, test cases để kiểm thử trường hợp hiển thị và phân trang (pagination) thì nên để sau các test case cho chức năng (nút) Tìm kiếm trong cùng màn hình.

Mức chi tiết của test case

Thường test case có nhiều mức, nhưng bài này mình nói về 2 mức chi tiết chính là high-level test case (test case cơ bản), và detailed test case (test case chi tiết).

High-level test case

Nhiều người cho rằng test case cơ bản này là checklist, nhưng thực ra nó không phải. Checklist là danh sách các trường hợp cần kiểm thử chung dành cho mọi chương trình, hệ thống. Nói cách khác, với checklist thì nó là “dùng chung” cho mọi sản phẩm cùng loại hoặc có chứng năng tương tự, ví dụ: khi kiểm thử web thì:

1. Nên kiểm thử trên nhiều trình duyệt khác nhau
2. Nên kiểm tra UI và UX
3. Nên kiểm tra chức năng chính
4. Nên kiểm tra việc phân quyền cho các loại user khác nhau
5. Nên kiểm tra hiệu năng (vì có thể sẽ có nhiều người truy cập cùng lúc)
6. Nên kiểm tra đánh giá khả năng bảo mật (security testing) của hệ thống

Nhưng tuỳ vào hệ thống mà bạn đang test, thì bạn sẽ phải biết (thường là dựa vào tài liệu mô tả yêu cầu chức năng, phi chức năng) để biết được UI thế nào là đúng và có bao nhiêu loại user trong hệ thống đó, và user nào có thể làm được gì (authorization).

High-level test case là khi bạn liệt kê danh sách những trường hợp cần kiểm thử đó, nhưng không mô tả chi tiết các bước thực hiện cũng như dữ liệu, giá trị cần nhập vào, và kết quả mong muốn như thế nào.

Test case chi tiết

Ngược lại với high-level test case, test case chi tiết phải bao gồm thông tin chi tiết các bước thực hiện cũng như dữ liệu, giá trị cần nhập vào, và kết quả mong muốn như thế nào. Tuỳ vào loại test case (UI, chức năng, phi chức năng,…) mà các bước thực hiện hoặc kết quả mong đợi sẽ khác nhau. Nhưng, điểm chung của test case chi tiết là phải mô tả dữ liệu đầu vào và kết quả mong đợi, thường được gọi là test data (dữ liệu test).

Test case và Test scenario

Để giúp bạn phân biệt test scenario và test case, vui lòng xem video ngắn này nhé

Câu hỏi thường gặp

Dưới đây là một số câu hỏi thường gặp liên quan đến vấn đề thiết kế test case.

Test case gồm những gì?

Test case thường bao gồm những thành phần chính sau:
1. Test case ID: Để dễ dàng xác định và phân biệt test case với nhau
2. Test summary: Để mô tả tóm tắt trường hợp cần kiểm thử. Còn gọi là test objective.
3. Test precondition: Điều kiện tiên quyết, điều kiện cần để test case này chạy được
4. Test steps: Các bước thực hiện test case
5. Expected result: Kết quả mong đợi, điều bạn muốn chương trình thực hiện

Làm sao để viết test case bao phủ tốt?

Test case bao phủ tốt là phải bao gồm các loại test case cho UI (nếu có – vì giả sử bạn đang test API thì làm gì có UI mà bắt buộc phải có test case cho UI), test case cho các trường hợp happy case (positive case), và negative case (unhappy case). Và quan trọng hơn hết, tập test case của bạn phải bao phủ mọi nghiệp vụ, chức năng cần thiết theo mô tả yêu cầu.

Dự án nào cần viết test case?

Dù bạn đang tham gia dự án gia công phần mềm (outsourcing) hay công ty phát triển phần mềm (hay gọi là công ty product) thì việc viết test case và mức độ chi tiết của test case sẽ khác nhau. Tuy nhiên, chí ít cũng nên viết checklist để bảo đảm các chức năng chính sẽ/đã được kiểm thử, và phần mềm đã bao phủ (cover) hết các yêu cầu đã mô tả.

Có cần phải viết test case không?

Không phải dự án nào cũng có đủ thời gian để viết test case. Thông thường thì trong khi Lập trình viên (dev) đang lập trình (phát triển) thì tester (QC) sẽ có thời gian để viết test case.
Nhưng cũng có nhiều trường hợp, dự án không hoàn toàn viết mới mà sẽ cải tiến, nâng cấp hệ thống cũ, thì thời gian lập trình thường sẽ hoàn thành trước thời gian viết test case. Và nhiều lúc cần gấp thì mình vẫn có thể test (kiểm thử) trước khi viết test case xong hoặc vừa kiểm thử vừa viết.

Không viết test case có được không?

Việc có viết test case hay không sẽ phụ thuộc vào từng trường hợp cụ thể. Phụ thuộc vào ngữ cảnh, tình hình thực tế của dự án mà tester cân nhắc nên test trước rồi viết test case hay là viết test case trước rồi test. Ngoài ra, mọi việc còn phụ thuộc vào quyết định của Khách hàng, QC/Tester Leader và Project Leader/Manager nữa.