UAT - User Acceptance Testing (edit)

Các vị trí trong dự án phát triển phần mềm:

• Product Owner (PO)
• Scrum Master
• Development Team (Member)

• Project Manager (PM)
• Business Analyst (BA)
• Quality Control (QC)
• Quality Assurance (QA)
• Software Tester (QA/QC)

https://itviec.com/blog/qc-la-gi-qa-la-gi/

https://usersnap.com/blog/user-acceptance-testing-right/

https://usersnap.com/blog/an-agencys-guide-to-successful-website-user-acceptance-testing/

https://www.linkedin.com/pulse/user-acceptance-testing-uat-nguyen-duong-hai

https://topdev.vn/blog/uat-user-acceptance-testing/

https://viblo.asia/p/cac-loai-user-acceptance-testing-gAm5yoqqZdb

https://viblo.asia/p/user-acceptance-testing-uat-bWrZnvOOZxw

https://viblo.asia/p/nhung-van-de-gap-phai-trong-kiem-thu-chap-nhan-san-pham-uat-va-giai-phap-APqzeagwzVe

https://techblog.vn/su-khac-nhau-giua-system-testing-va-acceptance-testing

https://techblog.vn/uat-user-acceptance-testing-la-gi-tai-sao-phai-co-va-test-nhu-the-nao

Acceptance test khá hữu dụng vì:

• Chúng nắm bắt các yêu cầu của người dùng bằng cách kiểm chứng trực tiếp

• Chúng tìm ra những vấn đề mà ở unit hay integration test có thể đã để lọt

• Và chúng cung cấp 1 cái nhìn tổng quan về kết quả hệ thống đạt được.

Khi nhìn vào quá trình phát triển phần mềm, chúng ta có thể thấy rằng UAT được sử dụng để xác định và xác minh nhu cầu của khách hàng.

1. Kiểm thử chấp nhận sản phẩm - User Acceptance Testing (UAT) là gì?

Trong vòng đời kiểm thử phần mềm, UAT, kiểm thử alpha và kiểm thử beta là kiểm thử chấp nhận sản phẩm, được thực hiện vào cuối vòng đời khi tất cả kiểm thử chức năng, kiểm thử phi chức năng và kiểm thử hồi quy được hoàn thành. Kiểm thử chấp nhận sản phẩm là giai đoạn cuối cùng khi mà người dùng cuối có thể kiểm tra phần mềm có làm đúng với yêu cầu nghiệp vụ không. Quá trình kiểm thử này được thực hiện bởi những người nhận thức được yêu cầu và hiểu về mục đích xây dựng phần mềm và là thử nghiệm cuối cùng trước khi golive sản phẩm.

2. Mục tiêu của kiểm thử chấp nhận sản phẩm

Phần mềm được code bởi lập trình viên sau khi giải thích các yêu cầu được đưa ra trong tài liệu. Tester và Deverloper kiểm tra phần mềm dựa vào ý hiểu các yêu cầu phần mềm của họ. Vì vậy, phần mềm được phát triển theo yêu cầu chức năng của khách hàng hoặc tổ chức, nhưng có một số yêu cầu nghiệp vụ mà chỉ có thể được hiểu bởi người dùng cuối của phần mềm. Những yêu cầu và quy trình nghiệp vụ này có thể bị lack khi xây dựng phần mềm, vì vậy UAT đóng vai trò rất quan trọng trong đó người dùng cuối kiểm tra phần mềm xem nó có đáp ứng với yêu cầu nghiệp vụ của họ hay không trước khi sản phẩm được chạy thật.

Trong UAT, người dùng cuối sử dụng các kịch bản thực tế và xây dựng test case UAT cho dữ liệu thật; do đó nó sẽ trở thành một phần quan trọng trong chu trình phát hành phần mềm. Vì vậy bất kỳ lỗi nào được tìm thấy trong UAT có chi phí sửa lỗi thấp hơn nhiều so với việc tìm kiếm và sửa chữa lỗi phần mềm sau khi phát hành.

3. Ai sẽ thực hiện UAT?

UAT được thực hiện bởi người dùng cuối những người mà sẽ sử dụng phần mềm. Ngoài ra một vài tổ chức tạo các group hoặc team nhỏ từ nhân viên của mình để lập UAT team để thực hiện kiểm thử phần mềm. Vì vậy phần mềm sẽ được kiểm tra từ nhiều khía cạnh khác nhau và mọi vai trò người dùng.

