Lập kế hoạch kiểm thử, UAT và nghiệm thu sản phẩm bàn giao.

Thiết kế kiểm thử theo điều cần chứng minh

Kế hoạch nên bắt đầu từ yêu cầu, rủi ro và các luồng sử dụng quan trọng. Với hệ thống mua hàng, cần xem tạo yêu cầu, phê duyệt, đặt hàng, nhận và đối soát cùng những ngoại lệ phù hợp. Một danh sách màn hình không thể hiện đầy đủ hành trình. Những yêu cầu phi chức năng như quyền, hiệu năng và phục hồi cần cách kiểm chứng riêng theo mức ảnh hưởng.

Đội kỹ thuật có thể kiểm tra thành phần, giao diện và tích hợp; người dùng kiểm tra tính phù hợp của quy trình; vận hành kiểm tra khả năng hỗ trợ và khôi phục. Ranh giới giữa các nhóm cần thống nhất để tránh bỏ sót hoặc làm trùng không cần thiết. Nếu cùng một kiểm tra cung cấp bằng chứng cho nhiều mục đích, phải ghi rõ phạm vi và điều kiện của bằng chứng.

Tài liệu ISTQB về acceptance testing cho thấy vai trò phối hợp giữa nghiệp vụ và kiểm thử. Áp dụng trong doanh nghiệp cần người có hiểu biết quy trình, không chỉ người rảnh để tham dự. Họ phải có đủ thời gian chuẩn bị dữ liệu, thực hiện và xác nhận. Khi kiểm thử không có chủ sở hữu phù hợp, lịch có thể hoàn thành nhưng quyết định chấp nhận vẫn thiếu cơ sở.

Các năng lực trong chương trình Quản Lý Dự Án IT giúp đưa những phần việc này vào kế hoạch. Sau khi xác định cần chứng minh điều gì, đội cần xây dữ liệu và môi trường đủ đại diện cho công việc, thay vì chỉ tạo điều kiện để kịch bản dễ chạy.

Chuẩn bị dữ liệu, môi trường và vai trò trước khi mở UAT

Môi trường phải có phiên bản, cấu hình và giao diện phù hợp với phạm vi kiểm tra. Không nhất thiết giống mọi chi tiết của production, nhưng những khác biệt có thể ảnh hưởng kết luận cần được ghi rõ. Nếu hiệu năng chỉ được thử trên cấu hình nhỏ, kết quả không tự chứng minh khả năng xử lý tại quy mô sử dụng. Người đọc phải biết giới hạn của bằng chứng.

Dữ liệu nên bao quát các trường hợp thông thường và ngoại lệ có ý nghĩa. Với mua hàng, cần đơn có một và nhiều nguồn chi phí, người dùng có vai trò khác nhau, giá trị thiếu hoặc trạng thái bị trả lại. Nếu dùng dữ liệu thực, phải áp dụng kiểm soát phù hợp; nếu dùng dữ liệu giả, phải bảo đảm nó đại diện cho quy tắc cần kiểm tra. Độ thuận tiện không nên là tiêu chí duy nhất khi chọn mẫu.

Người dùng cần biết mục tiêu, cách thực hiện và nơi ghi kết quả. Kịch bản phải đủ hướng dẫn nhưng không ép họ bỏ qua bước nghiệp vụ cần thiết. Khi gặp tình trạng không phù hợp, cần ghi điều đã làm, kết quả mong đợi, kết quả thực tế và dữ liệu liên quan. Những thông tin này giúp phân biệt lỗi sản phẩm, sai cấu hình, thiếu hướng dẫn hay yêu cầu còn mơ hồ.

Vấn đề quyền và dữ liệu cần có sự tham gia của quản lý an toàn thông tin. Tài khoản kiểm thử không nên có quyền rộng đến mức che mất sai lệch phân quyền. Điều kiện mở UAT cần xác nhận các đầu vào ấy đã có, để người dùng không mất thời gian chờ những việc lẽ ra phải chuẩn bị trước.

Đặt điều kiện bắt đầu và kết thúc có bằng chứng

Điều kiện bắt đầu có thể gồm yêu cầu đã đủ rõ, phiên bản ổn định cho phạm vi kiểm tra, dữ liệu sẵn sàng và người tham gia đã được bố trí. Những kiểm tra kỹ thuật cần thiết trước UAT cũng phải có kết quả phù hợp. Nếu bắt đầu khi đầu vào chưa đạt, cần quyết định phạm vi giới hạn và ghi phần chưa thể kiểm chứng. Không nên báo UAT đang chạy đầy đủ trong khi nhiều luồng còn bị chặn.

Điều kiện kết thúc phải phản ánh độ bao phủ và tác động lỗi, không chỉ tỷ lệ kịch bản đạt. Một tỷ lệ cao có thể che một luồng kinh doanh thiết yếu chưa sử dụng được. Cần quy định cách phân loại và quyền chấp nhận tồn đọng theo cơ chế dự án. Các ngưỡng phải được lựa chọn theo rủi ro và nghĩa vụ thực tế, không lấy một con số chung làm chuẩn mọi hệ thống.

Bảng sau là công cụ đề xuất để nối kế hoạch kiểm thử với quyết định. Các điều kiện cụ thể cần được thống nhất cho dự án trước khi thực hiện.

Trong tình huống mở bài, luồng nhiều trung tâm chi phí cần được đánh giá theo tác động nghiệp vụ. Nếu nó là phần quan trọng đã thống nhất, không thể coi tỷ lệ đạt chung là lý do bỏ qua. Có thể sửa trước, giới hạn phạm vi sử dụng hoặc xem xét phương án khác theo quyền, nhưng quyết định phải giữ được điều kiện và trách nhiệm.

