phát triển theo hướng kiểm tra - Ai nên viết các bài kiểm tra?

Ban đầu, nhiệm vụ của nhà phát triển là viết bài kiểm tra, nhưng tôi nhận thấy rằng trong nhiều trường hợp / nhà phát triển trưởng thành điện tử, những trường hợp đó không đưa ra mức độ bao phủ thậm chí 80%.
Làm thế nào về việc tôi có một người QA chuyên viết TẤT CẢ các bài kiểm tra cho một dự án nhất định thay vì nhà phát triển?
Có bất kỳ khuyết điểm nào không?

Trong Phát triển dựa trên thử nghiệm, các thử nghiệm phải được viết bởi nhà phát triển. Nếu không, một ai đó không phải là nhà phát triển đang thúc đẩy sự phát triển.

Vì vậy, ngay khi bạn giao công việc viết bài kiểm tra cho người không phải là nhà phát triển, người đó sẽ trở thành nhà phát triển.

Kinh nghiệm của tôi về TDD là viết mã kiểm tra thường khó hoặc khó hơn viết mã sản xuất. Vì vậy, nếu bạn có tài nguyên có khả năng viết mã kiểm thử đơn vị / tích hợp tốt, họ nên viết mã sản xuất làm cho các thử nghiệm đó vượt qua.

Công việc của QA là thực hiện loại thử nghiệm hoàn toàn khác nhau (tức là thử nghiệm khả năng sử dụng / tích hợp). Họ không thực sự phải biết các công nghệ được sử dụng trong mã.

Nếu bạn lo lắng về phạm vi bảo hiểm mã thấp, bạn cần kỷ luật các nhà phát triển của mình. Ví dụ: dừng hoạt động trên bất kỳ tính năng mới nào, cho đến khi phạm vi bảo hiểm mã tăng. Một số tổ chức đi xa đến mức có một hook hook trước trên kho lưu trữ của họ sẽ không cho phép kiểm tra mã không được phát hiện.

Cuối cùng nhưng không kém phần quan trọng, trong TTD 'thuần', không nên có mã nào được phát hiện ra (vì bạn viết bài kiểm tra trước). Tuy nhiên, có những trường hợp (mặc dù mọi người tranh luận về nó) trong đó phạm vi bảo hiểm mã thấp hơn được chấp nhận. Một số ý kiến ​​cho rằng, ví dụ, viết bài kiểm tra cho getters / setters của POJO là một sự lãng phí thời gian.

những trường hợp đó không được bảo hiểm thậm chí 80%

Đó có thể là một vấn đề quản lý.

Hoặc nó có thể không liên quan.

Đầu tiên, sự khác biệt giữa bảo hiểm 80% và 100% có lẽ là rất nhiều chi phí cho rất ít lợi ích.

"Bảo hiểm" có thể có nghĩa là bất cứ điều gì. Các dòng mã, đường dẫn logic, v.v ... Tôi đoán bạn có nghĩa là các dòng mã (không phải đường dẫn logic).

Một số đường dẫn logic được kiểm tra khá tốt "bằng cách kiểm tra". Mã này là rõ ràng, không có câu lệnh if, có độ phức tạp rất, rất thấp và có lẽ không cần thử nghiệm bổ sung.

20% bài kiểm tra không phải lúc nào cũng chất lượng hơn 20%.

Thứ hai. Đó là một vấn đề quản lý. Nếu quản lý muốn bảo hiểm 100%, họ phải đặt một hệ thống phần thưởng thay thế phần thưởng bảo hiểm 100% thay vì "đủ tốt để phát hành" bảo hiểm 80%.

Thêm người QA để viết thêm bài kiểm tra sẽ không giúp được nhiều.

Thêm các nhà phát triển để viết thêm các bài kiểm tra là những gì sẽ được yêu cầu để có được phạm vi kiểm tra 100%.

Kiểm tra đơn vị IMHO không phải là một quy trình QA. Đó là nhiều hơn về việc tăng tốc độ phát triển (bằng cách thu hẹp vòng lặp phản hồi cho các nhà phát triển). Nó nên được thực hiện bởi người viết thành phần (còn gọi là đơn vị) với trọng tâm là việc sử dụng các thành phần (bởi nhà phát triển khác).

Kiểm tra chức năng là một quy trình QA có thể và nên được thực hiện bởi nhóm QA. Những điều này có thể được thực hiện bởi nhà phát triển nhưng một nhà phát triển không phải là nhà phát triển sẽ tốt hơn vì nhà phát triển có thể không biết tất cả các cách mà người dùng có thể sử dụng ứng dụng.

Cả hai có thể được thực hiện trong một thời trang TDD.

TDD không chỉ là về thử nghiệm, mà còn về thiết kế. Viết mã chỉ để vượt qua các bài kiểm tra thường dẫn đến mã nhỏ hơn và có thể duy trì. Nếu bạn ủy quyền cho bất kỳ người nào khác viết bài kiểm tra, bạn cũng sẽ được ủy quyền về khả năng tạo mã tốt.

Bạn cũng nên lưu ý rằng phạm vi bảo hiểm sẽ không cho bạn biết về chất lượng mã và sẽ không cho bạn biết nếu các quy tắc tên miền đang được bảo hiểm.

Nếu bạn cần bảo hiểm ít nhất 80%, thì bạn cần làm một vài điều:

• Cung cấp cho nhà phát triển của bạn các công cụ họ cần để xác định mức độ bảo hiểm họ có - và đảm bảo rằng đó là táo. Có nhiều hơn một cách để đo lường phạm vi bảo hiểm.
• Cung cấp một phần thưởng / khuyến khích để hoàn thành kỳ tích đó. Các lập trình viên sẽ chỉ làm những gì họ cảm thấy sẽ được đền đáp. Nếu bảo hiểm 50% là đủ tốt để đảm bảo chất lượng và hoàn thành công việc, đó là những gì họ sẽ làm.

Cuối cùng, hãy hiểu rằng có một sự khác biệt giữa các đường dẫn thực hiện dự định và các đường dẫn thực hiện ngoài ý muốn . Trong quá trình viết mã hướng kiểm tra, bạn có thể đã chứng minh rằng bạn cần một cặp câu lệnh if độc lập. Kết quả là có các bài kiểm tra cho hai trong số bốn đường dẫn thực thi tiềm năng có sẵn. Thêm một câu lệnh if độc lập hơn và bạn có tiềm năng cho tám đường dẫn thực thi (nghĩa là nó sẽ tăng theo cấp số nhân).

Hiểu rằng TDD không nhất thiết phải dự đoán mọi đường thực thi tiềm năng, do đó, có một số bài kiểm tra có thể cần phải được viết để hoàn thành nhưng không được viết vì không cần phải kiểm tra đường dẫn đó. Nói tóm lại, TDD không đảm bảo phạm vi bảo hiểm, nhưng nó đảm bảo rằng có ít nhất một thử nghiệm để chứng minh lý do chính xác cho mã tồn tại.