Làm thế nào bạn thuyết phục người quản lý của bạn để cho bạn kiểm tra đơn vị?

Bằng cách "sử dụng", tôi có nghĩa là được phép phát triển, đăng ký để kiểm soát nguồn và duy trì các bài kiểm tra đơn vị theo thời gian, v.v.

Phản đối quản lý điển hình là:

1. Khách hàng không trả tiền cho các bài kiểm tra đơn vị
2. Dự án không cho phép thời gian thử nghiệm đơn vị
3. Nợ kỹ thuật? Nợ kỹ thuật gì?

Bạn có biết những phản đối khác? Câu trả lời của bạn là gì?

Cảm ơn trước!

Gần đây tôi gặp phải vấn đề này khi một khách hàng tham gia phương pháp của chúng tôi, nhưng ban lãnh đạo cao hơn nhận thấy rằng các nhà phát triển đã dành thời gian để thử nghiệm thay vì phát triển và lo ngại về điều này - sau tất cả, họ đã nhờ người QA thực hiện thử nghiệm! Tôi viết blog về cách tôi xử lý nó ở đây:

http://prrealagility.com/show-them-the-numbers-its-results-that-matter/

Tóm lại, tôi đã so sánh số giờ ước tính của chúng tôi với số giờ thực tế cho dự án và sau đó so sánh tỷ lệ lỗi của chúng tôi với tỷ lệ lỗi của các đội khác. Trong trường hợp của chúng tôi, những con số này được so sánh thuận lợi và không còn mối quan tâm nào nữa.

Kết luận của tôi dựa trên kinh nghiệm này là:

... Cách tốt nhất để thuyết phục bất cứ ai rằng cách tiếp cận của bạn để làm một cái gì đó là thực tế và thực dụng, là làm nó và đo lường nó chống lại các phương pháp khác. Mọi người không quan tâm đến giáo điều, hoặc tại sao bạn nghĩ rằng một cái gì đó nên là cách tốt nhất. Chỉ bằng cách cho mọi người thấy các con số và đo lường hiệu quả của phương pháp của bạn, bạn mới có thể thực sự cho thấy rằng các hoạt động của bạn có hiệu quả.

Trong các dự án khác, chúng tôi đã làm việc cùng với các nhà phát triển khách hàng, những người không tạo ra các thử nghiệm đơn vị hoặc thực hiện TDD và chúng tôi phải duy trì các thử nghiệm mà họ phá vỡ. Tuy nhiên, việc bán phương pháp TDD cho những nhà phát triển khách hàng đó trở nên rất dễ dàng khi bạn có thể nói với họ những gì họ đã phá vỡ mã trước khi họ biết!

Vì vậy, trong trường hợp của bạn, tôi sẽ làm điều đó bằng cách lén lút nếu cần thiết (có lẽ có một khu vực nhỏ của mã mà bạn có thể bắt đầu kiểm tra các thay đổi đó thường xuyên hoặc bạn chịu trách nhiệm), nhưng hãy theo dõi các con số của bạn - đó là gì nỗ lực để tạo ra các bài kiểm tra của bạn? Tỷ lệ khuyết tật là gì? Làm thế nào để so sánh với các dự án / thành viên nhóm khác?

Theo tôi, không ai cần phải xin phép hoặc xin lỗi vì muốn thực hiện công việc của họ đúng cách và bất kỳ nhà phát triển chuyên nghiệp nào cũng nên thử kiểm tra mã của họ bằng các kiểm tra tự động bất cứ khi nào có thể và thực tế. Hy vọng rằng đó là cả hai điều này trong trường hợp của bạn. Chúc may mắn!

Hiển thị lợi tức đầu tư (ROI)

Viết bài kiểm tra tự động cần có thời gian. Một lần. Chạy thử nghiệm tự động mất không thời gian, bởi vì bạn có thể làm một cái gì đó khác trong khi chúng đang chạy.

Ví dụ: Tính năng kiểm tra thủ công X mất 30 phút. Viết một bài kiểm tra tự động cho nó sẽ mất 1 giờ. Ngay cả khi chúng tôi không có lỗi, chúng tôi sẽ phải kiểm tra tính năng X mười lần trong suốt quá trình của dự án vì các lớp và thành phần phụ thuộc của nó được sửa đổi. Vì vậy, tự động hóa thử nghiệm tính năng X sẽ giúp chúng tôi tiết kiệm 4 giờ trong suốt vòng đời của dự án.

