테스트 범위(scope)를 정의하는 것은 수동 테스트의 기본적인 과제로, 애플리케이션의 가장 중요하고 핵심적인 부분에 집중할 수 있게 합니다.
프로젝트 발전과 함께 테스트 가능한 기능의 양이 증가하고, 수동으로 모든 시나리오를 커버하는 것은 불가능합니다. Agile/점진적 개발의 출현으로 scope 정의의 역할이 크게 증가했습니다.
테스트 범위가 모호하면 다음과 같은 위험이 있습니다:
테스트 범위는 다음을 기반으로 정의되어야 합니다:
주요 특징:
구현된 모든 것을 테스트해야 하나요, 심지어 아주 작은 세부사항도?
아니요, 테스트 원칙은 특히 오류가 발생할 가능성이 가장 높은 중요한 부분에 집중하는 것입니다. 버그가 비즈니스에 중대한 영향을 미칠 수 있습니다.
테스터는 새로운 요구사항이 발생했을 때 팀 리더나 제품 관리자와 협의 없이 스스로 범위를 확대하거나 축소할 수 있는가요?
아니요, 범위의 변경은 반드시 제품 관리자나 팀 리더와 협의해야 하며, 격차나 작업의 중복을 피할 수 있습니다.
테스트 범위를 정의하는 데 기술 문서에만 의존하는 것이 충분한가요?
아니요, 비즈니스 맥락, 실제 사용자 작업, 고객 피드백도 고려해야 합니다.
테스터가 모든 기능과 경우를 커버하기로 결심, 결국 중요한 경로 테스트에 시간이 부족하여 주요 버그가 발견되지 않음.
장점:
단점:
스프린트 초기에 테스터는 계획에 참여하여 팀 전체와 함께 범위를 고정하고 가장 중요한 사용자 시나리오에 집중하며 작업량을 조율하고 이를 Confluence에 문서화합니다.
장점:
단점: