Các nhà phát triển, người thử nghiệm và người dùng doanh nghiệp có nên có một kịch bản thử nghiệm thống nhất không?

Trong quá trình phát triển, thông thường tôi sẽ có các kịch bản thử nghiệm của riêng mình để ghi lại dữ liệu, kịch bản và các bước thực hiện mà tôi dự định kiểm tra; đây là kế hoạch kiểm tra dev của tôi Khi chức năng đã được triển khai để Kiểm tra, người kiểm tra kiểm tra nó bằng cách sử dụng tập lệnh kiểm tra riêng mà họ đã viết. Trong UAT, người dùng doanh nghiệp sau đó kiểm tra bằng kế hoạch kiểm tra của riêng họ.

Nhìn lại, có vẻ như điều này cung cấp phạm vi bảo hiểm tốt hơn, với các thử nghiệm dev có sự kết hợp giữa thử nghiệm hộp đen và trắng, trong khi người thử nghiệm và người dùng doanh nghiệp tập trung vào thử nghiệm hộp đen. Nhưng mặt khác, điều này đưa ra các trường hợp thử nghiệm riêng biệt chỉ được thực hiện trên mỗi giai đoạn (ví dụ: một số trường hợp mà người thử nghiệm nghĩ là chỉ được thực hiện trên Giai đoạn thử nghiệm) và nó muốn nhà phát triển bỏ qua nó, khiến nó trở thành một lỗi tìm kiếm / lỗi .

Có đáng để hợp nhất các kịch bản thử nghiệm từ đầu không? Vì vậy, bằng cách sử dụng một tập lệnh kiểm tra thống nhất, hoặc có khó khăn để thực hiện việc trả trước này không?

Thứ nhất QA không phải là Test. Nếu bộ phận QA của bạn không tham gia vào toàn bộ quá trình phát triển, thì đó là Kiểm tra, không phải QA. QA khi thực hiện công việc của mình, đảm bảo chất lượng, tốt nhất là Test cho thấy sự thiếu chất lượng, nhưng không thể chứng minh chất lượng tồn tại - tức là Test cho thấy QA đã thất bại, nhưng không thể cho thấy họ đã thành công, vì vậy Test và QA không nên là cùng một bộ phận.

Tôi tin rằng cách tốt nhất là để mỗi nhóm quản lý các bài kiểm tra của riêng họ, vì nó cung cấp phạm vi bảo hiểm tốt hơn. Tuy nhiên, mỗi đội nên bắt đầu thử nghiệm càng sớm càng tốt. Điều này có nghĩa là UAT bắt đầu ngay khi có thứ gì đó mà Người dùng có thể sử dụng, Kiểm tra bắt đầu ngay khi một phần mà họ đã kiểm tra đã sẵn sàng, v.v ... Điều này ngăn việc phát hiện muộn các trường hợp kiểm tra khác biệt. Điều này có thể có nghĩa là một số đánh giá lại các mô hình công việc của bạn, vì thường UAT và Test dự kiến ​​sẽ hoạt động trên sản phẩm hoàn chỉnh và cần được đào tạo để thử nghiệm các đầu ra hoàn thành một phần. Nó có thể tốn kém hơn trừ khi quy trình làm việc bị kỷ luật và nhà phát triển "Hoàn thành" có nghĩa là Hoàn thành.

QA nên giám sát điều này, cùng với các biện pháp chất lượng khác, để đảm bảo quy trình không chỉ mang lại đầu ra chất lượng mong muốn mà còn ở mức độ hiệu quả khủng bố.

Chỉnh sửa: Tham chiếu câu hỏi ban đầu về QA đã bị xóa, do đó câu trả lời này hiện xuất hiện OT.

Chúng tôi sử dụng UAT từ đầu.

Nó hoạt động như một tài liệu tham khảo phổ quát và tôi nghĩ rằng nó hoạt động tốt. Mặc dù có thể có các tập lệnh kiểm tra chỉ được sử dụng bởi Devs hoặc Testers cho các thành phần nhỏ hơn, hướng của thử nghiệm luôn hướng về một mục tiêu thống nhất. Vào cuối ngày, UAT là người duy nhất được tính vì vậy bạn cũng có thể làm cho nó trở thành tâm điểm khi bắt đầu.

Làm UAT ngay từ đầu cũng có thêm lợi ích. Nó thực sự xóa tan mọi sự mơ hồ giữa mong đợi của khách hàng và của chính bạn.

Họ không cần một kịch bản kiểm tra chưa được chỉnh sửa vì những điều họ kiểm tra và cách họ thực hiện các bài kiểm tra thường được coi là khác nhau, điều họ cần là một yêu cầu thống nhất mà tất cả các bên đang giải quyết. Nếu UAT và QA đang thử nghiệm những thứ mà nhà phát triển không bao giờ nghĩ tới, thì đã đến lúc xem xét các yêu cầu.

Tôi đồng ý rằng việc có một kịch bản thử nghiệm thống nhất cho các nhà phát triển, người thử nghiệm và người dùng doanh nghiệp sẽ rất tốt để có nhưng tôi tin rằng điều đó là không thể nếu không có nhiều nỗ lực trong đó chi phí vượt quá lợi ích.

Lý do cho sự khó khăn là nội dung cơ sở dữ liệu trong mỗi hệ thống là khác nhau và các bài kiểm tra thường phụ thuộc rất nhiều vào nội dung cơ sở dữ liệu. Cách tiếp cận của chúng tôi đối với "các kiểm tra hợp nhất" là mọi hệ thống cũng có một cơ sở dữ liệu kiểm tra bổ sung và có các tập lệnh để tạo db đó từ đầu. các kịch bản thử nghiệm chạy với testdb trong đó nội dung được đặt ra.

Trong các nhà phát triển thế giới hoàn hảo phải có các bài kiểm tra đơn vị (xUnit), người kiểm tra - kiểm tra tích hợp tự động (Selenium) và người dùng doanh nghiệp - kiểm tra chấp nhận (FIT). Họ có thể có quyền truy cập vào các bài kiểm tra khác.

Nó thực sự phụ thuộc vào dự án. Trong một số trường hợp, một thử nghiệm thống nhất, nhóm QA và UAT gặp nhau để thảo luận về các phát hiện có thể mang lại lợi ích cao. Nó tiết kiệm sự trùng lặp của nỗ lực thử nghiệm và đảm bảo rằng tất cả các bên có sự hiểu biết rõ ràng hơn về nhu cầu kinh doanh thông qua các tập lệnh UAT. Mặt khác, tùy thuộc vào mức độ phức tạp của dự án, có thể có ý nghĩa hơn khi kiểm tra kỹ lưỡng các đầu vào và đầu ra trước khi thử nghiệm các ví dụ kinh doanh. Để phát triển hệ thống được trồng tại nhà, QA ban đầu sẽ là điều bắt buộc trước khi người dùng chấp nhận. Đối với việc triển khai ngoài luồng, một nhóm thử nghiệm thống nhất sẽ có ý nghĩa nhất.