개발 팀이 자동화 된 테스트 기반 (단위, 통합, 웹 테스트)에서 어떤 수준의 확신을 갖고 있는지 확인하려고합니다. 나는 다음과 같은 질문에 대해 합리적인 답을 얻고 싶습니다.팀 테스트 확신을 평가하는 기술?
필자는이 영역을 탐구하는 데 사용할 수있는 기존 메트릭과 설문지가 있었으면 좋겠다. 내 목표는 자동화 된 배포 수준을 높이는 것이지만 개발자가 신뢰하거나 믿는 것을 자동화 할 수 있다고 생각합니다.
누구든지이 기술을 알고 있습니까?
회의에 전화하여 질문하는 것을 생각해 봤습니까?
숫자와 메트릭에서 표현할 수없는 함정이 발생할 수 있음을 설명합니다.
저는이 분야의 기존 연구에 대해 알고 있지 않습니다. 당신의 질문은 좋으며 각 질문마다 1 ~ 5 개의 별표가있는 종이에 올려 놓으면 아이디어를 얻을 수 있습니다. 다른 요인을 고려해야합니다 :
우리는 발견 된 버그에 대해 꽤 괜찮은 메트릭스를 가지고 있습니다.하지만 수용 테스트에 들어가는 회귀 분석에 초점을 맞추는 경향이 있습니다. 테스트 배터리는 꽤 많은 시간을 소비하지만 실제로 이러한 문제를 해결하기 위해 CI를 사용합니다. 제 생각에 개발자의 인식에 초점을 맞추는 것은 "하드"메트릭만큼 중요 할 수 있습니다. 테스트에서 얻은 * 값 *을 반영하기 때문입니다. – krosenvold
이러한 질문은 바로 그들에게하십시오.
"수용을위한 자동 배포"에 관한 것이 특히 중요합니다. 큰 망설임이 있는지 알아보십시오. 그렇다면 어떻게 해결할 수 있습니까?
다음은 또 다른 아이디어입니다. 승인을 위해 자동 배포하기 위해 3 일 또는 1 주 동안 시험 사용을 고려해보십시오. 그 후에 두 번째 토론을하고 그것이 어떻게 진행되었는지 평가하십시오. 자동화 된 제작 빌드로 작업하십시오.
분명 이러한 흥미로운 사료 될 수있다 코드 커버리지
수집에 의해 발견
예, 우리는 항상이 문제에 대해 토론하고 우리 환경의 함정을 많이 알고 있다고 생각합니다;) 개인 및 집단 테스트 확신을 평가하는 것은 모든 종류의 방향으로 이끌 수 있습니다. 개별적인 설문 조사를 통해 * 우리가 가진 회의가 그룹 전체를 더욱 발전시킬 수 있다고 생각합니다. – krosenvold