QA Skills thực hành, phần 1: Bắt đầu từ yêu cầu và kiểm thử thủ công

Một bộ ca kiểm thử dài chưa trả lời được câu hỏi quan trọng nhất: sản phẩm có giúp người dùng hoàn thành việc họ cần làm hay không? Với người mới học QA, điểm bắt đầu hữu ích là chọn một hành trình nhỏ, hiểu điều kiện thành công của nó rồi thu thập bằng chứng. Công cụ sẽ phát huy tác dụng khi câu hỏi kiểm thử đã rõ.

Đây là phần đầu của loạt sáu bài trong thư viện QA Skills. Lộ trình lần lượt đi qua nền tảng và manual testing; tự động hóa, API và hợp đồng; hiệu năng và quan sát hệ thống; mobile và trải nghiệm tiếp cận; bảo mật và đánh giá AI; cuối cùng là CI, báo cáo và phát triển nghề nghiệp. Bạn có thể thực hành các phần trên cùng một ứng dụng mẫu để thấy các lớp kiểm thử bổ sung cho nhau.

Chọn một yêu cầu đủ nhỏ để nhìn thấy toàn bộ

Giả sử ứng dụng mẫu có chức năng lưu sách vào danh sách đọc sau. Yêu cầu ban đầu chỉ ghi: “Người dùng lưu được sách yêu thích.” Đây là tình huống minh họa, chưa phải đặc tả của một sản phẩm có thật. Trước khi viết bước thao tác, hãy làm rõ ai được lưu, sách đã lưu sẽ hiện ở đâu, hành vi khi bấm lặp lại và điều gì xảy ra nếu mất mạng.

Một cuộc trao đổi ngắn với người phụ trách sản phẩm có thể xác định rằng người đã đăng nhập được lưu một sách đang phát hành, mỗi sách xuất hiện một lần trong danh sách, và thông báo thành công chỉ hiện khi hệ thống xác nhận. Nếu chưa có câu trả lời cho việc sách ngừng phát hành có còn trong danh sách hay không, hãy ghi đó là câu hỏi mở. Đừng âm thầm biến một phỏng đoán của tester thành yêu cầu chính thức.

Manual Tester mô tả quy trình từ phân tích yêu cầu, thiết kế ca kiểm thử, lập kế hoạch đến khám phá và báo lỗi. Cách dùng thực tế là tạo một bảng truy vết nhỏ: mỗi tiêu chí chấp nhận đi kèm tình huống cần kiểm tra và bằng chứng dự kiến. Khi yêu cầu đổi, bảng này cho biết phần nào cần được xem lại.

Thiết kế theo rủi ro, thay vì liệt kê mọi cú nhấp

Với danh sách đọc sau, việc lưu nhầm tài khoản có tác động khác với khoảng cách giữa hai biểu tượng chưa đều. Hãy xét cả mức ảnh hưởng, khả năng xuất hiện và độ khó phát hiện trước khi quyết định kiểm tra gì trước. Rủi ro là giả thuyết cần thảo luận; nó không trở thành chính xác chỉ vì có một ô màu đỏ trong bảng.

Nhóm tình huống theo trạng thái giúp thiết kế gọn hơn:

Trạng thái ban đầu	Hành động minh họa	Điều cần xác nhận theo yêu cầu đã thống nhất
Chưa lưu sách	Chọn lưu	Sách xuất hiện trong đúng danh sách của người dùng
Đã lưu sách	Chọn lưu lần nữa	Không tạo bản ghi trùng
Chưa đăng nhập	Chọn lưu	Hiện hướng dẫn đăng nhập theo thiết kế
Kết nối bị gián đoạn	Chọn lưu	Không báo thành công sai; có cách thử lại
Đang chờ phản hồi	Chọn lưu liên tiếp	Trạng thái cuối cùng nhất quán

Với trường nhập tên danh sách, phân vùng tương đương giúp gom những dữ liệu có cùng cách xử lý, chẳng hạn rỗng, hợp lệ và vượt giới hạn. Phân tích giá trị biên tập trung vào hai phía của giới hạn đã được xác nhận. Nếu giới hạn chưa rõ là số ký tự hiển thị hay độ dài lưu trữ, đó là việc phải làm rõ trước khi chọn dữ liệu. Tiếng Việt có dấu và khoảng trắng đầu cuối cũng đáng được cân nhắc khi chúng phù hợp với ngữ cảnh sản phẩm.

