재현 절차는 완벽한데 개발자 답변은 늘 "안 됩니다"였던 분들에게, Network와 Application 탭을 리포트에 끌어오는 법을 알려드려요.
"재현 안 됩니다"라는 답을 줄이고 싶다면 캡처 한 장보다 Network와 Application 탭이 먼저입니다.
Web·App·API 구조부터 실전 리포트 작성법까지 정리했습니다.
결함 리포트에 캡처만 붙이고 있다면, 먼저 구조를 나눠보세요
QA가 작성하는 결함 리포트는 결국 개발자가 "어디를 봐야 하는지"를 알려주는 문서입니다.
그런데 화면 캡처와 재현 절차만 적힌 리포트는, 받는 사람이 직접 재현해보기 전까지는 원인 범위를 좁힐 수 없습니다.
이 문제를 해결하는 출발점은 서비스를 Web, App, API라는 세 영역으로 나눠 보는 습관입니다.
Web은 사용자가 직접 마주하는 화면, App은 그 화면의 요청을 받아 처리하는 서버 로직, API는 둘을 연결하는 통신 구간입니다.
결함을 발견했을 때 "이게 화면에서 끝나는 문제인가, 아니면 서버까지 다녀와야 하는 문제인가"를 먼저 구분하는 것만으로도 리포트의 방향이 달라집니다.
여기서 한 단계 더 들어가면 FE, API, BE, DB라는 네 가지 책임 영역으로 원인을 분류할 수 있습니다.
FE(Front-End;프론트엔드): 웹사이트나 앱에서 사용자가 직접 눈으로 보고 상호작용하는 화면 영역을 개발하는 IT 직무 또는 분야
API(Application Programming Interface;응용 프로그램 프로그래밍 인터페이스)는 서로 다른 소프트웨어 프로그램들이 서로 데이터를 주고받고 통신할 수 있도록 도와주는 규칙과 통신 매개체
BE(Back-End;백엔드) : 사용자의 눈에 보이지 않는 서버, 데이터베이스, 애플리케이션 로직을 관리하고 프론트엔드와 원활하게 데이터를 주고받는 '뒷단'의 영역
DB(Database;데이터베이스): 컴퓨터 시스템에 전자적으로 저장되는 구조화된 정보 또는 데이터의 체계적인 집합
화면에 보이는 표현 자체의 문제는 FE, 요청이 제대로 나갔는지는 API의 요청 구간, 응답값이 정책과 맞는지는 API의 응답 구간, 서버의 처리 로직 문제는 BE, 그리고 값 자체가 잘못 저장되거나 조회되는 문제는 DB로 나눠볼 수 있습니다.
이 네 가지를 머릿속 체크리스트로 가지고 있으면, 같은 화면 캡처를 봐도 "어디부터 의심해야 하는지"가 보이기 시작합니다.
리포트를 쓰기 전에, 이 리포트를 누가 읽을지부터 생각합니다
같은 결함이라도 기획자, 디자이너, 프론트엔드 개발자, 백엔드 개발자, QA가 리포트에서 확인하고 싶은 정보는 전부 다릅니다.
기획자는 "이게 의도된 동작인지"를 먼저 보고, 프론트엔드 개발자는 화면 요소나 콘솔 에러를, 백엔드 개발자는 요청과 응답값을 먼저 확인하고 싶어 합니다.
그래서 리포트를 쓰기 전에 "이 결함은 누가 처리하게 될까"를 먼저 떠올리는 게 도움이 됩니다.
개발자 도구를 실행해 볼까요?
Windows 크롬과 엣지 모두 단축키는 동일합니다.
개발자 도구 전체 열기: F12 또는 Ctrl + Shift + I 요소 검사(특정 요소를 바로 선택): 화면에서 우클릭 후 "검사" 클릭 Console 탭으로 바로 이동: Ctrl + Shift + J
Mac
개발자 도구 전체 열기: Cmd + Option + I 요소 검사: 화면에서 우클릭(또는 Control + 클릭) 후 "검사" 클릭 Console 탭으로 바로 이동: Cmd + Option + J
탭 간 이동 (Windows/Mac 공통)
개발자 도구가 열린 상태에서 Ctrl(Cmd) + [ 또는 ] 를 누르면 Elements, Console, Network, Application 등 탭 사이를 순서대로 이동할 수 있습니다.
메뉴를 통한 접근 (단축키가 막혀 있을 때)
브라우저 우측 상단의 점 세 개(⋮) 또는 메뉴 아이콘 클릭 → "도구 더보기" → "개발자 도구" 선택하면 동일하게 열 수 있습니다.
회사 PC처럼 보안 정책으로 F12나 우클릭이 막혀 있는 환경에서는 이 메뉴 경로가 유용합니다.
만약 백엔드 개발자가 받을 가능성이 높은 결함이라면, 화면 캡처보다 Network 탭의 요청·응답 정보가 훨씬 중요한 증거가 됩니다.
반대로 화면이 깨지거나 버튼이 비활성화된 문제라면 Elements 탭에서 확인한 DOM·CSS 상태가 더 결정적인 증거가 됩니다.
이제 이 판단 기준을 가지고, 실제로 크롬 개발자 도구(DevTools)를 열어서 어떻게 증거를 모으는지 하나씩 살펴보겠습니다.
찾고 싶은 부분을 우클릭 후 "검사"를 누르면 됩니다.
실습 1. 회원가입 화면으로 Network 탭의 Request·Response·Status Code 읽어보기
먼저 회원가입처럼 사용자가 입력한 정보가 서버로 전송되는 화면을 하나 골라보세요.
본인 블로그나 테스트용 사이트의 회원가입 페이지, 혹은 실습용 사이트(예: saucedemo.com 같은 데모 사이트)도 좋습니다.
https://testmanager.tistory.com/notice/595
[공유] 소프트웨어 테스트 대상 사이트/앱/소스
기존 테스트 대상사이트 포스팅참고하세요
진행 순서는 다음과 같습니다.
먼저 크롬 개발자 도구를 열고 상단의 Network 탭을 클릭합니다.
이 상태에서 회원가입 페이지를 새로 불러오거나, 회원가입 정보를 입력하고 가입 버튼을 누릅니다.
demosite
demoqa.com
이 상태에서 회원가입 정보를 입력하고 가입[Register] 버튼을 누릅니다.
First Name: Test
Last Name: User
UserName: testuser0613
Password: Test1234!
가입 버튼을 누르면 Network 탭에 User라는 이름의 요청이 새로 생성됩니다.
정확한 경로는 Account/v1/User이며, 일반적으로 언급되는 /signup이나 /register라는 이름과는 다르니, "방금 새로 추가된 요청"을 기준으로 찾으시면 됩니다.
Network 탭 상단 필터를 Fetch/XHR로 설정해두면 다른 리소스(이미지, CSS 등)에 가려지지 않고 이 요청을 바로 찾을 수 있습니다.
이 요청 항목을 클릭하면 우측에 세부 정보가 펼쳐집니다. 여기서 확인해야 할 핵심 정보는 세 가지입니다.
Headers 탭에서는 Request URL과 Status Code를 확인합니다.
정상적으로 회원가입에 성공한 경우 Status Code는 201 Created로 표시됩니다.
만약 이미 사용 중인 아이디로 가입을 시도하면 406 Not Acceptable이 표시되는데, 이는 요청 자체는 정상적으로 도달했지만 서버가 비즈니스 규칙(중복 아이디)에 따라 처리를 거부했다는 신호입니다.
Payload 탭에서는 입력한 username과 password가 어떤 형태로 전송되었는지 확인합니다.
demoqa.com은 JSON 형식으로 {"userName": "...", "password": "..."}가 그대로 전송됩니다.
이때 비밀번호가 평문으로 보이는 것 자체는 HTTPS 통신에서는 일반적인 현상이며, 문제로 봐야 할 부분은 오히려 "이 값이 다른 응답이나 로그에도 그대로 노출되는지"입니다.
이메일 입력은 demoqa.com에는 없으니, 본인이 입력한 username/password 값과 Payload에 표시된 값이 정확히 일치하는지를 비교해보시면 됩니다.
Response 탭에서는 서버가 돌려준 응답을 확인합니다.
회원가입에 성공한 경우(201) Response에는 새로 생성된 userID와 입력한 username이 JSON으로 내려옵니다.
다만 demoqa.com에서는 이 단계에서 인증 토큰이 발급되지 않으니, "토큰이 없다"는 건 결함이 아니라 이 사이트의 정상적인 구조입니다.
반대로 중복 아이디로 실패한 경우(406)에는 Response에 "message": "User exists!"와 같은 에러 메시지가 JSON으로 내려옵니다.
(성공 시와 실패 시 Response를 각각 캡처해서 비교하는 형태로 첨부하면 좋습니다.)
실습 2. 로그인 후 Application 탭에서 토큰 저장 상태 확인하기
로그인 전, 먼저 확인해둘 것
로그인을 시도하기 전에 개발자 도구를 열고 Application 탭으로 이동합니다.
demosite
demoqa.com
정상가입된 UserName, Password 입력 후 [Login] 클릭
First Name: Test
Last Name: User
UserName: testuser0613
Password: Test1234!
이 상태에서 그대로 두고, 이전 글에서 만든 테스트 계정으로 로그인을 진행합니다.
로그인 후, 어디를 보면 되는지
로그인 버튼을 누른 뒤 다시 Local Storage 항목을 클릭(또는 새로고침 아이콘 클릭)하면, 새로운 키-값들이 추가된 것을 확인할 수 있습니다.
로그인 성공 시 아래와 같은 키들을 Local Storage에 저장합니다.
- token : 인증 토큰 값 (긴 문자열)
- userId : 로그인한 계정의 고유 ID
- expires : 토큰 만료 시각
- userName : 로그인한 사용자명
본문에서 언급한 accessToken, refreshToken이라는 이름은 demoqa.com에서는 쓰이지 않고, 단순히 token이라는 이름 하나로 저장된다는 점을 캡처와 함께 짚어주시면 좋습니다.
즉 사이트마다 키 이름은 다르지만, "로그인 후 새로운 키-값이 생성된다"는 원리 자체는 동일하다는 걸 보여주는 식으로 설명하시면 됩니다.
"자꾸 로그아웃된다" 결함을 재현하고 싶다면
로그인 직후 위 화면을 캡처한 뒤, 페이지를 새로고침(F5)하고 다시 Local Storage를 확인합니다. 정상이라면 token, userId, expires, userName 값이 그대로 유지되어야 합니다.
만약 새로고침 후 이 값들이 사라져 있거나, expires에 표시된 시각이 이미 지난 시각이라면, "새로고침 시 토큰이 삭제됨" 또는 "토큰 만료 시간이 비정상적으로 짧음"이라는 형태로 결함의 원인 범위를 좁힐 수 있습니다.
이렇게 로그인 전·후, 그리고 새로고침 전·후 캡처 세 장만 있으면, "로그인이 자꾸 풀려요"라는 모호한 보고 대신 "새로고침 후 token 키 자체가 사라짐"처럼 구체적인 증거가 담긴 리포트가 됩니다.
로그인 관련 결함은 특히 "로그인이 풀렸어요", "다시 로그인하라고 나와요" 같은 모호한 표현으로 접수되는 경우가 많습니다.
이럴 때 Application 탭을 확인하면 훨씬 구체적인 증거를 남길 수 있습니다.
먼저 로그인을 완료한 상태에서 개발자 도구의 Application 탭으로 이동합니다.
좌측 메뉴에서 Cookies, Local Storage, Session Storage 항목을 차례로 확인할 수 있습니다.
Local Storage나 Session Storage를 클릭하면 현재 사이트에 저장된 키-값 목록이 보입니다.
보통 accessToken, refreshToken, userId 같은 이름으로 로그인 정보가 저장되어 있는데, 여기서 확인할 포인트는 다음과 같습니다.
로그인 직후 토큰 값이 정상적으로 생성되었는지, 그리고 새로고침이나 일정 시간이 지난 후에도 그 값이 유지되는지를 비교해봅니다.
만약 "자꾸 로그아웃된다"는 결함이라면, 새로고침 전후로 Local Storage 값을 각각 캡처해서 비교하는 것만으로도 토큰이 사라지는 시점을 증명할 수 있습니다.
demoqa.com은 로그인 정보를 Local Storage가 아니라 Cookies에 저장합니다.
Application 탭 좌측 메뉴에서 Local Storage가 아니라 Storage > Cookies > https://demoqa.com을 클릭합니다.
여기서 로그인 관련 값들을 확인할 수 있습니다.
로그인 후 생성되는 핵심 쿠키 4종
- token : JWT 형식의 인증 토큰. 점(.)으로 구분된 세 부분으로 이루어져 있으며, 디코딩하면 userName, password, 발급 시각(iat)이 들어있습니다.
- userID : 로그인한 계정의 고유 ID (UUID 형식)
- userName : 로그인 시 입력한 username
- expires : 토큰 만료 시각 (URL 인코딩된 날짜 형식)
"로그아웃됨" 결함 재현 시 주목할 포인트
이 4개 쿠키의 Expires/Max-Age 컬럼을 보면 모두 Session으로 표시되어 있는 걸 확인할 수 있습니다.
이는 "브라우저를 완전히 종료하면 자동으로 삭제되는 쿠키"라는 의미입니다.
즉 demoqa.com 구조상 "브라우저를 껐다 켜면 로그아웃되는" 것은 정상 동작입니다.
만약 사용자가 "탭을 새로고침만 했는데 로그아웃됐다"고 보고했다면, 새로고침 전후로 이 4개 쿠키가 그대로 유지되는지를 비교해서 캡처하시면 됩니다(Session 쿠키는 새로고침에는 영향받지 않아야 정상입니다).
반대로 expires 쿠키 값 안에 들어있는 실제 날짜(2026-06-19T21:06:05.783Z 형태)와 현재 시각을 비교해서, 이 시각이 지났는데도 여전히 로그인 상태가 유지되고 있거나, 혹은 이 시각이 되기 전인데 로그아웃되어 있다면 — "쿠키의 만료 시각과 실제 로그아웃 시점이 불일치한다"는 형태로 결함을 구체화할 수 있습니다.
참고: token 쿠키 디코딩해보기
token 값을 복사해서 https://jwt.io 같은 JWT 디코더에 붙여넣으면, payload 부분에 userName, password, iat(발급 시각)이 그대로 들어있는 것을 볼 수 있습니다.
이 자체가 보안 관점에서는 "비밀번호가 토큰에 평문으로 포함됨"이라는 흥미로운 발견이 될 수 있는데, 본문에서 다룬 "Payload 확인 시 비밀번호 노출 여부 체크"와 자연스럽게 연결되는 사례입니다.
실습 3. Elements 탭으로 화면에 보이는 문제를 구조로 증명하기
마지막은 화면에 보이는 문제, 예를 들어 버튼이 비활성화되어 눌리지 않거나 입력창에 글자가 입력되지 않는 경우입니다.
이런 결함은 "버튼이 안 눌려요"라고만 적으면 받는 사람이 직접 재현해봐야 하지만, Elements 탭을 활용하면 그 자리에서 원인을 짚어줄 수 있습니다.
문제가 되는 버튼이나 입력창 위에서 마우스 우클릭 후 "검사"를 선택하면, Elements 탭에서 해당 요소의 HTML 구조가 바로 선택된 상태로 열립니다.
여기서 확인할 부분은 해당 요소에 disabled 속성이 붙어 있는지, 혹은 클래스명에 disabled나 inactive 같은 상태를 나타내는 클래스가 추가되어 있는지입니다.
만약 버튼에 disabled 속성이 그대로 남아 있다면, 이는 화면(FE) 영역에서 상태값이 제대로 갱신되지 않고 있다는 뜻이 됩니다.
추가로 우측의 Styles 패널을 보면 해당 요소에 어떤 CSS가 적용되어 있는지, 혹시 의도한 스타일이 다른 CSS에 의해 덮여쓰여지고 있는지(취소선으로 표시됨)도 확인할 수 있습니다.
세 가지 증거를 하나의 리포트로 묶으면 달라지는 것들
지금까지 살펴본 Network, Application, Elements 탭은 각각 API 구간, 인증·저장 상태, 화면 구조라는 서로 다른 영역의 증거를 보여줍니다.
결함 리포트를 작성할 때 이 중 어떤 탭의 정보가 필요한지는 결함의 종류에 따라 다르지만, 최소한 재현 절차와 함께 "어떤 탭에서 무엇을 확인했는지" 한 줄을 더하는 것만으로도 리포트의 신뢰도는 크게 달라집니다.
예를 들어 "회원가입 시 이메일 중복 체크가 동작하지 않습니다"라는 결함이라면, 재현 절차 다음에 Network 탭에서 확인한 요청 Payload와 Response 내용, 그리고 Status Code를 함께 첨부하는 것만으로 백엔드 개발자는 별도의 재현 없이 바로 응답 로직을 들여다볼 수 있게 됩니다.
캡처 한 장이 아니라 구조를 보여주는 캡처 세 장. 이 차이가 결국 "재현이 안 돼요"라는 댓글을 줄이는 가장 현실적인 방법이라고 생각합니다.
'11. 자료실·기타 > 테스트 관련 강좌' 카테고리의 다른 글
| 테스트 케이스만 따라가다 보면 놓치는 결함들, 탐색적 테스트가 필요한 이유 (0) | 2026.06.13 |
|---|---|
| Python 한 줄도 몰라도 시작하는 웹 테스트 자동화, Playwright로 로그인부터 자동화해보기 (0) | 2026.06.13 |
| 테스트만 하는 QA는 끝났다" 토스증권 채용 공고에서 읽은 AI 시대 품질 엔지니어의 변신 (0) | 2026.05.26 |
| "집에 돌아오기 전에 꺼두는 그것처럼" QA도 이제 자동화로 혼자 일한다 (0) | 2026.05.23 |
| [IT 가이드] 복잡한 배치 업무를 한눈에! 통합 관리 시스템 'JFlow'란 무엇일까? (0) | 2026.05.14 |