Chào mừng các bạn trở lại với loạt bài viết “QA Engineer (Tester) Roadmap”! Sau khi chúng ta đã cùng nhau khám phá lộ trình tổng thể, tìm hiểu bảo đảm chất lượng là gì, phát triển tư duy của một người kiểm thử, và nắm vững các loại kiểm thử cơ bản như Black Box, White Box, cũng như các mô hình SDLC và vai trò của QA trong Agile, giờ là lúc chúng ta đi sâu vào một kỹ năng cốt lõi: viết tài liệu kiểm thử.
Kỹ năng viết Kế hoạch Kiểm thử (Test Plan), Trường hợp Kiểm thử (Test Case) và Kịch bản Kiểm thử (Test Scenario) là nền tảng cho bất kỳ QA Engineer nào, đặc biệt là những người mới bắt đầu với kiểm thử thủ công. Những tài liệu này không chỉ giúp bạn tổ chức công việc một cách có hệ thống mà còn là công cụ giao tiếp hiệu quả với các thành viên khác trong nhóm phát triển.
Trong bài viết này, chúng ta sẽ cùng tìm hiểu rõ về từng loại tài liệu này, vai trò của chúng, và quan trọng nhất là cách để viết chúng một cách hiệu quả nhất.
Mục lục
Kế hoạch Kiểm thử (Test Plan): Bản Đồ Chiến Lược
Kế hoạch Kiểm thử là một tài liệu mang tính chiến lược, cung cấp cái nhìn tổng quan về toàn bộ quá trình kiểm thử cho một dự án hoặc một phân hệ cụ thể. Nó giống như bản đồ chỉ đường, giúp mọi người hiểu rõ mục tiêu, phạm vi, tài nguyên, thời gian biểu và các rủi ro liên quan đến hoạt động kiểm thử.
Một Kế hoạch Kiểm thử hiệu quả cần trả lời các câu hỏi quan trọng như:
- Chúng ta sẽ kiểm thử cái gì? (Phạm vi)
- Mục tiêu của việc kiểm thử là gì? (Mục tiêu)
- Làm thế nào chúng ta sẽ kiểm thử? (Phương pháp tiếp cận)
- Khi nào việc kiểm thử sẽ diễn ra? (Thời gian biểu)
- Ai sẽ thực hiện việc kiểm thử? (Trách nhiệm, Tài nguyên nhân lực)
- Chúng ta cần những gì để kiểm thử? (Môi trường, Công cụ, Dữ liệu)
- Khi nào chúng ta biết việc kiểm thử đã hoàn thành? (Tiêu chí Kết thúc)
- Những rủi ro nào có thể ảnh hưởng đến quá trình kiểm thử? (Quản lý rủi ro)
Các Thành Phần Chính Của Một Kế hoạch Kiểm thử
Mặc dù cấu trúc chi tiết có thể thay đổi tùy theo dự án, mô hình phát triển (Agile hay Waterfall), và công ty, một Kế hoạch Kiểm thử điển hình thường bao gồm:
- Giới thiệu: Mục đích của tài liệu, phạm vi dự án/sản phẩm.
- Mục tiêu Kiểm thử: Các mục tiêu cụ thể cần đạt được thông qua hoạt động kiểm thử.
- Phạm vi Kiểm thử (In Scope/Out of Scope): Xác định rõ ràng những gì sẽ được kiểm thử và những gì không. Điều này cực kỳ quan trọng để quản lý kỳ vọng.
- Các Tính năng Cần Kiểm thử: Liệt kê các tính năng hoặc phân hệ chính sẽ được kiểm thử.
- Các Tính năng Không Cần Kiểm thử: Liệt kê những phần không thuộc phạm vi kiểm thử.
- Phương pháp Tiếp cận Kiểm thử: Cách thức thực hiện kiểm thử (ví dụ: Black-box testing, kiểm thử tự động, kiểm thử hồi quy…).
- Tiêu chí Bắt đầu (Entry Criteria): Điều kiện cần thiết để bắt đầu một giai đoạn kiểm thử cụ thể (ví dụ: bản build ổn định, môi trường kiểm thử sẵn sàng, yêu cầu đầy đủ).
- Tiêu chí Kết thúc (Exit Criteria): Điều kiện để xác định khi nào một giai đoạn kiểm thử được coi là hoàn thành (ví dụ: độ bao phủ kiểm thử đạt mức X%, số lỗi nghiêm trọng còn lại dưới Y, tất cả các trường hợp kiểm thử ưu tiên cao đã PASS).
- Kết quả Có Thể Giao Nộp (Deliverables): Các tài liệu, báo cáo cần nộp sau khi kiểm thử (ví dụ: Kế hoạch Kiểm thử, Trường hợp Kiểm thử, Báo cáo Lỗi, Báo cáo Tổng kết Kiểm thử).
- Môi trường Kiểm thử: Mô tả chi tiết môi trường cần thiết (phần cứng, phần mềm, cấu hình mạng).
- Công cụ Kiểm thử: Liệt kê các công cụ sẽ sử dụng (quản lý test case, theo dõi lỗi, tự động hóa…).
- Tài nguyên và Trách nhiệm: Phân công vai trò và trách nhiệm cho từng thành viên trong nhóm kiểm thử, ước tính nguồn lực cần thiết.
- Thời gian Biểu và Ước lượng: Lịch trình chi tiết cho các hoạt động kiểm thử.
- Quản lý Rủi ro: Xác định các rủi ro tiềm ẩn và kế hoạch giảm thiểu rủi ro.
- Quản lý Thay đổi: Quy trình xử lý các thay đổi đối với kế hoạch.
Lưu Ý Khi Viết Kế hoạch Kiểm thử
- Bắt đầu sớm: Kế hoạch nên được bắt đầu ngay khi có đủ thông tin về yêu cầu.
- Tham khảo yêu cầu: Đảm bảo kế hoạch dựa trên các yêu cầu sản phẩm (requirements) đã được phê duyệt.
- Thảo luận với nhóm: Chia sẻ và thu thập ý kiến từ Product Owner, Business Analyst, Developers và các bên liên quan khác.
- Linh hoạt: Đặc biệt trong môi trường Agile, kế hoạch kiểm thử có thể nhẹ nhàng hơn và được cập nhật thường xuyên theo từng Sprint.
- Chi tiết vừa đủ: Không cần quá dài dòng, tập trung vào những thông tin quan trọng nhất.
Kịch bản Kiểm thử (Test Scenario): Góc Nhìn Từ Người Dùng
Kịch bản Kiểm thử là một cách tiếp cận cấp cao để xác định những gì cần được kiểm thử, thường tập trung vào các luồng nghiệp vụ hoặc các chức năng chính từ góc nhìn của người dùng cuối. Một kịch bản thường mô tả một khả năng sử dụng cụ thể của hệ thống.
Mục đích của Kịch bản Kiểm thử là đảm bảo chúng ta bao phủ được các chức năng quan trọng nhất của ứng dụng mà không đi vào chi tiết quá mức. Chúng giúp nhóm kiểm thử và các bên liên quan có cùng sự hiểu biết về các khía cạnh cần được xác nhận.
Ví Dụ về Kịch bản Kiểm thử
Thay vì viết một test case chi tiết ngay, bạn có thể bắt đầu bằng các kịch bản:
SCENARIO #1: Kiểm thử chức năng Đăng nhập
SCENARIO #2: Kiểm thử chức năng Tìm kiếm Sản phẩm
SCENARIO #3: Kiểm thử quá trình Thanh toán thành công
SCENARIO #4: Kiểm thử việc thêm Sản phẩm vào Giỏ hàng
Từ mỗi Kịch bản Kiểm thử này, bạn sẽ phân rã thành nhiều Trường hợp Kiểm thử chi tiết hơn.
Lưu Ý Khi Viết Kịch bản Kiểm thử
- Dựa trên yêu cầu và luồng người dùng: Xác định các kịch bản từ các tài liệu yêu cầu (User Stories, Functional Specifications) và cách người dùng thực sự tương tác với hệ thống.
- Cấp độ cao: Không chứa các bước thực hiện chi tiết.
- Bao phủ rộng: Đảm bảo các kịch bản bao phủ các chức năng cốt lõi và các luồng nghiệp vụ quan trọng.
- Dễ hiểu: Sử dụng ngôn ngữ đơn giản, dễ hiểu cho cả người không chuyên về kỹ thuật.
Trường hợp Kiểm thử (Test Case): Hướng Dẫn Chi Tiết Từng Bước
Trường hợp Kiểm thử là tài liệu chi tiết nhất, mô tả các bước cụ thể cần thực hiện, dữ liệu đầu vào, và kết quả mong muốn để xác minh một chức năng hoặc một khía cạnh cụ thể của ứng dụng hoạt động đúng như yêu cầu.
Trường hợp Kiểm thử là đơn vị thực thi của hoạt động kiểm thử. Chúng giúp đảm bảo tính nhất quán khi kiểm thử, cho phép lặp lại quy trình kiểm thử một cách chính xác, và cung cấp cơ sở để báo cáo kết quả.
Các Thành Phần Chính Của Một Trường hợp Kiểm thử
Một Trường hợp Kiểm thử tốt thường bao gồm:
- ID Trường hợp Kiểm thử: Mã định danh duy nhất.
- Tên Trường hợp Kiểm thử: Tiêu đề ngắn gọn mô tả mục đích (ví dụ: Đăng nhập với tài khoản hợp lệ).
- Mô tả: Giải thích chi tiết hơn về mục đích của trường hợp kiểm thử này.
- Các Điều kiện Tiên quyết (Preconditions): Các điều kiện cần phải đúng trước khi thực hiện trường hợp kiểm thử (ví dụ: Người dùng đã đăng ký tài khoản, Sản phẩm đã được thêm vào kho hàng).
- Các Bước Thực hiện (Test Steps): Danh sách các hành động cụ thể cần thực hiện theo trình tự. Mỗi bước nên rõ ràng và dễ lặp lại.
- Dữ liệu Kiểm thử (Test Data): Dữ liệu cụ thể cần sử dụng cho trường hợp kiểm thử này (ví dụ: Username = “test_user”, Password = “password123”).
- Kết quả Mong muốn (Expected Result): Kết quả mà hệ thống được kỳ vọng sẽ hiển thị hoặc thực hiện sau khi hoàn thành các bước thực hiện. Đây là tiêu chí để đánh giá PASS/FAIL.
- Kết quả Thực tế (Actual Result): Kết quả thực tế quan sát được khi thực hiện trường hợp kiểm thử.
- Trạng thái (Status): PASS, FAIL, BLOCKED, SKIP…
- Hậu điều kiện (Postconditions – Tùy chọn): Trạng thái của hệ thống sau khi thực hiện test case.
- Liên kết đến Yêu cầu/Kịch bản/Bug: Tham chiếu đến yêu cầu liên quan, kịch bản kiểm thử mà nó thuộc về, hoặc lỗi mà nó kiểm tra lại.
Ví Dụ về Trường hợp Kiểm thử
Dựa trên Kịch bản Kiểm thử #1: Kiểm thử chức năng Đăng nhập, chúng ta có thể có Trường hợp Kiểm thử sau:
Test Case ID: TC_Login_001
Tên Test Case: Đăng nhập thành công với thông tin hợp lệ
Mô tả: Xác minh người dùng có thể đăng nhập vào hệ thống bằng tài khoản đã đăng ký hợp lệ.
Điều kiện Tiên quyết:
1. Người dùng đã có tài khoản hợp lệ trên hệ thống.
2. Trang Đăng nhập đã được hiển thị.
Các Bước Thực hiện:
1. Mở trình duyệt và truy cập URL của trang web/ứng dụng.
2. Click vào nút "Đăng nhập" hoặc điền trực tiếp vào form đăng nhập.
3. Nhập Username hợp lệ vào trường "Tên đăng nhập".
4. Nhập Password hợp lệ vào trường "Mật khẩu".
5. Click vào nút "Đăng nhập".
Dữ liệu Kiểm thử:
Username: [email protected]
Password: password123
Kết quả Mong muốn:
1. Người dùng được điều hướng đến trang Dashboard/Trang chủ sau khi đăng nhập thành công.
2. Tên người dùng hoặc ảnh đại diện được hiển thị ở góc trên bên phải màn hình.
3. Không có thông báo lỗi nào hiển thị.
Kết quả Thực tế: (Để trống khi viết, điền sau khi thực hiện)
Trạng thái: (Để trống khi viết, điền sau khi thực hiện)
Lưu Ý Khi Viết Trường hợp Kiểm thử
- Rõ ràng và Súc tích: Sử dụng ngôn ngữ đơn giản, không mơ hồ.
- Mỗi bước là một hành động: Tránh gộp nhiều hành động vào một bước.
- Kết quả mong muốn chính xác: Mô tả rõ ràng điều kiện để PASS/FAIL.
- Độc lập: Mỗi trường hợp kiểm thử nên càng độc lập càng tốt.
- Dễ bảo trì: Sử dụng template chuẩn, tổ chức test case theo module hoặc chức năng.
- Kết nối với yêu cầu: Đảm bảo mỗi test case kiểm tra một hoặc nhiều yêu cầu cụ thể. Điều này giúp đo lường độ bao phủ yêu cầu.
Mối Quan Hệ Giữa Kế hoạch, Kịch bản và Trường hợp Kiểm thử
Ba loại tài liệu này bổ trợ cho nhau trong suốt quá trình kiểm thử. Kế hoạch Kiểm thử đặt nền tảng chiến lược, Kịch bản Kiểm thử xác định “những gì” cần kiểm thử ở cấp độ cao, và Trường hợp Kiểm thử mô tả “làm thế nào” để kiểm thử từng khía cạnh cụ thể.
Quy trình thường là: Yêu cầu -> Kế hoạch Kiểm thử -> Kịch bản Kiểm thử -> Trường hợp Kiểm thử.
Hãy hình dung:
- Kế hoạch Kiểm thử: Bạn muốn xây một ngôi nhà (dự án). Kế hoạch Kiểm thử là bản quy hoạch tổng thể: diện tích, số tầng, ngân sách, thời gian thi công, ai làm gì, vật liệu chính là gì, khi nào thì coi như xong móng, khi nào xong nhà…
- Kịch bản Kiểm thử: Dựa trên bản quy hoạch, bạn xác định các khu vực chính cần có: Phòng khách, Phòng ngủ, Bếp, Nhà tắm. Đây là các Kịch bản Kiểm thử – những “khu vực” chức năng chính cần được kiểm tra.
- Trường hợp Kiểm thử: Với mỗi khu vực (kịch bản), bạn viết các hướng dẫn chi tiết để xây dựng/kiểm tra nó: Cách lắp đặt gạch nền cho phòng khách (bước 1, bước 2, kiểm tra mạch gạch), Cách lắp đặt bồn rửa mặt trong nhà tắm (bước A, bước B, kiểm tra độ kín nước). Đây là các Trường hợp Kiểm thử chi tiết.
Bảng dưới đây tóm tắt sự khác biệt và mối liên hệ giữa chúng:
| Tài liệu | Mục đích | Phạm vi | Mức độ Chi tiết | Thời điểm Thường được Tạo |
|---|---|---|---|---|
| Kế hoạch Kiểm thử (Test Plan) | Định nghĩa chiến lược, phạm vi, tài nguyên và lịch trình kiểm thử cho toàn bộ dự án/phân hệ. | Rất rộng (toàn bộ hoặc phần lớn dự án). | Thấp (Tổng quan, chiến lược). | Giai đoạn đầu dự án, sau khi có yêu cầu ban đầu. |
| Kịch bản Kiểm thử (Test Scenario) | Xác định các luồng nghiệp vụ hoặc chức năng chính cần kiểm thử từ góc nhìn người dùng. | Trung bình (một chức năng hoặc luồng nghiệp vụ). | Trung bình (Cao hơn Plan, nhưng thấp hơn Case). | Sau khi Kế hoạch Kiểm thử được phác thảo, dựa trên yêu cầu. |
| Trường hợp Kiểm thử (Test Case) | Mô tả các bước thực hiện cụ thể, dữ liệu đầu vào và kết quả mong muốn để xác minh một khía cạnh chi tiết. | Hẹp (một kịch bản cụ thể, một điều kiện nhất định). | Rất cao (Chi tiết từng bước). | Sau khi Kịch bản Kiểm thử được xác định, song song với quá trình phát triển tính năng. |
Các Thực Hành Tốt Để Viết Tài Liệu Kiểm thử Hiệu quả
Dù là Plan, Scenario hay Case, có một số nguyên tắc chung giúp bạn viết tài liệu kiểm thử chất lượng:
- Hiểu rõ Yêu cầu: Đây là điều quan trọng nhất. Nếu không hiểu bạn đang kiểm thử cái gì, bạn sẽ không thể viết tài liệu hiệu quả. Dành thời gian đọc, đặt câu hỏi và làm rõ yêu cầu. Áp dụng tư duy kiểm thử sớm ngay từ giai đoạn này.
- Sử dụng Ngôn ngữ Rõ ràng, Chính xác, Không Mơ hồ: Tránh các từ ngữ đa nghĩa. Mỗi người đọc tài liệu của bạn phải hiểu theo cùng một cách.
- Giữ cho Tài liệu Có Thể Bảo trì: Viết test case độc lập, sử dụng lại dữ liệu kiểm thử, đặt tên nhất quán, tổ chức tài liệu theo cấu trúc logic. Tài liệu kiểm thử sẽ cần được cập nhật khi ứng dụng thay đổi.
- Tập trung vào Kết quả Mong muốn: Đây là trái tim của test case. Nó định nghĩa tiêu chí PASS/FAIL. Kết quả mong muốn phải rõ ràng, đo lường được và dựa trên yêu cầu.
- Xem xét các Trường hợp Biên (Edge Cases) và Tiêu cực (Negative Cases): Đừng chỉ kiểm thử những luồng hoạt động thành công. Suy nghĩ về những gì sẽ xảy ra khi người dùng nhập sai dữ liệu, vượt quá giới hạn, hoặc thực hiện các hành động không mong muốn.
- Sử dụng Hệ thống Quản lý Test Case (Test Case Management Tool): Các công cụ như Jira (với plugin như Zephyr, Xray), TestRail, TestLink, Azure Test Plans… giúp bạn viết, tổ chức, thực hiện và theo dõi kết quả kiểm thử một cách hiệu quả hơn rất nhiều so với chỉ dùng Excel hoặc Word.
- Review Tài liệu: Nhờ đồng nghiệp, BA, hoặc Developer xem xét tài liệu kiểm thử của bạn. Họ có thể phát hiện ra những điểm thiếu sót hoặc hiểu nhầm về yêu cầu.
- Liên kết với Yêu cầu/User Stories: Đảm bảo mỗi test case/kịch bản được liên kết với yêu cầu hoặc user story tương ứng. Điều này giúp theo dõi độ bao phủ (traceability).
Kết Luận
Viết Kế hoạch Kiểm thử, Kịch bản Kiểm thử và Trường hợp Kiểm thử là một kỹ năng nền tảng mà bất kỳ QA Engineer nào cũng cần phải thành thạo. Đây không chỉ là công việc ghi chép mà còn là cách bạn tư duy có hệ thống về chất lượng sản phẩm, đảm bảo rằng mọi khía cạnh quan trọng đều được xem xét và kiểm tra kỹ lưỡng.
Đối với các bạn mới bắt đầu, đừng ngại dành thời gian luyện tập viết những tài liệu này. Bắt đầu với các chức năng đơn giản, tham khảo các mẫu có sẵn, và luôn tìm cách cải thiện. Tài liệu kiểm thử rõ ràng, đầy đủ sẽ giúp bạn thực hiện công việc kiểm thử hiệu quả hơn, giao tiếp tốt hơn với đồng đội, và đóng góp tích cực vào sự thành công của dự án.
Trong các bài viết tiếp theo của lộ trình, chúng ta sẽ tiếp tục khám phá sâu hơn vào thế giới kiểm thử, từ các kỹ thuật kiểm thử nâng cao đến tự động hóa.
Chúc các bạn thành công và hẹn gặp lại trong những bài viết tiếp theo!
