Nghiệm thu phần mềm thường mất bao lâu?

Tùy phạm vi dự án, thường từ vài ngày đến vài tuần cho một hệ thống nội bộ vừa. Thời gian phụ thuộc chủ yếu vào việc tiêu chí nghiệm thu đã được viết rõ từ đầu dự án hay chưa và số vòng sửa lỗi chặn cần thiết.

Ai trong doanh nghiệp nên tham gia kiểm thử UAT?

Những nhân viên sẽ dùng phần mềm hằng ngày, mỗi phòng ban có tính năng cử một người. Không nên giao toàn bộ cho bộ phận IT hay một trợ lý, vì chỉ người làm công việc thật mới phát hiện được các tình huống ngoại lệ thực tế.

Lỗi phát hiện sau khi đã ký biên bản nghiệm thu thì xử lý thế nào?

Lỗi thuộc phạm vi đã nghiệm thu sẽ được sửa trong thời gian bảo hành theo hợp đồng. F2C Labs bảo hành ba tháng sau bàn giao cho mọi dự án. Yêu cầu vượt ngoài phạm vi ban đầu được hai bên thỏa thuận riêng.

Có nên ký biên bản khi phần mềm vẫn còn lỗi?

Chỉ nên ký khi các lỗi chặn nghiệm thu đã được sửa hết. Lỗi nhỏ không ảnh hưởng vận hành có thể ghi kèm trong biên bản cùng thời hạn sửa cụ thể trong bảo hành, thay vì nhận lời hứa sửa sau bằng miệng.

Nghiệm thu phần mềm: quy trình UAT trước khi nhận bàn giao

Nhiều doanh nghiệp coi nghiệm thu là buổi họp cuối dự án: hai bên ngồi lại, đơn vị làm phần mềm trình chiếu vài màn hình đẹp, khách hàng ký biên bản, chuyển khoản đợt cuối, xong. Cách làm đó biến nghiệm thu từ một công cụ bảo vệ người mua thành thủ tục giấy tờ, và hậu quả thường chỉ lộ ra vài tuần sau, khi nhân viên dùng thật thì báo lỗi khắp nơi còn đơn vị làm thì trả lời rằng biên bản đã ký. Nghiệm thu phần mềm là một quy trình có chuẩn bị, có tiêu chí và có bằng chứng, và người làm chủ doanh nghiệp hoàn toàn có thể tự điều hành nó mà không cần biết lập trình. Bài viết này trình bày quy trình đó theo đúng thứ tự bạn sẽ gặp trong một dự án thật.

Nghiệm thu phần mềm là gì và vì sao nó quyết định bạn nhận được gì

Nghiệm thu phần mềm là quá trình khách hàng kiểm tra và xác nhận rằng sản phẩm bàn giao đúng với những gì hai bên đã thỏa thuận trong hợp đồng và tài liệu yêu cầu. Chữ ký trong biên bản nghiệm thu có hai ý nghĩa lớn: dự án được coi là hoàn thành nghĩa vụ giai đoạn xây dựng, và sau đó mọi sửa đổi nhỏ sẽ được tính theo hướng bảo hành hoặc phát sinh phí, tùy điều khoản. Vì vậy nghiệm thu không phải nghi lễ kết thúc mà là thời điểm duy nhất bạn còn giữ được thế đàm phán mạnh nhất: khi chưa ký, việc sửa cho đúng là nghĩa vụ của đơn vị làm; khi đã ký, quan hệ chuyển sang một giai đoạn khác.

Điều đó không có nghĩa bạn nên kéo dài nghiệm thu vô hạn. Một quy trình tốt chốt được trong vài tuần nếu cả hai bên đi đúng bước, và đơn vị làm chuyên nghiệp sẽ không ngại một quy trình như vậy, vì nó cũng bảo vệ họ khỏi những yêu cầu vô tận không có trong phạm vi ban đầu.

UAT khác gì những đợt kiểm thử đơn vị phần mềm đã làm

Trong suốt dự án, đội kỹ thuật chạy nhiều loại kiểm thử: kiểm thử từng hàm riêng lẻ, kiểm thử tích hợp giữa các module, kiểm thử hiệu năng và bảo mật. Những đợt đó trả lời câu hỏi hệ thống có chạy đúng như kỹ thuật thiết kế hay không. UAT, viết tắt của User Acceptance Testing hay kiểm thử chấp nhận người dùng, trả lời một câu hỏi khác: phần mềm có giải quyết được công việc thực tế của người dùng thực tế hay không.

Sự khác biệt nằm ở người kiểm thử và dữ liệu kiểm thử. Kỹ thuật kiểm thử bằng dữ liệu mẫu do họ tự tạo, còn UAT do chính nhân viên của bạn thao tác với tình huống công việc thật: một đơn hàng thật, một quy trình duyệt thật, một báo cáo thật với số liệu thật. Chính vì thế UAT thường lộ ra những vấn đề mà kiểm thử kỹ thuật không bao giờ thấy, ví dụ một bước xử lý ngoại lệ mà chỉ kế toán của bạn mới biết là tồn tại.

Chuẩn bị tiêu chí nghiệm thu từ trước khi bàn giao

Danh sách tiêu chí nghiệm thu phần mềm được ghi trên clipboard — Tiêu chí nghiệm thu viết ra từ đầu dự án giúp buổi UAT đi đúng trọng tâm.

UAT chỉ có ý nghĩa khi có thứ để đo. Thứ đó là bộ tiêu chí nghiệm thu, và nó nên được viết ra từ đầu dự án chứ không phải trước buổi họp nghiệm thu vài ngày. Tiêu chí tốt mô tả hành vi quan sát được: đăng nhập bằng tài khoản nội bộ thì vào được trang tổng quan trong vòng ba giây, tạo đơn mới với đủ trường bắt buộc thì đơn xuất hiện trong danh sách chờ duyệt và người duyệt nhận được thông báo, người không có quyền kế toán thì không xem được báo cáo doanh thu. Mỗi tiêu chí như vậy có kết quả đạt hoặc không đạt, không có chuyện đạt một nửa.

