Hãy hình dung một buổi nghiệm thu lúc năm giờ chiều. Mọi người mở vài màn hình quen thuộc, tạo thử một đơn hàng, in thử một phiếu, rồi người quản lý nói “ổn” và ký. Tuần sau, kế toán mở báo cáo và thấy đơn có mã giảm giá vẫn ghi giá gốc. Lỗi không nằm ở chỗ ai cẩu thả. Buổi nghiệm thu chưa từng đi qua luồng đó, nên không ai có cơ hội thấy nó sai. Cách chắc hơn là nghiệm thu bằng kịch bản kiểm thử: mỗi việc cần kiểm được viết thành một kịch bản bám theo quy trình thật, có điều kiện đầu, các bước và kết quả mong đợi. Người nghiệm thu ghi kết quả thực tế cho từng dòng, rồi ký theo danh sách đã chốt từ trước, không ký theo cảm giác.
Nghiệm thu nghĩa là người dùng tự xác nhận hệ thống làm được việc
Theo ISTQB Glossary phiên bản 4.8.1, kiểm thử chấp nhận người dùng (user acceptance testing, viết tắt UAT) là một loại kiểm thử chấp nhận, do người dùng dự định thực hiện để xác định họ có chấp nhận hệ thống hay không. Glossary này cũng xếp kiểm thử chấp nhận thành một cấp kiểm thử riêng, tập trung vào việc quyết định có nhận hệ thống hay không. Cả hai định nghĩa đều đặt người quyết định ở phía người dùng. Đội viết mã đã kiểm tra mọi hàm, nhưng nếu người dùng không chấp nhận, hệ thống vẫn chưa sẵn sàng để đưa vào vận hành.
Điểm này dễ bị bỏ qua khi một dự án chạy theo tiến độ. Kiểm thử trong đội kỹ thuật trả lời câu hỏi hệ thống có chạy đúng đặc tả không. UAT trả lời câu hỏi khác, và khó hơn: việc hệ thống làm có đúng với cách doanh nghiệp làm việc hay không. Vì vậy buổi xem demo không đủ để làm nghiệm thu. Nó cần một bộ việc cụ thể để chạy, một người chạy, và một cách ghi kết quả.
Kịch bản bám theo quy trình thật của người dùng
Kịch bản nghiệm thu không được viết theo danh sách màn hình. Nếu viết theo màn hình, người kiểm thử mở từng trang, bấm từng nút, và kiểm được từng ô riêng lẻ, nhưng không ai chạy cả chuỗi việc mà người dùng làm mỗi ngày. Lỗi giảm giá không nằm trong một màn hình nào. Nó nằm ở chỗ thông tin đi qua ba bước: nhập mã, tính tiền, rồi ghi vào báo cáo.
Tài liệu kế hoạch UAT của Đại học Arkansas mô tả cách làm này khá rõ. Các kịch bản được rút ra từ yêu cầu nghiệp vụ, mỗi kịch bản gồm nhiều test case có đầu vào, hành động và kết quả mong đợi, và có một ma trận truy vết để kiểm tra mọi yêu cầu đã có kịch bản phủ. Tài liệu này cũng yêu cầu liệt kê rõ phạm vi trong và ngoài nghiệm thu, để không ai hiểu nhầm rằng mọi thứ đã được kiểm. Với phần mềm quản lý bán hàng, một kịch bản đáng giá thường bắt đầu từ khách hàng vào đơn, đi qua giảm giá, thanh toán, và kết thúc ở báo cáo cuối ngày. Nhóm bán hàng đa kênh có thêm một lớp nữa, và phần mềm bán hàng omnichannel đòi hỏi kịch bản phủ cả đơn từ nhiều kênh vào cùng một báo cáo.
Khi chọn quy trình để viết, hãy bắt đầu từ việc quan trọng nhất với doanh nghiệp, không bắt đầu từ việc dễ kiểm nhất. Nếu cần vẽ trước các bước của quy trình, workflow là gì và cách thiết kế một quy trình khoa học là điểm bắt đầu hợp lý. Một kịch bản về đăng nhập rất dễ viết, nhưng nếu lỗi đơn giảm giá làm sai doanh thu mỗi ngày thì kịch bản đó phải đứng đầu danh sách. Người viết hỏi người vận hành: việc nào nếu sai thì mất tiền, mất khách, hoặc phải làm lại bằng tay?
Mỗi kịch bản cần điều kiện đầu, các bước và kết quả mong đợi
ISTQB định nghĩa test case là một tập gồm điều kiện đầu, đầu vào, hành động (khi cần), kết quả mong đợi và điều kiện sau, được xây dựng từ các điều kiện kiểm thử. Test procedure, theo cùng glossary, là một chuỗi test case theo thứ tự thực hiện, kèm các việc chuẩn bị điều kiện đầu và dọn dẹp sau khi chạy. Bài này gọi “kịch bản kiểm thử” là một test procedure đi theo một quy trình nghiệp vụ. Mỗi dòng trong kịch bản là một test case nhỏ, và người nghiệm thu chạy lần lượt từ trên xuống.
Bảng dưới đây là một dòng kịch bản mẫu. Dữ liệu trong bảng là ví dụ minh hoạ để thấy cấu trúc, không phải số liệu của khách hàng nào. Cột “Điều kiện đầu” phải đủ để người khác dựng lại đúng trạng thái trước khi chạy. Cột “Các bước” viết bằng động từ, mỗi bước một hành động. Cột “Kết quả mong đợi” viết thành con số hoặc hiện tượng nhìn thấy được, không viết “hiển thị đúng”.
| Mã | Điều kiện đầu | Các bước | Kết quả mong đợi | Kết quả thực | Trạng thái |
|---|---|---|---|---|---|
| UAT-BH-03 | Khách thuộc nhóm VIP, có mã giảm 10%, giỏ hàng có hai sản phẩm với tổng 500.000đ | 1. Tạo đơn mới cho khách. 2. Thêm hai sản phẩm. 3. Nhập mã giảm giá. 4. Bấm xác nhận đơn. | Tổng thanh toán là 450.000đ. Đơn hiện dòng “Mã giảm 10%”. Báo cáo cuối ngày ghi đúng 450.000đ. | Người nghiệm thu điền sau khi chạy | Chưa chạy |
Cột “Kết quả thực” để trống khi soạn kịch bản, và người nghiệm thu điền ngay sau khi chạy. Không ghi “ổn” vào ô này. Ghi con số đã thấy, ví dụ 500.000đ, để đội kỹ thuật biết chính xác hệ thống làm gì. Cột “Trạng thái” chỉ có ba giá trị: đạt, không đạt, hoặc bị chặn vì một lỗi khác. Một kịch bản bị chặn phải ghi mã lỗi chặn nó, không được bỏ qua lặng lẽ.
Lỗi ghi đủ để người khác làm lại được đúng lỗi đó
Một dòng ghi lỗi kiểu “đơn giảm giá sai” không giúp ai sửa được gì. Đội kỹ thuật phải đoán mã nào bị dùng, khách nào, sản phẩm nào, và sai ở bước nào. Lỗi ghi đủ để tái hiện cần có mã kịch bản, số bước làm lỗi xuất hiện, dữ liệu đã nhập, kết quả thực, kết quả đúng mong đợi, ảnh chụp màn hình, thời điểm và người chạy. Có đủ bấy nhiêu thứ, người sửa lỗi làm lại được đúng việc người nghiệm thu đã làm và thấy cùng một kết quả.
Mức độ nghiêm trọng đánh theo ảnh hưởng tới nghiệp vụ, không theo mức khó chịu của người chạy. Một lỗi làm sai tiền khi thanh toán là nghiêm trọng, dù giao diện vẫn đẹp. Một lỗi căn lệch vài pixel ở trang in thì để sau cũng được. Khi đã chốt cách phân loại trước buổi nghiệm thu, cuộc tranh luận về từng lỗi sẽ ngắn hơn nhiều.
Ai tham gia nghiệm thu và việc của từng người
Tài liệu UAT của Đại học Arkansas phân vai khá gọn. Trưởng nhóm UAT điều phối mọi việc và làm việc với các bên liên quan. Người kiểm thử là người dùng cuối, họ chạy kịch bản, ghi lỗi và phản hồi. Nhà phân tích nghiệp vụ hỗ trợ viết kịch bản và trả lời những chỗ yêu cầu chưa rõ. Đội phát triển xử lý lỗi và hỗ trợ người kiểm thử khi họ bị kẹt. Quản lý dự án theo dõi lịch và báo cáo tiến độ cho ban lãnh đạo.
Ranh giới trong bảng phân vai này quan trọng hơn bản thân danh sách. Người viết mã không nên được quyết định một kịch bản đã đạt hay chưa, vì họ biết hệ thống hoạt động thế nào và dễ bỏ qua những chỗ người dùng thực sự đi vào. Người nghiệm thu không tự sửa cấu hình để chạy cho qua. Mỗi người có một việc, và việc đó được ghi trong biên bản nghiệm thu.
Tổ chức buổi nghiệm thu theo thứ tự rõ ràng
Buổi nghiệm thu thường mất thời gian nhất ở việc chuẩn bị, không phải ở lúc chạy kịch bản. Nếu dữ liệu thử chưa sẵn, người nghiệm thu sẽ ngồi chờ. Nếu phạm vi chưa rõ, mỗi người sẽ hỏi lại về một chức năng khác nhau. Dưới đây là thứ tự làm việc, dựa trên các thành phần mà tài liệu UAT của Đại học Arkansas liệt kê: phạm vi, kịch bản, dữ liệu, thực hiện, lỗi và tiêu chí chấp nhận.
Ảnh dưới đây chụp một buổi làm việc kiểu họp bàn, nơi người dùng và người phân tích rà lại kịch bản trước khi chạy. Trước khi bắt đầu, cả nhóm cần thống nhất những gì được kiểm và những gì không được kiểm trong đợt này.
- Chốt phạm vi: liệt kê các quy trình nằm trong đợt nghiệm thu và các quy trình để lại cho đợt sau.
- Viết kịch bản theo từng quy trình nghiệp vụ, mỗi quy trình một nhóm, mỗi dòng có đủ điều kiện đầu, bước và kết quả mong đợi.
- Chuẩn bị dữ liệu thử gần với thực tế, dùng được dữ liệu đã ẩn danh hoặc dữ liệu tổng hợp, và ghi rõ dữ liệu nào đã dùng. Cách tổ chức dữ liệu nghiệp vụ để lấy ra thử nghiệm được cũng là một phần của cách quản lý dữ liệu cho doanh nghiệp.
- Người nghiệm thu chạy kịch bản, điền kết quả thực và trạng thái ngay sau mỗi dòng, không để đến cuối ngày mới điền lại.
- Lỗi đưa vào một danh sách chung với đủ thông tin tái hiện. Đội kỹ thuật sửa, rồi chạy lại đúng kịch bản bị lỗi.
- Đối chiếu kết quả với tiêu chí đạt hoặc không đạt đã chốt từ trước, rồi mới ký.
Ký nghiệm thu theo danh sách tiêu chí đã chốt từ trước
Tài liệu UAT của Đại học Arkansas yêu cầu xác định tiêu chí đạt hoặc không đạt ngay từ đầu. Tiêu chí có thể là số lỗi tối đa được chấp nhận, hoặc danh sách các kịch bản quan trọng bắt buộc phải đạt. Sau khi nghiệm thu xong, bước ký là xác nhận chính thức của các bên liên quan về nghiệp vụ. Thứ tự này rất quan trọng: tiêu chí được viết trước khi có kết quả, nên không ai có thể đổi tiêu chí để khớp với kết quả đã có.
Trong thực tế, một biên bản nghiệm thu tốt có ba phần rõ ràng. Trước khi viết kịch bản, người phụ trách đọc qua kiểm thử phần mềm là gì và quy trình kiểm thử gồm những bước nào để hiểu UAT đứng ở đâu trong chuỗi kiểm thử. Phần một là danh sách kịch bản đã chạy, với kết quả thực của từng dòng. Phần hai là danh sách lỗi còn mở, mỗi lỗi có mức nghiêm trọng và người chấp nhận rủi ro nếu còn để lại. Phần ba là chữ ký của người có quyền nghiệm thu, đi kèm ngày ký. Biên bản kiểu cảm tưởng chỉ có một dòng “đã kiểm tra, ổn”, và chính dòng đó sẽ không giúp gì khi lỗi đơn giảm giá xuất hiện sau một tuần.
Hỏi đáp
Nghiệm thu UAT khác kiểm thử thông thường ở điểm nào?
Kiểm thử trong đội kỹ thuật kiểm tra hệ thống có chạy đúng đặc tả không. UAT kiểm tra một câu hỏi khác: người dùng dự định có chấp nhận hệ thống để làm việc hay không. Cả hai đều cần kịch bản và kết quả ghi lại, nhưng người quyết định khác nhau. Vì vậy một hệ thống qua hết kiểm thử kỹ thuật vẫn có thể không qua nghiệm thu, khi quy trình thực tế của doanh nghiệp không khớp với cách hệ thống xử lý.
Người không biết lập trình có viết được kịch bản không?
Có. Kịch bản viết bằng ngôn ngữ nghiệp vụ, mô tả việc người dùng làm và thứ họ thấy, không mô tả cách hệ thống được xây dựng. Người vận hành đã biết quy trình của mình, nên họ thường là người hiểu quy trình rõ nhất để viết kịch bản. Phần kỹ thuật cần được hỗ trợ ở cột điều kiện đầu, nơi phải nói rõ dữ liệu nào đã có sẵn trong môi trường thử.
Có cần kiểm mọi chức năng trước khi ký không?
Không. Điều quan trọng là phạm vi được ghi rõ. Tài liệu UAT của Đại học Arkansas yêu cầu liệt kê cả phạm vi trong và ngoài nghiệm thu, để những gì chưa kiểm được biết trước, không bị hiểu nhầm là đã đạt. Một đợt nghiệm thu nhỏ nhưng phủ đúng các quy trình quan trọng thường có giá trị hơn một đợt dài mà không ai biết đã kiểm gì.
Lỗi nhỏ còn lại có ký nghiệm thu được không?
Được, nếu tiêu chí đã cho phép và lỗi được ghi đầy đủ. Lỗi còn lại phải có mức nghiêm trọng, mô tả tái hiện, và người chấp nhận rủi ro được ghi tên trên biên bản. Lỗi tiền bạc hay lỗi làm sai báo cáo không được đi vào vận hành chỉ vì buổi nghiệm thu đã kéo dài.
Có nhất thiết phải dùng phần mềm quản lý kiểm thử không?
Không bắt buộc. Một bảng tính đủ cột như bảng kịch bản ở trên vẫn dùng được, miễn là mỗi dòng có mã, các bước và kết quả thực được điền ngay khi chạy. Phần mềm quản lý kiểm thử giúp khi số kịch bản lớn và nhiều người cùng chạy song song. Với quy mô nhỏ, điều quyết định là kỷ luật ghi kết quả, không phải công cụ.
Doanh nghiệp đang cần phần mềm theo yêu cầu và muốn có kịch bản nghiệm thu ngay từ đầu dự án bắt đầu từ trang dịch vụ viết phần mềm theo yêu cầu của MONA. Khi cần trao đổi trực tiếp về phạm vi và cách chia đợt nghiệm thu, gọi hotline 1900 636 648.
