Một biện pháp tốt của hiệu quả thử nghiệm / thử nghiệm là gì?

Tôi sắp tham gia một cuộc thảo luận với ban quản lý về việc đo lường hiệu quả thử nghiệm của chúng tôi với tư cách là một tổ chức QA. Lý do chính đằng sau điều này là một nửa nhóm của chúng tôi đã ký hợp đồng và doanh nghiệp của chúng tôi muốn cung cấp một số số liệu về hiệu quả / hiệu quả của chúng tôi, để chúng tôi có dữ liệu cơ sở để đàm phán các tham số hợp đồng với thỏa thuận dịch vụ của các nhà thầu của chúng tôi .

Tôi đã tìm hiểu một chút và hầu hết các ý kiến ​​tôi đã tìm thấy về chủ đề này xoay quanh hiệu quả của nhà phát triển: dòng mã, điểm câu chuyện được phân phối, lỗi được giới thiệu, v.v.

Nhưng những gì về người thử nghiệm? Thử nghiệm của chúng tôi chủ yếu dựa trên các yêu cầu và kết hợp thử nghiệm thủ công, bán tự động và tự động (không phải vì chúng tôi không có khả năng tự động hóa mọi thứ mà vì một số thứ không thể tự động hóa trong hệ thống thử nghiệm của chúng tôi).

Số lượng bài kiểm tra viết là vô ích, và một số lượng lớn lỗi được tìm thấy có thể là thước đo cho sự phát triển kém hơn là QA hiệu quả.

Các biện pháp tự động hóa (bảo hiểm mã, bảo hiểm tính năng ...) có thể tốt, nhưng tôi nghĩ chúng giúp ích nhiều hơn cho việc phát triển (với tư cách là nhà phát triển, tôi sẽ biết nếu tôi vô tình phá vỡ thứ gì đó) so với khách hàng (tôi muốn làm điều đó và nó không hoạt động).

Vì chất lượng là tốt nếu khách hàng không gặp phải vấn đề, do đó, thước đo tốt về hiệu quả (không phải hiệu quả) của nhóm QA và quy trình là thước đo lỗi được tìm thấy bởi khách hàng mà QA đã tìm thấy .

Vấn đề chính với số liệu đó là có thể có độ trễ đáng kể giữa công việc được thực hiện và khi bạn bắt đầu có những con số có ý nghĩa.

Có một vài số liệu mà chúng tôi đã sử dụng trong công việc cuối cùng của mình để đánh giá QA:

• Số lỗi được tìm thấy. Tôi ghét cái này Nó giống như "Số dòng mã được viết" cho nhà phát triển.
• Số lượng các trường hợp thử nghiệm tự động được sản xuất.
• Tỷ lệ phần trăm của tổng số ứng dụng được bảo hiểm trong thử nghiệm chức năng.
• Số lượng lỗi được tìm thấy trong dàn so với sản xuất.

Cuối cùng, công việc của nhóm QA của bạn là tìm ra các lỗi trước khi chúng ra ngoài tự nhiên. Số liệu của họ nên được dựa trên thực tế đạt được mục tiêu đó. Nếu có độ bao phủ thấp của các trường hợp thử nghiệm, số lượng thử nghiệm tự động tối thiểu và tỷ lệ lỗi cao trong sản xuất, thì chúng không hoạt động tốt. Tuy nhiên, nếu họ có một hồ sơ theo dõi tốt về việc tìm ra các lỗi từ lâu trước khi họ đánh prod, thì số liệu của họ sẽ khá cao.

QA nên được đo lường bằng hai số liệu chính: có bao nhiêu lỗi vượt qua QA được tìm thấy trong lĩnh vực này? Mức độ nghiêm trọng của họ là gì?

Bạn có thể có thể tìm QA để tìm các lỗi nghiêm trọng gần hơn để phát hành hơn là hoàn thành. Bạn có thể nhận được QA vì không hoàn thành kiểm tra trước ngày hoàn thành ước tính của họ (mỗi tính năng).

Mặc dù cuối cùng, tôi sợ bạn sẽ chi nhiều tiền hơn để cố gắng đo lường hiệu quả của nhân viên hợp đồng của bạn hơn là tiết kiệm có được bằng cách sử dụng một nhân viên hợp đồng ...

Công ty tôi làm việc sử dụng một số số liệu QA.

Một trong những điều tôi cảm thấy có liên quan nhất là bảo hiểm mã. Một công cụ như EMMA hoạt động tuyệt vời khi họ viết các bài kiểm tra tự động kỹ lưỡng bên cạnh các bài kiểm tra thủ công của họ.

Dù bạn làm gì, đừng tập trung vào số lượng bài kiểm tra. Điều đó cũng hữu ích như LỘC mỗi ngày.

Nhiều cách để đo lường hiệu suất trong các giai đoạn phát triển và thử nghiệm trong quá trình thực hiện dự án. Chúng tôi sử dụng các biện pháp dưới đây trong các dự án của chúng tôi. Hiệu suất phát triển được đo bằng 4 số liệu Mã phổ biến (Chỉ số duy trì, Độ phức tạp theo chu kỳ, Độ sâu của tính kế thừa, Khớp nối lớp). Đối với C # sẽ nhận được nó trong Microsoft Visual Studio. Đối với phạm vi kiểm tra Ncover / Ndepend là rất hữu ích. Hiệu suất thử nghiệm được đo bằng không có lỗi phát triển - kiểm soát 4 lần chạy nước rút gần đây Lỗi kiểm tra hệ thống vượt qua 4 lần chạy nước rút gần đây. Không có thử nghiệm tự động hóa thông qua phát hành cụ thể / Tính năng được phân phối.