QA 테스트 단계를 모두 스크린샷으로 남겨야 할까?

QA 기록은 두 종류의 독자가 봅니다. 당일 승인하는 검토자와 몇 달 뒤 회귀를 조사하는 담당자입니다. 두 사람 모두 무엇을 어떤 데이터로 테스트했고 결과가 어땠는지 확인해야 합니다. 클릭마다 스크린샷이 필요한 사람은 없습니다.

이 글은 수동 테스트 기록의 구조와 스크린샷이 증거가 되는 지점을 Mac의 Temposhot 워크플로로 설명합니다.

예시는 모두 TC-142 하나를 사용합니다. 스테이징 사이트의 비밀번호 재설정 테스트이며 4단계로 구성됩니다. 체크포인트만 기록하면 5페이지, 모든 클릭을 기록하면 11페이지가 생성됩니다.

테스트 목표 하나 정의

각 테스트 케이스는 동작 하나를 검증해야 합니다. "사용자가 유효한 이메일 링크로 비밀번호를 재설정할 수 있음"은 하나의 목표입니다. "계정 설정이 작동함"은 테스트 케이스가 아니라 테스트 계획입니다.

목표는 참 또는 거짓으로 판단할 수 있는 문장으로 씁니다. 마지막 스크린샷이 둘 중 어느 쪽인지 보여 줍니다.

두 테스트를 숨기는 목표 나누기

목표에 "and"가 들어 있으면 테스트가 두 개인 경우가 많습니다. "사용자가 비밀번호를 재설정하고 이메일 주소를 변경할 수 있음"은 한 부분만 실패해도 전체가 실패로 표시되며, 기록에는 어느 부분인지 드러나지 않습니다. 이때는 케이스를 두 개로 나누고 각각 ID와 기록을 부여합니다.

목표를 좁게 잡으면 기록도 짧아집니다. TC-142는 사용자가 새 비밀번호로 로그인한 시점에 끝납니다. 이전 비밀번호가 더 이상 작동하지 않는지 확인하는 것은 별도 케이스인 TC-143이며, 고유한 시작 상태를 가집니다.

사용자 관점에서 목표 쓰기

사용자 관점에서 쓴 목표는 사용자가 볼 수 있는 결과를 가리킵니다. "사용자가 유효한 이메일 링크로 비밀번호를 재설정할 수 있음"은 로그인 후 대시보드라는 화면에서 끝납니다. "재설정 엔드포인트가 200을 반환함"은 로그에서 끝나며, 이런 목표에는 스크린샷 기록 형식이 맞지 않습니다.

케이스가 두 종류를 함께 다루면 사용자에게 보이는 결과를 목표로 유지하고, 로그 줄은 텍스트로 첨부합니다. 스크린샷은 사용자에게 보이는 결과를 증명하고, 텍스트는 그 결과 뒤의 시스템 동작을 증명합니다.

사전 조건과 테스트 데이터 기록

1단계 전에 준비되어야 하는 항목을 나열해 누구나 테스트를 반복할 수 있게 합니다.

항목	예시
테스트 케이스 ID	TC-142
빌드 또는 버전	테스트 대상 빌드 번호
환경	스테이징 URL, macOS 버전, 브라우저와 버전
계정	역할과 테스트 계정 이름. 실제 고객 계정은 사용하지 않음
테스트 데이터	테스트가 사용하는 주문, 파일 또는 레코드
사전 조건	기능 플래그 켜짐, 장바구니 비어 있음, 로그아웃 상태

가상 데이터를 사용합니다. 테스트 기록은 널리 공유되며 오래 보관됩니다.

첫 페이지에서 사전 조건 증명

글로만 적힌 사전 조건은 나중에 확인할 수 없습니다. 기록의 첫 페이지에는 시작 상태를 화면으로 보여 줍니다. 예를 들어 스테이징 URL이 보이는 로그아웃 상태의 로그인 페이지입니다. 검토자는 환경을 따로 묻지 않고 확인할 수 있습니다.

TC-142에서는 빈 테스트 받은편지함이 중요합니다. 이전 재설정 이메일이 받은편지함에 남아 있으면 테스터가 잘못된 링크를 열 수 있고, 기록에는 테스트 대상이 아닌 링크로 통과한 것처럼 나타납니다.

명확히 가짜인 테스트 데이터 사용

