11화 Test Types 확인 테스팅

소프트웨어 테스팅

테스트 기간 중 버그가 발견되어 맨티스, 지라, 레드 마인과 같은 버그 트래킹 시스템에 보고했습니다. 이슈 코멘트에 다음 빌드 수정 예정이라고 합니다. 수정된 빌드가 배포되었고 이전에 보고했던 테스트 사전 조건과 재현 스텝을 똑같이 수행해봅니다. 문제가 해결되었다면 해당 버그는 Close 상태가 되고 QA팀의 추적 관리가 진행됩니다. 한번 발생한 버그는 또 다른 조건과 경로에서 발생할 수 있기 때문입니다. 이러한 과정 검증을 확인 테스팅 또는 재테스트라고 부릅니다. 실무에서는 BTS 이슈 수정 확인으로도 사용됩니다.

얼핏 보면 리그레션 테스팅과 비슷해 보이지만 다른 유형입니다. 확인 테스팅의 목적은 발생한 사전 조건과 재현 스텝을 수정된 빌드에서 동일하게 실행했을 때 더 이상 버그가 발생하지 않는다는 것만 보증할 수 있습니다.

실무에서는 가능하다면 동일한 조건에서의 수정 확인 여부 검증뿐 아니라 혹시 모를 사이드 이펙트를 예방하고 찾아내기 위해 해당 버그와 연관된 기능들에 대해서만 추가 검증이 되면 좋습니다. 이를 좁은 범위의 리그레션 테스팅이라 합니다. 이러한 경우 테스트 디자인 단계에서 준비된 상태로 수행하는 것이 아니기 때문에 일반적으로 애드혹 테스팅이나 탐색적 테스팅을 활용합니다.

하지만 수정 확인 필요한 버그가 많고 일정상 여유롭지 않다면 동일한 조건과 스텝에서만 빠르게 확인하여 최소한의 검증을 하는 것도 하나의 방법입니다. 다만 이러한 경우 유관부서에 테스트 진행 상황 공유가 필요합니다. 테스트 진행 상황 공유는 곧 프로젝트 리스크를 공유하는 것과 동일합니다. 관련해서 QA, Tester는 능동적이고 유연한 대처가 필요합니다. 상황을 공유하는 것이지 잘못을 공유하는 건 아니기 때문이죠. 이번 차수에 발생한 버그 및 테스트 진행 상황에 대해서 보다 능동적인 태도로 팀 공유하려는 마인드가 필요합니다.