4. Những thách thức phải đối mặt trong UAT

UAT là một phần rất quan trọng và quyết định đến phát hành sản phẩm. Rất nhiều tổ chức bị thiệt hai do sai sót trong quá trình UAT và release phần mềm. Đó thực sự là thách thức lớn. Các vấn đề như là thiếu người tham gia UAT, người sử dụng miễn cưỡng thực hiện UAT, kế hoạch kiểm thử không chính xác... là một số vấn đề trong UAT. Do đó chúng ta phải khắc phục được những vấn đề này. Dưới đây là một số khó khăn gặp phải trong UAT:

• Lập kế hoạch kiểm thử không đúng: UAT được thực hiện trong giai đoạn cuối của chu trình phát triển phần mềm và là phần quan trọng nhất. Vì vậy, sự chậm trễ trong bất kỳ giai đoạn kiểm thử nào cũng sẽ dẫn đến áp lực và hạn chế thời gian cho UAT. Điều gì sẽ xảy ra khi kế hoạch kiểm thử hệ thống và UAT bị chồng chéo lẫn nhau. Phần mềm được triển khai trong môi trường UAT thậm chí không hoàn thành kiểm thử chức năng dẫn đến sự thiếu chính xác trong phần mềm.

• Môi trường UAT và triển khai: UAT nên được thực hiện trên môi trường khác với môi trường kiểm thử chức năng và kiểm thử hệ thống. Nếu chúng ta thực hiện UAT trên cùng một môi trường, nó sẽ dẫn đến thiếu trường hợp thử nghiệm thực tế. Khi có môi trường kiểm thử UAT riêng, chúng ta cần quan tâm đến phiên bản phần mềm mới nhất được triển khai. Thật lãng phí thời gian nếu như bản phần mềm đang thử nghiệm không phải là phiên bản mới nhất.

• Xử lý các yêu cầu nghiệp vụ mới và bug phát sinh: Trong quá trình UAT rất nhiều vấn đề được tìm thấy do không rõ ràng trong tài liệu và những người kiểm thử đưa lên các lỗi giống nhau.

• Người test UAT không có kiến thức về sản phẩm: Những người test UAT không được đào tạo đúng cách và không có kiến thức đầy đủ về yêu cầu nghiệp vụ của phần mềm. Các tổ chức đưa những người không có kinh nghiệm để thực hiện UAT khiến cho UAT thất bại hoặc không đạt hiệu quả. Đôi khi những người khồn có kỹ thuật được thuê để thực hiện UAT cũng gặp phải những vấn đề về kỹ thuật.

• Khoảng cách giao tiếp giữa các team: Bình thường thì luôn có các vấn đề giao tiếp giữa team phát triển, team UAT và team kiểm thử nếu các team ở những nơi khác nhau. Việc giao tiếp bằng email giữa các team như team offshore và onsite có thể gây ra độ trễ rất lớn, thậm chí tốn cả một ngày chỉ vì một sự mập mờ nhỏ trong bản mô tả phần mềm. Vì vậy cần có một kế hoạch hợp lý và sắp xếp thời gian giao tiếp để có thể UAT hiệu quả. Cần có một công cụ đề các team có thể ghi lại và tổng hợp các ghi chú, log bug.

• Khách hàng đẩy trách nhiệm cho team kiểm thử chức năng: Do lịch trình bận rộn và thiếu thốn user, khách hàng thường sẽ tìm cách giảm bới việc phải làm và yêu cầu team kiểm thử chức năng thực hiện UAT. Điều này có thể dẫn đến việc bỏ qua một số kịch bản của user thật và UAT kém hiệu quả, ảnh hưởng đến trải nghiệm người dùng. Vì vậy UAT nên được giao cho các user kinh nghiệm, có nhiều hiểu biết về nghiệp vụ.

• Không chấp nhận phần mềm: Đôi khi khách hàng sẽ cố để chỉ ra một số lỗi từ chối phần mềm chỉ để chứng tỏ vị thế cao hơn của mình. Team kinh doanh cố gắng hạ thấp vị trí của team phát triển và team kiểm thử. Điều này rất hiếm và chỉ sảy ra khi có tranh chấp trong tổ chức. Điều này có thể tránh được bằng cách xây dựng các mối qua hệ tích cực giữa các team.