Nếu bạn chưa có tài liệu này, hãy ngồi lại với đơn vị làm để lập nó ngay khi nhận thông báo chuẩn bị bàn giao. Tài liệu yêu cầu và báo giá ban đầu là nền để đối chiếu. Bạn có thể tham khảo bài viết về cách viết tài liệu yêu cầu phần mềm trên blog này, vì tiêu chí nghiệm thu chính là phần tiếp nối tự nhiên của tài liệu yêu cầu được viết tử tế.

Quy trình UAT từng bước cho đội không chuyên kỹ thuật

Nhân viên kiểm thử phần mềm với tình huống công việc thật — UAT do chính người dùng thực tế thao tác với dữ liệu và tình huống thật.

Bước đầu tiên là chọn người kiểm thử nội bộ. Hãy chọn những nhân viên sẽ dùng phần mềm hằng ngày, mỗi phòng ban có tính năng thì cử một người, và phân công rõ ai kiểm phần nào. Kế toán kiểm phần báo cáo tài chính, kho kiểm phần xuất nhập tồn, quản lý kiểm phần phê duyệt và phân quyền.

Bước thứ hai là viết kịch bản kiểm thử dựa trên công việc thật. Thay vì bấm bừa xem lỗi ở đâu, mỗi người kiểm theo một danh sách tình huống cụ thể: nhập một phiếu nhập kho mới, duyệt một đơn xin nghỉ phép, xuất báo cáo doanh thu tháng trước ra file Excel. Mỗi tình huống ghi kết quả mong đợi theo tiêu chí đã chốt, và người kiểm ghi lại kết quả thực tế cùng ảnh chụp màn hình khi có lỗi.

Bước thứ ba là tổng hợp lỗi vào một bảng chung, phân loại rõ lỗi chặn nghiệm thu và lỗi có thể sửa trong bảo hành. Nút bấm không hoạt động hay tính sai số tiền là lỗi chặn. Chữ hiển thị lệch một dòng hay màu sắc chưa đúng ý thích là lỗi có thể hẹn. Việc phân loại này giữ cho buổi nghiệm thu đi về đích thay vì tranh cãi từng chi tiết nhỏ.

Bước thứ tư là đơn vị làm sửa lỗi chặn và hai bên kiểm lại chỉ những điểm đã sửa cộng thêm một vòng kiểm hồi quy nhanh để chắc rằng sửa chỗ này không làm hỏng chỗ khác. Khi danh sách lỗi chặn bằng không, hai bên có thể ngồi vào buổi nghiệm thu chính thức và ký biên bản với danh sách lỗi tồn đọng kèm thời hạn sửa trong bảo hành.

Những lỗi doanh nghiệp hay mắc khi nghiệm thu

Lỗi phổ biến nhất là cử người không dùng phần mềm đi kiểm thử, thường là anh IT hoặc một trợ lý rảnh việc. Hệ quả là những khó chịu trong công việc hằng ngày chỉ bị phát hiện sau khi nhân viên thật bắt đầu dùng. Lỗi thứ hai là kiểm thử bằng dữ liệu giả quá đẹp, mọi số tròn trĩnh, mọi tình huống đúng chuẩn, trong khi thực tế vận hành đầy ngoại lệ. Lỗi thứ ba là ký biên bản khi vẫn còn lỗi chặn với hứa hẹn sẽ sửa sau, khiến thế mạnh duy nhất của bạn tan biến cùng chữ ký. Lỗi thứ tư là bỏ qua phần kiểm tra phân quyền và dữ liệu cũ: ai được xem gì, dữ liệu nhập từ file Excel cũ vào có đúng và đủ không. Cuối cùng là không ghi lại bằng chứng, để rồi tranh luận sau đó chỉ còn là lời nói đối lại lời nói.

Sau biên bản: bàn giao mã nguồn, tài liệu và bảo hành

Hai bên ký biên bản nghiệm thu và bàn giao dự án phần mềm — Chỉ ký biên bản khi danh sách lỗi chặn đã về không.

Nghiệm thu xong chưa phải kết thúc hợp đồng. Ngay sau ký, hãy chắc chắn bạn nhận đủ ba thứ: toàn bộ mã nguồn cùng quyền sở hữu như hợp đồng đã ghi, bộ tài liệu hướng dẫn cài đặt và vận hành, và xác nhận bằng văn bản về thời gian cùng phạm vi bảo hành. Bàn giao đầy đủ mã nguồn và tài liệu là cách làm tiêu chuẩn ở F2C Labs, và bảo hành ba tháng sau bàn giao là cam kết chúng tôi đưa ra cho mọi dự án, vì lỗi thật thường xuất hiện khi hệ thống chạy với dữ liệu và cường độ thật. Bạn cũng nên đọc thêm bài về bảo trì phần mềm doanh nghiệp sau bảo hành trên blog này để chuẩn bị cho giai đoạn vận hành dài hạn, và bài checklist nghiệm thu khi thuê đơn vị thiết kế web app nếu muốn có một bản in ra để đối chiếu trong buổi họp.

Nếu doanh nghiệp của bạn đang chuẩn bị thuê một đội làm phần mềm theo yêu cầu và muốn trao đổi trước về cách đặt tiêu chí nghiệm thu cho đúng ngay từ hợp đồng, F2C Labs sẵn sàng trò chuyện một buổi tư vấn không cam kết qua trang liên hệ của website này.