Các nhà phát triển có nên tham gia vào các giai đoạn thử nghiệm?

chúng tôi đang sử dụng một quá trình phát triển hình chữ V cổ điển. Sau đó chúng tôi có các yêu cầu, kiến ​​trúc, thiết kế, thực hiện, kiểm tra tích hợp, kiểm tra hệ thống và chấp nhận.
Người thử nghiệm đang chuẩn bị các trường hợp thử nghiệm trong các giai đoạn đầu tiên của dự án. Vấn đề là, do vấn đề tài nguyên (*), các giai đoạn thử nghiệm quá dài và thường bị rút ngắn do hạn chế về thời gian (bạn biết người quản lý dự án ...;)). Các nhà phát triển đang thực hiện các bài kiểm tra đơn vị của họ khi cần.

Vì vậy, câu hỏi của tôi rất đơn giản: các nhà phát triển có nên tham gia vào các giai đoạn thử nghiệm không và nó có quá 'nguy hiểm' không. Tôi e rằng nó sẽ mang lại cho các nhà quản lý dự án một cảm giác sai lầm về chất lượng tốt hơn vì công việc đã được thực hiện nhưng liệu man.days được thêm vào có giá trị gì không? Tôi không thực sự tin tưởng vào các nhà phát triển thực hiện các bài kiểm tra (không vi phạm ở đây nhưng tất cả chúng ta đều biết rằng khá khó để phá vỡ trong một vài cú nhấp chuột những gì bạn đã thực hiện trong nhiều ngày).

Cảm ơn vì đã chia sẻ suy nghĩ của bạn.

(*) Vì những lý do mơ hồ, việc tăng số lượng người thử nghiệm không phải là một lựa chọn như ngày nay.

(Chỉ cần trả trước, nó không phải là một bản sao của 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 không? Điều này nói về việc chuẩn bị kiểm tra và không thực hiện kiểm thử, nơi chúng tôi tránh hàm ý của các nhà phát triển)

Nhìn vào câu hỏi của bạn theo nghĩa đen ("liên quan đến") Câu trả lời duy nhất của tôi là không rõ ràng tuyệt đối

ĐÚNG

Devs không bao giờ nên có tiếng nói cuối cùng về mã riêng của họ .

Nhưng, các Dev nên tham gia vào việc thử nghiệm công việc của các dev khác. Nó làm hai việc:

1. Nó mang lại cái nhìn sâu sắc của nhà phát triển để thử nghiệm. Đây là cả hai từ trường hợp chung là chỉ cần biết API nào có thể đang được sử dụng tại một điểm nhất định, ngoại lệ nào có thể đến từ các API đó và cách xử lý chúng. Nó cũng giúp cho một dự án cụ thể vì các nhà phát triển tiếp xúc nhiều hơn với các cuộc thảo luận khác nhau về lý do tại sao một việc gì đó được thực hiện hơn QA thường, có nghĩa là họ có thể phát hiện ra các trường hợp cạnh mà QA sẽ không làm. Lỗi được phát hiện bởi một nhà phát triển cũng có khả năng rẻ hơn để sửa vì một nhà phát triển thường sẽ cung cấp thêm thông tin và hiểu biết sâu sắc hơn về cách khắc phục ngay lập tức.
2. Nó cung cấp cho nhà phát triển tiếp xúc với các phần của ứng dụng mà họ có thể không được tiếp xúc. Điều này sẽ làm cho họ phát triển tốt hơn cho ứng dụng đó trong thời gian dài. Khi tôi biết API của mình được tiêu thụ như thế nào, tôi sẽ tốt hơn nhiều trong việc dự đoán điều tiếp theo tôi nên làm hơn là nếu tôi chỉ lái xe đi một thông số kỹ thuật. Quan trọng nhất, tôi có thể biết khi nào thông số kỹ thuật bị sai trước khi tôi bắt đầu viết mã nếu tôi biết ứng dụng và việc sử dụng nó.

Cuối cùng, tại sao bạn không sử dụng càng nhiều mắt càng tốt? Bạn hiếm khi có thể đủ khả năng để trải qua quá trình tuyển dụng và lên máy bay để đưa thêm người QA lên tàu trong thời gian khủng hoảng. Vì vậy, nơi bạn tìm thấy đôi mắt thêm bạn cần? Hay bạn cố gắng vượt qua thời gian khủng hoảng với cùng số lượng QA bạn có cùng? Ngay cả khi các nhà phát triển dành 20% thời gian để thử nghiệm và 80% khắc phục bất kỳ lỗi nào phát sinh, thì vẫn có nhiều ứng dụng hơn ứng dụng so với trước đây. Kiểm tra tự động chỉ cung cấp cho bạn một mức độ đảm bảo nhất định và nó sẽ không bao giờ là 100%.

http://haacked.com/archive/2010/12/20/not-really-interested-in-lean.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+haacked+%28you%27ve+been+HA

Đối với bất cứ điều gì ngoại trừ kiểm tra đơn vị, hoàn toàn không. Các nhà phát triển chỉ biết quá nhiều về ứng dụng và cách "được cho là" hoạt động để trở thành người thử nghiệm khách quan.

