Trong môi trường phát triển phần mềm nhanh chóng, khoảng cách giữa những gì một bên liên quan hình dung và điều mà nhà phát triển xây dựng có thể rất lớn. Khoảng cách này thường được thu hẹp nhờ vàoTiêu chí chấp nhận Câu chuyện Người dùng. Đối với các đội Kiểm thử Chất lượng (QA), những tiêu chí này không chỉ là danh sách kiểm tra; chúng là hợp đồng về chất lượng. Khi được viết rõ ràng, chúng biến sự mơ hồ thành các tình huống kiểm thử có thể thực hiện được.
Nhiều đội ngũ gặp khó khăn với các yêu cầu mơ hồ. Những cụm từ như “dễ sử dụng” hay “tải nhanh” thường xuất hiện trong các bản nháp đầu tiên nhưng thất bại khi bị kiểm tra nghiêm ngặt. Hướng dẫn này cung cấp một cách tiếp cận có cấu trúc để xây dựngtiêu chí chấp nhận kiểm thử được giúp các kỹ sư QA tự tin hơn, giảm thiểu rò rỉ lỗi và đảm bảo sự thống nhất giữa các chức năng Sản phẩm, Phát triển và Kiểm thử.
🎯 Tại sao Tiêu chí chấp nhận kiểm thử được lại quan trọng
Tiêu chí chấp nhận (AC) xác định ranh giới của một câu chuyện người dùng. Chúng xác định các điều kiện phải được đáp ứng để câu chuyện được coi là hoàn thành. Đối với các chuyên gia QA, những phát biểu này đóng vai trò nền tảng cho việc tạo lập các trường hợp kiểm thử. Không có chúng, kiểm thử trở thành trò chơi đoán mò.
- Rõ ràng trong kỳ vọng: Các tiêu chí rõ ràng loại bỏ sai lệch hiểu lầm giữa các vai trò.
- Kiểm thử hiệu quả: Các điều kiện cụ thể cho phép người kiểm thử viết các trường hợp kiểm thử chính xác ngay lập tức.
- Giảm thiểu công việc phải làm lại: Sự mơ hồ thường dẫn đến việc xây dựng tính năng sai. Tiêu chí AC tốt sẽ ngăn chặn sự lãng phí này.
- Hỗ trợ kiểm thử tự động: Các phát biểu kiểm thử được là điều kiện tiên quyết cho các kịch bản tự động hóa.
Khi AC mơ hồ, đội QA phải dành thời gian làm rõ yêu cầu trong suốt sprint, làm chậm tiến độ giao hàng. Khi AC chính xác, trọng tâm chuyển hoàn toàn sang xác thực và đảm bảo chất lượng.
🔍 Đặc điểm của một phát biểu kiểm thử được
Không phải mọi yêu cầu nào cũng kiểm thử được. Một phát biểu chỉ hợp lệ nếu có thể xác minh một cách khách quan. Để đảm bảo khả năng kiểm thử, các tiêu chí cần tuân theo các nguyên tắc sau:
- Không mơ hồ: Chỉ có một cách hiểu duy nhất cho phát biểu này.
- Có thể xác minh được: Có thể xác nhận kết quả đạt hay không đạt thông qua quan sát hoặc dữ liệu.
- Nguyên tử: Mỗi tiêu chí chỉ đề cập đến một điều kiện duy nhất, chứ không phải một yêu cầu kết hợp.
- Liên quan: Nó liên quan trực tiếp đến mục tiêu của câu chuyện người dùng.
- Nhất quán: Nó không mâu thuẫn với các tiêu chí khác hoặc các giới hạn hệ thống.
Xem xét sự khác biệt giữa ngôn ngữ chủ quan và khách quan. Các thuật ngữ chủ quan dựa trên ý kiến, trong khi các thuật ngữ khách quan dựa trên dữ liệu.
📉 Ví dụ về chủ quan so với khách quan
| Chủ quan (Tránh dùng) | Khách quan (Mục tiêu) |
|---|---|
| Trang web phải tải nhanh. | Trang web phải tải trong vòng 2 giây trên kết nối 3G. |
| Hệ thống phải an toàn. | Mật khẩu phải được mã hóa bằng thuật toán băm SHA-256. |
| Người dùng phải thấy việc điều hướng dễ dàng. | Người dùng có thể truy cập trang thanh toán trong vòng 3 lần nhấp từ trang chủ. |
| Báo cáo phải trông tốt. | Báo cáo phải hiển thị tổng cộng 5 cột với các tiêu đề được căn chỉnh. |
Lưu ý cách các phiên bản khách quan cung cấp các chỉ số, phương pháp hoặc con số cụ thể. Những điều này cho phép người kiểm thử thực hiện quyết định đạt/điểm qua mà không cần tham khảo người sở hữu sản phẩm.
🛠 Kỹ thuật viết tiêu chí chấp nhận
Một số định dạng tồn tại để ghi chép tiêu chí chấp nhận. Sự lựa chọn phụ thuộc vào trình độ chín muồi của đội ngũ và mức độ phức tạp của tính năng. Dưới đây là những phương pháp hiệu quả nhất.
1. Câu tuyên bố bằng ngôn ngữ thông thường
Những câu đơn giản, khai báo tốt cho các tính năng đơn giản. Cách tiếp cận này dễ tiếp cận đối với các bên liên quan không chuyên về kỹ thuật.
- Khi người dùng nhấp vào nút gửi, một thông báo thành công sẽ xuất hiện.
- Khi người dùng nhập địa chỉ email không hợp lệ, một thông báo lỗi sẽ hiển thị phía dưới trường.
- Hệ thống không được phép tạo tài khoản trùng lặp với cùng một địa chỉ email.
2. Ngữ pháp Gherkin (Given/When/Then)
Định dạng này phù hợp gần như hoàn toàn với Phát triển hành vi (BDD). Nó cấu trúc các tiêu chí thành Bối cảnh, Hành động và Kết quả. Định dạng này được ưu tiên cao cho các quy trình phức tạp.
- Cho rằng: Người dùng đang ở trên trang đăng nhập.
- Khi: Người dùng nhập tên người dùng và mật khẩu hợp lệ.
- Thì: Hệ thống chuyển hướng người dùng đến bảng điều khiển.
Cấu trúc này buộc người viết phải xem xét rõ ràng các điều kiện tiên quyết và kết quả mong đợi.
3. Định dạng danh sách kiểm tra
Đôi khi một danh sách các điều kiện là đủ, đặc biệt là đối với các cập nhật giao diện người dùng hoặc thay đổi cấu hình. Mỗi mục đại diện cho một điều kiện có thể kiểm thử.
- Header hiển thị biểu tượng công ty.
- Thanh điều hướng giữ nguyên vị trí ở đầu trang khi cuộn.
- Chân trang chứa năm bản quyền và các liên kết pháp lý.
- Mẫu liên hệ yêu cầu tên và họ.
🤝 Chiến lược hợp tác
Viết tiêu chí chấp nhận hiếm khi là công việc đơn độc. Nó đòi hỏi sự đóng góp từ Chủ sở hữu sản phẩm, các nhà phát triển và kỹ sư kiểm thử chất lượng. Buổi họp “Ba người bạn” là một thực hành phổ biến, nơi ba vai trò này gặp nhau để cùng xác định các tiêu chí.
Mục tiêu hợp tác chính
- Hiểu biết chung:Đảm bảo mọi người hiểu yêu cầu như nhau.
- Kiểm tra khả thi:Các nhà phát triển xác nhận xem các tiêu chí có thể thực hiện được về mặt kỹ thuật hay không.
- Xem xét khả năng kiểm thử:Kiểm thử chất lượng đảm bảo các tiêu chí có thể được xác minh mà không gây hiểu lầm.
- Xác định các trường hợp biên:Nhóm thảo luận những gì xảy ra khi mọi thứ không như mong đợi.
Bằng cách tham gia QA từ giai đoạn viết, các rào cản tiềm ẩn được phát hiện trước khi bắt đầu lập trình. Điều này giảm thiểu rủi ro phát hiện các lỗi nghiêm trọng vào cuối chu kỳ.
⚠️ Những sai lầm phổ biến và mẫu phản tác dụng
Ngay cả các đội có kinh nghiệm cũng dễ mắc bẫy khi viết tiêu chí. Nhận diện những mẫu này giúp duy trì chất lượng cao.
1. Bao gồm chi tiết triển khai kỹ thuật
Tiêu chí chấp nhận nên mô tảđiều gìhệ thống làm, chứ không phảicách thứcnó thực hiện như thế nào. Chi tiết triển khai thuộc về tài liệu thiết kế kỹ thuật.
- Xấu:Cơ sở dữ liệu phải sử dụng bảng MySQL tên là users.
- Tốt:Hệ thống phải lưu trữ thông tin đăng nhập người dùng một cách an toàn và truy xuất chúng để xác thực.
2. Gánh quá nhiều tính năng
Mỗi tiêu chí nên đề cập đến một hành vi cụ thể. Việc kết hợp nhiều hành vi sẽ tạo ra một điều kiện phức tạp, khó kiểm thử.
- Xấu:Người dùng có thể đăng nhập và xem ảnh đại diện của họ.
- Tốt:Người dùng có thể đăng nhập. Trang hồ sơ người dùng hiển thị hình ảnh đã tải lên.
3. Sử dụng cách diễn đạt tiêu cực quá mức
Mặc dù kiểm thử tiêu cực là quan trọng, nhưng quá nhiều câu lệnh “phải không” có thể làm mờ dòng chảy chính.
- Xấu: Hệ thống không được phép chấp nhận các giá trị null. Hệ thống không được phép chấp nhận chuỗi rỗng. Hệ thống không được phép chấp nhận ký tự đặc biệt.
- Tốt: Hệ thống xác thực các trường nhập liệu để đảm bảo chúng chỉ chứa ký tự chữ và số, đồng thời không được để trống.
4. Bỏ qua các yêu cầu phi chức năng
Các tiêu chí chức năng là rất quan trọng, nhưng hiệu suất, bảo mật và khả năng truy cập cũng quan trọng không kém. Những yếu tố này cần được đưa vào nếu chúng ảnh hưởng đến trải nghiệm người dùng.
- Thời gian phản hồi không được vượt quá 200ms đối với các truy vấn tìm kiếm.
- Giao diện phải hỗ trợ điều hướng bằng bàn phím cho tất cả các thành phần tương tác.
- Việc truyền dữ liệu phải được mã hóa thông qua HTTPS.
🧩 Các trường hợp biên và điều kiện biên
Các hành trình thông thường dễ viết. Giá trị thực sự của kiểm thử chất lượng nằm ở việc khám phá các giới hạn. Các tiêu chí chấp nhận cần nêu rõ cách hệ thống xử lý các đầu vào cực đoan hoặc bất thường.
Các loại trường hợp biên
- Giá trị bằng 0: Điều gì xảy ra nếu số lượng là 0?
- Giới hạn tối đa: Số ký tự tối đa cho một trường văn bản là bao nhiêu?
- Trạng thái null: Giao diện người dùng hiển thị như thế nào khi dữ liệu bị thiếu?
- Các hành động đồng thời: Điều gì xảy ra nếu hai người dùng chỉnh sửa cùng một bản ghi đồng thời?
- Lỗi mạng: Hệ thống hoạt động như thế nào khi internet bị ngắt kết nối?
Ví dụ về một tiêu chí trường hợp biên:
- Nếu người dùng cố gắng tải lên một tệp lớn hơn 50MB, hệ thống sẽ hiển thị thông báo lỗi và từ chối tệp.
🔄 Bảo trì và Phát triển
Các tiêu chí chấp nhận không phải là tài liệu tĩnh. Khi sản phẩm phát triển, các tiêu chí cũng phải thay đổi theo. Việc tái cấu trúc mã thường đòi hỏi cập nhật các tiêu chí để phù hợp với hành vi mới.
Các thực hành tốt nhất trong bảo trì
- Xem xét trong quá trình lập kế hoạch Sprint:Xem lại các câu chuyện cũ để đảm bảo các tiêu chí vẫn phù hợp với hành vi hiện tại.
- Cập nhật sau khi sửa lỗi:Nếu một lỗi tiết lộ một điều kiện bị thiếu, hãy thêm ngay vào tiêu chí chấp nhận.
- Lưu trữ các tiêu chí lỗi thời:Loại bỏ các tiêu chí không còn áp dụng để tránh hiểu lầm.
- Kiểm soát phiên bản:Giữ lại lịch sử thay đổi các tiêu chí vì mục đích kiểm toán.
Duy trì các tiêu chí cập nhật giúp đảm bảo kiểm thử hồi quy vẫn hiệu quả. Các tiêu chí lỗi thời dẫn đến kết quả dương tính giả, khi các bài kiểm thử vượt qua dù tính năng đã thay đổi.
📊 Đo lường chất lượng của tiêu chí chấp nhận
Làm sao bạn biết được các tiêu chí chấp nhận của mình có hoạt động không? Sử dụng các chỉ số để đánh giá hiệu quả của chúng theo thời gian.
- Phạm vi bao phủ bài kiểm thử:Phạm vi bao phủ cao cho thấy các tiêu chí rõ ràng. Phạm vi bao phủ thấp cho thấy sự mơ hồ.
- Sự rò rỉ lỗi:Nếu các lỗi thoát ra môi trường sản xuất mâu thuẫn với tiêu chí chấp nhận, thì có thể các tiêu chí không đủ mạnh.
- Thời gian làm rõ:Theo dõi thời gian QA dành để đặt câu hỏi về yêu cầu. Thời gian dài cho thấy tiêu chí chấp nhận kém.
- Tỷ lệ tự động hóa:Tỷ lệ tự động hóa cao tương quan với các tiêu chí có thể kiểm thử, rõ ràng và không mơ hồ.
Các buổi tổng kết định kỳ có thể giúp các đội thảo luận về các chỉ số này và điều chỉnh quy trình viết của họ cho phù hợp.
🔗 Tích hợp với Định nghĩa Hoàn thành
Tiêu chí chấp nhận là cụ thể với từng câu chuyện người dùng. Định nghĩa Hoàn thành (DoD) áp dụng cho toàn bộ bản phát hành hoặc sprint. Chúng hoạt động cùng nhau nhưng phục vụ các mục đích khác nhau.
- DoD: “Tất cả mã nguồn đã được xem xét,” “Tất cả bài kiểm thử đơn vị đã vượt qua,” “Tài liệu đã được cập nhật.” (Tiêu chuẩn toàn cầu)
- AC: “Người dùng có thể đặt lại mật khẩu qua email.” (Cụ thể cho tính năng)
Một câu chuyện chỉ hoàn chỉnh khi cả hai tiêu chí chấp nhận đều được đáp ứng và tiêu chí hoàn thành được thỏa mãn. Các đội QA phải xác minh cả hai lớp để phê duyệt một tính năng.
💡 Ví dụ thực tế
Để củng cố sự hiểu biết, hãy cùng xem một ví dụ hoàn chỉnh về một câu chuyện người dùng với các tiêu chí kém và được cải thiện.
Câu chuyện: Chức năng đặt lại mật khẩu
❌ Tiêu chí chấp nhận kém
- Người dùng có thể đặt lại mật khẩu.
- Hệ thống gửi email.
- Liên kết hết hạn sau một thời gian nhất định.
- Bảo mật là điều quan trọng.
✅ Tiêu chí chấp nhận được cải thiện
- Cho rằng người dùng đang ở trang đăng nhập, khi họ nhấp vào “Quên mật khẩu”, họ sẽ được chuyển hướng đến biểu mẫu đặt lại.
- Khi người dùng nhập địa chỉ email đã đăng ký và gửi đi, một thông báo xác nhận sẽ xuất hiện trên màn hình.
- Một email chứa liên kết đặt lại duy nhất sẽ được gửi trong vòng 5 phút.
- Liên kết đặt lại hết hạn sau 24 giờ kể từ khi tạo.
- Nếu người dùng nhập mã sai, hệ thống sẽ hiển thị lỗi và cho phép thử lại.
- Mật khẩu mới phải đáp ứng các yêu cầu độ phức tạp (8 ký tự, 1 chữ số, 1 ký hiệu).
Phiên bản được cải thiện cho phép QA viết các trường hợp kiểm thử cụ thể về thời gian gửi email, thời hạn hết hạn liên kết và các quy tắc độ phức tạp mật khẩu.
🚀 Tiến bước về phía trước
Viết các tiêu chí chấp nhận có thể kiểm thử là một kỹ năng được cải thiện qua thực hành. Điều này đòi hỏi sự kỷ luật để tránh ngôn ngữ mơ hồ và cam kết với sự rõ ràng. Bằng cách tập trung vào các phát biểu khách quan, có thể kiểm chứng, các đội QA có thể giảm thiểu sự mơ hồ và cung cấp phần mềm chất lượng cao hơn.
Bắt đầu bằng việc kiểm tra các câu chuyện hiện tại của bạn. Xác định các tiêu chí phụ thuộc vào ý kiến cá nhân hoặc các chỉ số mơ hồ. Viết lại chúng để bao gồm các điều kiện cụ thể. Khuyến khích sự hợp tác giữa các vai trò để đảm bảo sự hiểu biết chung. Theo thời gian, việc giảm thiểu lỗi và công việc phải làm lại sẽ chứng minh giá trị của nỗ lực này.
Hãy nhớ, mục tiêu không chỉ là viết văn bản. Mục tiêu là định nghĩa chất lượng. Khi các tiêu chí rõ ràng, kiểm thử trở nên hiệu quả và sản phẩm trở nên đáng tin cậy.