Các lập trình viên có nên giúp người kiểm thử trong việc thiết kế các bài kiểm tra?

Các lập trình viên nên giúp người kiểm thử bao nhiêu trong việc thiết kế các bài kiểm tra?

Tôi không nghĩ họ nên giúp đỡ gì cả. Lo lắng của tôi là nếu họ giúp người kiểm thử thiết kế các bài kiểm tra cho mã của riêng họ, họ sẽ 'lây nhiễm' cho người kiểm tra bằng những định kiến ​​và điểm mù của riêng họ về mã đó.

Tôi cảm thấy rằng các yêu cầu phải đủ để cung cấp thông tin cần thiết cho người thử nghiệm để tạo thử nghiệm của họ. Nếu có một phần của việc triển khai mà các lập trình viên thấy đáng lo ngại, thì tôi nghĩ rằng nhiệm vụ của họ là thực hiện các thử nghiệm đơn vị để kiểm tra phần đó hoặc thậm chí chạy thử nghiệm hệ thống không chính thức của họ để kiểm tra phần đó.

Không phải tất cả mọi người tôi biết đều đồng ý với điều này (và tôi hiểu một số điểm của họ ở một mức độ nhất định). Người khác nghĩ gì về điều này? Điều này được thảo luận trong các tài liệu bất cứ nơi nào?

Tôi đồng ý. Các lập trình viên có thể giúp người kiểm tra hiểu các thông số chức năng, tìm tài nguyên cho nghiên cứu nhưng không gây ô nhiễm tâm trí của người kiểm tra với ý tưởng của riêng họ về cách tiếp cận kiểm tra.

Tôi nghĩ rằng có chỗ cho các nhà phát triển và người thử nghiệm cùng tồn tại hòa bình trong vương quốc của QA. :)

Cụ thể hơn, tôi nghĩ các nhà phát triển nên chịu trách nhiệm cho cấp độ thử nghiệm đầu tiên - thử nghiệm đơn vị và thử nghiệm tích hợp cơ bản để đảm bảo rằng công cụ của họ hoạt động trong hầu hết các trường hợp trước khi giao cho người thử nghiệm.

Tùy thuộc vào người kiểm tra để tạo các thử nghiệm chấp nhận dựa trên các yêu cầu hoàn toàn không biết về bất kỳ chi tiết triển khai nào (điều này thường được gọi là 'thử nghiệm hộp đen'). Nếu có sự khác biệt trong cách người kiểm thử và nhà phát triển hiểu các yêu cầu, thì đó là vấn đề cần được giải quyết bởi người quản lý dự án (nếu có) hoặc bằng cách đảm bảo mọi người đều ở cùng một trang trong giai đoạn thiết kế của tính năng.

Tôi nghĩ rằng cả thử nghiệm và phát triển đều là những nỗ lực hợp tác , vì vậy, tất nhiên (IMO), các nhà phát triển nên đưa ra ý tưởng thử nghiệm cho người thử nghiệm. Tôi không nghĩ rằng nó lây nhiễm cho họ hoặc làm hỏng người thử nghiệm. Người thử nghiệm, tất nhiên, nên tăng cường các thử nghiệm đó bằng nhiều phương pháp thử nghiệm khác.

Tôi cũng là một fan hâm mộ lớn của những người thử nghiệm giúp các nhà phát triển - Tôi đã lên ý tưởng thiết kế với các nhà phát triển và kết hợp với họ để sửa lỗi (và chỉ ra các lỗi và đề xuất sửa lỗi) nhiều lần trong sự nghiệp của tôi và đừng nghĩ rằng tôi ve đã từng làm hỏng một nhà phát triển với các thử nghiệm cooties.

Nếu bạn không xem đó là một nỗ lực hợp tác, bạn sẽ chỉ có mã "ném qua tường" từ nhà phát triển để kiểm tra ... và bạn sẽ có chất lượng thấp hơn. Đó là sự thật trong thế giới của tôi, nhưng (tất nhiên), ymmv.

Theo cách tôi thấy thì đó không phải là công việc của QA để kiểm tra mã của tôi. Công việc của người kiểm tra là đảm bảo mã của tôi đáp ứng tất cả các yêu cầu cho nhiệm vụ đó.