5. Làm thế nào vượt qua được những thách thức trong giai đoạn kiểm thử chấp nhận sản phẩm?

• Lập kế hoạch kiểm thử chấp nhận tốt: Trước tiên chúng ta nên lập một cái kế hoạch UAT tốt. Thực hiện UAT ngẫu nhiên và không chính thức sẽ không có hiệu quả trong việc tìm ra khiếm khuyến tiềm ẩn là những rắc rối chính của phần mềm. Nếu chúng ta làm kế hoạch không đúng mà không cần bất kỳ tài liệu nào, chúng ta sẽ không bao giờ chắc chắn về việc hoàn thành UAT. Kế hoạch sẽ ở trong các giai đoạn như ở mức chiến lược, mức độ hợp lý và mức độ sau đó chi tiết. Người sử dụng nên xác định các tiêu chuẩn cho UAT trong tài liệu, thay đổi quy trình kiểm soát và khung thời gian.

• Liên quan đến người sử dụng thực tế trong UAT: Thông thường các công ty thuê một đội người sử dụng thay thế những người thực hiện UAT nhưng không phải là những người là người sử dụng thực tế. Người sử dụng thực tế khi làm việc trên phần mềm tìm thấy các vấn đề mà không thể được nhìn thấy bởi những người sử dụng thay thế. Trong trường hợp này, khi người sử dụng thật là không sẵn sàng để thực hiện UAT, công ty nên tổ chức vài cuộc họp tổng kết với những người sử dụng thực tế.

• Xác định cường độ thử nghiệm liên quan đến các rủi ro và kỹ năng của người lao động: Một số dự án không yêu cầu kiểm tra toàn diện và các dự án có thể yêu cầu thử nghiệm rộng rãi. Chúng ta nên thực hiện đánh giá rủi ro để xác định các vùng nghiêm trọng và có thể bị ảnh hưởng, do đó sẽ tập trung nhiều hơn vào các vùng đó để phát hiện lỗi và tránh những hậu quả tiêu cực. Việc đánh giá rủi ro cần được chính thức và tài liệu hóa, định lượng. đánh giá rủi ro không chính thức không thể xác định một thất bại quan trọng.

• Điều kiện thực tế thời gian và không có yêu cầu người sử dụng: Đây là điều quan trọng nhất trong UAT; UAT là không đầy đủ nếu chúng ta không xem xét các tình huống thực tế trong kiểm thử. Trong UAT chúng ta cần phải thực hiện cả hai kiểm tra và xác nhận, Kiểm tra được thực hiện trên đặc tả và yêu cầu trong khi đó xác nhận được thực hiện dựa trên các trường hợp kiểm thử thực tế. Testcase UAT được xây dựng để kiểm thử phần mềm trên các điều kiện thực tế.

• Hiểu được các giai đoạn của UAT: UAT chủ yếu được thực hiện vào cuối dự án khi mà phần mềm đã hoàn thành và cài đặt. Kết thúc dự án là thời gian tồi tệ nhất để tìm và sửa chữa các lỗi vì lỗi tìm thấy trong thời gian này có chi phí sửa lỗi cao gấp 10 lần so với thông thường. Chúng ta nên yêu cầu người sử dụng tham gia từ khi bắt đầu để họ xác định được các tiêu chí chấp nhận sản phẩm khi cung cấp dữ liệu đầu vào cho phần mềm

• Xem xét kế hoạch kiểm thử: Kế hoạch kiểm thử có thể mắc những sai sót phổ biến. Vì vậy nó cần được xem xét kỹ lưỡng.

Kết luận

Tôi nghĩ rằng bài viết trên đây đã giúp bạn hiểu được các vấn đề phải đối mặt trong UAT, ngoài ra các giải pháp đưa ra sẽ giúp bạn thực hiện các trường hợp thử nghiệm UAT. Nếu bạn thích bài viết này bạn có thể thích/ chia sẻ/ bình luận ở bên dưới.

Bài viết tham khảo và dịch từ nguồn: https://viblo.asia/p/nhung-van-de-gap-phai-trong-kiem-thu-chap-nhan-san-pham-uat-va-giai-phap-APqzeagwzVe

Bài viết tham khảo và dịch từ nguồn: http://www.softwaretestingclass.com/what-are-the-main-problems-facing-in-user-acceptance-testing-uat-and-its-solutions/