기획자가 이건 할 줄 알아야지? -통합테스트
4-2. 통합테스트
단위테스트가 끝난 후 각 기능간 상호작용이 정상적으로 이루어져 서비스 내 프로세스 진행에 문제가 없는지에 대해 테스트하는 단계
=통테, 통합테스트 시나리오
Why?
- 단위테스트 완료 후 정상적으로 작동하는 기능들이 모여 하나의 프로세스를 진행하게 되는데 이 프로세스가 문제없이 완료되는지에 대해 고객사와 수행사가 함께 테스트 후 결함이 발생하면 빠르게 조치하기 위함
- 오픈 전 마지막 테스트 단계로써 다양한 데이터를 활용하여 오픈 후 많은 변수를 가진 사용자들이 서비스를 수월하게 이용할 수 있도록 하기 위함
How?
- 고객사와 수행사가 하나의 양식으로 함께 테스트를 진행하며 결함 발생 시 즉시 조치담당자와 컨텍하여 해결할 수 있도록 해야 함
- 단위테스트와 작성 항목은 비슷하나, 하나의 케이스가 서비스 내 프로세스의 시작부터 종료까지 큰 범위를 이룸
- 고객사가 업무범위 외의 요소에 대해 결함이라고 판단, 조치를 요청할 경우를 대비해 내부 PL, PM 등 기획자 - 관리자 간 소통을 통해 이슈사항을 파악하고 있어야 함
*이번 통합테스트 작성요령은 글쓴이의 프로젝트 경험을 기준으로 작성하였으므로 회사마다 상이할 수 있으니 참고하시길 바랍니다.
1. 고객사의 결함 내역 발견 및 조치 요청
통합테스트 고객사 요청 항목단위테스트가 작은 각각의 기능에 대해 테스트하는 것이라면, 통합테스트는 테스트 완료된 기능들이 포함된 프로세스의 시작부터 끝까지 테스트를 진행하는 단계이다. 회원가입 프로세스를 예로 들면 단위테스트는 회원가입 프로세스의 각 화면을 기준으로 화면 내 각각의 기능들에 대해서 테스트를 진행하지만, 통합테스트는 회원가입 시작부터 회원가입 완료까지의 흐름에 대해서 정상적으로 완료가 되는지를 확인하는 것이다.
고객사는 서비스 내 모든 프로세스에 대해 테스트를 진행하며 발생된 오류에 대해 작성하여 수행사에 테스트 결과 문서를 보낸다. 이때 작성하는 항목은 다음과 같다.
1) 화면ID
- 결함이 발생한 화면ID를 작성
2) 요청일
- 해당 건을 수행사에 전달한 날짜를 작성
- 요청일로부터 조치하는데 얼마나 걸리는지에 대해 파악하기 위함
- 설계 및 구현 단계에서 발견되지 못한 부분이었는지 역추적을 통한 확인 시 시간의 경과에 대한 증거가 될 수 있음
3) 요청자
- 해당 건의 책임담당자를 작성
4) 요청경로
- 화면설계서에 라벨을 얹어 전달했는지, 이메일로 발송했는지, 전화 및 회의로 전달했는지에 대해 작성
5) 수정/오류 사항 내용
- 해당 화면에서 어떤 오류가 발생했는지, 혹은 요청할 수정 사항이 있는지에 대해 작성
2. 수행사의 오류 확인 및 조치 여부 판단
통합테스트 수행사 작성 항목고객사가 테스트 결과를 문서로 보내면 수행사는 테스트 결과에 나온 오류 및 요청 사항에 대해 다시 한번 테스트를 진행한다. 이유는 계약에 포함된 업무 범위를 벗어난 건에 대해서 임의로 조치할 수 없고, 잠시 서버가 내려갔거나 고객사에서 실수할 경우 등 의도치 않은 오류가 날 수도 있는 상황도 있기 때문이다. 테스트 진행 후 오류 또는 수정 사항에 대해 조치가 필요하다고 판단된 건에 대해서는 즉각적으로 조치가 이루어진다. 이때 작성하는 항목은 다음과 같다.
1) 조치예정일
- 오류 확인 후 조치자의 스케줄에 맞춰 조치예정일을 작성
- 고객사는 오픈이 얼마 안남은 시점이기 때문에 조치에 대해 자세한 경과 파악을 원함
2) 조치일
- 실제 조치가 완료된 날짜를 작성
3) 조치여부
- 발생한 건에 대해 오류를 수정했는지, 변경 사항을 적용했는지 등 고객사의 요청에 대한 결과를 작성
4) 조치자
- 조치 담당자 이름을 작성
- 오류 및 수정의 재발 시 책임담당자를 명확하게 파악하기 위함
5) 현업확인
- 고객사가 요청한 건에 대해 수행사가 적절한 조치를 취했는지에 대해 고객사가 확인했는지 파악 후 작성
6) 비고
- 기타 문의 및 이슈에 대해 작성
단위테스트와 통합테스트 모두 서비스가 정상적으로 진행될 때까지 게속 업데이트한다. 수많은 화면과 메뉴를 고객사의 각 담당자들이 동시에 테스트를 진행하고, 발견된 오류 및 요청 사항은 몇 안되는 기획자에게 전달된다. 그렇기 때문에 기획자는 전달받은 모든 정보를 문서화하여 관리해야 여기저기서 발생하는 오류 - 조치의 건들에 대해 대응할 수 있을 것이다. 기획자는 단순히 서비스를 기획하고 화면설계서를 그리는 게 아니라 프로젝트 내 모든 사람과 소통할 수 있는 역량 또한 필요하다.
이렇게 우리는 요구사항정의서부터 IA, 화면설계서를 지나 단위/통합테스트까지 에이전시의 기획자라면 마주할 수 밖에 없는 문서들을 작성하는 방법에 대해서 알아보았다. 사실 글쓴이가 복습하고자 작성한 글들인데 생각보다 많은 분들께 도움이 된 것 같아 뿌듯하다:) 다음 글부터 많은 주니어 기획자 및 취준생들이 궁금해하는 UI/UX 용어를 포함한 기획 관련 용어에 대해 다뤄볼 예정이다.
