Việc tạo ra một hệ thống hoàn toàn trùng lặp để đảm bảo chất lượng (QA) của một hệ thống khác là một thực tiễn xấu?

Trong công việc chúng tôi có một hệ thống khá phức tạp. Hãy gọi hệ thống này, System_A. Nhóm QA của chúng tôi đã tạo một hệ thống khác, gọi hệ thống này là System_B để kiểm tra System_A.

Cách System_B được sử dụng như sau. Chúng tôi tạo đầu vào (sử dụng chính System_B), IN, xử lý các đầu vào đó trở lại thông qua System_B và tạo đầu ra, O_B. Vì vậy, quá trình như sau:

System_B(IN) -> O_B.

Sau đó, chúng tôi cũng làm tương tự cho System_A để tạo đầu ra của riêng mình, O_A:

System_A(IN) -> O_A.

Bất cứ lúc nào, người ta cho rằng O_B là đầu ra dự kiến ​​và O_A là đầu ra thực tế được quan sát. Ngụ ý rằng O_B là nguồn "vàng" (sự thật). Tuy nhiên, chúng tôi đã chạy vào một sự kết hợp của các vấn đề.

• O_A sai, O_B đúng
• O_A đúng, O_B đúng
• O_A sai, O_B sai
• O_A đúng, O_B sai

Ai xác định điều gì đúng nếu O_B được cho là luôn luôn đúng (hoặc dự kiến)? Chà, hóa ra O_B đôi khi (hoặc thường) sai khi kiểm tra và phân tích con người. Mọi thứ sẽ vượt qua QA bằng cách sử dụng quy trình này và người dùng thực sự sẽ phàn nàn và chúng tôi quay lại phát hiện ra rằng O_B đã sai.

Câu hỏi đặt ra là: có phải là một thực tiễn tồi khi tạo ra một "hệ thống thử nghiệm" để kiểm tra hệ thống thực không?

• Còn dốc trơn trượt thì sao? Sau đó, chúng ta không thể tranh luận rằng chúng ta cần một hệ thống khác để kiểm tra "hệ thống kiểm tra"?
• Chi phí chắc chắn là rất lớn, vì các nhà phát triển hiện cần học ít nhất 2 cơ sở mã, với độ phức tạp của System_B có thể lớn hơn System_A. Làm thế nào chúng ta sẽ định lượng mức độ tốt hay xấu của System_B đối với tổ chức?
• Một trong những lý do "hấp dẫn" ban đầu để tạo System_B là "tự động hóa" thử nghiệm. Bây giờ chúng tôi rất tự hào rằng chúng tôi hoàn toàn tự động (vì System_B tạo đầu vào để tự khởi động quá trình sử dụng chính nó để tạo đầu ra). Nhưng tôi nghĩ rằng chúng tôi đã làm hại nhiều hơn và giới thiệu sự phức tạp hơn, theo một cách không thể chấp nhận được. Là công việc của QA được hoàn toàn tự động? Là lý do đó đủ để biện minh để tạo ra một hệ thống song song?
• Mối quan tâm thực sự của tôi là điều này, mặc dù tất cả chúng ta đều biết System_B là sai (khá thường xuyên). Nếu System_B rất giỏi trong việc xử lý đầu vào và đầu ra của nó là nguồn vàng, tại sao không thay thế System_A bằng System_B? Do đó, không ai trong công việc có thể cung cấp một phản ứng thỏa đáng.

Bất kỳ hướng dẫn về vấn đề này được đánh giá cao.

• O_A sai, O_B đúng

Sửa lỗi

• O_A đúng, O_B sai

Sửa lỗi B

• O_A đúng, O_B đúng

Hy vọng, họ cũng đồng ý.

• O_A sai, O_B sai

Hy vọng, họ không đồng ý vì vậy bạn sẽ biết phải làm gì đó với nó.

Không có quá trình bắt tất cả mọi thứ. Chắc chắn, bạn đã nhân đôi mã của mình nhưng nghĩ về nó giống như 2 trong O (2n). QA tự động tất cả các cách để kiểm tra tích hợp là một điều tuyệt vời. Kiểm tra thủ công là một kéo trên inovation. Đặc biệt là về những thay đổi xuyên suốt sẽ đòi hỏi một bài kiểm tra đầy đủ. Ngoài ra, vì bạn sẽ có các lập trình viên khác nhau thực hiện cùng một điều, bạn có thể để họ đua.

Nên là những người khác nhau để tăng tỷ lệ mắc các lỗi khác nhau. Tôi không khuyên bạn nên tạo hệ thống B bằng cách đối phó từ hệ thống A. Tất cả những gì mang lại cho bạn là một bài kiểm tra hồi quy. Bạn có thể nhận được điều tương tự chỉ bằng cách lưu các bản sao cũ của O_A để so sánh với bản mới.

Câu hỏi đặt ra là: có phải là một thực tiễn tồi khi tạo ra một "hệ thống thử nghiệm" để kiểm tra hệ thống thực không?

Nếu có, thì tất cả các thử nghiệm là xấu.

• Còn dốc trơn trượt thì sao? Sau đó, chúng ta không thể tranh luận rằng chúng ta cần một hệ thống khác để kiểm tra "hệ thống kiểm tra"?

Vâng, chúng ta có thể tranh luận rằng. Chúng tôi sẽ gọi hệ thống thứ 3 này, system_A. : P

• Chi phí chắc chắn là rất lớn, vì các nhà phát triển hiện cần học ít nhất 2 cơ sở mã, với độ phức tạp của System_B có thể lớn hơn System_A. Làm thế nào chúng ta sẽ định lượng mức độ tốt hay xấu của System_B đối với tổ chức?