가상 데이터는 한눈에 가짜로 보여야 합니다. "QA Reset 01" 같은 이름과 테스트 도메인의 주소는 나중에 읽는 사람에게 실제 인물이 관련되지 않았음을 분명히 보여 줍니다. 그럴듯한 이름과 성처럼 현실적인 가짜 이름은 기록에 고객 데이터가 있는지에 대한 질문을 부릅니다.

명확한 테스트 데이터는 마스킹 작업도 줄입니다. 개인 정보가 없는 기록에는 Blur가 필요 없으므로 무료 플랜으로 충분하며, 페이지에 가려진 영역 없이 전체 화면이 표시됩니다.

예상 체크포인트가 있는 단계 작성

각 단계에는 수행할 동작과, 관찰 가능한 결과가 나와야 하는 경우 예상 결과를 씁니다.

1. 로그인 페이지를 엶. Expected: "Forgot password" 링크가 보임.
2. Forgot password를 선택하고 테스트 이메일을 입력함. Expected: 확인 메시지가 표시됨.
3. 테스트 받은편지함에서 재설정 링크를 엶. Expected: 새 비밀번호 양식이 보임.
4. 유효한 새 비밀번호를 입력하고 제출함. Expected: 로그인 상태가 되고 대시보드가 보임.

예상 결과가 없는 단계는 준비 작업입니다. 예상 결과가 있는 단계는 체크포인트이며, 스크린샷은 체크포인트에 남깁니다.

예상 결과를 관찰 가능하게 작성

"정상적으로 동작함"은 예상 결과가 될 수 없습니다. 어떤 스크린샷으로도 보여 줄 수 없기 때문입니다. 예상 결과에는 메시지 문구, 필드, 값, 페이지 제목처럼 화면에 보이는 것을 적습니다. "Confirmation message: Check your email for a reset link"처럼 적으면 화면과 단어 단위로 비교할 수 있습니다.

화면에서 확인할 수 없는 예상 결과, 예를 들어 이메일 도착 시간은 페이지 설명에 텍스트로 기록합니다. 스크린샷은 화면을 보여 주고, 설명은 값을 담습니다.

단계 번호 유지

테스트 케이스의 단계 번호와 기록의 페이지 제목은 일치해야 합니다. 케이스를 나중에 수정하면서 단계를 추가해야 할 때는 번호를 다시 매기지 않고 2a처럼 접미사를 붙입니다. 그래야 예전 기록도 올바른 단계를 가리키고, "step 4"로 회귀를 검색하면 모든 빌드에서 같은 동작을 찾을 수 있습니다.

페이지 제목은 Page Inspector의 Page title에서 수정합니다. 초안 제목은 케이스와 단계 ID로 시작하도록 고친 뒤, Description에 Expected:와 Actual: 줄을 추가합니다.

준비 단계와 체크포인트 분리

TC-142에는 기록에 나타나지 않는 준비 작업이 있습니다. 테스트 받은편지함 열기, 이메일 주소 복사, 이메일 도착 대기가 이에 해당합니다. 이런 작업을 기록에서 빼면 기록은 5페이지로 유지됩니다. 준비 작업이 실패하면 조용한 공백 대신 자체 페이지가 있는 Blocked 결과가 됩니다.

실용적인 판단 기준은 다음과 같습니다. 케이스에 "Expected" 줄이 없는 단계는 페이지를 만들지 않고, 있는 단계는 정확히 한 페이지를 만듭니다.

QA 테스트 단계를 모두 스크린샷으로 남겨야 할까?

아닙니다. 다음 시점만 캡처합니다.

• 시작 상태: 사전 조건이 충족되었음을 증명함.
• 각 체크포인트: 예상 결과 또는 예상과 다른 결과를 보여 줌.
• 최종 결과: 목표가 충족되었는지 보여 줌.
• 실패: 결과가 달라진 시점의 화면과 바로 앞 단계의 화면.

단순 탐색 클릭의 스크린샷은 증거를 더하지 않고 페이지만 늘립니다. 기록을 검토하는 속도도 느려집니다.

Temposhot에서는 체크포인트만 캡처할 수 있습니다. Action Capture(Command+3)를 열고 Configure를 선택한 뒤, Mouse click capture를 수정자 키가 눌린 클릭만 캡처하거나 클릭을 전혀 캡처하지 않도록 설정합니다. 각 체크포인트에서 Shift+Command+2(수동 캡처 단축키)를 누릅니다. Start Action Capture를 선택하고 Specific Window를 고른 뒤 테스트를 실행하고 Finish capture를 선택합니다. 그러면 체크포인트마다 한 페이지씩 있는 Document가 열립니다.