Sự khác biệt cơ bản trong việc kiểm tra các triết lý giữa các nhà phát triển và Q là: lập trình viên thường kiểm tra chương trình của anh ta để chứng minh rằng mã của anh ta hoạt động (thử nghiệm "tích cực"). QA có thể và thực hiện việc này, nhưng cũng tập trung hơn vào việc tìm hiểu những gì không hoạt động bằng cách cố gắng phá vỡ phần mềm (sử dụng thử nghiệm "âm tính").

Trong phạm vi mà các nhân viên QA có thể có khả năng bị hỏng bởi các lập trình viên kiểm tra "chứng minh" rằng phần mềm hoạt động, cần có sự cách ly giữa kiểm thử của nhà phát triển và kiểm tra QA. Nhà phát triển chắc chắn có thể giúp kiểm tra QA cùng với việc chứng minh những gì hoạt động, nhưng tùy thuộc vào QA để xác minh độc lập rằng phần mềm không bị hỏng.

Điều tốt nhất mà lập trình viên có thể làm để hỗ trợ nỗ lực thử nghiệm là cung cấp một bộ thử nghiệm đơn vị toàn diện, chất lượng cao, có thể kiểm chứng, chứa các thử nghiệm phù hợp với các yêu cầu riêng lẻ trong tài liệu yêu cầu.

Về mặt kiểm tra, có 3 loại.

Hộp đen, hộp xám, và hộp trắng.

Hộp đen đề cập đến người dùng thử nghiệm sản phẩm, không có kiến ​​thức về cách sản phẩm hoạt động bên trong.

Hộp màu xám dùng để chỉ những người dùng có kiến ​​thức về lập trình máy tính, nhưng không thuộc nhóm phát triển. Những người này sẽ kiểm tra xem sản phẩm có bị rò rỉ bộ nhớ hay không, vấn đề yêu cầu hệ thống, v.v.

Đây là phần chính: Hộp trắng đề cập đến các nhà phát triển thử nghiệm sản phẩm ở cấp mã. Điều này có nghĩa là để nói rằng họ thực hiện kiểm tra đơn vị, gỡ lỗi, ... vv

Do đó, điều tốt là người dùng và nhóm phát triển đều tham gia vào giai đoạn thử nghiệm, nhưng mỗi thử nghiệm yêu cầu mức độ cam kết phù hợp từ người dùng và nhóm phát triển, tùy thuộc vào những gì được thử nghiệm.

ĐƠN VỊ KIỂM TRA là bắt buộc cho tất cả các nhà phát triển

Để biết thông tin về cách sử dụng lợi ích này, hãy đọc qua các liên kết sau nếu bạn tham gia phát triển C ++:

• Giới thiệu nhanh về Khung thử nghiệm Google C ++
• Các công cụ kiểm tra đơn vị C / C ++ mã nguồn mở, Phần 1: Tìm hiểu khung kiểm tra đơn vị Boost
• Các công cụ kiểm tra đơn vị C / C ++ mã nguồn mở, Phần 3: Tìm hiểu về CppTest

KHÔNG CÓ CÁCH NÀO MỘT CÁ NHÂN QA CÓ THỂ LÀM NHỮNG KIỂM TRA NÀY. KHÔNG ĐỜI NÀO.

Giả sử rằng dự án có một số lượng đáng kể các nhà phát triển, thì bằng mọi cách, các nhà phát triển sẽ thử nghiệm. Một cảnh báo sẽ là các nhà phát triển không làm việc trên thử nghiệm (điều này không bao gồm thử nghiệm đơn vị) cho mã riêng của họ.

Tôi thà thấy nhân viên hành chính (hoặc người dùng tiềm năng thực tế) thực hiện kiểm tra QA hơn là nhà phát triển. Một người không biết làm thế nào sản phẩm được thiết kế để hoạt động, cần phải cố gắng sử dụng nó. Các nhà phát triển có xu hướng rất hạn chế trong cách họ tiếp cận thử nghiệm và thật lòng họ cũng quá đắt mỗi giờ để sử dụng cho thử nghiệm QA.

Bạn viết:

Vấn đề là, do vấn đề tài nguyên (*), các giai đoạn thử nghiệm quá dài và thường bị rút ngắn do hạn chế về thời gian Đó là do các nhà phát triển không thực hiện chúng. Một trong những công ty Internet lớn nhất cung cấp các sản phẩm ổn định nhất tốt nhất hoàn toàn không sử dụng máy kiểm tra. Họ chỉ sử dụng thử nghiệm tự động, tất cả được thực hiện bởi chính các nhà phát triển. Kết quả là x10 sản phẩm tốt hơn so với khi nhà phát triển bỏ thử nghiệm cho "người thử nghiệm".

Giống như có công nhân xây dựng xây dựng ngôi nhà của bạn, nhưng có một đội ngũ khác đảm bảo rằng tòa nhà thực sự đứng, cửa mở và đóng, điều hòa đang hoạt động, v.v ... Có thể sẽ mất x10 để xây dựng các tòa nhà, và hầu hết sẽ kết thúc không đáng tin cậy