안녕하세요.
딩딩입니다.
이번 포스팅은 Test Case 작성 방법에 대해서 정리해드리려고 합니다!
이전에 다루었던 포스팅에서도 대략적인 내용을 확인할 수 있긴 한데요.
Test Case 작성 방법
Test Case, 줄여서 흔히 TC로 부릅니다.
검증을 하기 전에 기획서를 기반으로 작성한 문서이기도 합니다.
이론상 검증하는 기능의 모든 테스트 기대결과가 문서로 담겨있어야 합니다.
테스트 케이스 작성 시점
작성 시점은 테스트 프로세스 단계 중 '분석/설계 단계'에서 진행합니다. (계획/제어 - 분석/설계 - 구현/실행 - 완료/리포팅 - 마감)
테스트 케이스를 작성, 구성, 설계한다 등으로 표현할 수 있습니다.
테스트 케이스 작성 도구
회사마다 다를 수 있습니다.
보통 엑셀 혹은 구글 스프레트 시트를 이용해서 작성합니다.
테스트 케이스 작성 프로세스
[테스트 베이시스 수집 > 테스트 케이스 작성 > 내부 리뷰 > 커버리지 분석 > 승인]
1. 테스트 베이시스 수집
명세(기획서) 기반으로 테스트 케이스는 작성되므로 명세에 포함되어 있는 모든 내용은 테스트 케이스의 기대 결과에 포함되어야 있어야 합니다.
사전에 최대한 많은 관련 자료를 수집을 해서 테스트 케이스 작성 간 활용합니다.
게임의 경우 기획서, UI 기획서, 테이블 등 다양한 자료가 존재합니다.
*물론 자료가 최신화되어있는 것인지 혹은 변경 예정이 있는지를 항상 테스트 케이스 작성 전에 문의하고 확인해야 합니다.
(게임 업계 특성상 기획서가 변경되는 일이 꽤 잦고 변경되는 텀도 짧습니다.)
2. 테스트 케이스 작성
회사 및 프로젝트별로 다르며, 담당자 개개인이 직접 하는 경우가 있고 혹은 프로젝트 리더가 작성해서 팀원에게 배포 및 테스트 진행을 맡기는 경우도 있습니다.
3. 내부 리뷰
실무에서는 보통 TL, QD라고 부르는 리더의 작성된 TC에 대한 리뷰를 진행합니다. 이후 피드백으로 TC를 개선합니다.
테스트 케이스를 리더가 작성하는 경우 별도의 내부 리뷰가 없는 경우도 있습니다. (^^;;;)
4. 커버리지 분석
작성된 테스트 케이스가 어느 정도의 요구 사항을 반영하는가에 대한 분석하는 단계입니다.
보통 기획서가 최신화되어있다면 모든 기획서 내용이 반영이 되어있어야 합니다.
5. 승인
피드백과 어느 정도의 커버리지가 확보가 되면, 실제 테스트에 사용할 전체 테스트케이스 문서(FullTC)에 포함시킵니다.
해당 문서의 관리는 주로 TL, QD와 같은 리더급이 진행합니다.
테스트 케이스의 구조적인 형태
1. 순서(No)
넘버링, 혹은 Sn, Index 등으로 표현합니다.
2. 분류(Category)
테스트 조건을 묶어서 분류별로 정리 대, 중, 소 분류 등으로 구분 가능합니다.
3. 사전 조건(Precondition)
테스트 조건을 확인하기 위해서 사전에 준비될 부분입니다.
4. 스텝(Test Step)
테스트 조건을 실행하기 위한 스텝입니다.
(터치, 클릭, 확인, 슬라이드 등의 사용자가 직접 행해야 할 행위가 포함됩니다.)
5. 기대 결과(Expected Result)
TC의 특징입니다. 스텝을 통해서 어떤 결과가 나와야 되는지에 대한 기대 결과가 표기되어야 합니다.
(~노출, ~팝업 호출, 표시, ~전시, 변경 등과같은 결과값)
간혹 ~ 확인 등으로 스텝을 기대 결과에 적는 경우가 있으니 유의
6. 결과(Test Result)
해당 케이스의 결과입니다. 성공인지 실패인지 등에 대한 결과입니다.
보통 Pass/Fail/Blocked/Not Available(N/A)/Not Tested(N/T) 등으로 구분합니다.
7. BTS
결과가 실패인 경우 별도의 결함 리포팅 후 해당 BTS 링크 표기 영역입니다.
8. 비고(Comment)
결과에 따른 내용 정리 및 특이사항 기입하는 영역입니다.
테스트 케이스 작성 시 유의사항
1. 테스트 스텝의 누락 방지
문서 리뷰 없이 작성한 테스트 케이스는 이해도 없이 내용이 작성되기 쉽습니다.
기획서를 보지 않고도 테스트케이스 문서의 스텝 만으로도 테스트가 진행될 수 있어야 합니다.
간혹 모호한 스텝으로 처음 하는 QA가 테스트에 제한이 되는 경우가 많습니다.
2. 가독성
테스트 케이스 문서가 너무 빡빡하게 채워지면 진행하는 QA 입장에서는 피로도가 증가합니다.
분류를 명확하게 작성하고 스텝은 간결하게, 사전 조건~기대 결과 내용들 역시도 깔끔하게 정리할 수 있어야 합니다.
3. 명확한 기대 결과 기입
해당 테스트 케이스의 결과가 명확하게 기대 결과에 나타나야 합니다.
그렇지 않으면 결과가 모호해서 결국 기획서를 다시 보거나, 담당자에게 문의를 하게 되는 상황이 발생합니다.
또는 스텝 부분인 ~확인, 노출, 출력등의 결과가 기대결과에 들어가는 경우가 있습니다.
4. 전문용어, 축약어 자제
테스트 케이스는 여러 인원이 버디 체크를 하면서 사용할 수도 있고, 신규인원이 해당 테스트 케이스를 이용해서 검증을 할 수 있습니다.
그러나 전문용어, 축약어를 사용하는 경우 지속적인 문의를 하며 검증을 진행하거나 검증 자체가 제한이 되는 경우가 생길 수 있으므로
최대한 자제합니다.
테스트 케이스 플로우 작성 정리
테스트 케이스는 정해진 답이 없습니다. 실무자가 어떤 식으로 구상하는가에 따라 같은 대상이라도 전혀 다른 결과물이 나올 수 있습니다.
다만 중점적으로 가져가야 할 것은 어느 정도의 커버리지가 확보가 되냐입니다. 커버리지 확보만 된다면 그다음으로는 진행 플로우가 중점적이게 됩니다.
1. 테스트 사전 세팅에 따른 플로우
테스트 진행 시에는 미리 세팅해야 할 경우가 많습니다. (로그인이나 특정 서버 시간을 변경해야 하거나 사전 세팅이 필요한 내역인 경우)
이때 한 번에 미리 세팅 후 한 번에 테스트가 진행되는 형태의 플로우로 테스트 케이스를 작성하면 실제 수행하는 경우 효율성이 훨씬 증가합니다.
2. UI~기능 작동 흐름에 따른 플로우
'실행 - 동작 - 기능 - 결과'의 흐름으로 플로우 확인하는 내역의 경우입니다. 일반적인 로비에서부터 특정 페이지가 존재하는 형태의 경우,
혹은 페이지 진입부터 눈에 보이는 UI들 그리고 해당 UI들을 상호작용하며 노출되는 팝업들과 기능에 대한 진행 순서에 따른 플로우가 있습니다.
3. 테스트 환경이 비슷한 것끼리 정렬한 플로우
한 콘텐츠에 여러 세부 영역들이 합쳐져 있는 경우입니다. 보통 분류로 정렬이 진행됩니다.
테스트 진행 시 한 번에 다른 페이지나 영역으로 진입하는 것이 아닌, 한 번에 해당 영역 내에서 세부적인 내용 전체를 테스트할 수 있도록 테스트 케이스를 작성해야 합니다.
이렇게 테스트 케이스의 작성방법에 대해서 말씀드렸는데요!!
약간의 부가적으로 테스트 케이스 사용 장단점에 대해서 정리하고 마무리하려고 합니다.
테스트 케이스 사용 장/단점
물론 QA 업무에서 산출물을 만들어내고 테스트 케이스를 통해서 디테일한 검증을 해야 하는 것은 맞습니다.
다만 아래와 같은 장/단점이 존재합니다.
[장점]
1. 검증 히스토리
테스트 케이스를 통해서 어떤 담당자가 어떤 테스트를 진행했는지와 검증 간 발생한 이슈들을 파악하기가 용이합니다.
또한 테스트 케이스 역시 QA 업무 중 생성되는 산출물 중 하나입니다.
2. 테스트 진행 상황 가시화
현재 전체 프로젝트의 어떤 부분에서 어느 정도의 테스트 진척도가 있는지 확인이 가능합니다.
물론 테스트 케이스 자체로 확인된다기보단, 하루 단위 주 단위 등으로 활용해 진행되는 결과를 정리한 내용입니다.
그러나 객관적으로 진척도를 파악하기 위해서는 결국 테스트 케이스가 필요합니다.
[단점]
1. 작성 시간
검증에도 인력이 필요하지만, 당연히 테스트 케이스를 작성하는데도 인력과 시간 리소스가 필요합니다.
일정에 따라 혹은 테스트할 콘텐츠에 따라서 테스트 케이스 없이 간략 체크리스트로 확인 가능한 경우에는 담당자 판단으로 탄력적인 일정 관리가
필요합니다.
2. 담당자 간 배경지식 부족
테스트 케이스 작성자는 충분한 문서 리뷰를 통해서 이해도가 있지만, 실제로 수행하는 인원은 그렇지 않은 경우가 있을 수 있으므로 검증 시간이 늦어지거나 제한이 될 수 있습니다.
3. 테스트 결과가 TC에만 의존
테스트 결과가 TC내용에 있는 케이스에 의존하게 되는 단점이있습니다. 즉 문서에서 Pass면 그냥 넘어가게 될 수 있는 부분이 많게 됩니다.
이 경우 TC문서에 케이스가 누락되었다면 놓치고 지나가게 된다는 것이지요.
(ISTQB에 있는 '살충제 파라독스'처럼 사용했던 문서를 반복적으로 진행 시 결과자체는 Pass이지만 실제적으로 미 식별되어 놓치는 이슈가 존재)
예외사항은 모두 TC에 포함하나?
예외 사항은 말 그대로 기획과 다르게 동작하는 부분에 대한 체크입니다.
TC는 명세 즉 기획서에 있는 내용이 모두 포함되어야 하는 문서인데, 예외 사항은 기대결과가 없습니다.
(물론 이러한 예외 사항들을 기획자가 기획서에 풀어주는 경우가 있는데 보통은 없는 경우가 많습니다.)
그래서 보통 아래와 같이 진행됩니다.
1. 기획자가 예외 사항과 기대결과를 적어놓은 경우
> TC문서에 해당 예외 사항, 기대결과로 케이스 추가
2. 기획자가 예외 사항에 대한 내용이 없는 경우
> 체크리스트로 정리를 해서 예상되는 예외 사항을 기획자에게 전달 > 기획서 추가 및 갱신 > TC에 케이스 추가
(기획리뷰 단계에서 진행되는 부분입니다.)
3. 경험기반 테스트로 케이스 추가
> 명세이외의 실제로 크리티컬한 이슈들은 보통 경험기반 테스트에서 식별되는 경우가 많습니다.
문서의 기본기능이 다 체크되었다면, 경험기반 테스트로 체크된 케이스들을 별도로 추가할 수 있습니다.
혹은 기획 리뷰 단계에서 예외사항을 체크리스트 형태로 미리 나열하여 문서에 추가할 수 있습니다.
(예외사항 케이스는 위에 설명한 '테스트케이스 플로우 작성'의 내용에 따라 기존의 플로우에 맞춰서 추가해주거나 별도로 예외사항 분류를 만들어서 추가해주기도 합니다.)
테스트 케이스를 만들 때, 업무 시간도 금방 갑니다!
또 새로운 콘텐츠나 시스템을 기획서로 먼저 리뷰해보면서 사전 이해도를 높이며 어떤 식으로 테스트 케이스를 구성할지 고민할 때는 재밌기도 합니다. 다만 일정이 타이트해서 바로바로 기획서 리뷰 - 문의 - TC 작성으로 진행될 때가 대부분이긴 하지만요 :(
위에서 언급을 하진 않았지만, 보통 기획서 내 수치들도 TC에 다 적는 경우가 있습니다.
저는 개인적으로 수치는 후에 별도 체크를 하는데요. (밸런스가 자주바뀜...)
1. 기능검증(코드 이슈 최대한 체크)
2. 데이터 검증(수치 오류 체크)
3. 애드훅 테스팅, 탐색적테스팅, 리그레션 테스팅(사이드 이펙트 최종 체크)
과 같은 형태로 진행하면 시간도 단축되고 안정성도 확보된다고 생각합니다. (경험상)
(블랙박스 테스트 기법적용은 별도의 포스팅으로 다루도록 하겠습니다.)
'[QA지식정보] > QA 지식' 카테고리의 다른 글
| [지식/경험] UX/UI와 컴포넌트 명칭 (0) | 2022.03.03 |
|---|---|
| [지식/경험] QA의 보안 등급 (0) | 2022.03.02 |
| [지식/경험] 성공 테스트와 실패 테스트 (0) | 2022.03.02 |
| [지식/경험] 사이드 이펙트 (0) | 2022.03.02 |
| [지식/경험] 리그레션 테스트 (0) | 2022.03.02 |