◆ V-RE100 QA 심층분석 v10-2  ·  287 TC · 5개 시트  ·  Function(기능) 199건 | Validation(유효성) 67건 | Error Handling 18건  ·  Happy Path 103건 | Edge Case 71건 | Error 63건 | Gap Analysis 47건  ·  AS-IS Gap 47건 전건 NT — TO-BE 240건 실행기준 PASS 95.8%  ·  Critical 140건(PASS율 55.7%) | Major 93건(PASS율 72.0%)  ·  ◆

① 핵심 지표 요약

Total 287 TC
Total
287
Sheet 1~5
PASS
184
64.1%
FAIL
3
1.0%
BLOCKED
5
1.7%
SKIPPED
48
16.7%
NT
47
16.4%
실행기준PASS
95.8
% · 184/192

② 종합 결과 분포 분석

전체 287건

전체 TC 결과 분포

287건

실행 TC (192건) 결과

PASS 95.8%

시트별 결과 누적 막대

Sheet 1~5

③ 검증유형(Verification Type)별 분석

Function 199 · Validation 67 · Error Handling 18 · Security 2 · Performance 1

검증유형별 TC 수 & PASS율

검증유형별 결과 누적 비율

검증유형별 상세 결과표

검증유형총건PASSFAILBLOCKEDSKIPPEDNT 실행기준 PASS율리스크 수준
Function(기능) 검증19910715464094.7%Medium
Validation(유효성) 검증6756202796.6%Medium
Error Handling18180000100%Low
Security220000100%Low
Performance110000100%Low
💡
검증유형 분석 인사이트
Error Handling / Security / Performance 100% PASS — 오류·보안·성능 처리 로직은 안정적으로 구현됨.
Function 기능 검증이 전체 TC의 69.3%를 차지하며, SKIPPED(46건)+NT(40건) 비중이 높아 실질 검증 커버리지 향상이 핵심 과제.
Validation 유효성에서 FAIL 2건 발생(매도단가 0원 · 거래시간 차단) → 입력 유효성 보강 필요.

④ TC 분류(Classification)별 심층 분석

Happy Path 103 · Edge Case 71 · Error 63 · Gap Analysis 47

분류별 TC 수 분포

분류별 결과 그룹 막대

분류별 결과 상세 & PASS율 비교

▶ Happy Path (103건) — 핵심 기능 정상 흐름
PASS
80건 77.7%
SKIPPED
15건 14.6%
NT
6건 5.8%
FAIL + BLOCKED
2건 1.9%
▶ Edge Case (71건) — 경계·예외 시나리오
PASS
55건 77.5%
SKIPPED
16건 22.5%
▶ Error (63건) — 오류 처리·유효성 검증
PASS
56건 88.9%
FAIL
2건 3.2%
SKIPPED
4건 6.3%
NT
1건 1.6%
▶ Gap Analysis (47건) — AS-IS vs TO-BE 갭 검증
NT (전건 미수행)
47건 100%
→ TO-BE 구현 완료 후 2차 수행 필요 (현재 0% 검증)
🎯
분류별 핵심 인사이트
Error 분류 실행기준 PASS율 96.6% — 오류·유효성 처리 로직이 가장 안정적. 단 FAIL 2건(매도단가·거래시간)은 즉시 수정 필요.
Happy Path / Edge Case SKIPPED 비율 각각 14.6% / 22.5% — 선행 TC(E2E 체인) 의존성 해소 시 실질 커버리지 대폭 향상 가능.
Gap Analysis 47건 전건 NT — AS-IS 대비 TO-BE Gap 검증이 전혀 이루어지지 않은 상태. 전체 TC의 16.4%가 사각지대.

⑤ 심각도(Severity)별 품질 분석

Critical 140 · Major 93 · High 23 · Medium 16 · Minor 12 · Low 3

심각도별 TC 수 & PASS율 (꺽은선+막대 복합)

심각도별 FAIL+BLOCKED 리스크 분포

심각도별 상세 결과 & 리스크 레벨

심각도총건PASSFAILBLOCKEDSKIPPEDNT 실행기준PASS율미검증율리스크
Critical140 781 32929 94.0% 41.4% 🔴 High
High23 150 143 93.8% 30.4% 🟡 Medium
Major93 672 1158 95.7% 24.7% 🟡 Medium
Medium16 110005 100% 31.3% 🔵 Low
Minor12 120000 100%0% 🟢 None
Low3 10002 100%66.7% ⚪ None
⚠️
Critical 심각도 핵심 리스크
Critical TC 140건 중 미검증(SKIPPED+NT) 비율 41.4%(58건) — 가장 높은 비중의 미검증 영역.
현재 실행된 82건 기준 PASS율 94.0%는 양호하나, 나머지 58건 검증 미완료는 출시 전 반드시 해소 필요.
FAIL 1건(유효성) + BLOCKED 3건(NPEX) 포함 시 Critical 리스크 TC = 4건 즉시 수정 대상.

⑥ AS-IS (현행) vs TO-BE (구현) 심층 분석

AS-IS Gap 47건 · TO-BE 검증 240건

