기획자가 이건 할 줄 알아야지? -단위테스트
4-1. 단위테스트
기능정의서 및 요구사항정의서에 명시된 구현되어야 할 요소들이 정상적으로 작동하는지 구현 단계가 끝난 후 기능 단위로 테스트하는 단계
=단테, 테스트케이스, 테스트시나리오
Why?
- 고객사가 요청한, 수행사가 제시한 개발 요소들이 설계 단계의 산출물 기준으로 정확하게 구현이 되었는지 판단하기 위함
- 가장 작은 기능 단위로 쪼개어 테스트를 진행해 작은 결함을 조기 발견함으로써 통합테스트를 수월하게 진행할 수 있도록 하기 위함
How?
- 표지 | 진행 현황 | 개정이력 | 테스트목록 순으로 작성
- Positive/Negative 양쪽의 관점에서 테스트케이스를 작성
- 한 화면에 UI/UX, Function, Text 영역으로 나누어 작성
1. 진행 현황
단위테스트 진행 현황설계 - 구현 단계가 끝나면 오픈까지 보통 1달에서 2달 정도의 여유가 생기는데 이 기간에 단위/통합테스트를 진행한다. 오픈 전 마지막 업무라고 볼 수 있기 때문에 시간적인 압박이 상당히 강하다. 또한, 오픈에 가까워질수록 고객사의 요구사항이 추가되거나, 설계 - 구현 단계에서 발견되지 못한 이슈들이 생기기도 한다. 그렇기 때문에 PM은 테스트 진행 현황을 파악함으로써 고객사를 안심시키거나 설득할 수 있고, 팀 내부적으로는 정해진 시간 안에 테스트를 마무리할 수 있도록 일정을 조율할 수 있다.
구성 요소 - 메뉴별 총 개수 및 그에 대한 잔여/오류/정상 개수 | 진행률, 적합률, 완료율 | 전체 총계
ㄴ진행률: 총 개수 대비 테스트 미실시한 항목(잔여)의 개수
ㄴ적합률: 테스트 실시한 항목의 개수(정상+오류) 대비 완료한 항목(정상)의 개수
ㄴ완료율: 총 개수 대비 테스트 실시한 항목(정상+오류)의 개수
2. 개정이력
단위테스트 개정이력앞서 작성한 다른 문서들과 마찬가지로 단위/통합테스트 문서 또한 개정이력을 작성해야 하는데, 테스트 문서의 개정이력 목적은 다음과 같다.
화면의 모든 구성요소에 대한 케이스를 작성하기 때문에 많은 항목의 변동사항(삭제, 추가, 변경)을 쉽게 파악하기 위함
변경된 이력에 대해 책임담당자를 명확히 하여 이슈 발생 시 추적이 가능할 수 있도록 하기 위함
3. 테스트목록
테스트목록 (1/2)
테스트목록 (2/2)화면설계서의 화면 설계 영역처럼 단위테스트에서 가장 신경 써야 할 부분인데, 화면설계서의 한 화면에 담겨있는 모든 기능 당 1개의 ID를 부여하기 때문에 화면 개수보다 더 많은 양을 다루어야 한다. 적어야 하는 항목 또한 화면목록에서 다루는 항목에 테스트 관련 항목이 추가되기 때문에 양식을 만드는 것 자체로 많은 시간이 소요된다. 여기서는 테스트목록을 구성하는 항목을 크게 공통/테스트 진행 관점/테스트 결함 처리 관점으로 나누어 설명하도록 하겠다(글쓴이의 방식이기 때문에 참고만 하길 바람).
1) 공통 항목
화면목록을 기준으로 테스트 진행 항목에 대해 ID 부여 및 케이스를 서술하며 항목은 다음과 같다.
테스트ID - 화면 ID에 테스트케이스의 분류를 네이밍 하여 작성(ex: 화면 ID + Function=001, UI/UX=002, Text=003 등)
Depth - 해당 화면에 진입하기 위해 필요한 경로를 작성
화면명, 화면 ID - 화면설계서와 일치해야 함
테스트 계정/데이터 - 해당 화면에서 테스트를 하기 위한 조건에 대해 작성(ex: 로그인 여부, 예외 데이터 필요 여부 등)
테스트케이스 - 화면을 기능 단위로 분류하여 세세한 테스트를 진행할 수 있도록 다양한 행동/가설 설정
2) 테스트 진행 관점 항목
테스트를 진행하는 담당자(기획자)가 작성하는 항목은 다음과 같다.
테스트 결과 - 테스트케이스대로 진행했을 때 나타나는 오류/정상 작동 여부에 대해 상세하게 서술식 작성
수행일 - 테스트를 수행한 일자 작성
테스터 - 테스트를 진행한 담당자 이름 작성
3) 테스트 결함 처리 관점 항목
테스트 진행 후 결함을 조치해야 하는 담당자(개발자/퍼블리셔/디자이너)가 작성하는 항목은 다음과 같다.
담당자 - 결함을 조치하는 담당자의 이름 작성
조치일 - 결함을 확인하고 조치를 시작한 일자 작성
조치내용 - 결함에 대해 어떻게 조치를 했는지에 대해 상세하게 서술식 작성
조치결과 - 조치 후 해당 항목의 상태를 작성(ex: 협의 필요, 정상, 추가 오류 발생 등)
4) 기타 항목
회사마다 사용하는 문서의 양식이 다르기 때문에 위의 항목 외에도 운영체제, 기술 난이도 등 다양한 기준을 두고 작성하는 경우도 있다.
4. 테스트케이스 작성
많은 항목 중 가장 신경 써야 할 부분은 테스트케이스를 작성하는 게 아닐까 싶다. 하나의 화면에서 나타나는 테스트케이스를 빠짐없이 작성해야 추후 통합테스트 단계에서 고객사의 핀잔을 듣지 않을 수 있고, 오픈까지 심리적 압박에서 자유로울 수 있기 때문이다. 테스트케이스를 작성하는 방법에 대해서 간단한 화면을 예를 들어 설명을 해보겠다.
테스트케이스 예시 화면우선 글쓴이는 위 화면을 레이아웃(UI/UX), 기능(Function), 문구(Text) 이렇게 세 가지로 나누었고 각각 001, 002, 003이라는 코드를 부여함으로써 분류하였다. 따라서 화면의 ID가 MO101010 일 때 테스트 ID는 MO101010-001, MO101010-002, MO101010-003 이 될 것이다.
그러면 각각의 ID의 테스트케이스는 어떻게 작성하면 될까?
ㄴMO101010-001의 테스트케이스
- 화면 레이아웃이 정상적으로 출력이 되는가?
- 텍스트 및 이미지 영역의 위치 및 내용이 정상적으로 출력이 되는가?
ㄴMO101010-002의 테스트케이스
- 헤더 영역의 뒤로 가기, 드로워 버튼 클릭 시 정상 작동하는가?
- 약정서 버튼 클릭 시 PDF 파일을 정상적으로 다운로드하는가?
- 각 버튼 클릭 시 해당 화면으로 이동 혹은 팝업을 표시하는가?
ㄴMO101010-003의 테스트케이스
- 화면 내 텍스트의 오탈자 및 깨짐 등의 오류가 있는가?
이렇게 단위/통합테스트 중 단위테스트에 대한 작성요령을 알아보았는데, 사실 단위테스트를 구글링 하면 블랙박스, 화이트박스 테스트 방식에 따라 작성하는 방법이 많이 보인다. 글쓴이는 정보처리기사 공부를 하면서
앞의 용어를 알게 되었는데, 에이전시에서 프로젝트를 수행하며 들어본 적은 없다... 하지만 단위테스트의 케이스 작성은 블랙박스, 화이트박스의 틀에서 벗어나지 않는다고 생각한다. 다양하고 예리한 관점에서 테스트를 진행했을 때 가장 완벽한 서비스가 구현되어 사용자에게 전달될 수 있을 것이다. 다음 글에서는 통합테스트 작성요령에 대해 써볼 예정이다.
