소개
프로덕트 디자이너는 개발자가 앱 개발을 마친 뒤, 기획과 디자인 의도대로 구현되었는지 확인하는 과정을 거칩니다. 흔히 Quality Assurance(QA)라고 부르는 이 작업은 앱의 품질을 유지하고, 시각적인 일관성과 기능의 정상 작동 여부까지 폭넓게 검토하는 단계예요.
그런데 QA 작업은 단순 반복 업무가 많고 시간이 오래 걸립니다. 티는 잘 안 나지만, 실제로는 많은 리소스가 들어가는 일이죠. 실제로 기업에서는 개발팀의 인력과 맞먹는 QA팀이 따로 있을 정도로 중요하게 여기고 리소스가 많이 들어가는 부분이지만, 빠른 검증이 필요한 스타트업에서는 최소한으로 진행할 수 밖에 없습니다. 하지만 아예 이 과정을 스킵하면 각종 버그와 사용성 문제로 검증이 제대로 되지 않는다는 한계가 존재했습니다.
그래서 디자인 업무 외에 QA까지 함께 챙기다 보니 시간이 크게 소모되었고, 자연스럽게 이 과정을 자동화할 방법은 없을까?라는 고민이 생겼습니다.
이런 문제의식에서 출발해, 직접 QA 자동화 시스템을 만들어보기로 했습니다. 진행 방식은 다음과 같습니다.
우선 디자이너라 그런지 UI가 그려져야 설계가 가능하겠더라구요.
시나리오를 자동으로 생성해주고, 클릭 한번이면 자동으로 모든 테스트를 실행해주는 앱! 이게 진짜 구현이 되면 얼마나 좋을까요... UI는 완벽하게 구성해보았지만 이걸 구현하는데에서 이제 시행 착오가 시작됩니다..
가장 기본이 될 시나리오를 만드는 프롬프트와, 시나리오를 실행하는 프롬프트도 만들었습니다.
설계 프롬프트:
당신은 웹/모바일 애플리케이션을 분석하여 QA 테스트 시나리오를 설계하는 전문가입니다.
나는 당신에게 단 하나의 화면 코드를 제공합니다. 이 화면은 어떤 종류(홈/로그인/상세 등)일 수도 있습니다.
목표:
지정된 화면에서 유저가 할 수 있는 모든 가능한 액션을 분석하고,
각 액션에 따른 예상 결과를 단 한 줄(액션 + 결과) 형태의 QA 시나리오로 생성하십시오.
제약 조건:
- 사람이나 실제 유저 로그는 없습니다. 코드만 보고 가능한 모든 유저 액션을 추론해야 합니다.
- 코드에 실제로 존재하는 UI 요소, 상태, 라우트, 텍스트만 근거로 하십시오.
- 없는 기능은 절대 상상하지 마세요.
- UX 패턴 기반 정상/엣지/오류/보안 플로우를 전문가 수준으로 고려하십시오.
- 내부 사고 과정은 복잡해도 되지만, 출력은 반드시 간단한 한 문장이어야 합니다.
출력 형식:
아래 예시는 “출력 형태 예시”이며 실제 기능명·시나리오는 제공된 코드에 맞게 생성하십시오.
예시:
넘버: 01
기능명: 예시기능명
시나리오: 어떤 행동을 하면 어떤 결과가 나타난다.
중요 규칙:
- 기능명은 화면 이름이 아니라, **각 시나리오가 속하는 실제 기능 단위(예: 컴포넌트명, UI 요소명, 상태 처리, 케이스 유형 등)**이어야 합니다.
(예: 실습 문서 목록, 로딩 UI, 상태 표시, 링크 처리, 에러 핸들링 등)
- 시나리오는 반드시 “사용자 액션 + 예상 결과”를 한 문장으로 표현해야 합니다.
- Steps, Expected Results 목록, 코드 설명은 절대 출력하지 않습니다.
- 가능한 모든 시나리오를 번호 순서대로 출력하십시오.실행 프롬프트:
당신은 웹/모바일 애플리케이션의 QA 테스트를 실제로 실행하는 전문가입니다.
나는 이미 생성된 "QA 시나리오”를 제공할테니, 당신은 시나리오에 따라 테스트를 진행하십시오.
당신의 역할은 다음과 같습니다:
1) AI-Tutor의 코드를 근거로 하여 각 유저 시나리오가 실제로 통과할지, 실패할지, 또는 판단이 불가능한지를 평가하십시오.
2) 반드시 코드에 존재하는 UI 요소, 상태, 조건, 함수, 데이터 구조만 근거로 판단해야 합니다.
(코드에 없는 기능이나 동작은 절대 상상하거나 가정하지 마십시오.)
3) 코드만으로 성공 또는 실패를 확신할 수 없다면 “추가 테스트 필요”로 분류하십시오.
4) 내부 사고 과정은 복잡해도 되지만, 출력은 지정된 형식만 따라야 합니다.
출력 형식(반드시 그대로):
넘버: 제공 됨
기능명: 제공 됨
시나리오: 제공 됨
파일경로: XXX
결과: 통과 / 실패 / 추가 테스트 필요
마지막 실행 날짜: YYYY-MM-DD
시나리오는 다음과 같습니다: 우선 이 하나하나 시나리오의 결과들을 저장하고 관리가 필요하니 데이터베이스가 필요했습니다.
그래서 supabase MCP를 사용해서 데이터를 업데이트를 해놓았습니다.
여기까지 세팅은 모두 마무리했습니다.
이제는 시나리오도 만들 수 있고, 테스트도 실행할 수 있는 프롬프트가 준비되어 있으며,
결과를 저장하는 데이터베이스와 그 결과를 보여주는 UI까지 전부 갖춰진 상태입니다.
하지만 그 다음에 마주한 것이 바로 가장 큰 난관,
즉 “그럼 어떻게 실제 테스트를 실행할 것인가?"였습니다.
고민 끝에 떠올랐던 여러 가지 방법들이 있었죠.
1번째 난관 — 테스트 실행 방식 그 자체
“AI가 사람처럼 하나하나 화면을 직접 눌러서 테스트하게 할 수 있을까?”
Playwright를 사용하면 화면 클릭이나 페이지 이동 같은 동작은 자동화할 수 있습니다.
하지만 이것만으로는 한계가 명확했습니다.
로그인 여부에 따라 달라지는 화면 상태
학생/강사/관리자 등 역할(Role)에 따른 조건 분기
특정 데이터가 있을 때만 나타나는 UI
실제로 “결과가 맞는지” 판단해야 하는 정교한 검증
GUI의 퀄리티 판단
이런 것들은 Playwright가 단순 클릭과 화면 비교만으로는 판단하기 어렵습니다.
결국 사람의 개입이 필요해졌고,
“그럼 클릭만 자동으로 해주고 결국 확인·판단은 내가 다 하면…이게 과연 자동화라고 할 수 있을까?”
라는 회의감이 들었습니다.
2번째 난관 — 전체 시스템 연동
두 번째 어려움은 모든 데이터를 연결하는 구조였습니다.
UI에서 테스트 실행 요청을 보내고
깃 저장소에서 로나 앱의 코드를 가져오고
해당 코드를 파싱해 시나리오를 생성하고
이 데이터를 다시 다른 서버에 저장하고
Claude API와 연동해 테스트를 실행하고
결과를 DB에 기록한 뒤
UI에서 다시 보기 좋게 표시하는 흐름
이 전체 파이프라인을 온전히 자동으로 연결하는 것이
생각보다 훨씬 높은 난이도의 작업이었습니다.
그러다가 강사님과의 코칭을 통해 결국 우리가 내린 결론은
“테스트 실행은 클로드 코드로 로컬 PC 안에서 돌리자!” 였습니다.
사실 중요한 것은 “결과가 어떤 UI로 보이느냐”가 아니라
테스트가 실제로 실행되느냐였기 때문에,
겉으로 어떻게 표현할지보다 테스트 실행 구조를 제대로 설계하는 것이 훨씬 중요하다고 판단했습니다.
일단 정확한 데이터만 뽑히면, 그걸 GUI로 어떻게 보여줄지는 나중에 결정해도 충분하니까요.
그리고 현실적으로 100% QA 자동화는 존재하지 않는다는 점을 인정했습니다.
사람의 개입이 완전히 사라지지 않는다면, 그 개입을 최소화하는 방향을 고민하는 것이 더 현실적이었습니다.
그 결과, 우리는 코드 리뷰 기반 테스트 방식을 선택했습니다.
즉,
로나 코드를 읽고
→ 코드에 따라 가능한 모든 유저 시나리오를 자동으로 생성하고
→ 그 시나리오대로 코드를 검증했을 때 문제가 없는지를 판별하는 방식
으로 테스트 프로세스를 구성했어요.
이 방식은 “사람의 손을 대신해 클릭하는 자동화”가 아니라,
코드를 직접 읽고 논리적으로 검증하는 테스트이기 때문에
더 안정적이고 더 자동화에 가까운 형태가 되었습니다.
그래서 아예 로나 앱 개발 폴더 안에 QA폴더를 만들었습니다.
그리고 프롬프트를 더 꼼꼼히 작성하여 2중으로 설계md와 실행md를 작성했습니다.
더욱 꼼꼼해진 설계 가이드:
# QA 테스트 시나리오 설계 가이드
## 개요
당신은 웹/모바일 애플리케이션을 분석하여 QA 테스트 시나리오를 설계하는 전문가입니다.
나는 당신에게 단 하나의 화면 코드를 제공합니다. 이 화면은 어떤 종류(홈/로그인/상세 등)일 수도 있습니다.
## 목표
지정된 화면에서 유저가 할 수 있는 모든 가능한 액션을 분석하고,
각 액션에 따른 예상 결과를 단 한 줄(액션 + 결과) 형태의 QA 시나리오로 생성하십시오.
## 제약 조건
- 사람이나 실제 유저 로그는 없습니다. 코드만 보고 가능한 모든 유저 액션을 추론해야 합니다.
- 코드에 실제로 존재하는 UI 요소, 상태, 라우트, 텍스트만 근거로 하십시오.
- 없는 기능은 절대 상상하지 마세요.
- UX 패턴 기반 정상/엣지/오류/보안 플로우를 전문가 수준으로 고려하십시오.
- 내부 사고 과정은 복잡해도 되지만, 출력은 반드시 간단한 한 문장이어야 합니다.
## 출력 형식
아래 예시는 "출력 형태 예시"이며 실제 기능명·시나리오는 제공된 코드에 맞게 생성하십시오.
### 예시:
```
넘버: 01
기능명: 예시기능명
시나리오: 어떤 행동을 하면 어떤 결과가 나타난다.
```
## 중요 규칙
1. **기능명**은 화면 이름이 아니라, **각 시나리오가 속하는 실제 기능 단위**이어야 합니다.
- 예: 실습 문서 목록, 로딩 UI, 상태 표시, 링크 처리, 에러 핸들링 등
- 컴포넌트명, UI 요소명, 상태 처리, 케이스 유형 등을 기준으로 작성
2. **시나리오**는 반드시 "사용자 액션 + 예상 결과"를 한 문장으로 표현해야 합니다.
- ✅ 좋은 예: "로그인 버튼을 클릭하면 로딩 스피너가 표시된다."
- ❌ 나쁜 예: "로그인 기능 테스트"
3. Steps, Expected Results 목록, 코드 설명은 절대 출력하지 않습니다.
4. 가능한 모든 시나리오를 번호 순서대로 출력하십시오.
## 분석 체크리스트
코드를 분석할 때 다음 항목들을 고려하십시오:
### UI 요소
- [ ] 버튼, 링크, 폼 필드 등 인터랙티브 요소
- [ ] 모달, 드롭다운, 탭 등 UI 컴포넌트
- [ ] 로딩 상태 (스켈레톤, 스피너 등)
- [ ] 에러 상태 (에러 메시지, 알림 등)
- [ ] 빈 상태 (empty state)
### 데이터 흐름
- [ ] API 호출 및 응답 처리
- [ ] 데이터 변환 (transform 함수)
- [ ] 상태 관리 (useState, store 등)
- [ ] 데이터 필터링, 정렬, 검색
### 사용자 액션
- [ ] 클릭, 호버, 포커스
- [ ] 입력, 선택, 드래그
- [ ] 스크롤, 네비게이션
- [ ] 삭제, 수정, 생성
### 엣지 케이스
- [ ] 빈 데이터
- [ ] 잘못된 데이터
- [ ] 권한 부족
- [ ] 네트워크 오류
- [ ] 로딩 중 상태
### 조건부 렌더링
- [ ] 권한에 따른 UI 변화
- [ ] 상태에 따른 UI 변화
- [ ] 데이터 유무에 따른 UI 변화
## 작업 프로세스
1. 제공된 화면 코드 읽기
2. 모든 UI 요소 식별
3. 모든 가능한 사용자 액션 나열
4. 각 액션의 예상 결과 파악
5. 시나리오 형식으로 작성
6. 번호 순서대로 정리
## 출력 예시
```
넘버: 01
기능명: 로딩 UI
시나리오: 실습 데이터를 불러오는 동안 스켈레톤 UI가 표시된다.
넘버: 02
기능명: 에러 핸들링
시나리오: 실습 목록 로딩에 실패하면 오류 메시지와 재시도 버튼이 표시된다.
넘버: 03
기능명: 에러 핸들링
시나리오: 재시도 버튼을 누르면 실습 목록을 다시 요청한다.
넘버: 04
기능명: 실습 문서 목록
시나리오: 실습 문서 데이터를 정상적으로 불러오면 전체 실습 목록이 화면에 표시된다.
넘버: 05
기능명: 실습 문서 목록
시나리오: 실습 문서 목록이 비어 있으면 빈 상태 화면 또는 빈 목록 UI가 표시된다.
```
## 파일 저장 규칙
생성한 시나리오는 반드시 다음 형식의 파일명으로 저장하십시오:
**파일명 형식:** `시나리오_[화면이름]_[날짜].md`
**예시:**
- `시나리오_홈화면_2025-11-26.md`
- `시나리오_로그인_2025-11-26.md`
- `시나리오_실습상세_2025-11-26.md`
**저장 위치:** `qa-tests/` 폴더
**주의사항:**
- 화면 이름은 분석한 실제 화면의 이름을 사용하세요
- 날짜는 YYYY-MM-DD 형식으로 작성하세요
- 이 파일은 나중에 "시나리오_실행.md" 프롬프트에서 읽어서 테스트 결과를 추가합니다
그리고 테스트를 해보았습니다. (10개만 예시)
---
넘버: 01
기능명: 로딩 UI
시나리오: 실습 데이터를 불러오는 동안 스켈레톤 UI가 표시된다.
파일경로: apps/desktop/src/pages/home.page.tsx:47
결과: 통과
마지막 실행 날짜: 2025-11-26
비고: Suspense fallback으로 PracticeListSkeleton 컴포넌트가 명시적으로 지정되어 있음
---
넘버: 02
기능명: 에러 핸들링
시나리오: 실습 목록 로딩에 실패하면 오류 메시지와 재시도 버튼이 표시된다.
파일경로: apps/desktop/src/pages/home.page.tsx:38-44
결과: 추가 테스트 필요
마지막 실행 날짜: 2025-11-26
불확실 이유: ErrorBoundary는 React 렌더링 에러를 잡지만, API 호출 실패는 useSuspenseQueries의 에러 처리에 의존. 실제 API 에러 상황에서 ErrorBoundary가 트리거되는지 확인 필요
추가 정보:
- 확인 필요 사항:
* API 호출 실패 시 ErrorBoundary가 실제로 트리거되는지
* useSuspenseQueries의 에러 처리 방식 확인
* 네트워크 에러, 500 에러 등 다양한 에러 상황에서의 동작 확인
- 가능한 엣지케이스:
* 네트워크 타임아웃
* 401, 403, 500 등 다양한 HTTP 상태 코드
* 부분적 실패 (한 쿼리는 성공, 다른 쿼리는 실패)
- 외부 의존성: React Query의 에러 처리, ErrorBoundary 동작 방식
- 주의사항: 실제 에러 상황을 시뮬레이션하여 테스트 필요
---
넘버: 03
기능명: 에러 핸들링
시나리오: 재시도 버튼을 누르면 실습 목록을 다시 요청한다.
파일경로: apps/desktop/src/pages/home.page.tsx:43
결과: 추가 테스트 필요
마지막 실행 날짜: 2025-11-26
불확실 이유: reset 함수가 ErrorBoundary의 reset이지만, 실제로 useSuspenseQueries를 다시 트리거하는지 확인 필요
추가 정보:
- 확인 필요 사항:
* ErrorBoundary의 reset 함수가 실제로 쿼리를 재시도하는지
* reset 후 Suspense가 다시 트리거되는지
* 쿼리 캐시 무효화 여부
- 가능한 엣지케이스:
* 재시도 후에도 동일한 에러가 발생하는 경우
* 부분적 재시도 (한 쿼리만 재시도)
- 외부 의존성: ErrorBoundary의 reset 동작, React Query의 재시도 메커니즘
- 주의사항: 실제 에러 상황에서 재시도 버튼 클릭 테스트 필요
---
넘버: 04
기능명: 실습 문서 목록
시나리오: 실습 문서 데이터를 정상적으로 불러오면 전체 실습 목록이 화면에 표시된다.
파일경로: apps/desktop/src/pages/home.page.tsx:65-70
결과: 추가 테스트 필요
마지막 실행 날짜: 2025-11-26
불확실 이유: API 응답 구조와 실제 데이터 변환 결과를 확인할 수 없음. 실제 API 응답이 예상한 형식인지 확인 필요
추가 정보:
- 확인 필요 사항:
* API 응답의 실제 구조 확인
* practice_docs 배열이 항상 존재하는지
* 빈 배열인 경우와 null/undefined인 경우 처리
* 데이터 변환 후 실제로 화면에 렌더링되는지
- 가능한 엣지케이스:
* API 응답이 null이거나 undefined인 경우
* practice_docs가 빈 배열인 경우
* 필수 필드(id, title 등)가 누락된 경우
- 외부 의존성: listPracticeDocsOptions API 응답 구조
- 주의사항: 실제 API 호출 결과로 데이터 표시 여부 확인 필요
---
넘버: 05
기능명: 실습 문서 목록
시나리오: 실습 문서 목록이 비어 있으면 빈 상태 화면 또는 빈 목록 UI가 표시된다.
파일경로: apps/desktop/src/features/practice-list/practice-list.tsx:128-136
결과: 통과
마지막 실행 날짜: 2025-11-26
비고: currentPractices.length === 0일 때 빈 상태 메시지를 표시하는 분기 처리 존재
---
넘버: 06
기능명: 사용자 실습 목록
시나리오: 사용자 실습 데이터를 불러오면 진행 중 또는 완료된 사용자 실습 목록이 함께 표시된다.
파일경로: apps/desktop/src/pages/home.page.tsx:64
결과: 통과
마지막 실행 날짜: 2025-11-26
비고: userPractices가 변환되어 PracticeList 컴포넌트로 전달됨
---
넘버: 07
기능명: 실습 상태 표시
시나리오: 실습 문서의 is_active가 true이면 해당 실습이 'active' 상태로 표시된다.
파일경로: apps/desktop/src/pages/home.page.tsx:20, apps/desktop/src/features/practice-list/components/practice-card.tsx
결과: 추가 테스트 필요
마지막 실행 날짜: 2025-11-26
불확실 이유: status 필드는 변환되지만 PracticeCard 컴포넌트에서 실제로 UI에 표시되지 않음. status 필드가 어디에 사용되는지 확인 필요
추가 정보:
- 확인 필요 사항:
* status 필드가 실제로 UI에 표시되는 위치 확인
* PracticeCard 외 다른 컴포넌트에서 status 사용 여부 확인
- 가능한 엣지케이스:
* status가 'pending'인 경우 처리 방식
* status 필드가 실제로 사용되지 않는 경우 시나리오 요구사항 재검토 필요
- 외부 의존성: PracticeModule 타입 정의와 실제 사용 위치
- 주의사항: 시나리오가 "표시된다"고 명시했으나 코드상 표시 로직이 없음
---
넘버: 08
기능명: 실습 상태 표시
시나리오: 실습 문서의 is_active가 false이면 해당 실습이 'completed' 상태로 표시된다.
파일경로: apps/desktop/src/pages/home.page.tsx:20, apps/desktop/src/features/practice-list/components/practice-card.tsx
결과: 추가 테스트 필요
마지막 실행 날짜: 2025-11-26
불확실 이유: status 필드는 변환되지만 PracticeCard 컴포넌트에서 실제로 UI에 표시되지 않음
추가 정보:
- 확인 필요 사항: 시나리오 07과 동일
- 가능한 엣지케이스: 시나리오 07과 동일
- 외부 의존성: 시나리오 07과 동일
- 주의사항: 시나리오 07과 동일
---
넘버: 09
기능명: 실습 상태 표시
시나리오: 사용자 실습 상태가 in_progress이면 해당 실습이 'active'로 표시된다.
파일경로: apps/desktop/src/pages/home.page.tsx:31, apps/desktop/src/features/practice-list/components/practice-card.tsx
결과: 추가 테스트 필요
마지막 실행 날짜: 2025-11-26
불확실 이유: status 필드는 변환되지만 PracticeCard 컴포넌트에서 실제로 UI에 표시되지 않음
추가 정보:
- 확인 필요 사항: 시나리오 07과 동일
- 가능한 엣지케이스: 시나리오 07과 동일
- 외부 의존성: 시나리오 07과 동일
- 주의사항: 시나리오 07과 동일
---
넘버: 10
기능명: 실습 상태 표시
시나리오: 사용자 실습 상태가 completed이면 해당 실습이 완료 상태로 표시된다.
파일경로: apps/desktop/src/pages/home.page.tsx:31, apps/desktop/src/features/practice-list/components/practice-card.tsx
결과: 추가 테스트 필요
마지막 실행 날짜: 2025-11-26
불확실 이유: status 필드는 변환되지만 PracticeCard 컴포넌트에서 실제로 UI에 표시되지 않음
추가 정보:
- 확인 필요 사항: 시나리오 07과 동일
- 가능한 엣지케이스: 시나리오 07과 동일
- 외부 의존성: 시나리오 07과 동일
- 주의사항: 시나리오 07과 동일
---
넘버: 11
기능명: 뷰 모드 전환
시나리오: '학생으로 전환' 버튼을 클릭하면 학생 모드로 전환되고 학생용 Hero 섹션이 표시된다.
파일경로: apps/desktop/src/features/practice-list/practice-list.tsx:72-74,95-96
결과: 통과
마지막 실행 날짜: 2025-11-26
비고: handleToggleViewMode 함수가 viewMode를 'student'로 변경하고, 조건부 렌더링으로 StudentHero가 표시됨
---
넘버: 12
기능명: 뷰 모드 전환
시나리오: '강사로 전환' 버튼을 클릭하면 강사 모드로 전환되고 강사용 Hero 섹션이 표시된다.
파일경로: apps/desktop/src/features/practice-list/practice-list.tsx:72-74,95-96
결과: 통과
마지막 실행 날짜: 2025-11-26
비고: handleToggleViewMode 함수가 viewMode를 'instructor'로 변경하고, 조건부 렌더링으로 InstructorHero가 표시됨
---
넘버: 13
기능명: 뷰 모드 전환
시나리오: 강사 모드일 때 강사가 개설한 실습 목록이 표시된다.
파일경로: apps/desktop/src/features/practice-list/practice-list.tsx:76
결과: 통과
마지막 실행 날짜: 2025-11-26
비고: viewMode === 'instructor'일 때 currentPractices가 practices로 설정됨
결과와 배운 점
처음에는 “코드를 보고 시나리오를 만들고, 또 그 코드로 테스트까지 하면…
모든 시나리오가 당연히 통과하지 않을까? 의미가 있을까?” 하는 걱정이 있었어요.
하지만 실제 결과는 기대 이상으로 만족스러웠습니다.
특히 좋았던 점은 다음과 같습니다:
통과/추가테스트 필요로 사람 개입 여부가 자동으로 구분됨
단순한 코드 구조 때문에 굳이 테스트하지 않아도 되는 부분과
꼭 테스트해야 하는 부분을 명확하게 구분해줘서 효율적이었습니다.
추가 테스트가 필요한 엣지 케이스 발견
사람이 수동으로 시나리오를 작성할 때 놓치기 쉬운 엣지 케이스들을
AI가 코드 구조를 바탕으로 먼저 제안해줘서 미리 대응할 수 있었습니다.
통과되지 않는 이유를 함께 제공
실패한 시나리오에 대해 “왜 통과하지 않았는지” 근거를 코드에서 찾아 설명해줘서
추가 검토가 필요한 영역을 빠르게 파악할 수 있었습니다.
하지만 역시 한계는 존재했습니다.
결국 최종 품질을 위해서는 사람이 직접 검토해야 하는 부분도 남아있다는 점이죠.
그럼에도 불구하고, 이번 QA 자동화를 통해
전체 QA 업무가 약 20~30% 정도는 줄어들 수 있을 것으로 예상됩니다.
사실 이 정도만 되어도 현장에서 느껴지는 체감은 꽤나 클 것이라 생각합니다.
최종 통계:
통과: 32개
추가 테스트 필요: 18개
실패: 0개
"추가 테스트 필요"로 변경된 시나리오 (18개):
시나리오 02, 03: 에러 핸들링 — 실제 에러 상황에서의 동작 확인 필요
시나리오 04: 실습 문서 목록 — API 응답 구조와 실제 데이터 표시 확인 필요
시나리오 07-10: 실습 상태 표시 — status 필드가 변환되지만 UI에 표시되지 않음 (코드상 표시 로직 없음)
시나리오 15: 실습 생성 — API 호출 성공 여부와 전체 플로우 확인 필요
시나리오 18, 20, 23, 24: 실습 참여 — API 호출, 라우팅, 토스트 메시지 표시 확인 필요
시나리오 25: 실습 카드 클릭 — 실제 라우팅 동작 확인 필요
시나리오 30: 날짜 표시 — 브라우저에서 실제 한국어 형식 표시 확인 필요
시나리오 34-37: 실습 삭제 — API 호출 성공, 토스트 메시지 표시 확인 필요
시나리오 45-46: 데이터 변환 — API 응답 구조와 변환 결과 확인 필요
시나리오 49-50: 레이아웃 — 실제 브라우저에서 반응형 동 작과 스크롤 확인 필요넘버: 07
기능명: 실습 상태 표시
시나리오: 실습 문서의 is_active가 true이면 해당 실습이 'active' 상태로 표시된다.
파일경로: apps/desktop/src/pages/home.page.tsx:20, apps/desktop/src/features/practice-list/components/practice-card.tsx
결과: 추가 테스트 필요
마지막 실행 날짜: 2025-11-26
불확실 이유: status 필드는 변환되지만 PracticeCard 컴포넌트에서 실제로 UI에 표시되지 않음. status 필드가 어디에 사용되는지 확인 필요
추가 정보:
- 확인 필요 사항:
* status 필드가 실제로 UI에 표시되는 위치 확인
* PracticeCard 외 다른 컴포넌트에서 status 사용 여부 확인
- 가능한 엣지케이스:
* status가 'pending'인 경우 처리 방식
* status 필드가 실제로 사용되지 않는 경우 시나리오 요구사항 재검토 필요
- 외부 의존성: PracticeModule 타입 정의와 실제 사용 위치
- 주의사항: 시나리오가 "표시된다"고 명시했으나 코드상 표시 로직이 없음
넘버: 37
기능명: 실습 삭제
시나리오: 실습 삭제에 실패하면 오류 메시지가 표시된다.
파일경로: apps/desktop/src/features/practice-list/practice-list.tsx:49-55,63-69
결과: 추가 테스트 필요
마지막 실행 날짜: 2025-11-26
불확실 이유: toast.error 호출은 확인되지만 실제로 토스트 메시지가 화면에 표시되는지 확인 필요
추가 정보:
- 확인 필요 사항:
* toast.error가 실제로 화면에 표시되는지
* APIErrorWithMessage와 일반 에러의 메시지 차이 확인
* 다양한 에러 상황에서의 메시지 확인
- 가능한 엣지케이스:
* 네트워크 에러
* 403 Forbidden
* 404 Not Found
* 500 Internal Server Error
- 외부 의존성: sonner 토스트 라이브러리, API 에러 응답 구조
- 주의사항: 실제 삭제 실패 시 토스트 메시지 표시 확인 필요