Theo dõi lỗi và kiểm tra lại theo phiên bản

Mỗi lỗi cần được liên kết với kịch bản, yêu cầu và phiên bản có liên quan. Đánh giá mức nghiêm trọng dựa trên tác động, còn ưu tiên xử lý cần nhìn thời điểm và phụ thuộc. Người quản lý phải thống nhất quy tắc với đội kiểm thử và nghiệp vụ để các nhóm không dùng cùng một nhãn theo nghĩa khác nhau. Lỗi có tranh luận về phạm vi cần được đưa đến người có quyền làm rõ.

Sau khi sửa, kiểm tra lại xác nhận sai lệch đã được xử lý, còn hồi quy xem thay đổi có gây ảnh hưởng đến phần khác không. Mức hồi quy nên dựa vào tác động và quan hệ hệ thống. Không cần kiểm tra lại mọi thứ cho mọi sửa đổi, nhưng cũng không nên mặc định chỉ chạy đúng kịch bản từng thất bại. Các yêu cầu liên quan trong RTM giúp định hướng phạm vi cần xem.

Nếu phiên bản thay đổi trong UAT, phải biết kết quả nào còn phù hợp và phần nào cần thực hiện lại. Không gộp kết quả của nhiều phiên bản rồi xem đó là bằng chứng cho bản cuối mà không đánh giá. Quyền sửa môi trường cũng cần kiểm soát để kết quả phản ánh một cấu hình xác định. Khi có khác biệt, hồ sơ phải giúp tái tạo điều kiện đã kiểm tra.

Nguồn lực sửa và kiểm tra lại cần được xác nhận cùng Trưởng Phòng IT – IT Manager và đầu mối nghiệp vụ. Một lịch UAT chỉ tính lượt đầu sẽ thiếu chỗ cho phần thường cần sau phát hiện. Phải dùng dữ liệu hiện tại để dự báo công việc còn lại, không giữ ngày kết thúc cũ bằng cách giảm độ sâu kiểm tra.

Phân định nghiệm thu sản phẩm với cho phép vận hành

Nghiệm thu cần đối chiếu sản phẩm với điều kiện đã thống nhất và các nghĩa vụ liên quan. Nếu có yếu tố hợp đồng, người có thẩm quyền phải xác nhận cách áp dụng theo hồ sơ thực tế. Người quản lý không nên suy diễn rằng hết thời gian kiểm tra hoặc không nhận phản hồi sẽ tự động có nghĩa chấp nhận. Mỗi quyết định phải có cơ sở phù hợp với thỏa thuận và cơ chế tổ chức.

Cho phép Go-live còn cần những điều kiện hỗ trợ, giám sát, dữ liệu và khả năng phục hồi. Một sản phẩm đạt chức năng có thể chưa sẵn sàng triển khai nếu đội tiếp nhận chưa có quyền truy cập hoặc chưa thực hành xử lý tình huống. Các năng lực của Quản Lý Dịch Vụ IT – ITSM giúp kiểm tra phần này và xác định nơi nhận trách nhiệm sau triển khai.

Tồn đọng được chấp nhận cần có người chịu tác động, biện pháp kiểm soát, người sửa và thời hạn. Nếu sử dụng cách thủ công tạm thời, phải biết khối lượng nào còn xử lý được và khi nào cần xem lại. Một biên bản ghi lỗi nhỏ sẽ xử lý sau không đủ nếu chưa mô tả nghĩa vụ cụ thể. Chấp nhận có điều kiện phải được thông báo cho người vận hành thực tế.

Khóa hồ sơ để bằng chứng tiếp tục sử dụng được

Sau quyết định, giữ phiên bản được chấp nhận, yêu cầu liên quan, kết quả kiểm tra và danh sách phần còn mở. Hồ sơ phải truy cập được bởi người có trách nhiệm khi vận hành hoặc xử lý tranh chấp. Những bằng chứng nằm riêng trong tài khoản một thành viên hoặc công cụ của đối tác cần được chuyển theo quyền sử dụng phù hợp. Đóng dự án không nên làm mất đường đi đến căn cứ nghiệm thu.

Rà soát sau sử dụng có thể cho thấy các kịch bản ban đầu đã bỏ sót ngoại lệ. Bài học nên chuyển thành cách chọn dữ liệu, mô tả tiêu chí và chuẩn bị người dùng cho lần sau. Không nên chỉ kết luận cần kiểm thử kỹ hơn; phải biết cần bổ sung loại kiểm tra nào và ai chịu trách nhiệm. Sự cụ thể giúp tổ chức học từ lỗi mà không làm mọi dự án mang cùng gánh nặng.

Với hệ thống mua hàng ở mở bài, bước đầu là đối chiếu luồng nhiều trung tâm chi phí với yêu cầu và tiêu chí đã duyệt, rồi chọn cách xử lý có căn cứ. Kế hoạch kiểm thử tốt tạo cơ hội phát hiện trước khi quyết định chấp nhận bị ép bởi ngày lịch. Khi UAT, nghiệm thu và Go-live được nối bằng bằng chứng, chữ ký bàn giao phản ánh khả năng sử dụng mà doanh nghiệp thực sự có.

Bài viết liên quan

• Quản lý yêu cầu và khả năng truy xuất bằng Requirements Traceability Matrix.
• Kiểm soát nhà thầu và các sản phẩm bàn giao theo hợp đồng.
• Lập kế hoạch Go-live, Rollback và hỗ trợ sau triển khai.
• Khách hàng đổi yêu cầu sát ngày nghiệm thu: Project Manager nên phản hồi ra sao?

Nguồn tham khảo

1. ISTQB — Certified Tester Acceptance Testing
2. APM — What is quality management and control?
3. UK Government — Government Functional Standard GovS 002: Project Delivery