무엇을 테스트할지 정하기

이 단계에서 두 가지를 정합니다. 내 앱이 어느 트랙에 속하는지, 그리고 그 앱에서 깨지면 사업이 멈추는 흐름이 무엇인지입니다. 이 둘이 다음 단계에서 그대로 테스트가 됩니다.

Claude Code에서 이 단계는 /3-analyze-target 스킬이 맡습니다. 앞 단계에서 정한 진행 방식(novice, experienced)에 따라 질문이 한 번에 하나씩 오거나 묶여서 옵니다.

1) 내 앱은 어느 트랙인가

세 트랙 중 하나 이상을 고릅니다. 보통은 하나입니다.

내 앱의 모양	트랙	쓰는 도구
브라우저로 여는 웹사이트, SPA, PWA	web	Playwright
설치해서 쓰는 데스크톱 앱 (Electron)	electron	Playwright _electron
폰에 설치하는 앱	mobile	Maestro

어느 트랙인지 헷갈리면 앱을 어떻게 여는지로 판단하면 됩니다. 주소창에 URL을 치고 들어가면 web이고, 아이콘을 두 번 눌러서 창이 뜨면 electron이며, 폰 홈 화면에서 누르면 mobile입니다.

모바일이면 일단 Maestro로 시작합니다. 모바일 안에서도 Expo인지 React Native인지 네이티브인지에 따라 더 세분된 선택지가 있지만, 그 갈래는 전문가용 매뉴얼에서 다룹니다. 비개발자용 매뉴얼에서는 “모바일이면 Maestro”로 충분합니다.

2) 내 앱에 어떻게 붙을 것인가

테스트가 본인 앱을 조작하려면 앱이 어디 있는지를 알려 줘야 합니다. 접근법은 트랙마다 조금씩 다릅니다.

• web: 로컬에서 띄우는 dev server 명령(예를 들어 npm run dev로 http://localhost:5173에 뜨는 경우) 또는 스테이징 URL을 알려 줍니다.
• electron: 빌드된 앱 바이너리 경로 또는 프로젝트 폴더를 알려 줍니다.
• mobile: Expo, React Native, 또는 네이티브 빌드를 시뮬레이터나 에뮬레이터에 설치한 상태여야 합니다.

여기서 본인이 답할 것은 앱의 위치와 띄우는 방법입니다. 테스트 계정 비밀번호 같은 실제 값은 이 단계에서 묻지 않습니다. 그 값은 본인이 직접 .env.test.local에 적습니다(사전 준비의 6번 항목).

운영 환경과 실제 데이터베이스에는 절대 붙지 마세요

여기서 알려 주는 “앱의 위치”는 로컬, 스테이징, 또는 테스트 전용 환경이어야 합니다. 실제 사용자가 쓰는 운영 환경 서버와 실제 데이터베이스에는 절대 붙이지 않습니다.

테스트는 회원가입을 하고, 결제를 누르고, 데이터를 만들고 지웁니다. 그 대상이 운영 환경 서버라면 진짜 사용자 데이터가 오염되고, 진짜 결제가 일어나고, 진짜 계정이 사라질 수 있습니다. AI도 본인이 운영 환경 URL을 넣으려 하면 경고하고 스테이징이나 전용 환경으로 유도합니다. 이 base가 가장 강하게 막아 두는 항목입니다.

스테이징 환경이 아직 없다면 로컬에서 dev server를 띄워 거기에 붙이는 방법이 가장 안전하고 빠릅니다.

3) 깨지면 치명적인 흐름 정리하기

이 항목이 가장 중요합니다. 본인 앱에서 “이게 안 되면 사업이 멈춘다” 수준의 사용자 흐름을 3~5개 뽑아냅니다.

AI가 이렇게 묻습니다.

이게 안 되면 사업이 멈추는 사용자 흐름을 알려주세요. (예: 로그인 → 결제 → 대시보드)

각 흐름은 “누가 / 무엇을 하면 / 어떤 결과”의 한 줄로 적습니다. 이 한 줄이 나중에 테스트 한 개가 됩니다. 예를 들면 이런 식입니다.

• 비로그인 방문자가 가격 페이지에서 Pro 결제를 누르면 대시보드로 들어간다
• 로그인한 사용자가 설정에서 프로필 이름을 바꾸면 저장된다
• 새 사용자가 회원가입을 마치면 환영 화면이 뜬다

여기서 욕심을 내지 않는 편이 좋습니다. 한 번에 모든 화면을 테스트하려 들면 끝이 나지 않습니다. 깨지면 가장 치명적인 흐름부터 35개만 고르고, 그중에서도 먼저 자동화할 12개를 표시합니다. 이 1~2개가 smoke 후보, 즉 가장 먼저 만들 테스트입니다. 나머지는 나중에 확장하면 됩니다.

4) 정리된 내용은 어디에 저장되나

답을 마치면 AI가 docs/design/e2e-spec.md라는 파일에 정리합니다. §1에는 앱 개요(이름, 설명, 트랙, 접근법, 환경)가 들어가고, §2에는 핵심 흐름 목록이 우선순위와 함께 들어갑니다. 이 파일이 앞으로 테스트의 기준점이 됩니다. AI가 다 적은 다음 어디가 바뀌었는지 보여 주니, 본인이 의도한 흐름이 맞게 들어갔는지 한 번 눈으로 확인하면 됩니다.

무엇을 테스트할지 도무지 떠오르지 않을 때

앱은 있는데 어떤 흐름이 치명적인지 정리가 되지 않는다면 /brainstorm-e2e를 먼저 부르면 됩니다. 짧은 대화로 “어떤 앱인지, 어떤 흐름이 깨지면 사업이 멈추는지”를 같이 좁혀 줍니다. 이 과정을 거친 다음 /3-analyze-target으로 넘어가면 답하기가 한결 수월합니다.

다음

트랙과 핵심 흐름이 정해졌다면 그중 하나를 실제 테스트로 옮길 차례입니다. 첫 테스트 한 개로 갑니다.