실패한 테스트의 모든 단계를 남기려면 Mouse click capture를 다시 모든 클릭으로 설정합니다. 수락된 클릭마다 클릭 직전의 창이 저장됩니다. Action Capture 가이드에서 캡처 모드 목록을 볼 수 있습니다.

두 기록 모드 비교

두 모드는 서로 다른 질문에 답합니다. 체크포인트만 기록한 기록은 "각 체크포인트가 예상 결과를 보여 주었는가"에 답합니다. 모든 클릭을 기록한 기록은 "테스터가 정확히 무엇을 했는가"에 답하며, 테스트가 실패했을 때 가장 중요합니다.

무료 플랜은 Action Capture 실행마다 5단계 제한이 있습니다. 체크포인트만 기록한 TC-142 기록은 시작 상태와 체크포인트 4개로 무료 실행 한 번에 정확히 들어갑니다. 모든 클릭을 기록한 실행은 5단계 후 일시 정지하며 그때까지의 단계를 유지합니다. Temposhot Pro는 이 제한을 없앱니다.

체크포인트 전용 실행 설정

Configure Action Capture는 설정을 Mac에 저장하므로 체크포인트 설정은 다음 테스트 세션에도 유지됩니다. 튜토리얼이나 버그 보고서를 기록하기 전에 원래대로 되돌립니다.

Mark clicked area는 단축키로 추가한 단계에도 적용됩니다. 체크포인트 기록에서 표시 마커는 포인터가 우연히 머문 위치를 가리키므로 검토자를 잘못 이끌 수 있습니다. 그래서 이 설정은 꺼 둡니다.

단축키로 TC-142 실행

1. 시작 상태 캡처

   카운트다운이 끝나면 로그아웃된 로그인 페이지에서 Shift+Command+2를 누릅니다. 이것이 1페이지입니다.

2. 각 체크포인트 캡처

   각 단계를 수행합니다. 예상 결과가 화면에 나타나야 할 때 단축키를 다시 누릅니다. 2번부터 5번 페이지가 체크포인트 4개입니다.

3. 완료

   Command+.를 누르거나 Finish capture를 선택합니다. Document가 5페이지로 열립니다.

빨리 사라지는 체크포인트

일부 예상 결과는 몇 초 동안만 보입니다. 양식 제출 후 나타나는 토스트 메시지가 그렇습니다. 메시지가 나타나는 즉시 단축키를 누르면 그 순간의 화면이 저장됩니다. 키를 누르기 전에 메시지가 사라졌다면 단계를 반복하고 단축키에 손을 둔 채 준비합니다.

너무 짧게 보여 캡처할 수 없는 결과라면 설명에 적고 그 다음에 나오는 화면을 캡처합니다. 예를 들어 "Expected: toast Password updated. Actual: 토스트 확인됨, 약 3초 후 닫힘, 대시보드 표시됨."이라고 적으면 검토자는 토스트를 관찰했다는 사실과 페이지에 없는 이유를 알 수 있습니다.

여러 창에 걸친 테스트

TC-142는 브라우저에서 테스트 받은편지함으로 갔다가 다시 브라우저로 돌아옵니다. 받은편지함이 다른 브라우저 창에서 열리면 Specific Window 대상은 첫 번째 창만 계속 캡처합니다. 여러 창을 사용하는 테스트에는 Full Screen을 선택하고, 실행 전에 테스트와 무관한 창을 모두 닫습니다.

체크포인트가 실패하면 모드 전환

4단계가 실패하면 체크포인트 기록에는 결과만 남고 정확한 입력값은 남지 않습니다. 모든 클릭 모드로 테스트를 다시 실행해 실패까지의 경로를 기록합니다. 두 번째 실행은 버그 보고서에 첨부하고, 첫 번째 기록은 테스트 결과로 유지합니다.

기록을 고치지 않고 실제 결과 남기기

기록에는 기대했어야 하는 결과가 아니라 실제로 일어난 일이 나타나야 합니다. Document 편집기에서 다음과 같이 합니다.

• 페이지 제목에 단계 ID와 동작을 넣음. 예: "TC-142 step 4: Submit new password"
• Page description에 예상 결과와 실제 결과를 각각 다른 줄에 씀.
• 실패한 체크포인트에서 잘못된 값 주위에 Rectangle(R)을 그리고, "Fail" Text 레이블(T)을 추가함.

