Làm thế nào để kiểm tra đơn vị tốt nhất để quản lý?

Question

Tôi đang chuẩn bị bản trình bày về kiểm tra đơn vị cho người quản lý. Nhóm của tôi đã viết các bài kiểm tra đơn vị trong nhiều năm nay nhưng các lĩnh vực khác của công ty dường như gặp khó khăn khi áp dụng nó. Tôi có thể khiến các nhà phát triển vui mừng về nó, nhưng nếu không có sự mua sắm từ quản lý, nó sẽ không trở thành một tiêu chuẩn.

Các bạn có đề xuất cách tiếp cận quản lý tốt nhất về vấn đề này không? Một số điều bạn đã thử trong quá khứ đã làm việc là gì? Những thứ gì không hiệu quả?

Answer 1

Đối với các nhà quản lý không công nghệ, tôi đã giảm trở lại tương tự xây dựng một ngôi nhà. Họ sẽ xây dựng một cái mà không có bản thiết kế, chỉ lấy viên gạch từ một đống và đặt một cái trên đỉnh kia với một ý tưởng hình ngôi nhà mơ hồ trong đầu? Nếu không thì tại sao họ sẽ không chấp nhận tài liệu thích hợp trước khi viết mã, đánh giá thiết kế, v.v ...?

Đối với đơn vị kiểm tra, bạn có thể thử so sánh nó với chất lượng thử nghiệm các thành phần nhà khác nhau riêng biệt trước khi đưa chúng lại với nhau (gạch, xi măng, cửa ra vào, cửa sổ, hệ thống ống nước)

Đối với những người bất kỳ nắm bắt công nghệ ở tất cả, tôi đề cập rằng 30% đến 50% xử lý các điều kiện lỗi và khôi phục (trong các hệ thống nhúng quan trọng của sứ mệnh) và rằng bạn không thể kiểm tra mà không cần thử nghiệm đơn vị. EG, nếu bạn chỉ thử nghiệm tích hợp blackbox thì làm sao bạn có thể kiểm soát được những gì xảy ra khi module A không thể cấp phát bộ nhớ tại một điểm nhất định hoặc thời gian chờ hết hạn trong mô-đun C khi chờ tin nhắn trả lời từ đâu đó, hoặc một cơ sở dữ liệu đọc mà thông thường sẽ thành công. Giải thích rằng bằng cách dummying ra interfacing module bạn có thể mô phỏng hành vi sai lầm của họ theo ý thích.

Và, tất nhiên, tôi vẽ biểu đồ favouriite của mình bằng ký hiệu $ trên một trục và đồng hồ ở một trục khác. Tôi đánh bại quản lý trên đầu với điều này ở mọi cơ hội để cho thấy rằng chi phí nhận được lỗi tăng sau đó họ được phát hiện (thay đổi một dòng trong một spec yêu cầu - 5 phút; một vài paras trong một tài liệu thiết kế - giờ; dòng mã (tại mã xem xét hoặc giai đoạn thử nghiệm đơn vị) - ngày; tìm kim trong một lỗi haystack và sửa chữa nó tại hệ thống kiểm tra - tuần). Nó không chỉ đơn vị kiểm tra - bạn phải thuyết phục quản lý - và các nhà phát triển đồng nghiệp của bạn - rằng "phí không cần thiết" của tài liệu, đánh giá, thử nghiệm ... s/w Quy trình nói chung (và bao gồm việc học các công cụ mới) ... thực sự tiết kiệm thời gian hơn là thêm thời gian vào một dự án. Nói cách khác, phải mất nhiều thời gian hơn và chi phí nhiều hơn để làm cho nó sai. Đo hai lần, cắt một lần, v.v.

Để kiểm tra đơn vị, hãy cho họ biết về continuous integration. Tôi khuyên bạn nên Jenkins, nhưng sử dụng bất cứ điều gì làm việc cho bạn. Giải thích rằng việc xây dựng thường xuyên, cho dù hàng đêm hoặc với mọi đăng ký, có thể tự động kéo các bài kiểm tra đơn vị từ VCS của bạn và chạy chúng, gửi email hoặc cảnh báo mã mới đã phá vỡ các thử nghiệm hiện tại gần như ngay khi nó xảy ra.

Nếu không ai trong số đó làm việc, tìm kiếm một công việc mới (nếu bạn đang ở Singapore, hoặc muốn trở thành, nói chuyện với tôi ;-)

Answer 2

Nói với họ rằng mã này giúp mã duy trì dễ dàng hơn và sẽ tiết kiệm tiền trong thời gian dài. Nó cũng làm giảm lỗi, nếu được thực hiện đúng.

Nói cách khác, nó làm giảm chi phí và tăng độ tin cậy của phần mềm.

Answer 3

Để xây dựng trên @hvgotcodes câu trả lời, đừng chỉ nói với họ như thế nào nó làm cho mọi thứ tốt hơn, biên dịch một số số liệu thống kê từ nhóm của riêng mình như thế nào nó có

1. Giảm lượt xung quanh
2. Giảm $ chi phí
3. Giảm hồi quy
4. vv

Đặc biệt là các chi phí, các doanh nghiệp yêu để tiết kiệm tiền :)

Answer 4

Đơn vị kiểm tra, nếu được thực hiện tốt, có nghĩa vụ phải

• lỗi bắt đầu, do đó làm giảm số lượng lỗi được tìm thấy bởi QA hoặc trong sản xuất, và cũng có thể giảm chi phí sửa chữa lỗi
• hỗ trợ refactoring , do đó giữ thiết kế sạch sẽ và có thể mở rộng, mà về lâu dài nên bảo trì rẻ hơn

