Google Sheet로 테스트 케이스 작성하기 (2)
이 대신 잇몸으로 어떻게든 해야 할 때
이전 글을 보시고 오셔야 이해하기 쉽습니다.
테스트할 세부 내용을 모두 작성했으니, 이제 테스트 수행 시 테스터와 개발 담당자가 수행 결과에 대해 기록을 남길 수 있도록 해야 합니다.
4. 테스트 수행 모니터링 준비
4-1. 테스트 수행 결과 및 처리 입력란 추가
각 테스트 항목에 대해 테스트 수행 결과 및 처리 결과를 순차적으로 입력할 수 있도록 열을 구분합니다.
수행 및 시트 입력 주체에 따라 색을 구분한 예시� 테스트 수행 주체: 테스터
결과: P(Pass), F(Fail), B(Blocked) 등으로 간단하게 결과를 입력할 수 있도록 합니다. 이 경우에도 해당 열에 데이터 확인 기능을 이용해 빠른 입력을 할 수 있도록 합니다.
테스터: 해당 테스트 항목의 테스터명을 기입해 둡니다. 이 열은 수정할 수 없도록 처리하여, 오기입이 발생하지 않도록 하는 것이 좋습니다.
테스트 일자: 테스트를 수행한 일자를 기록합니다. 미리 해당 열의 입력 양식을 맞춰두고, 데이터 확인 기능으로 올바른 날짜를 입력해 두도록 설정해 두면 좋습니다.
테스터 노트: 테스트 수행 관련하여 오류현상에 대한 상세한 설명을 기입할 수 있게 합니다. P(Pass)인 경우 입력할 필요가 없습니다.
참고 url: Web환경을 테스트한 경우, 해당 현상이 발생한 정확한 url을 작성하여 처리 담당자가 확인할 수 있도록 합니다. 또는 오류 현상이 발생한 당시 촬영한 스크린샷 또는 동영상이 있는 경우, Slack 등으로 파일을 공유하고, 파일의 Link를 입력합니다.
� 테스트 수행 결과 확인 및 처리 주체: 처리 담당자
처리 담당자: 해당 테스트 항목의 처리 담당자명을 기입해 둡니다. 테스트 수행 전 미리 개발부서에 공유하여 각 항목의 처리 담당자가 정확히 기입되어 있는지 미리 확인을 받으면 좋습니다.
처리: 처리중, 완료 등으로 처리 상태를 구분합니다. 처리 담당자가 해당 건에 대해 인지했는지 또는 F(Fail) 건을 처리 완료했는지 알기 어렵기 때문에, 반드시 입력을 해야 합니다. 테스트 수행 결과가 P(Pass)인 경우 입력할 필요가 없습니다.
처리 일자: 처리를 완료한 일자를 입력합니다. 테스트 담당자가 처리 완료 후 재 확인을 해야 하기 때문에, 정확한 일자를 기입해야 합니다. 테스트 수행 결과가 P(Pass)인 경우 입력할 필요가 없습니다.
처리 담당자 노트: 처리 내용에 대해 상세한 설명을 기입할 수 있게 합니다. 예를 들어, 'iOS에서 발생하는 오류로 확인했습니다. n.n버전에서 해결됨' 등으로 어떤 이유나 환경으로 인해 발생한 현상이었으며 어떻게 처리했는지 등을 기입합니다. 테스트 수행 결과가 P(Pass)인 경우 입력할 필요가 없습니다.
� 테스트 처리 확인 주체: 테스터
처리 확인: 확인중, 재발생, 확인완료 등으로 상태를 구분합니다. 처리 담당자가 처리를 완료하면, 테스터는 오류가 해결되었는지 재확인합니다. 만약 동일한 오류 현상 또는 새로운 오류 현상이 발견된 경우 '재발생'으로 상태를 입력하여 처리 담당자가 다시 확인할 수 있도록 합니다.
처리 확인 일자: 처리 여부를 확인한 일자를 입력합니다.
처리 확인 노트: 오류현상에 대한 상세한 설명을 기입할 수 있게 합니다.
시트 예시여기에 추가로 한 가지 열을 더하는데, 바로 '비고'입니다. 비고란에는 1) 해당 테스트 건과 관련하여 공유할만한 내용이나, 2) 여러 차례 재처리 및 확인을 한 내용을 작성합니다. 1)의 경우, 특정 기기나 모델 또는 경로 및 동작 등에서 발생하는 특이건이 있는 경우 내용을 작성합니다. 추후 유사한 현상이 발생할 경우 참고할 수 있도록 하기 위함입니다. 2) 대부분의 경우 1차 처리에서 오류가 수정되지만, 원인을 찾기 어려운 경우 처리 및 재확인을 N차까지 해야 하는 경우가 있습니다. 이 경우 처리 내용을 계속해서 열을 추가하여 작성하면 확인하기 어렵기 때문에, 비고란에 작성자와 작성일자를 함께 작성하여 테스터와 처리 담당자가 소통할 수 있도록 합니다. 기본 댓글이나 메모 기능을 활용할 수도 있으나, 파일 내에서 한눈에 보이지 않기 때문에 가능하면 히스토리 확인을 위해 비고란에도 적는 것을 추천합니다.
4.2. 진행 상태 변경
테스트 상태에 관련된 열은 총 3개(결과, 처리, 처리 확인)로, 한눈에 확인하기 어려울 수 있습니다. 좀 더 알아보기 쉽게 하기 위해 1개 테스트 항목 자체의 진행 상태를 보여주는 수식을 설정해 줍니다. 먼저 고유번호 열 앞이나 뒤에 '진행 상태' 열을 만듭니다.
진행 상태 수식 설정
예시에서는 결과는 Q열, 테스터는 R열, 처리는 W열, 처리확인은 Z열입니다. 테스터열을 활용한 것은, 테스터 배정이 지연되어 수식이 에러가 나는 것을 보기 좋게 처리하기 위해서입니다. 경우에 따라 생략 또는 다른 값으로 대체해도 무관합니다.
=IFS($R2="","",$Q2="P","완료",$Z2="확인 완료","완료",$W2="","처리필요",$Z2="재발생","재처리필요",$W2="완료","확인필요",$W2="처리중","처리필요",$Z2="","확인필요",$Q2="F","처리필요")
조금 복잡해 보이지만 사실 간단한 구조입니다. 설명을 덧붙이자면 IFS 함수는 작성한 조건을 충족하는 경우 해당 값을 반환하게 되며, 나열한 조건의 순서를 순차적으로 참조합니다. 만약 첫 번째 조건을 충족한다면, 두세 번째의 조건은 참조하지 않습니다. 이 함수를 사용할 때에는 조건을 나열하는 순서를 논리적으로 잘 구성하는 것을 주의해야 합니다. 참고로 위 함수는 테스터 및 처리담당자가 입력을 누락하는 경우도 고려하여 여러 경우의 수에 대응하도록 조금 많은 조건이 작성되어 있습니다.
$Q2="P","완료" : 결과가 Pass인 경우, 해당 테스트 항목은 '완료'로 표기
$Z2="확인 완료","완료" : 처리확인이 완료된 경우, 해당 테스트 항목은 '완료'로 표기
$W2="","처리필요": 처리가 안된 경우 '처리필요'로 표기
$Z2="재발생","재처리필요" : 테스터가 재확인했으나 오류가 재발생한 경우 '재처리필요'로 표기
$W2="완료","확인필요" : 처리가 완료된 경우 '확인필요'로 표기
$W2="처리중","처리필요" : 처리중인 경우 '처리필요'로 표기
$Z2="","확인필요" : 처리 확인이 안 된 경우 '확인필요'로 표기
$Q2="F","처리필요" : 결과가 Fail인 경우 '처리필요'로 표기
5. 테스트 시트 페이지 구조
테스트를 작성하는 방법은 조직, 프로젝트, 작성자에 따라 상이할 수 있습니다. 각 프로젝트의 수행 환경과 조직의 성격에 알맞게 작성합니다. 이 파일에서는 파일의 커버, 버전 히스토리, 테스트 현황(Dashboard), 모니터링 용 통합 테스트 시나리오, 각 테스트 환경별 테스트 결과 작성 시트로 나누었습니다.
대규모 인원일 때는 각 환경별로 시트를 분리하여, 분리된 시트가 원본이 되고, 통합된 내용을 각 시트에서 참조하여 가지고 오는 식으로 해야 그나마 원활합니다. 여러 개의 시트와 셀에서 수정이 동시다발적으로 일어나면 로딩이 느려지기 때문에, 다인원일 수록 시트를 나누는 것을 권장합니다.
6. 테스트 현황표 작성
현황 시트를 만들어, 테스트 진척 현황을 한눈에 볼 수 있도록 합니다. 관리자 및 경영진이 가장 자주 보는 화면이기도 합니다. 유관부서와 협의하여 보고할 항목과 집계 기준을 정하고, 그에 맞게 표시될 수 있도록 합니다.
6-1. 테스트 진척률
테스트 현황에는 아래와 같은 항목들을 작성합니다. 이때 각 항목을 나타내는 함수에는 위에서 만든 '진행상태' 열과 '결과' 열을 참조하면 수식이 좀 더 간단해집니다.
테스트 수행 건 수: 테스터가 테스터를 수행한 건 수를 표시합니다. '결과' 열이 비어있지 않은 경우에 집계하도록 설정해 둡니다.
테스트 진척률: 전체 테스트 단위 수 대비 테스트 수행 건 수를 %로 나타냅니다.
Fail 건 수: '결과' 열이 F(Fail)인 경우 집계하도록 합니다.
미처리 건 수: '진행상태' 열이 '처리필요'인 경우 집계합니다.
처리건 수: '결과'열이 F(Fail)이면서 '진행상태' 열이 '완료'인 경우 집계합니다.
처리율: 전체 테스트 단위 수 대비 처리 건 수를 %로 나타냅니다.
최종완료 건 수: '결과'열이 P(Pass)이거나 '진행상태' 열이 '완료'인 경우 집계합니다.
완료율: 전체 테스트 단위 수 대비 최종 완료 건 수를 %로 나타냅니다.
6-2. 담당자별, 환경별 처리 현황
필요에 따라 담당자별, 테스트 수행 환경별 처리 현황을 표시합니다. 특정 환경에서 오류가 더 많이 발생한다면 원인을 추적하고 추후 유사한 기능 개발 및 테스트에 참고할 수 있습니다.
7. 테스트 수행 정보 관리
이제 테스트 실행 전 테스트 안내 문서를 작성하여, 참여 대상 전체를 위해 미팅을 진행합니다. Notion, Slack의 Canvas 기능 등 조직 구성원이 열람하기 쉬운 형태로 문서를 작성하고 미리 공유하여 질문사항이 있는지 확인합니다. 그리고 일정을 잡아 테스트 수행의 목적, 방법, 관련 자료, QnA 등을 나누는 시간을 가집니다. 이 테스트에서는 Slack의 Canvas 기능을 사용하여 문서를 작성했습니다.
테스트 일정
테스트 수행 방법
기타 테스트 관련 정보작성한 문서는 쉽게 찾을 수 있도록 Slack의 채널 상단에 고정해 둡니다.
이제 구글 스프레드 시트를 이용해 테스트를 수행하고, 진척과 결과를 추적할 준비가 끝났습니다. ��
테스트는 우리 소프트웨어의 품질을 보증하고 사용자들에게 더 나은 경험을 제공하기 위해 필수적인 단계입니다. 구글 시트를 활용하여 대규모 테스트 프로젝트를 체계적으로 관리하면서, 테스트 케이스의 작성과 수행을 조금 더 효율적으로 진행할 수 있습니다. 테스트의 진척도를 시각적으로 파악하고 문제를 신속하게 대응하는 능력을 키우면서, 프로젝트는 보다 안정적이고 좋은 품질로 나아갈 것입니다.
주의사항: 모든 프로젝트는 각 조직과 프로젝트의 상황과 성격에 따라 다릅니다. 아래 예시는 테스트 케이스 작성에 참고로만 활용하시고, 반드시 상황에 맞는 테스트를 계획하시기 바랍니다.