검토자에게 필요한 URL이나 빌드 레이블 같은 맥락은 잘라내지 않습니다. Framing은 관련 없는 창을 제거할 때만 사용합니다. 개인 정보는 Blur(B, Pro)로 가리고, 결과가 맞아 보이도록 값을 고치지 않습니다.

증거 주석 규칙

Temposhot의 주석은 비파괴적입니다. 사각형이나 레이블 아래의 스크린샷은 변경되지 않습니다. 이 방식은 증거를 온전하게 유지하지만, 내보낸 PDF의 독자는 렌더링된 페이지만 봅니다. 주석으로 할 수 있는 일과 할 수 없는 일의 규칙을 정해 두면 내보낸 기록을 신뢰할 수 있습니다.

고정 형식으로 설명 작성

두 줄의 고정 형식은 5페이지든 50페이지든 설명을 빠르게 훑어볼 수 있게 합니다. 첫 줄은 "Expected:"와 예상 결과이고, 둘째 줄은 "Actual:"과 스크린샷에 보이는 내용입니다.

TC-142 5페이지의 설명은 다음과 같습니다. "Expected: signed in, dashboard shown. Actual: banner Reset link expired, sign-in form shown." 검토자는 Actual 줄을 스크린샷과 한눈에 대조할 수 있습니다.

QA 실행 기록 양식 사용

• 테스트 케이스 ID, 목적, 빌드, 환경, 테스터, 날짜를 기록함.
• 사전 조건과 테스트 데이터를 기록함.
• 예상 결과가 포함된 단계를 기록함.
• 시작, 체크포인트, 종료, 실패 지점의 스크린샷을 포함함.
• 체크포인트별 실제 결과를 기록함.
• 상태를 Pass, Fail 또는 Blocked 중 하나로 기록함.
• 실패마다 연결된 버그 보고서를 기록함.

테스트 관리 도구에 첨부할 때는 Document에서 Export PDF로 내보냅니다. 본문에 넣을 증거가 필요하면 More export formats에서 PNG 페이지를 내보냅니다. 파일 이름은 TC-142_build-2026-08-27.pdf처럼 케이스 ID와 빌드로 짓습니다. 내보내기 가이드에서 형식 목록을 볼 수 있습니다. 같은 화면의 두 스크린샷을 빌드 간에 비교하려면 브라우저 도구 Compare Images가 차이점을 로컬에서 표시합니다.

테스트 기록의 PDF 설정

기본 Export PDF 설정은 대부분의 기록에 맞습니다. A4, Landscape, 표지, 단계 번호와 페이지 번호 켜짐, 이미지 앞에 설명을 배치합니다. 표지에는 문서 제목과 단계 수가 나오므로 "TC-142 build 2026-08-27 Fail" 같은 제목을 쓰면 첫 페이지에서 결과를 볼 수 있습니다. PDF 설정을 바꾸려면 Temposhot Pro가 필요합니다.

Pro에서는 미국 용지로 인쇄하는 팀이 Paper size를 Letter로 바꿀 수 있습니다. Image quality를 Small file로 설정하면 50페이지짜리 회귀 기록도 첨부 파일 크기 제한이 있는 도구에 들어갈 만큼 작아집니다.

증거로 상태 설정

각 상태에는 다른 증거가 필요합니다. 일치하는 페이지 없이 상태만 표시된 기록은 검토자가 반려해야 합니다.

케이스와 빌드별로 기록 정리

기록은 날짜만으로 찾는 경우가 드물고, 나중에 케이스 ID와 빌드로 찾습니다. 케이스마다 폴더 하나를 두고, 그 아래 빌드마다 하위 폴더를 두어야 회귀 검색으로 같은 케이스를 빌드 간에 비교할 수 있습니다.

Document 이미지 파일은 페이지 제목을 따라 이름이 붙습니다. 제목이 단계 ID로 시작하면 파일 이름이 단계 순서대로 정렬되고 빌드 사이에서도 일치합니다.

빌드 간 체크포인트 비교

TC-142가 2026-08-27 빌드에서 실패한 뒤 2026-09-03 빌드에서 통과하면, 두 4단계 PNG 파일을 Compare Images에서 엽니다. 슬라이더나 픽셀 차이 보기에서 배너만 바뀌었는지, 레이아웃도 움직였는지 확인할 수 있습니다. 실패한 기록은 회귀를 문서화하므로 두 기록을 모두 보관합니다.

증거 검토와 승인