Có bất kỳ số liệu thống kê nào có liên quan được thu thập trong công ty của bạn có thể căn cứ vào những yêu sách này không? I E. số lỗi do QA/người dùng tìm thấy trong các sản phẩm khác nhau, hoặc chi phí thực hiện chi phí sửa lỗi/tính năng trung bình, ...

Answer 5

Đừng đánh lừa.

Khi bạn trích dẫn giảm chi phí, bạn ngụ ý rằng chi phí của QA và tái cấu trúc dễ dàng hơn lớn hơn giá tạo và duy trì các thử nghiệm. Nó sẽ là tốt để chỉ ra rằng và thử và đưa ra một số số liệu để củng cố quan điểm của bạn.

Vấn đề là bạn không thể đặt giá trị đồng đô la trên đường dẫn không được thực hiện ("Chúng tôi đã tránh 1.000 lỗi có thể có giá $ 1 triệu để sửa!").

Nhưng bạn nên biết trước thực tế là có chi phí để tạo thử nghiệm và chúng phải được duy trì. Nếu bạn tạo ra chúng và sau đó để cho họ rơi vào hư hỏng bạn chỉ là xấu đi.

Đối số của bạn sẽ tăng cường khi bạn thêm các tính năng mới và dễ dàng hơn vì bạn đã giữ mã sạch.

Answer 6

Tôi nghĩ rằng thống kê sẽ làm cho các trường hợp tốt nhất như xa như các nhà quản lý không kỹ thuật bị liên quan. Code Complete, 2nd Ed. có một bản tóm tắt về một vài nghiên cứu cho thấy rằng thử nghiệm đơn vị dẫn đến tỷ lệ phát hiện lỗi trung bình là 30% (Bảng 20-2, p 470). Tôi nghĩ rằng nó sẽ được dễ dàng để có nó từ đó và làm cho các trường hợp mà ít lỗi dịch để tiết kiệm nhiều tiền hơn.

Answer 7

Trong một số trường hợp, tôi thấy rằng việc chờ cơ hội phù hợp là chìa khóa.

Ví dụ: trong một trường hợp, tôi đợi cho đến khi có trang web nóng với khách hàng. Nó rất đau (nghĩ $$$). Một trong những câu hỏi không thể tránh khỏi được hỏi bởi quản lý cấp cao là làm thế nào để tránh cùng một vấn đề trong tương lai. Và đó là khi tôi trình bày thử nghiệm đơn vị cho ban quản lý ...

Vì vậy, tôi đoán điều đó phụ thuộc rất nhiều vào hoàn cảnh.

Answer 8

Hiển thị cho họ ví dụ về nơi thử nghiệm đã gặp sự cố và lưu ngày đó.

Answer 9

Nếu có thể, tôi sẽ cố gắng cung cấp các ví dụ thực tế về những khó khăn mà công ty bạn đã gặp phải trong quá khứ khi hỗ trợ mã trực tiếp mà không cần kiểm tra. Sau đó đi vào để làm nổi bật có lẽ với các ví dụ cụ thể giảm chi phí hỗ trợ cho các bản cập nhật và sửa lỗi đã được thử nghiệm tại chỗ.

Chúc may mắn và cho chúng tôi biết cách bạn tiếp tục.:)

Answer 10

Trình bày dưới dạng Behavior Driven Development hoặc Test Driven Development, không chỉ là kiểm tra đơn vị.

Cả BDD và TDD đều có những tác động dễ hiểu do các kỹ thuật viên không hiểu rõ. Trong thực tế, một trong những lợi thế chính của họ là họ tập trung vào phi kỹ thuật.

Thử nghiệm đơn vị, mặt khác, là một khái niệm kỹ thuật có thể rất trừu tượng đối với người không lập trình. Kiểm tra mã của bạn? Bạn không làm điều đó trong khi phát triển? Tại sao chúng tôi phải trả tiền cho nhân viên kiểm tra? Và cứ thế.

Answer 11

1 - Họ có cần biết hoặc thậm chí chấp thuận không? Bạn là kỹ sư và bạn biết rõ hơn họ cách xây dựng những thứ hoạt động, vì vậy họ thực sự không nên can thiệp. Họ có quan tâm đến những công cụ và phương pháp đảm bảo chất lượng/an toàn nào bạn đã sử dụng nếu đó là một mẫu xe mới mà bạn đã xây dựng cho họ? Sẽ không nghĩ như vậy.

2 - Chi phí của các lỗi là rất, rất cao. Chất lượng thấp, khuyết tật và nợ kỹ thuật là một rủi ro dự án rất nghiêm trọng có thể gây nguy hiểm cho toàn bộ khoản đầu tư của một dự án phần mềm. Phòng ngừa khiếm khuyết là easilly chi phí hiệu quả hơn phát hiện lỗi (nhiều bội số theo nghiên cứu). Các xét nghiệm đơn vị có vòng lặp phản hồi ngắn nhất có thể, do đó tránh được chất lượng dự án thấp có hệ thống và giảm đáng kể rủi ro dự án.

3 - Bạn không thể đi nhanh trong một thời gian dài mà không có tỷ lệ lỗi rất thấp - hay còn gọi là Đầu tư đánh bại chi tiêu/suy đoán (điều này họ sẽ nhận được).

Answer 12

Vẽ một tương tự để một cái gì đó các nhà quản lý có thể sử dụng một cách thường xuyên - như một kiểm tra chính tả trong ứng dụng thư hoặc biên tập tài liệu ....