Khi tôi chuyển một cái gì đó cho QA, tôi chắc chắn rằng họ biết nhiệm vụ tôi đang làm, không phải là chi tiết cụ thể về mã của tôi. Tôi không bao giờ chuyển bất cứ điều gì cho QA có lỗi "đầu xương" trong đó. Điều đó làm lãng phí thời gian của tôi, thời gian của họ ... và khá nhiều thời gian của mọi người.

Ở công việc cuối cùng của tôi, chúng tôi đã tham gia QA ngay từ đầu. Điều đó ngồi trong các phiên thu thập yêu cầu, các cuộc họp dự án và các cuộc họp thiết kế là tốt. Họ lắng nghe và đặt câu hỏi và trong khi các nhà phát triển đang viết mã, họ đang viết kế hoạch kiểm tra của họ. Nó hoạt động rất tốt và chúng tôi đã nắm bắt được rất nhiều vấn đề có lẽ sẽ xảy ra.

Tôi nghĩ rằng bạn khá sai lầm ở đây. Tôi đã từng là một người thử nghiệm và một nhà phát triển, và đã được hưởng lợi rất nhiều khi là một người thử nghiệm từ sự hướng dẫn của các nhà phát triển về các lĩnh vực mà họ cho là có rủi ro cao hoặc dễ vỡ; Là một nhà phát triển, tôi muốn những người thử nghiệm tìm ra những vấn đề mà tôi chưa từng nghiên cứu sâu.

Không có "ô nhiễm" trừ khi mã của bạn là nước thải thô, và đó sẽ là một lý do hoàn toàn khác.

Các yêu cầu thực hiện một công việc khủng khiếp là truyền đạt các vấn đề kỹ thuật mà một chuyên gia QA sẽ quan tâm, bởi vì chúng chỉ giải thích tốt nhất những gì các nhà phân tích kinh doanh đã nắm bắt được. Các nhà phát triển giỏi sẽ nhận thức được rằng mã của họ được tối ưu hóa xung quanh "đường dẫn hạnh phúc" và sẽ muốn biết những gì họ đã bỏ quên. Họ ít nhất sẽ có một trực giác về những gì có thể sai, và những lĩnh vực họ muốn QA thăm dò. Họ cũng biết bức tranh lớn có rủi ro gì xung quanh một tính năng cụ thể dựa trên thiết kế của họ.

Là một người thử nghiệm không có hướng dẫn từ nhóm phát triển, đôi khi tôi đã thực hiện một cách tiếp cận sai lầm tạo ra các báo cáo lỗi tốt, nhưng không thực hiện hoàn toàn các đường dẫn mã rủi ro cao và các vấn đề lớn hơn, có thể tránh được thông qua cộng tác tốt hơn với đội ngũ phát triển, vận chuyển đến khách hàng.

Mặc dù một người kiểm tra chắc chắn không nên giới hạn bản thân mình chỉ kiểm tra những gì nhà phát triển nói là quan trọng, họ sẽ không bị tổn hại bằng cách tìm hiểu những gì các nhà phát triển quan tâm về mã này. Đôi khi, họ có thể tinh chỉnh cách tiếp cận của họ dựa trên kiến ​​thức của họ về việc thực hiện. Chỉ khi một người thử nghiệm đặc biệt thiển cận, họ mới xem xét ý kiến ​​của nhà phát triển về những rủi ro là từ cuối cùng; họ sẽ không hoàn toàn loại bỏ những thứ mà nhà phát triển xác định là rủi ro thấp, nhưng họ sẽ đầu tư nhiều nỗ lực hơn vào những thứ có thể có tác động đến khách hàng cao hơn.

Nhóm QA có thể thấy các khu vực có phạm vi thử nghiệm kết hợp lớn hơn các bộ thu thập hoặc nhà phát triển yêu cầu của một hệ thống, nhưng họ có thể không nhận thức được các thành phần của hệ thống có loại dễ vỡ tinh tế hơn có lợi từ nhận thức về thiết kế hoặc thực hiện hệ thống.

Theo kinh nghiệm của tôi, sự hợp tác giữa QA và Development tạo ra những sản phẩm chất lượng tốt hơn. Tôi sẽ không bao giờ khuyên bạn chỉ làm một bàn giao hộp đen.

