이번 포스트부터 QA/Test Process의 주요 단계들에 대해 기재해봅니다.
테스트 계획단계에서는 테스트의 범위나 목적을 명확히 하고, 그 후에 테스트 작업의 방침, 테스트 실행 체제, 일정 등을 책정합니다.
경우에 따라서는 해당 소프트웨어의 충분한 요건정의나 설계가 진행되지 않은 경우도 있습니다. 때문에 체제나 일정을 결정할 때에는 이러한 상황도 고려하여 작업량을 생각하는 것이 필요합니다.
테스트의 종료기준에 대해서도 이 단계에서 고려합니다.
테스트 대상이 되는 범위(Scope)를 결정합니다. 테스트 대상이 되는것은 프로덕트나 서비스를 구성하는 기늠, Sub-system, 시스템 등이며 그 모든 것을 대상으로 할지, 일부분만 대상으로 할지도 검토합니다.
그리고 어떠한 테스트를 진행할지 테스트 목적을 결정합니다.
구체적으로는 QA가 참여하는 시점에서 기획에서의 기획서나 Epic 등을 확인하거나 관계자들에게 공유요청을 하고, 추가로 기획자, 개발자들과의 Communication을 해나가며 테스트 범위를 좁힙니다. 또한 테스트를 진행할 시에 고려해야할 리스크에 대해서도 판단합니다.
어떻게 테스트를 할 것인지 등의 정책(Policy)나 전략(Strategy)를 결정합니다. 즉, 테스트의 목적을 구체화합니다. 프로젝트나 기획의 목표에 따라 테스트 목적을 결정하고, 실제 테스트에서 실행할 것을 결정해나갑니다.
테스트 시작기준/종료기준도 이 단계에서 구체화합니다.
결정한 정책, 전략에 따라 어떠한 테스트 활동을 진행할 것인지를 결정합니다.
테스트 대상의 동작환경, 버전, 사용해야할 도구, 기기 등을 선정해나갑니다. 테스트를 실제로 담당하는 테스터들의 역량에 따라 테스트 내용을 할당합니다.
또한 특정 도구들이나 테스트 환경에 대한 교육이 필요한 경우도 검토하여 일정을 조정합니다.
실제로 테스트 대상을 분석하고, 테스트 케이스를 설계하는 일정을 고려해야합니다.
BlackBox test를 하는 경우에는 요구사항 정의서나 그외 기획서 등의 문서를 확인해야합니다.
Whitebox / Graybox test를 하는 경우에는 System architecture 문서나 설계서, 데이터베이스 설계서 등을 확인합니다.
과거의 경험이나 테스트에 관한 실제 참고치를 기반으로 하여 일정을 산출합니다.
테스트 설계에 기반하여 테스트 케이스 작성 일정 및 테스트 환경 준비 일정을 산출합니다.
위 내용들이 고려되었다면, 이것을 하나로 문서화 시켜 이해관계자들에게 공유 및 기록으로 남깁니다.