Viết ca kiểm thử để người khác thực hiện được

Một ca kiểm thử tốt có mục tiêu riêng, điều kiện ban đầu, dữ liệu, bước thao tác và kết quả mong đợi đủ cụ thể. “Kiểm tra nút lưu hoạt động đúng” không cho người thực hiện biết phải quan sát điều gì. Thay vào đó, có thể viết: “Với tài khoản thử nghiệm chưa lưu cuốn sách đang mở, chọn Lưu; sau khi hệ thống xác nhận, cuốn sách xuất hiện một lần trong danh sách đọc sau của tài khoản đó.”

Không đưa mật khẩu hoặc token vào tài liệu. Hãy tham chiếu vai trò của tài khoản được cấp trong môi trường thử nghiệm và nơi quản lý dữ liệu an toàn của nhóm. Test Data Generator có thể là đầu mối đọc thêm về thiết kế dữ liệu, nhưng dữ liệu sinh ra vẫn cần được rà soát về tính phù hợp và quyền riêng tư.

Tách kết quả mong đợi khỏi kết quả thực tế. Kết quả mong đợi xuất phát từ đặc tả hoặc quy tắc đã được chấp thuận. Kết quả thực tế là điều quan sát được trong lần chạy cụ thể. Một tài liệu ca kiểm thử được AI soạn chưa phải bằng chứng rằng phần mềm đã vượt qua các ca đó.

Khám phá có mục tiêu và có ghi chép

Sau các tình huống đã biết, dành một phiên khám phá cho câu hỏi: “Người dùng có mất niềm tin vào trạng thái đã lưu khi chuyển trang hoặc bị gián đoạn không?” Mục tiêu này tập trung hơn việc mở ứng dụng và bấm tùy ý. Ghi lại đường đi, trạng thái dữ liệu, điều bất thường và câu hỏi nảy sinh trong lúc thực hiện.

Thử chuyển từ trang chi tiết sang danh sách, mở lại trang, thao tác qua bàn phím và quan sát khi phản hồi chậm trong môi trường được phép. Nếu phát hiện biểu tượng đã lưu nhưng danh sách chưa cập nhật, hãy ghi cả hai bề mặt giao diện. Đừng kết luận nguyên nhân thuộc bộ nhớ đệm hay API nếu chưa có bằng chứng kỹ thuật. Cuối phiên, trao đổi ngắn về phát hiện, khoảng trống còn lại và hướng kiểm tra tiếp theo.

Báo lỗi bằng điều có thể tái hiện

Tiêu đề nên mô tả hiện tượng và điều kiện: “Sách xuất hiện hai lần sau khi chọn Lưu liên tiếp lúc phản hồi chậm.” Nội dung cần phiên bản ứng dụng, môi trường, điều kiện ban đầu, bước tối thiểu, kết quả thực tế, kết quả mong đợi và bằng chứng đã loại thông tin nhạy cảm. Nếu chưa biết tần suất, ghi chưa xác định; nếu chỉ gặp một lần, nói đúng như vậy.

Phân biệt độ nghiêm trọng với thứ tự xử lý. Độ nghiêm trọng mô tả ảnh hưởng của lỗi; mức ưu tiên còn phụ thuộc lịch phát hành, phạm vi người dùng và phương án khắc phục tạm thời. QA cung cấp dữ kiện để nhóm quyết định, đồng thời nêu rõ phần nào chưa kiểm tra.

Bài thực hành để mang sang phần tiếp theo

Chọn một chức năng, viết bản tóm tắt yêu cầu, bảng rủi ro, các ca kiểm thử trọng tâm và một mục tiêu khám phá. Thực hiện trên ứng dụng bạn có quyền kiểm tra rồi lưu bằng chứng theo lần chạy. Nếu không tìm thấy lỗi, hãy nộp ghi chép và khoảng trống kiểm thử; không cần tạo một lỗi tưởng tượng để làm đẹp hồ sơ.

Chủ đề tham khảo từ bộ AI Tester Skills. Nội dung được biên soạn lại thành hướng dẫn thực hành cho người đọc.