테스트 / 테스터 효율성의 좋은 척도는 무엇입니까?

QA 조직으로서의 테스트 효율성 측정과 관련하여 경영진과 논의에 참여하려고합니다. 이것의 주된 이유는 우리 팀의 절반이 계약을 맺고 비즈니스가 우리가 얼마나 효과적이고 효율적인지에 대한 몇 가지 메트릭을 제공하기를 원하기 때문에 계약자의 서비스 계약과 계약 매개 변수를 협상 할 기본 데이터를 갖기 때문입니다. .

나는이 주제에 대해 내가 찾은 의견의 대부분을 개발자의 효율성과 관련이 있습니다. 코드 라인, 제공된 스토리 포인트, 도입 된 결함 등

그러나 테스터는 어떻습니까? 테스트는 대부분 요구 사항 기반이며 수동, 반자동 및 자동 테스트가 혼합되어 있습니다 (모든 것을 자동화하지 않았기 때문에가 아니라 테스트 시스템에서 자동화 할 수없는 것이 있기 때문).

작성된 테스트 수는 쓸모가 없으며, 발견 된 많은 수의 버그는 효율적인 QA보다는 개발이 열악한 척도 일 수 있습니다.

자동화 조치 (코드 적용 범위, 기능 적용 범위 ...)는 좋을 수 있지만 고객보다 개발에 더 도움이 될 것이라고 생각합니다 (개발자로서 실수로 문제가 발생하면 알게 될 것입니다) 작동하지 않습니다).

고객이 문제를 겪지 않으면 품질이 좋아 지므로 QA 팀과 프로세스의 효율성 (비효율이 아님)을 잘 측정하는 것은 QA 가 찾지 못한 고객이 발견 한 버그를 측정 하는 것입니다 .

이 측정 항목의 주요 문제점은 수행 한 작업과 의미있는 숫자를 시작할 때 사이에 상당한 지연이있을 수 있다는 것입니다.

마지막 작업에서 QA를 평가하는 데 사용한 몇 가지 측정 항목이 있습니다.

• 발견 된 버그 수 나는 이것을 싫어한다. 개발자를위한 "코드 라인 수"와 같습니다.
• 자동 테스트 사례 수
• 기능 테스트에서 다루는 전체 애플리케이션의 백분율입니다.
• 스테이징 대 프로덕션에서 발견 된 버그 수

결국 QA 팀의 임무는 버그가 발생하기 전에 버그를 찾는 것입니다. 그들의 척도는 실제로 그 목표를 달성 한 것에 근거해야합니다. 테스트 사례에 대한 적용 범위가 적고, 자동화 된 테스트의 양이 적고, 생산시 버그가 많으면 제대로 작동하지 않는 것입니다. 그러나, 그들이 제품을 출시하기 훨씬 전에 버그를 발견 한 좋은 실적을 가지고 있다면, 그들의 측정치는 상당히 높아야합니다.

QA는 두 가지 주요 측정 항목으로 측정해야합니다. 필드에서 QA를 통과 한 버그는 몇 개입니까? 그들의 심각성은 무엇입니까?

개발 완료보다 릴리스에 더 가까운 심각한 버그를 찾기 위해 QA를 할 수 있습니다. 예상 완료 날짜 (기능별)까지 테스트를 완료하지 않은 경우 QA를 중단 할 수 있습니다.

결국 계약 직원을 사용하여 얻은 절감액보다 계약 직원의 효과를 측정하기 위해 더 많은 돈을 소비 할 것이라 생각합니다.

내가 일하는 회사는 많은 QA 측정 항목을 사용합니다.

내가 가장 적절하다고 생각하는 것은 코드 범위입니다. EMMA 와 같은 도구 는 수동 테스트 외에도 철저한 자동 테스트를 작성하는 데 효과적입니다.

무엇을 하든지 테스트 횟수에 집중하지 마십시오. 그것은 매일 LOC 만큼 유용합니다 .

프로젝트 실행 중 개발 및 테스트 단계에서 성능을 측정하는 여러 가지 방법. 우리는 프로젝트에서 아래 측정 값을 사용했습니다. 4 가지 인기있는 코드 메트릭 (유지 관리 성 지수, 사이클로 메트릭 복잡성, 상속 깊이, 클래스 커플 링)로 측정 된 개발 성능. C #의 경우 Microsoft Visual Studio에서 가져옵니다. 테스트 범위를 위해 Ncover / Ndepend가 매우 유용합니다. 개발 버그가없는 것으로 측정 된 테스트 성능-마지막 4 개의 스프린트로 롤오버 시스템 테스트 버그는 지난 4 개의 스프린트로 롤링됩니다. 제공되는 특정 릴리스 / 기능에서 자동화 테스트를 통과하지 못했습니다.