Là một người thử nghiệm, tôi hoàn toàn không phản đối các lập trình viên đề xuất các trường hợp thử nghiệm (mặc dù điều đó không có nghĩa là tôi chỉ dính vào các trường hợp thử nghiệm đó) hoặc mô tả chi tiết thực hiện. Đôi khi nó có thể thực sự hữu ích khi có ai đó nói "Tôi nghĩ rằng bit này có thể có rủi ro, tôi thực sự thích nó nếu bạn đã kiểm tra bit này khá kỹ lưỡng". Biết một số chi tiết triển khai giúp tôi áp dụng nhiều năm kinh nghiệm để chọn các bài kiểm tra mà tôi nghĩ có khả năng thất bại nhất. Đôi khi chỉ cần một đề cập ngắn gọn có nghĩa là một vài bài kiểm tra đột nhiên phóng to lên danh sách ưu tiên của tôi.

Nó làm tôi khó chịu? Tôi hơi nhột vì ý tưởng của các lập trình viên đang cố gắng hết sức để bảo vệ sự thuần khiết của người thử nghiệm của tôi, nhưng thực sự - không, đây là một huyền thoại. Nhiều thông tin thường kích hoạt nhiều câu hỏi hơn cho tôi, không phải ít hơn. Tôi đoán đó là một điều đáng suy nghĩ - Tôi không tìm thấy lỗi vì tôi không biết gì, tôi thấy có vấn đề bởi vì tôi là một người đa nghi, không đáng tin, người quá bướng bỉnh khi hoàn toàn tin tưởng vào mọi thứ. Trên mọi hệ thống tôi đã thử nghiệm, tôi thấy rằng tôi tìm thấy nhiều vấn đề hơn và những vấn đề "thú vị" hơn, tôi càng hiểu sâu hơn về nó.

Tôi muốn xem xét các kế hoạch kiểm tra và đề xuất các trường hợp kiểm tra bổ sung mà QA có thể không nghĩ tới. Tôi không chắc làm thế nào điều đó sẽ "lây nhiễm những người thử nghiệm với định kiến ​​của riêng tôi".

Tôi thấy mình ở vị trí kỳ lạ này mà tôi cần phải thực hiện và viết các trường hợp thử nghiệm trong Selenium sau đó vì chúng tôi thiếu nhân viên QA. Tôi tin rằng sự phát triển dựa trên thử nghiệm sẽ vô cùng hữu ích nhưng nó chưa được điều chỉnh trong cửa hàng của tôi.

Một điều tôi thấy bài kiểm tra viết hữu ích là tôi tìm thấy lỗi khi tôi viết bài kiểm tra. Tôi nghĩ theo quan điểm khác nhau để giúp tôi viết mã mạnh mẽ hơn. Nhưng sự thật là phạm vi kiểm tra có thể bị hạn chế. Trong trường hợp này, QAs luôn có thể cho chúng tôi biết những gì họ muốn được bảo hiểm. Hoặc, chúng ta có thể thụ động thêm nhiều bài kiểm tra khi thấy lỗi.

Tôi đang làm QA và không giống như hầu hết các miền biết cách sử dụng mã của chúng tôi khó khăn hơn nhiều so với việc học bất kỳ ngôn ngữ lập trình nào. Vì vậy, chúng tôi tin tưởng vào các nhà phát triển để cung cấp cho chúng tôi các trường hợp thử nghiệm cho các tính năng whizzbang hoàn toàn mới của họ, bởi vì chúng tôi không biết làm thế nào. Trong mọi trường hợp, các vấn đề QA là nhiều hơn để bắt hồi quy và những thứ bị hỏng hơn so với thử nghiệm ban đầu của các tính năng mới. Trong mọi trường hợp khi kết quả là một tính toán phức tạp, thật khó để biết đâu là câu trả lời đúng và đâu là câu trả lời sai, hoặc ngay cả khi một chấm dứt bất thường là điều tốt hay xấu.

Trong mọi trường hợp, một nhà phát triển, nếu anh ta trung thực có thể biết điều gì đó về các lỗ hổng trẻ con của anh ta. Anh ta có thể biết ở giá trị tham số nào, anh ta phải chọn các thuật toán hoặc miền khác nhau trong tra cứu bảng hoặc bất cứ điều gì. Biết rằng, nếu anh ta thành thật về kiểm tra nghiêm ngặt, anh ta sẽ có thể tạo ra một bộ thử nghiệm có kích thước hợp lý bao gồm rất nhiều mã.