검토자는 테스트를 직접 실행하지 않고도 세 가지를 확인해야 합니다. 사전 조건이 충족되었는지, 각 체크포인트가 명시된 결과를 보여 주는지, 최종 상태가 스크린샷과 일치하는지입니다. 검토자가 추측해야 한다면 기록에 체크포인트를 하나 더 추가해야 합니다.

Temposhot은 Document를 로컬에 저장하며 승인 워크플로는 제공하지 않습니다. 승인을 추적하는 테스트 관리 도구나 티켓에 내보낸 파일을 첨부합니다.

검토자의 확인 순서

검토자는 고정된 순서로 읽으면 5페이지 기록을 몇 분 안에 확인할 수 있습니다. 먼저 표지 제목과 1페이지를 사전 조건과 비교합니다. 빌드, URL, 로그아웃 상태가 맞는지 봅니다. 둘째, 각 체크포인트 페이지를 읽고 "Actual" 줄을 스크린샷과 비교합니다.

셋째, 표지의 상태가 페이지와 일치하는지 확인합니다. 5페이지에 빨간 오류 배너가 있는데 Pass로 표시된 기록은 테스터에게 반려됩니다. 연결된 버그 보고서 없이 Fail로 표시된 기록도 반려됩니다.

Blocked는 Fail이 아님

테스트는 체크포인트에 도달하지 못했고, 그 이유가 검증 대상 동작 밖에 있을 때 Blocked입니다. TC-142에서 스테이징 장애로 재설정 이메일이 도착하지 않으면 3단계가 Blocked 상태가 됩니다. 기록에는 시작 상태와 도달 가능했던 마지막 화면이 나타나고, 이유는 설명에 적습니다.

Blocked 테스트를 Fail로 표시하면 실패율이 실제보다 나빠 보이고 버그가 잘못된 팀에 전달됩니다. Pass로 표시하면 공백이 숨겨집니다. Blocked를 별도 상태로 유지하고, 차단 요인이 해결되면 케이스를 다시 실행합니다.

실패한 체크포인트에서 재테스트까지

실패는 고정된 경로를 따라 진행됩니다. 원래 기록은 각 단계에서 그대로 유지됩니다.

테스트 세션의 키보드 흐름

10~20개 케이스를 한 세션에서 실행하는 테스터는 키보드를 떠나지 않을 때 효율적입니다. 아래 키는 기록과 첫 편집 단계를 다룹니다.

Mac에서 기록 보관

Document는 기록한 Mac에 남고, 원본 세션은 보관 한도까지 Capture History에 남습니다. 기본 한도는 30개 세션이며 Settings > History에서 1~500개 사이로 조정할 수 있습니다. 바쁜 테스트 주기에는 며칠 만에 30개 세션을 넘을 수 있으므로, 케이스가 끝나면 각 기록을 테스트 관리 도구로 내보냅니다.

자주 묻는 질문

스크린샷만으로 테스트 증거가 충분한가요?

수동 UI 테스트에서는 핵심 증거입니다. 화면에 나타나지 않는 실패는 로그, 콘솔 출력, 네트워크 데이터를 텍스트로 추가합니다. 자세한 내용은 스크린샷 증거에서 설명합니다.

자동화 테스트도 스크린샷을 남겨야 하나요?

자동화 스위트는 보통 실패 시 스크린샷을 캡처합니다. 빌드 간 스크린샷을 자동으로 비교하는 방법은 시각적 회귀 테스트에서 설명합니다.

QA 중 발견한 실패는 어떻게 보고하나요?

케이스에 연결된 별도의 버그 보고서를 작성합니다. Mac에서 단계별 스크린샷으로 버그를 기록하는 방법에서 절차를 설명합니다.

테스트 기록에는 페이지가 몇 개여야 하나요?

시작 상태에 1페이지, 체크포인트마다 1페이지, 실패가 있으면 실패 페이지 1페이지입니다. TC-142에는 체크포인트가 4개이므로 통과한 기록은 5페이지입니다.

체크포인트 페이지에 포인터를 표시할 수 있나요?

예. Configure Action Capture에서 Show cursor in shortcut captures를 켭니다. 포인터 위치가 결과와 관계없으면 끕니다.

클릭을 명확한 단계별 가이드로 바꾸기

Action Capture는 실행에 따라 단축키 또는 모든 클릭으로 체크포인트를 기록합니다. Temposhot 다운로드에서 앱을 받고, 다음 테스트 기록을 순서가 있는 PDF로 첨부합니다.