AS-IS 현행 시스템 (re100-legacy.example.test)

47건 Gap TC
• Gap Analysis 분류 TC 47건 전건 NT (미수행)
• AS-IS 사이트 직접 검증 항목: UI/UX · 입력유효성 · 세션관리 · 검색/필터 · 오류처리 · 알림 등
• 전자서명/공인인증서 · 계약서 수정발급 · 통계 대시보드 등 AS-IS 전용 기능
현재 0% 검증 완료 — TO-BE 구현 후 비교 검증 필요

TO-BE 신규 구현 (vre100-staging)

240건 검증
• 검증 대상 240건 — PASS 184 / FAIL 3 / BLOCKED 5 / SKIPPED 48
• 실행 완료 192건 — 실행기준 PASS율 95.8%
• SKIPPED 48건은 E2E 선행 TC 의존 체인 (선행 완료 시 자동 수행 가능)
BLOCKED 5건 해소 시 실질 PASS율 97.9% 도달 가능

AS-IS Gap TC 도메인별 분포

47건

AS-IS Gap 항목 우선순위 매트릭스

Gap 항목수량구현 우선순위위험도
전자계약서 상세 기능 (G1~G4)16건P1 즉시Critical
알림·이메일 자동발송 (G2×5)5건P1 즉시Critical
NPEX 연동 검증 (Gap)4건P1 즉시Critical
중간·최종정산 AS-IS Gap6건P2 단기Major
계약 변경·해지 Gap6건P2 단기Major
현물·계약매매 시나리오 플로우 Gap9건P3 중기Medium
UI/UX · 입력유효성 Gap1건P4 저우선Minor

AS-IS vs TO-BE 도메인별 검증 완료율 비교 레이더

⑦ 발견된 문제점 & 리스크 대응 방안

FAIL 3 · BLOCKED 5 · NT 47 · SKIPPED 48
R01
🔴 NPEX/REMS 외부 API 미연동 — Critical BLOCKED 3건
문제: 스테이징 환경에서 NPEX API 방화벽 차단으로 REC 거래 결과 반영 검증 불가

대안 1: NPEX 테스트 환경 허용 IP 등록 요청 (개발팀 → NEA 담당자 경유)
대안 2: NPEX API Mock 서버 구축으로 API 응답 시뮬레이션
대안 3: NPEX 실환경 접속 전 데이터 정합성 단위 테스트로 커버

즉시 조치 필요 담당: 개발팀(NPEX연동)
R02
🔴 매도단가 0원 유효성 검증 미작동 (D-001)
문제: 현물 매도주문 등록 시 단가 0원 입력 허용 → 거래 데이터 무결성 위협

대안 1: 프론트엔드 input 이벤트에서 min=1 속성 + 실시간 검증 추가
대안 2: 등록 API 서버에서 price ≤ 0 요청 거부 (400 Bad Request)
대안 3: 오류 메시지 토스트: "단가는 1원 이상이어야 합니다"

P1 즉시 수정 담당: FE 개발팀
R03
🔴 거래시간 외 등록 차단 로직 미동작 (D-002)
문제: 관리자 설정(10:00~16:00) 거래시간 제한이 실제 API에 반영 안됨

대안 1: 등록 API 서버에서 현재 시각을 KST로 환산 후 거래시간 비교 처리
대안 2: ADM 설정 변경 시 Redis 캐시 갱신 → API 서버에서 참조
대안 3: 프론트엔드에서도 시간 체크 후 버튼 비활성화 (이중 방어)

P1 즉시 수정 담당: BE 개발팀
R04
🟡 AS-IS Gap 47건 전건 미검증 — TO-BE 구현 공백
문제: 현행(AS-IS) 기능 중 TO-BE 전환 후 동작 여부 검증 전무. 전체 TC의 16.4% 사각지대

대안 1: AS-IS Gap TC를 기능 구현 스프린트와 연동해 완료 즉시 수행
대안 2: 고위험 Gap(알림·NPEX·전자계약) 16건 우선 수행 목표 설정
대안 3: AS-IS 기능 스크린샷·녹화로 베이스라인 확보 후 TO-BE 비교

P2 단기 조치 담당: QA + PM
R05
🟡 SKIPPED 48건 — E2E 선행 TC 의존 체인 미해소
문제: Sheet 3~5의 E2E 프로세스 TC들이 선행 TC 완료 없이 수행 불가 상태

대안 1: 선행 TC(계약 생성 등) 완료 상태를 DB Seed로 미리 준비 후 수행
대안 2: 각 E2E 체인의 진입점 TC 완료 후 연속 수행 배치 스크립트 작성
대안 3: Test Fixture 패턴으로 beforeAll에서 선행 데이터 자동 생성

P2 단기 조치 담당: QA 자동화팀
R06
🔵 BUYER 장외거래 페이지 접근 불가 (D-005)
문제: BUYER 계정으로 /consumer/certificate/contract 접근 시 로그인 리다이렉트

대안 1: 개발팀에 BUYER 역할 장외거래 메뉴 올바른 URL 경로 공유 요청
대안 2: 스테이징 서버 메뉴 구조 직접 탐색으로 실제 경로 파악
대안 3: 페이지 미구현 시 구현 일정 확인 후 TC 상태 업데이트

