Người kiểm tra nên phê duyệt các bản phát hành, hay chỉ báo cáo về các bài kiểm tra?

Liệu nó có ý nghĩa để cung cấp thẩm quyền đăng nhập cho người thử nghiệm? Một đội thử nghiệm

1. Chỉ cần kiểm tra các tính năng, sự cố, v.v. và chỉ cần báo cáo trên cơ sở vượt qua / thất bại, để cho người khác hành động dựa trên các kết quả đó, hoặc
2. Có thẩm quyền để giữ bản phát hành dựa trên những kết quả đó?

Nói cách khác, người kiểm tra có nên được yêu cầu thực sự đăng xuất trên các bản phát hành không? Nhóm thử nghiệm mà tôi đang làm việc cảm thấy rằng họ làm như vậy và chúng tôi gặp vấn đề với vấn đề này vì "phạm vi thử nghiệm leo" - việc từ chối phê duyệt các bản phát hành đôi khi dựa trên các vấn đề không được giải quyết rõ ràng trong bản phát hành.

Hầu hết những nơi tôi đã làm việc, người QA đều có một số bước đăng xuất, nhưng không có thẩm quyền cuối cùng về việc phát hành có tiếp tục hay không. Việc đăng xuất của họ thể hiện rằng họ đã hoàn thành thử nghiệm theo kế hoạch phát hành, không phải việc phát hành là hoàn hảo.

Cuối cùng QA! = Doanh nghiệp và doanh nghiệp cần quyết định xem họ có ổn không khi triển khai mã ở trạng thái hiện tại hoặc nếu lợi ích vượt trội hơn nhược điểm hay bất cứ điều gì. Điều này thường được thực hiện bởi khách hàng hoặc các bên liên quan ngay trước khi triển khai và thường được gọi là Chấp nhận người dùng.

Nếu QA của bạn cũng là nhóm Chấp nhận người dùng của bạn thì có khả năng họ có quyền định nghĩa ứng viên phát hành của bạn là không thể chấp nhận được, nhưng nếu bạn gặp phải vấn đề này nằm ngoài phạm vi của lỗi / lặp / chạy nước rút / thay đổi yêu cầu / bất cứ điều gì bạn bỏ thời gian của mình vào, sau đó Giám đốc dự án hoặc các bên liên quan trong ngành kinh doanh cần phải đến cuộc họp của Chúa Giêsu với nhóm QA.

Bạn có thể báo cáo về các khiếm khuyết đã có từ trước hoặc các kết quả không mong muốn của các yêu cầu mới, nhưng nếu nó nằm ngoài phạm vi và không gây hại thì thường không thể chấp nhận gắn nhãn đó là vấn đề chặn. Nó đi vào tồn đọng để chủ sở hữu sản phẩm ưu tiên như mọi thứ khác.

Một số người cần có thẩm quyền đó . Cho dù đó là một người thử nghiệm, nhóm người thử nghiệm, người lãnh đạo nhóm người thử nghiệm hay người lãnh đạo của tổ chức phát triển có phần không liên quan. Hoặc có lẽ chính xác hơn, nó phụ thuộc vào tổ chức.

Cuối cùng, sự lựa chọn để phát hành phần mềm là một chức năng kinh doanh. Doanh nghiệp phải quyết định xem chất lượng có phù hợp hay không. Có thể cho rằng, giám đốc đảm bảo chất lượng nên đưa ra quyết định đó, hoặc đưa quyết định đó cho đơn vị kinh doanh phù hợp. Tất cả phụ thuộc vào quy mô của công ty, tầm quan trọng tương đối của chất lượng, v.v.

Tất cả những gì đang được nói, thông tin được sử dụng để đưa ra quyết định bắt đầu với người thử nghiệm . Cho dù họ có quyền ngăn chặn việc phát hành hay không, họ nên cảm thấy có trách nhiệm thông báo cho những người ra quyết định khi họ thấy điều gì đó mà họ nghĩ sẽ gây ra sự chậm trễ trong việc phát hành.

Trao quyền đăng xuất (tức là quyền phủ quyết) cho các bản phát hành cho người kiểm tra có ý nghĩa nhiều như trao quyền đó cho nhà phát triển: không có gì cả.

Người thử nghiệm và nhà phát triển chủ yếu là người kỹ thuật, vì vậy họ có khả năng đưa ra quyết định của họ chủ yếu là cơ sở kỹ thuật. Nhưng, những mối quan tâm cần được cân nhắc khi phát hành là cả mối quan tâm về kỹ thuật và kinh doanh. Rõ ràng, khách hàng sẽ không hài lòng nếu bạn cung cấp một sản phẩm có lỗi, nhưng khách hàng sẽ không hài lòng như nhau nếu bạn tiếp tục hoãn phát hành vì vẫn còn vấn đề mở trên sản phẩm.

Ai đó cần tìm sự cân bằng phù hợp giữa một sản phẩm tốt và tuân thủ đúng tiến độ đã hứa với khách hàng. Để làm điều đó, bạn không nên tham gia vào dự án trong vai trò kỹ thuật thuần túy, mà là vai trò định hướng quản lý / kinh doanh hơn như người quản lý dự án hoặc chủ sở hữu sản phẩm và lấy ý kiến ​​của bạn từ người kiểm tra và nhà phát triển.

Quyết định 'phát hành' hoặc 'không phát hành' là vào cuối ngày một quyết định kinh doanh, trong đó cần phải thực hiện phân tích rủi ro / phần thưởng nghiêm ngặt.

Bất kỳ tổ chức nào đều yêu cầu nhóm thử nghiệm đảm nhận trách nhiệm này hoặc nhóm thử nghiệm đồng ý với trách nhiệm này.

Vai trò của nhóm thử nghiệm là cung cấp phân tích về chất lượng của phần mềm, mức độ sẵn sàng để phát hành và mọi rủi ro được xác định là đầu vào cho quyết định kinh doanh phát hành hay không phát hành.

Như những người khác đã lưu ý, _ ai đó _ (và tôi tin rằng đó là một cá nhân) cần có thẩm quyền để đưa ra quyết định 'phát hành' hoặc 'không phát hành'. Người đó có thể đã ủy thác quyết định đó trong các điều kiện cụ thể (nghĩa là không có lỗi P1 hoặc P2)

Tôi đã làm việc với tình huống tương tự những người thử nghiệm quá mức và phát minh ra những cách sáng tạo hơn để phá vỡ một hệ thống, khi rủi ro được đánh giá, rất khó có thể xảy ra trong sản xuất.

Mặc dù tôi hiểu và khen ngợi nhóm thử nghiệm vì không muốn gửi bản phát hành không hoàn hảo, nhưng nó đòi hỏi quyền sở hữu sản phẩm mạnh mẽ để xác định đâu là "rủi ro chấp nhận được".

Theo kinh nghiệm của tôi, nhóm thử nghiệm nên được quyền phủ quyết về việc phát hành phần mềm nhưng quyền phủ quyết này phải được chủ sở hữu sản phẩm ghi đè nhưng chỉ sau khi thảo luận với người kiểm tra chính.

Phần mềm sẽ không bao giờ hoàn hảo, nếu bạn đang bị thử nghiệm creep thì bạn sẽ không bao giờ được phát hành bất cứ điều gì cho đến khi có một vấn đề sản xuất lớn (sẽ không được kiểm tra chính xác) và vội vã.