Trong thực tế, đó là khi bạn có một lỗi mà các bài kiểm tra tự động thực sự phải trả giá - Đầu tiên, họ phát hiện ra lỗi sớm và rẻ, giúp tiết kiệm thời gian và sự bối rối. Thứ hai, nếu bạn gặp một lỗi khó khăn và trải qua nhiều chu kỳ kiểm tra xây dựng mã để tìm ra nó, thời gian được lưu trong quá trình kiểm tra thủ công sẽ tăng lên cực kỳ nhanh.

Doanh nghiệp hiểu tiết kiệm thời gian và tiền bạc. Đó là cách bán nó.

Nếu bạn đã đối đầu với họ và họ không ổn với điều đó, nhưng bạn không cảm thấy thoải mái khi viết mã mà không có họ ... thì đừng hỏi lại. Chỉ cần viết chúng và không kiểm tra chúng.

Ban quản lý sẽ không đếm các dòng mã, nhưng họ sẽ thấy rằng tất cả các đăng ký của bạn có tỷ lệ vượt qua cao hơn từ QA (hoặc khách hàng) và cuối cùng họ sẽ hỏi tại sao ... sau đó bạn có thể giống như "BAM! TDD ! "

Bạn không làm phiền với dự án, quy trình hoặc nguồn ... vì vậy tôi không thấy lý do tiêu cực. Thành thật mà nói, tôi không thấy lý do tại sao nó khác thời gian hơn là chạy tất cả các lần chạy thủ công + đầu vào + kiểm tra kết quả kiểm tra.

1) Khách hàng không trả tiền cho các bài kiểm tra đơn vị

Các khách hàng (nghĩ rằng họ) trả tiền cho một giải pháp làm việc. Tùy thuộc vào các hợp đồng sửa chữa các khiếm khuyết thực sự có thể mang lại lợi nhuận cho công ty của bạn. Nếu có đủ khóa. Vì vậy, quay trở lại trả tiền cho một giải pháp làm việc. TDD nên hỗ trợ mục tiêu đó.

2) Dự án không cho phép thời gian cho TDD

TDD không mất nhiều thời gian hơn. Nó sẽ làm giảm số lượng mã ngoại lai hoặc không cần thiết và tập trung vào cơ sở mã vào những gì làm cho các bài kiểm tra vượt qua. Tất cả các bài kiểm tra vượt qua, tùy thuộc vào chất lượng kiểm tra và sự phù hợp, có nghĩa là mã được thực hiện.

3) Nợ kỹ thuật? Nợ kỹ thuật gì?

Tôi có ấn tượng rằng bạn có thể tranh luận về việc hồi tưởng thêm các bài kiểm tra vào mã hiện có. Đây là một cơn ác mộng bán vào thời điểm tốt nhất và không mang lại lợi ích mà bạn có thể mong đợi. Tuy nhiên, việc thêm các bài kiểm tra khi bạn sửa lỗi sẽ được chấp nhận và trợ giúp về lâu dài.

Tôi không khuyên bạn nên viết các bài kiểm tra vì Snorfus đã đề xuất. Nghe có vẻ đẹp về mặt lý thuyết, nhưng kiểm tra đơn vị có thể và làm thay đổi theo thời gian. Khi yêu cầu thay đổi, các tính năng mới được thêm vào, các bài kiểm tra đơn vị cần được cập nhật. Nếu bạn đang làm việc như một phần của nhóm, các bài kiểm tra đơn vị của bạn sẽ bị lỗi thời khi những người khác thêm tính năng / sửa lỗi.

Tôi đang giải quyết các điểm cụ thể mà bạn đã đề cập thay vì nêu ra những điểm mới bởi vì có nhiều thời gian để đạt được tiến bộ hoặc hiểu lý do tại sao nó bị chặn.

Đối với mọi khách hàng phải đối mặt với vấn đề sản xuất,

1. Viết bài kiểm tra Đơn vị và gửi email đến người quản lý nói rằng Bạn đã thêm bài kiểm tra Đơn vị để bao quát kịch bản.

2. Và nói với anh ta rằng vấn đề này sẽ không xảy ra một lần nữa trong sản xuất vì thử nghiệm đơn vị của chúng tôi đang chạy hàng đêm và chúng tôi sẽ biết trước khi mã đi vào sản xuất bằng cách xem thử nghiệm đơn vị này.

3. Nói với anh ta rằng nếu chúng tôi đã có bài kiểm tra Đơn vị này trước khi mã được đưa vào sản xuất, vấn đề sản xuất này sẽ không bao giờ xảy ra.

Làm điều này một cách nhất quán và kiên trì và chẳng mấy chốc anh ta sẽ bị thuyết phục. Các nhà quản lý không thích khách hàng phải đối mặt với các vấn đề sản xuất và anh ta sẽ mua ý tưởng thử nghiệm của Đơn vị. Chúc may mắn.