스크린샷으로 QA 테스트 단계를 문서화하는 방법

이 가이드에서는 QA 테스트 실행의 스크린샷 증거를 모으는 방법을 설명합니다. 테스트 목표를 정하고 준비 사항과 데이터를 기록한 뒤, 검증할 수 있는 단계를 쓰세요. 증거를 캡처하고 결과를 판정한 다음 실행 기록을 완성합니다.

핵심 요약: QA 기록은 계획한 각 동작을 예상 결과와 연결하고, 해당 실행에서 나온 증거를 바탕으로 최종 통과, 실패 또는 차단 상태를 뒷받침합니다.

테스트 목표 하나를 정합니다

테스트 목표에는 검토할 동작과 성공 조건이 드러나야 합니다. 기록 하나는 결과 하나에 집중하세요. 실패했을 때 제품의 어느 부분에 문제가 있는지 분명해집니다.

예를 들어 "Free 사용자가 Action Capture 문서를 PNG로 내보낼 수 있는지 확인"은 테스트할 수 있습니다. "Action Capture 내보내기 테스트"에는 여러 형식, 플랜 상태, 실패 경로가 섞이므로 별도 케이스로 나누는 편이 좋습니다.

반복해서 실행할 테스트라면 바뀌지 않는 테스트 케이스 ID를 지정하세요. 제목이 나중에 바뀌더라도 이후 실행, 회귀 테스트, 결함 보고서를 연결할 수 있습니다.

준비 사항과 테스트 데이터를 기록합니다

준비 사항을 적으면 테스트를 같은 조건에서 다시 실행할 수 있습니다. 제품 버전, 운영체제, 플랜 또는 계정 상태, 권한, 기능 플래그, 준비된 문서, 첫 단계 전에 필요한 데이터를 나열하세요.

"유효한 정보 입력"처럼 모호하게 쓰지 말고 정확한 테스트 데이터를 사용하세요. 값에 로그인 정보나 고객 기록이 포함될 수 있다면 안전한 테스트 데이터를 만들고, 테스터가 어디에서 가져올 수 있는지 적습니다.

간단한 설정은 다음과 같이 쓸 수 있습니다.

실행 환경: macOS 15.5, Shotomatic 1.8.2
계정 상태: Free
권한: Screen Recording 허용됨
테스트 데이터: 페이지 세 장이 있는 Action Capture 문서
시작 화면: Documents 편집기, 첫 페이지 선택됨

단계와 예상 확인 지점을 함께 씁니다

각 단계에서 동작 하나와 테스터가 확인할 결과를 짝지으세요. 긴 동작 목록을 모두 수행한 뒤에야 결과를 확인하는 일을 막을 수 있습니다.

지시는 바로 이해할 수 있게 씁니다.

1. Export 메뉴를 엽니다. 예상 결과: PNG와 JPG를 선택할 수 있습니다.
2. PNG를 선택합니다. 예상 결과: 저장 대화상자가 열립니다.
3. 테스트 폴더를 고르고 저장합니다. 예상 결과: 페이지마다 PNG 파일 하나가 생성됩니다.
4. 내보낸 파일을 엽니다. 예상 결과: 페이지가 문서 순서대로 있으며 편집기 화면과 일치합니다.

동작 여러 개를 한 단계에 묶지 마세요. 묶인 단계가 실패하면 어느 동작이 원인인지 알기 어렵습니다.

중요한 확인 지점에서 증거를 캡처합니다

유용한 증거는 테스트 판정에 필요한 상태를 보여 줍니다. 시작 설정, 플랜에 따라 달라지는 옵션, 최종 결과, 예상하지 못한 결과를 캡처하세요.

모든 클릭에 스크린샷이 필요하지는 않습니다. 테스트에서 제공 형식을 확인한다면 메뉴를 연 화면은 증거가 되지만, 평범한 폴더를 선택한 화면은 별다른 정보를 더하지 않을 수 있습니다.

테스트가 UI 경로를 따라간다면 Action Capture로 클릭별 순서를 모을 수 있습니다. 이후 페이지를 검토하고 테스트 결과를 뒷받침하는 상태만 남기세요. Free 세션은 저장 단계 5개와 Documents의 모든 내보내기 형식을 지원합니다. Pro에서는 단계 제한이 없어지고 Blur, Click Marker, Step Numbers가 추가됩니다.

실제 결과를 사실 그대로 기록합니다

실제 결과에는 이번 실행에서 일어난 일을 적습니다. 실패에 맞추려고 예상 결과를 바꾸거나, 변경 사실을 기록하지 않은 채 실행 도중 계획한 단계를 고치지 마세요.

다음 세 가지 상태 중 하나를 사용합니다.

• 통과: 필요한 결과가 모두 일치했습니다.
• 실패: 필요한 결과 중 하나 이상이 일치하지 않았습니다.
• 차단: 준비 사항 또는 별도 결함 때문에 테스트를 끝까지 실행하지 못해 판정할 수 없습니다.

테스트가 실패하면 처음 일치하지 않은 확인 지점을 적고 별도의 버그 보고서를 연결하세요. 재사용할 테스트 케이스를 지나치게 복잡하게 만들지 않고도 버그 보고서에 최소 재현 경로, 환경, 빈도, 진단 증거를 담을 수 있습니다.

이 QA 실행 기록 구조를 사용합니다

다음 구조는 재사용할 테스트 정의와 한 차례 실행 결과를 구분합니다.

테스트 케이스 ID:
목표:

실행 환경:
준비 사항:
테스트 데이터:

단계 및 예상 결과:
1. 동작:
   예상 결과:
2. 동작:
   예상 결과:

실행일:
테스터:
테스트한 빌드:

실제 결과:
상태: 통과 / 실패 / 차단
증거:
연결된 결함:
메모 또는 계획과 달라진 점:

팀에서 이미 사용하는 QA 시스템에 복사해 쓸 수 있는 문서 구조입니다. Shotomatic으로 가져오는 프로젝트 템플릿은 아닙니다.

증거를 검토하고 승인합니다

최종 검토에서는 증거가 기록된 실행에서 나온 것이 맞는지 확인합니다. 다른 사람이 출시 승인 자료로 쓰기 전에 빌드, 계정 상태, 날짜, 페이지 순서, 내보낸 결과를 점검하세요.

중복된 스크린샷을 지우고 비공개 테스트 데이터를 보호하세요. 파일을 테스트 관리 시스템 밖에 저장한다면 파일명이나 페이지 제목에 테스트 케이스 ID를 넣습니다. 기록을 공유하기 전에 마지막 검토와 독자 관점의 따라 하기 테스트를 진행하세요.

QA 기록을 본 검토자가 테스트한 내용과 설정을 파악하고, 예상 결과와 실제 결과를 비교하며, 최종 상태를 이해할 수 있으면 완성입니다. 클릭으로 진행한 테스트 순서를 모을 때는 Action Capture를 사용하세요. 계획한 테스트가 아니라 이미 발견한 문제에서 시작하는 증거라면 Mac에서 단계별 스크린샷으로 버그를 문서화하는 방법을 참고하세요.