P3 중기 조치 담당: 개발팀 + QA

⑧ 기획 보강 사항 & 액션 플랜

총 15개 보강 항목

🔴 즉시 조치 (1~2주 내)

5건
01
매도단가·유효성 검증 추가 (D-001)
min=1 프론트 검증 + API서버 0원 거부 + 오류메시지 문구 통일
FE+BE팀
~04-22
02
거래시간 차단 로직 수정 (D-002)
KST 타임존 기반 API 시간 제어 + 프론트 버튼 비활성화 이중 방어
BE팀
~04-22
03
매도주문 버튼 활성화 조건 개선 (D-003)
REC 선택 시 버튼 활성화 + data-testid 속성 + 빈목록 가이드
FE팀
~04-22
04
NPEX API 허용 IP 등록 (D-004)
스테이징 서버 IP를 NPEX 방화벽 허용 목록에 추가 요청
NPEX연동팀
~04-25
05
BUYER 장외거래 URL 경로 확인 (D-005)
개발팀에 BUYER 역할 장외거래·전자계약 화면 URL 공식 경로 공유 요청
개발팀+QA
~04-22

🟡 단기 보강 (2~4주 내)

5건
06
SKIPPED 48건 재수행 환경 구축
E2E 선행 TC용 DB Seed 스크립트 작성 + beforeAll Fixture 패턴 도입
QA자동화
~05-02
07
Critical NT 58건 검증 일정 수립
Critical 미검증 58건(SKIPPED 29+NT 29) 대상 스프린트별 수행 계획 수립
PM + QA
~04-28
08
알림·이메일 자동발송 Gap TC 구현 확인
EC4-G2 등 HIGH RISK Gap TC — TO-BE 알림 로직 구현 여부 확인 및 수행
BE팀 + QA
~05-02
09
전자계약서 상태 전환 E2E 수행
EC4-HP-C1~C8 완전한 E2E 수행을 위한 멀티 액터 환경 구성
QA
~05-05
10
TC 자동화 testid 속성 규격 정의
주요 버튼·입력필드에 data-testid 속성 부여 가이드 문서화 → 자동화 안정성↑
FE팀 + QA
~05-05

🔵 중기 기획 보강 (1~2개월)

5건
📋
AS-IS Gap 47건 TO-BE 전환 로드맵
Gap Analysis TC 47건을 P1(즉시) 16건 → P2(단기) 13건 → P3(중기) 18건 단계로 나누어 각 개발 스프린트 완료 즉시 수행 계획 수립. AS-IS 화면 베이스라인 스크린샷 아카이빙 필수.
🔗
E2E 체인 TC Fixture 자동화
SKIPPED 48건의 근본 원인인 선행 TC 의존성을 pytest-style beforeAll Fixture로 해소. 계약 생성·체결 상태를 테스트 데이터로 사전 주입해 독립 실행 가능한 TC 구조로 리팩토링.
NPEX Mock 서버 구축
NPEX API 미연동 환경에서도 BLOCKED 3건을 검증할 수 있도록 WireMock / MSW 기반 NPEX API Mock 서버 구축. 실데이터 전송·정합성 시나리오를 스테이징에서 테스트 가능하게 구성.
📊
회귀 테스트 자동화 파이프라인
현재 수동/반자동 수행 구조를 GitHub Actions CI/CD 파이프라인에 통합. PR 머지 시 Playwright 회귀 테스트 자동 수행 + Slack 알림 + 결과 엑셀 자동 업데이트.
📝
요구사항 추적 매트릭스(RTM) 구축
기획 요구사항 ID ↔ TC ID ↔ 구현 함수 3-way 매핑 RTM 문서화. 현재 TC col7(요구사항 ID) 활용하여 요구사항 커버리지 100% 달성 목표 관리 체계 수립.

🟣 장기 품질 전략 (3개월+)

5건
#전략 항목기대 효과우선순위
11정량적 품질 게이트(Quality Gate) 도입배포 전 PASS율 98% 이상 + Critical NT 0건 강제 조건 설정으로 출시 품질 보장High
12멀티 액터 동시 수행 테스트 프레임워크BUYER·SELLER·ADMIN·SUPPL 4인 동시 상호작용 E2E를 병렬 실행 가능한 구조 구현Medium
13성능·부하 테스트 확대 (Performance TC 1건 → 20건)현재 Performance TC 1건 → 동시 접속·대용량 거래·체결 지연 등 시나리오 확대Medium
14AS-IS → TO-BE 데이터 마이그레이션 검증 TC 추가기존 계약 데이터의 신규 시스템 이전 정합성 검증 → 운영 전환 리스크 최소화High
15사용자 접근성(A11y) 및 모바일 반응형 TC 추가현재 0건인 접근성·반응형 검증 → 웹 표준 준수 및 다양한 환경 대응력 확보Low

⑨ TC 버전별 증가 추이 & 품질 진화

v01(2026-01) → v10-2(2026-04)

버전별 TC 수 증가 꺾은선 차트