UAT hay còn gọi là Beta testing, là giai đoạn cuối của kiểm thử phần mềm. UAT được thực hiện sau giai đoạn Alpha Testing (test nội bộ bao gồm functional, integration và system testing) dựa trên những tài liệu (Business, Functional, Non-Functional Requirements, v.v.) đã được tạo và chốt với khách hàng ở giai đoạn Solution. Các giai đoạn kiểu thử trước đó đều do các developer xử lý và tiến hành test. Còn với beta testing, người kiểm thử có thể là khách hàng, hoặc BA/BrSE dự án đứng dưới góc nhìn của end-user. Giai đoạn kiểm thử này có những khó khăn gì? Làm thế nào nào để nghiệm thu kết quả test hiệu quả?

1. Trở ngại khi kiểm thử UAT: 

Có thể nói, kiểm thử UAT là một cái nhìn bao quát lại project. Bởi vì là bước test cuối, khối lượng công việc ở giai đoạn test này chắc chắn rất nặng. Một số trở ngại của các tester trong gia đoạn kiểm thử này là:

● Ước lượng sai thời gian kiểm thử:

Vấn đề này thường xảy ra với các đội nhóm chưa có kinh nghiệm kiểm thử. Do chưa có kinh nghiệm lên timeline test, các tester sẽ mất nhiều thời gian kiểm thử hơn. Điều này có thể dẫn đến sự chồng chéo của kiểm thử hệ thống và kiểm thử UAT. Phần mềm được kiểm thử trong môi trường UAT thậm chí không hoàn thành được kiểm thử chức năng, dẫn đến sự thiếu chính xác trong phần mềm.

● Chưa làm rõ môi trường UAT:

Nên tách biệt UAT với môi trường kiểm thử chức năng và kiểm thử hệ thống. Thực hiện UAT trên cùng 2 môi trường kia có thể dẫn đến thiếu trường hợp thực tế. Với một môi trường UAT riêng, tester dễ dàng thấy được phiên bản phần mềm mới nhất cần triển khai. 

● UAT Tester thiếu kiến thức về sản phẩm:

Mặc dù nói người thực hiện UAT là end-user nhưng end-user ở đây là những ai? Theo kinh nghiệm của AMELA, người kiểm thử thường sẽ là:

◦ Người dùng thực tế của sản phẩm đang go live

◦ Người dùng phiên bản trước đó của sản phẩm

◦ Các stakeholders có liên quan tới giai đoạn phát triển sản phẩm

◦ BA/BrSE dự án đứng trên góc nhìn của end-user

● Xử lý lỗi phát sinh và các yêu cầu nghiệp vụ:

Trong quá trình UAT, sẽ có những lỗi mới mà có thể tester chưa gặp bao giờ. Nguyên nhân là do không rõ ràng trong tài liệu hoặc những người kiểm thử đưa lên các lỗi giống nhau.

● Vấn đề giao tiếp giữa các team:

Thông thường, tester là BA và BrSE thì sẽ ít xảy ra vấn đề trong  quá trình trao đổi do được làm việc trực tiếp. Nếu người kiểm thử là khách hàng, thì việc giao tiếp bằng email giữa các team offshore và onsite có thể gây ra độ trễ lớn. Chính vì thế, 2 bên nên thống nhất phương thức giao tiếp phù hợp nhất để kịp tiến độ dự án. Tại AMELA, chúng tôi sẽ tạo một file feedback list, khách hàng có thể tổng hợp lại toàn bộ lỗi trong quá trình test, đội phát triển sẽ xác nhận lại, và tiếp hành chỉnh sửa và sẽ báo lại khách hàng qua file này.

2. Góc nhìn nghiệm thu

Để khắc phục những khó khăn trong quá trình kiểm thử UAT, bạn có thể tham khảo góc nhìn nghiệm thu cơ bản như sau:

2.1: Góc nhìn nghiệm thu cơ bản

2.2 Góc nhìn nghiệm thu kiểm thử chức năng & kiểm thử phi chức năng

2.3 Góc nhìn nghiệm thu – UI/UX

3. Lời kết

Trên đây là những khó khăn trong quá trình nghiệm thu UAT và những góc nhìn nghiệm thu cơ bản nhất giúp người kiểm thử tránh được lỗi không đáng có và khắc phục khó khăn trong quá trình kiểm thử. Kiểm thử UAT là công đoạn then chốt quyết định tính hoàn thiện của sản phẩm. Với hơn 4 năm kinh nghiệm làm việc với các doanh nghiệp lớn nhỏ, AMELA đã xây dựng được một quy trình kiểm thử UAT khoa học, dễ theo dõi và thực hiện và quan trọng nhất là hiệu quả, hài lòng khách hàng.

Bạn đang muốn thiết kế website? hay phát triển một mobile-app? Liên hệ với AMELA ngay để nhận tư vấn miễn phí!

Biên tập: AMELA