Theo số lượng khách hàng hài lòng trả tiền cho chúng tôi để chơi với súng nerf. Bạn đã giải phóng cho mình chi phí kiểm tra thủ công. Bạn đã tạo ra thứ gì đó có tính hữu dụng sẽ được chứng minh mỗi khi phát hiện ra lỗi. Lỗi bắt được chi phí sớm ít hơn nhiều so với lỗi báo cáo muộn.

• Một trong những lý do "hấp dẫn" ban đầu để tạo System_B là "tự động hóa" thử nghiệm. Bây giờ chúng tôi rất tự hào rằng chúng tôi hoàn toàn tự động (vì System_B tạo đầu vào để tự khởi động quá trình sử dụng chính nó để tạo đầu ra). Nhưng tôi nghĩ rằng chúng tôi đã làm hại nhiều hơn và giới thiệu sự phức tạp hơn, theo một cách không thể chấp nhận được. Là công việc của QA được hoàn toàn tự động? Là lý do đó đủ để biện minh để tạo ra một hệ thống song song?

Độ phức tạp của System_B được cách ly tuyệt vời với System_A. Việc thêm các tính năng vào System_A không khó hơn vì System_B tồn tại. Nó hoàn toàn dễ dàng hơn vì System_B giúp họ tự tin đi nhanh.

• Mối quan tâm thực sự của tôi là điều này, mặc dù tất cả chúng ta đều biết System_B là sai (khá thường xuyên). Nếu System_B rất giỏi trong việc xử lý đầu vào và đầu ra của nó là nguồn vàng, tại sao không thay thế System_A bằng System_B? Do đó, không ai trong công việc có thể cung cấp một phản ứng thỏa đáng.

Đây có phải là một lỗi đánh máy? System_B thường khá sai, vậy đó có phải là tiêu chuẩn vàng bạn muốn sử dụng để thay thế System_A không?

Tôi sẽ giả sử bạn có nghĩa là System_A thường sai. Không thực sự quan trọng cái nào là sai thường xuyên nhất. Bất cứ ai sai là người cần làm việc. Các hệ thống này không quyết định đúng sai, các nhà phát triển làm. Những gì thử nghiệm làm là tạo ra sự bất đồng có nghĩa là có gì đó không đúng. Các nhà phát triển tìm ra đó là gì. Hãy nhớ rằng, không có tiêu chuẩn vàng được sản xuất ở đây. Chỉ có sự đồng ý hoặc không đồng ý. Không đồng ý đòi hỏi công việc cần phải làm. Một phần của công việc đó là tìm ra nơi.

Khi bạn có một hệ thống trong sản xuất thực sự được sử dụng bởi khách hàng, có một hệ thống QA để xác minh lỗi và chức năng mới là điều bắt buộc. Từ quan điểm chất lượng, nó phải càng gần một bản sao của hệ thống sản xuất càng tốt. Theo cách đó, nếu bạn đảm bảo rằng hệ thống sản xuất và hệ thống QA của nó giống hệt nhau, cái gì hoạt động trên cái này, sẽ hoạt động trên cái kia. Nếu không phải như vậy, thì các hệ thống không giống nhau, các đầu vào không giống nhau và / hoặc các đầu ra bị hiểu sai.

Điều này gấp đôi vì vậy nếu hệ thống của bạn là nhiệm vụ quan trọng và được yêu cầu phải sẵn sàng 24/7. Sau đó, bạn không thể kết hợp sự xa xỉ để không có hệ thống QA, bởi vì bạn phải giảm thiểu tối đa thời gian chết trên hệ thống sản xuất. Và nếu đó là một hệ thống 24/7, thì bản sao chính xác của hệ thống sản xuất là một khuyến nghị rất, rất mạnh mẽ.

Bây giờ, nhược điểm rõ ràng của phương pháp này là chi phí. Nó tăng gấp đôi chi phí phần cứng, và tăng chi phí triển khai và bảo trì. Thêm vào đó, việc sao chép dữ liệu liên tục từ hệ thống sản xuất sang QA sẽ phải được thực hiện, do đó chúng tôi sẽ giảm thiểu khả năng kết quả khác nhau do sự khác biệt trong dữ liệu mà hệ thống làm việc.

Một số cân bằng thường có thể được tìm thấy bằng cách thu nhỏ một số thành phần của hệ thống QA so với hệ thống sản xuất, do đó hầu hết các chức năng có thể được kiểm tra chính xác. Chúng thường là các máy chủ dự phòng, kích thước của máy chủ hoặc số lượng máy trạm. Tuy nhiên, theo kinh nghiệm của tôi, một số lỗi luôn được tìm thấy chính xác ở phần bị thu nhỏ, và sau đó là một cơn ác mộng khi tái tạo vấn đề và thực hiện sửa lỗi trong khi duy trì thời gian chết tối thiểu cho phép trong hệ thống sản xuất.

Bất cứ khi nào bạn kiểm tra một hệ thống, bạn phải biết kết quả mong đợi của bạn là gì.

Vấn đề với việc có một hệ thống tạo ra kết quả mong đợi này rõ ràng là 'làm thế nào để tôi kiểm tra hệ thống đó'

Mặc dù vậy, thông thường không thấy mọi người sử dụng bảng tính chẳng hạn để tạo ra các kết quả mong đợi.

Vào cuối ngày, mặc dù bạn thực sự cần một con người để giải thích các yêu cầu của hệ thống và tự tạo ra kết quả mong đợi. Nếu bạn có một hệ thống làm điều đó và chỉ kiểm tra sự khác biệt thì bạn đang bỏ qua thử nghiệm của mình.