NộI Dung
- Demo và chết!
- Bước vào đôi giày của người dùng
- Lịch sử tóm tắt về UAT
- UAT cho bạn biết hệ thống có thể sử dụng như thế nào
- Ai có thể thực hiện UAT?
- Không lỗi, không căng thẳng - Hướng dẫn từng bước của bạn để tạo ra phần mềm thay đổi cuộc sống mà không phá hủy cuộc sống của bạn
- Thành công và thất bại
- Lợi ích UAT
Nguồn: Lightcome / iStockphoto
Lấy đi:
Khi phần mềm trải qua kiểm tra đơn vị, tích hợp và kiểm tra hệ thống, nhu cầu kiểm tra chấp nhận có vẻ dư thừa. Tại sao kiểm tra chấp nhận người dùng (UAT) vẫn quan trọng? Ở đây, cũng tìm hiểu về lợi ích của UAT và tại sao nó độc đáo.
Demo và chết!
Bạn đã bao giờ cung cấp một bài thuyết trình hoặc đào tạo của khách hàng, và một cái gì đó phá vỡ nửa chừng? Hoặc, bạn đã bao giờ đưa cho ai đó một bộ hướng dẫn và nhận ra bạn đã bỏ lỡ điều gì đó, hoặc nó không hoạt động như bạn mong muốn? Trong mỗi trường hợp này, bạn chấp nhận viễn cảnh của người dùng cuối và làm việc với phần mềm trong tính cách đó. Rất có thể, bạn đã làm một cái gì đó khác biệt bởi vì bạn đang suy nghĩ như một người dùng, chứ không phải là một nhà phát triển.
Bước vào đôi giày của người dùng
Góc duy nhất của thử nghiệm chấp nhận người dùng (UAT) là kiểm tra phần mềm với tư cách là người dùng cuối. Phần mềm được xây dựng để cung cấp cho người dùng kết quả rõ ràng. Ví dụ, các trang web thương mại điện tử cho phép khách hàng mua sản phẩm. Khi khách hàng đặt hàng, phần mềm trang web thương mại điện tử sẽ thông báo cho quản trị viên cửa hàng, để mặt hàng được chọn có thể được kéo và đóng gói để vận chuyển. Có thể có nhiều loại người dùng phần mềm khác nhau, vì vậy giai đoạn thử nghiệm này cho phép nhóm phát triển xác minh rằng người dùng cuối đạt được kết quả phần mềm mong đợi.
Lịch sử tóm tắt về UAT
Trước khi internet ra đời, hầu hết các phần mềm đã được triển khai cho một đối tượng người dùng đã biết. Nếu một công ty phát triển phần mềm cho khách hàng, người quản lý được chỉ định có thẩm quyền xác minh rằng phần mềm đã hoàn thành các điều khoản hợp đồng. Điều này có nghĩa là đại diện cho một điểm mà phần mềm "phù hợp với mục đích", điều này đạt được bằng cách chọn đại diện người dùng cuối để thực hiện kiểm tra và cung cấp báo cáo với kết quả. Bởi vì người dùng là một nhóm kín, đã biết, mỗi nhóm có thể được đào tạo về việc sử dụng phần mềm, thường là thông qua các bước kiểm tra rất chi tiết. Phương châm của ngày hôm đó là chi tiết hơn là tốt hơn.
Khi ngày càng có nhiều phần mềm được phát triển cho khách hàng trên web, đối tượng người dùng cuối trở nên cởi mở hơn. Không thể xác định và huấn luyện tất cả người dùng cuối có khả năng, vì vậy thiết kế phần mềm phải chú trọng nhiều hơn vào khả năng sử dụng và phải dễ hiểu - ngay cả với thông tin được cung cấp tối thiểu. Vì vậy, UAT đã phải thay đổi để đáp ứng các yêu cầu này.
UAT cho bạn biết hệ thống có thể sử dụng như thế nào
Vì vậy, UAT không chỉ cho chúng ta biết phạm vi chức năng của một phần mềm, mà còn cho chúng ta biết mức độ sử dụng của nó. Hầu hết UAT được thực hiện tốt nhất bởi những cá nhân hiểu người dùng cuối được nhắm mục tiêu sẽ trải nghiệm phần mềm với ít kiến thức trước đó và có thể đưa ra một dấu hiệu xác thực về phần mềm dễ sử dụng và những gì cần cải thiện.
Ai có thể thực hiện UAT?
Khi các nhà phát triển kiểm tra phần mềm, họ nhớ chi tiết về cách viết một hệ thống. Kiến thức này có thể ảnh hưởng đến việc kiểm tra và các nhà phát triển có thể thực hiện các bước khác với người dùng cuối, chẳng hạn như thực hiện các bước nhanh hơn hoặc loại bỏ các chi tiết tốt mà người dùng cuối có thể thấy khó hiểu. Do đó, các nhà phát triển không phải là ứng cử viên UAT tốt nhất. Vậy, ai là ai?
Nhiều tổ chức sử dụng các nhóm thử nghiệm cụ thể không liên quan đến thiết kế và phát triển kỹ thuật. Các tổ chức nhỏ hơn hoặc phân bổ thử nghiệm cho các nhân viên không phát triển, như những người thực hiện nhiệm vụ hành chính hoặc sử dụng các dịch vụ của một công ty bên ngoài. Một số tổ chức sử dụng cái gọi là "thử nghiệm hành lang", trong đó họ thực sự chọn các nhân viên không tích cực làm việc trong dự án và yêu cầu họ dùng thử hệ thống từ quan điểm của người dùng cuối. Một ví dụ sẽ được đặt hàng trực tuyến.
Sau khi thử nghiệm nội bộ, các giai đoạn thử nghiệm hoặc thử nghiệm beta có thể xảy ra, nhờ đó phần mềm được cung cấp cho các nhóm nhỏ người dùng "thực" được mời sử dụng sản phẩm miễn phí hoặc giảm giá đáng kể, để đáp lại phản hồi sử dụng chi tiết.
Không lỗi, không căng thẳng - Hướng dẫn từng bước của bạn để tạo ra phần mềm thay đổi cuộc sống mà không phá hủy cuộc sống của bạn
Bạn không thể cải thiện kỹ năng lập trình của mình khi không ai quan tâm đến chất lượng phần mềm.
Các giai đoạn UAT tiến bộ với nhiều đối tượng khác nhau làm tăng sự tự tin về khả năng sử dụng phần mềm. Kết hợp với các giai đoạn phát triển lặp lại, nhiều chu kỳ UAT có thể được thực hiện để kiểm tra các tính năng mới khi chúng được phân phối, đồng thời xác minh các chức năng trước đó.
Những người kiểm tra UAT giỏi rất tò mò muốn xem điều gì sẽ xảy ra nếu họ đi các tuyến đường khác nhau đến một mục tiêu cụ thể. Rốt cuộc, mọi người đều tiếp cận việc sử dụng phần mềm theo nhiều cách khác nhau, vì vậy nếu nhiều khả năng có thể được bao phủ bởi một nhóm người nhỏ, thì độ tin cậy của phần mềm trong chế độ vận hành sẽ cao hơn.
Thành công và thất bại
Các quy trình UAT cần xác minh rằng mỗi loại người dùng phần mềm đều đạt được kết quả rõ ràng cần thiết cho cả luồng thành công và thất bại.
Trong một dòng chảy thành công, một người dùng cuối bỏ đi với một kết quả mong đợi, chẳng hạn như đặt hàng sản phẩm. Trong luồng lỗi, phần mềm hỗ trợ người dùng cuối thông qua một số dạng kịch bản lỗi, chẳng hạn như khi khách hàng cung cấp thông tin thanh toán thẻ tín dụng không hợp lệ.
Để xác minh chức năng, một số thông tin phải được cung cấp cho người kiểm tra. Mặt khác, họ không biết phần mềm phải làm gì. Nhưng để kiểm tra khả năng sử dụng, điều này phải tối thiểu - chỉ dựa trên nhiệm vụ hoặc yêu cầu, chẳng hạn như mua "x" (sản phẩm) và trả "y" (sử dụng chi tiết thẻ tín dụng). Các onus phải được đặt trên người kiểm tra để ghi lại các quan sát, thành công và thất bại.
Lợi ích UAT
Một lợi ích chính của UAT tốt là nó giữ cho chi phí bảo trì liên tục ở mức thấp nhất có thể. Nó rẻ hơn để sửa chữa các vấn đề chức năng và khả năng sử dụng sớm. Khó hơn rất nhiều để sửa lỗi khi có nhiều mã xung quanh nó để kiểm tra hồi quy hoặc nếu nhà phát triển ban đầu không có sẵn.
UAT được thực hiện trong nhiều giai đoạn và với các loại đối tượng thử nghiệm khác nhau cung cấp cơ hội tối ưu để xác định và sửa chữa các tính năng bị hỏng / các vấn đề về khả năng sử dụng trong các giai đoạn đầu của thử nghiệm. Giữ các mục tiêu UAT ở mức độ nhiệm vụ và yêu cầu cho phép người kiểm tra quan sát và chú ý nhiều hơn và thậm chí thử các bước bên ngoài phạm vi được các nhà phát triển cung cấp.
Phản hồi từ các chu trình UAT có thể được đưa vào các lần phát triển tiếp theo, tăng tính mạnh mẽ và khả năng sử dụng phần mềm. Đúng thời gian, thậm chí các giai đoạn thử nghiệm beta có thể bổ sung cho các hoạt động tiếp thị và bán hàng bằng cách cung cấp tài liệu tham khảo và phản hồi nghiên cứu trường hợp.