Có ai sử dụng quy tắc cơ sở để ước tính nỗ lực cần thiết để thử nghiệm theo tỷ lệ phần trăm nỗ lực cần thiết cho phát triển không? Và nếu bạn sử dụng phần trăm nào?ước tính nỗ lực thử nghiệm theo phần trăm thời gian phát triển
Khi bạn đang ước tính thử nghiệm, bạn cần phải xác định phạm vi thử nghiệm của mình - chúng ta đang nói về kiểm tra đơn vị, chức năng, UAT, giao diện, bảo mật, hiệu suất và khối lượng?
Nếu bạn đang ở trên một dự án thác nước, bạn có thể có một số tác vụ trên không thường xuyên. Dành thời gian chuẩn bị bất kỳ tài liệu, lịch biểu và báo cáo quy hoạch nào.
Đối với giai đoạn thử nghiệm chức năng (Tôi là "người kiểm tra hệ thống", vì vậy đó là điểm tham chiếu chính của tôi) đừng quên bao gồm lập kế hoạch! Một trường hợp thử nghiệm thường cần ít nhất là nhiều nỗ lực để trích xuất từ các yêu cầu/thông số/câu chuyện của người dùng vì nó sẽ thực hiện. Ngoài ra, bạn cần phải bao gồm một số thời gian để nâng cao/kiểm tra lỗi. Đối với một nhóm lớn hơn, bạn sẽ cần phải yếu tố trong quản lý kiểm tra - lập kế hoạch, báo cáo, các cuộc họp.
Nói chung, ước tính của tôi dựa trên độ phức tạp của các tính năng được phân phối thay vì tỷ lệ phần trăm nỗ lực của nhà phát triển. Tuy nhiên, điều này yêu cầu quyền truy cập vào ít nhất một bộ hướng dẫn cấp cao. Nhiều năm làm thử nghiệm cho phép tôi làm việc ra rằng một thử nghiệm của một phức tạp đặc biệt sẽ mất x giờ nỗ lực để chuẩn bị và thực hiện. Một số thử nghiệm có thể cần thêm nỗ lực để thiết lập dữ liệu. Một số xét nghiệm có thể liên quan đến việc đàm phán với các hệ thống bên ngoài và có thời gian vượt quá nỗ lực cần thiết.
Cuối cùng, bạn cần xem lại trong ngữ cảnh của dự án tổng thể. Nếu ước lượng của bạn cao hơn mức BA hoặc Phát triển thì có thể có điều gì đó sai trái với các giả định cơ bản của bạn.
Tôi biết đây là chủ đề cũ nhưng đó là điều tôi đang xem xét lại vào lúc này và là mối quan tâm lâu năm đối với người quản lý dự án.
Các thử nghiệm của Google Blog discussed this problem recently:
Vì vậy, một câu trả lời ngây thơ là viết bài thi mang một mức thuế 10%. Tuy nhiên, chúng tôi phải trả thuế để đổi lấy thứ gì đó.
(snip)
Những lợi ích dịch với giá trị sản hiện nay cũng như ngày mai. Tôi viết các bài kiểm tra, bởi vì các lợi ích bổ sung tôi nhận được nhiều hơn bù đắp chi phí bổ sung là 10%. Ngay cả khi tôi không bao gồm những lợi ích lâu dài, giá trị tôi nhận được từ thử nghiệm ngày hôm nay cũng có giá trị. Tôi nhanh hơn trong việc phát triển mã với kiểm tra. Bao nhiêu, cũng phụ thuộc vào sự phức tạp của mã. Điều phức tạp hơn mà bạn đang cố gắng xây dựng là (nhiều ifs/vòng/phụ thuộc) thì lợi ích của các bài kiểm tra càng lớn.
Một vài năm trước, trong một lĩnh vực an toàn quan trọng, tôi đã nghe một cái gì đó giống như một ngày để kiểm tra đơn vị mười dòng mã.
Tôi cũng đã quan sát thấy 50% nỗ lực phát triển và 50% cho thử nghiệm (không chỉ thử nghiệm đơn vị).
Bạn đang nói về kiểm tra đơn vị/tích hợp tự động hoặc kiểm tra thủ công?
Trước đây, quy tắc chung của tôi (dựa trên số đo) là 40-50% được thêm vào thời gian phát triển tức là nếu phát triển trường hợp sử dụng mất 10 ngày (trước khi xảy ra lỗi QA và sửa lỗi nghiêm trọng) 4 đến 5 ngày - mặc dù điều này tốt nhất nên xảy ra trước và trong quá trình phát triển, chứ không phải sau đó.
Thời gian thử nghiệm có lẽ tương quan chặt chẽ hơn với phạm vi tính năng so với thời gian phát triển. Tôi cũng sẽ tranh luận (có lẽ gây tranh cãi) rằng thời gian thử nghiệm tương quan với kỹ năng của nhóm phát triển của bạn.
Để có nỗ lực phát triển từ 6 đến 9 tháng, tôi yêu cầu thời gian thử nghiệm tối thiểu là 2 tuần, được thực hiện bởi người thử nghiệm thực tế (không phải nhóm phát triển), những người thông thạo phần mềm họ sẽ kiểm tra (ví dụ: , 2 tuần không bao gồm thời gian tăng tốc). Đây là một dự án có ~ 5 nhà phát triển.
Lần duy nhất tôi tính thêm thời gian để thử nghiệm là nếu tôi không quen với công nghệ thử nghiệm tôi sẽ sử dụng (ví dụ: sử dụng kiểm tra Selenium lần đầu tiên). Sau đó, tôi yếu tố có thể 10-20% cho việc tăng tốc độ các công cụ và nhận được cơ sở hạ tầng thử nghiệm tại chỗ.
Nếu không, thử nghiệm chỉ là một phần phát triển bẩm sinh và không đảm bảo ước tính thêm. Thực tế, tôi có thể tăng ước tính cho mã được thực hiện mà không cần thử nghiệm.
EDIT: Lưu ý rằng tôi thường viết mã kiểm tra trước. Nếu tôi phải đi vào sau khi thực tế và viết các bài kiểm tra cho mã hiện có mà sẽ làm chậm những thứ xuống. Tôi không thấy rằng phát triển thử nghiệm đầu tiên làm chậm tôi ở tất cả ngoại trừ mã hóa rất thám hiểm (đọc: ném đi).
Khi bạn nói về kiểm tra, bạn có thể có nghĩa là phát triển thử nghiệm thác nước hoặc phát triển nhanh. Trong một môi trường nhanh nhẹn, các nhà phát triển nên dành 50% thời gian của họ phát triển và duy trì các bài kiểm tra.
Nhưng 50% bổ sung đó sẽ lưu bạn thời gian khi thời gian xác minh lại và xác minh thủ công xuất hiện.
Tôi nhận ra rằng tôi không rõ ràng lắm. Xin lỗi. Tôi đang nói về bối cảnh chuẩn bị báo giá cho khách hàng và sử dụng phương pháp luận có nhiều thác hơn là nhanh nhẹn. Khách hàng muốn biết ngân sách là gì. Chúng ta cần phải cung cấp cho họ một con số thực tế nhưng đồng thời bảo vệ chính mình khỏi những ẩn số gazillion rằng có đang nằm trước rất sớm trong một dự án. CHÚNG TÔI có xu hướng đồng ý với một báo giá cố định để xác định và điều chỉnh dự án; nhưng chỉ đưa ra một dấu hiệu cho các lần lặp lại/giai đoạn tiếp theo sau đó. –
Đánh giá theo thời tiết hôm qua. Đã mất bao lâu rồi? Bạn có xu hướng dài hơn hay ngắn hơn không? Mỗi cửa hàng là khác nhau.
Hầu hết các cửa hàng nhanh nhẹn cần ít thời gian hơn, có ít lỗi hơn và thời gian nhanh hơn để giải quyết chúng do TDD. Mặc dù vậy, hầu hết các cửa hàng nhanh nhẹn đều có thời gian đo lường được với thử nghiệm/QC.
Nếu đây là lần chạy thử đầu tiên cho ứng dụng này, thì câu trả lời là "cho phép xem" theo sau là một lần thử. Tùy thuộc vào việc bạn có thể trả lời câu hỏi nhanh như thế nào, - cách có thể kiểm tra, - số lượng tính năng/chức năng - số lượng lỗi được phát hiện, - cách giải quyết nhanh chóng, - số chu kỳ mã thông qua thử nghiệm và - số lần thử nghiệm bị chặn bởi lỗi. Không có cách nào để nói. Bạn có thể gọi nó là 50% hoặc 175% hoặc hơn, và không sai. Tại sao không thực hiện một dự đoán thô và nhân bởi Pi? Nó sẽ không tồi tệ hơn bất kỳ câu trả lời nào khác mà bạn có thể bù đắp.
Bạn nên (phải) biết mất bao lâu và liệu nó có nhanh hơn hay chậm hơn và liệu mức độ phù hợp có tăng hoặc giảm hay không. Với ba bit thông tin đó, bạn có thể đoán khá tốt.
Gartner vào tháng 10 năm 2006 cho biết rằng thử nghiệm thường tiêu tốn từ 10% đến 35% công việc trên một dự án tích hợp hệ thống. Tôi cho rằng nó áp dụng cho phương pháp thác nước. Đây là một phạm vi khá rộng - nhưng có nhiều phụ thuộc vào số lượng các tùy chỉnh cho một sản phẩm tiêu chuẩn và số lượng các hệ thống được tích hợp.
Từ kinh nghiệm của tôi, 25% nỗ lực được chi cho Phân tích; 50% cho thiết kế, phát triển và thử nghiệm đơn vị; còn lại 25% để thử nghiệm. Hầu hết các dự án sẽ phù hợp với sự chênh lệch +/- 10% của quy tắc này tùy thuộc vào bản chất của dự án, kiến thức về tài nguyên, chất lượng đầu vào & kết quả đầu ra, v.v. Có thể thêm chi phí quản lý dự án trong các tỷ lệ phần trăm này hoặc dưới dạng trên đầu trong phạm vi 10-15%.
Vì lý do an toàn, nó cũng là tỷ lệ 10 dòng kiểm tra đối với mỗi dòng mã. –
Có ai có tài liệu tham khảo có uy tín về thống kê này không? – Steztric