SamProject/sam-hotfix
4
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
15ea608d448af3a1c0ece2573094a6340a62b9b0
sam-hotfix/e2e/results/hotfix/HOTFIX-REPORT_dev-team_2026-02-20.md

15 KiB
Raw Blame History

Hotfix 버그 수정 요청서

작성일: 2026-02-20 작성자: QA팀 (E2E 자동화 테스트) 대상: 개발팀 서버: https://dev.codebridge-x.com (hotfix 브랜치)

요약

E2E 테스트 품질 개선(false positive 제거) 후 이전에 숨겨져 있던 실제 버그 5건이 노출되었습니다. 184개 시나리오 중 9개가 일관되게 FAIL하며, 2회 연속 실행에서 동일한 결과를 확인했습니다 (flaky 0건).

전체 시나리오 PASS FAIL 성공률 Flaky
184 175 9 95.1% 0건

버그 우선순위 요약

# Bug ID 우선순위 카테고리 FAIL 시나리오 수 영향 페이지 수
1 BUG-SORT-001 HIGH 기능 미구현 3개 8개 페이지
2 BUG-FILTER-001 HIGH 기능 미동작 1개 1개 페이지
3 BUG-REDIRECT-001 MEDIUM UX 결함 2개 2개 페이지
4 BUG-BATCH-DELETE-001 MEDIUM 데이터 처리 2개 2개 페이지
5 BUG-PERF-001 LOW 성능 1개 1개 페이지

BUG-SORT-001: 테이블 컬럼 정렬 미구현

기본 정보

항목 내용
우선순위 HIGH
카테고리 기능 미구현
FAIL 시나리오 pagination-sort-acc, pagination-sort-hr, pagination-sort-sales
영향 페이지 8개 (아래 표 참조)

영향 범위

모듈 페이지 URL
회계관리 어음관리 /accounting/bills
회계관리 입금관리 /accounting/deposits
회계관리 거래처관리 /accounting/client-management
인사관리 사원관리 /hr/employee-management
게시판 자유게시판 /boards/free
판매관리 거래처관리 /sales/client-management-sales-admin
판매관리 수주관리 /sales/order-management
판매관리 견적관리 /sales/estimate-management

증상

  • 테이블 컬럼 헤더(<th>)를 클릭해도 데이터 정렬 순서가 변하지 않음
  • 클릭 전후 첫 번째 행 데이터가 동일

재현 방법

  1. 해당 페이지 접속
  2. 테이블 컬럼 헤더 클릭
  3. 테이블 데이터 순서 확인 → 변화 없음

수정 가이드

공통 테이블 컴포넌트에 정렬 기능 구현 필요:

1. 컬럼 헤더에 클릭 이벤트 핸들러 추가
2. 클릭 시 해당 컬럼 기준 오름차순/내림차순 토글
3. 구현 방식 선택:
   - (A) 프론트엔드 정렬: 현재 페이지 데이터를 JS로 정렬
   - (B) 서버 정렬: API에 sort 파라미터 추가 (예: ?sort=column&order=asc)
4. 정렬 상태 시각적 표시 (▲▼ 아이콘)

확인 필요 사항:

  • 공통 테이블 컴포넌트 위치 (8개 페이지에 일괄 적용 가능 여부)
  • API가 정렬 파라미터를 지원하는지 확인
  • 페이지네이션과 정렬의 연동 방식 결정

E2E 검증 결과 (상세)

pagination-sort-acc (회계):

페이지 정렬 페이지네이션
어음관리 FAIL PASS
입금관리 FAIL FAIL*
거래처관리 FAIL PASS

*입금관리 페이지네이션도 동일 데이터 표시 (별도 이슈 가능)

pagination-sort-hr (인사/게시판):

페이지 정렬 페이지네이션
사원관리 FAIL PASS
자유게시판 FAIL PASS

pagination-sort-sales (판매):

페이지 정렬 페이지네이션
거래처관리 FAIL PASS
수주관리 FAIL PASS
견적관리 FAIL PASS

BUG-FILTER-001: 매출관리 거래처/매출유형 필터 미동작

기본 정보

항목 내용
우선순위 HIGH
카테고리 기능 미동작
FAIL 시나리오 search-filter-acc-sales
영향 페이지 회계관리 > 매출관리 (/accounting/sales)

증상

  1. 거래처 필터: 콤보박스에서 특정 거래처 선택 후 테이블 조회 → 다른 거래처 데이터도 포함됨
  2. 매출유형 필터: 콤보박스에서 특정 유형 선택 후 테이블 조회 → 다른 유형 데이터도 포함됨

재현 방법

거래처 필터:
1. /accounting/sales 접속
2. 거래처 콤보박스에서 특정 거래처 선택 (예: "(주)가우스랩")
3. 테이블 확인 → 선택한 거래처가 아닌 행 존재 (FAIL)

매출유형 필터:
1. 매출유형 콤보박스에서 특정 유형 선택
2. 테이블 확인 → 선택한 유형이 아닌 행 존재 (FAIL)

수정 가이드

확인 포인트:
1. 콤보박스 onChange 이벤트에서 필터 값이 state에 정상 반영되는지
2. 필터 값 변경 시 API 재호출이 트리거되는지
3. API 요청에 필터 파라미터가 포함되는지
   예: GET /api/v1/sales?vendor=XXX&type=YYY
4. 서버가 필터 파라미터를 실제로 처리하는지

가능한 원인:
- (A) onChange 핸들러에서 API 재호출 누락
- (B) API 호출 시 필터 파라미터 미전달
- (C) 서버에서 필터 파라미터 무시
- (D) 프론트엔드 필터링 로직 미구현 (서버 필터 미지원 시)

E2E 검증 결과 (상세)

스텝 내용 결과
Step 3 초기 행 수 캡처 (20행, 콤보 5개) PASS
Step 4-5 날짜 범위 필터 설정/초기화 PASS
Step 6 거래처 필터 선택 PASS
Step 7 거래처 필터 결과 검증 FAIL
Step 10 매출유형 필터 선택 PASS
Step 11 매출유형 필터 결과 검증 FAIL
Step 15 페이지네이션 검증 PASS

BUG-REDIRECT-001: 어음/입금 등록 후 목록 리다이렉트 미발생

기본 정보

항목 내용
우선순위 MEDIUM
카테고리 UX 결함
FAIL 시나리오 reload-persist-acc-bills, reload-persist-acc-deposit
영향 페이지 어음관리, 입금관리

증상

  • 데이터 등록(POST 성공) 후 URL이 폼 페이지에 머무름
  • 목록 페이지로 자동 리다이렉트 미발생
페이지 등록 후 URL (현재) 기대 URL
어음관리 /accounting/bills?mode=new /accounting/bills
입금관리 /accounting/deposits?mode=new /accounting/deposits

재현 방법

1. 어음관리(또는 입금관리) 접속
2. 등록 버튼 클릭 → 폼 페이지 이동 (/accounting/bills?mode=new)
3. 필수 필드 입력
4. 저장 버튼 클릭
5. URL 확인 → 여전히 ?mode=new (목록으로 이동 안 됨)

참고: 데이터는 정상적으로 생성됨. 수동으로 목록 복귀 후 확인하면 데이터 존재 확인 가능.

수정 가이드

어음관리 저장 핸들러:
  - 현재: POST 성공 → (아무 동작 없음)
  - 수정: POST 성공 → router.push('/accounting/bills')

입금관리 저장 핸들러:
  - 현재: POST 성공 → (아무 동작 없음)
  - 수정: POST 성공 → router.push('/accounting/deposits')

확인 포인트:
1. 저장 API 성공 콜백(onSuccess/then)에서 router.push 호출 여부
2. 성공 토스트 표시 후 리다이렉트 순서 확인
3. 다른 관리 페이지(매출관리, 출금관리 등)에서는 정상 동작하는지 비교

E2E 검증 결과 (상세)

reload-persist-acc-bills:

스텝 내용 결과 비고
Step 3 [CREATE] 데이터 생성 FAIL URL=/accounting/bills?mode=new (27.4초)
Step 5 [CREATE] 목록 복귀 (수동) PASS evaluate로 강제 이동
Step 7 [VERIFY] 새로고침 전 데이터 확인 PASS 데이터 정상 존재
Step 11 [VERIFY] 새로고침 후 데이터 유지 PASS
Step 12 [DELETE] 테스트 데이터 삭제 PASS

reload-persist-acc-deposit:

스텝 내용 결과 비고
Step 3 [CREATE] 데이터 생성 FAIL URL=/accounting/deposits?mode=new (19.5초)
Step 5 [CREATE] 목록 복귀 (수동) PASS evaluate로 강제 이동
Step 7 [VERIFY] 새로고침 전 데이터 확인 PASS 데이터 정상 존재
Step 11 [VERIFY] 새로고침 후 데이터 유지 PASS
Step 12 [DELETE] 테스트 데이터 삭제 PASS

BUG-BATCH-DELETE-001: 연속 삭제 시 2번째 데이터 미탐지

기본 정보

항목 내용
우선순위 MEDIUM
카테고리 데이터 처리
FAIL 시나리오 batch-create-acc-bills, batch-create-acc-deposit
영향 페이지 어음관리, 입금관리

증상

어음관리 (batch-create-acc-bills):

  • 3건 생성(CREATE #1~#3) 모두 성공
  • VERIFY 단계에서 E2E_TEST_어음_{timestamp} 패턴 매칭 0건 (기대 3건)
  • DELETE에서도 테스트 데이터 미탐지
  • 원인: 생성된 데이터의 어음번호/거래처명에 E2E_TEST_어음_ 접두사가 포함되지 않음 (기존 E2E_TEST_EB 접두사와 불일치)

입금관리 (batch-create-acc-deposit):

  • 3건 생성 + VERIFY 성공 + DELETE #1 성공
  • DELETE #1 후 목록 갱신 시 나머지 E2E_TEST_ 데이터가 다음 페이지로 밀림
  • DELETE #2에서 현재 페이지에 해당 데이터 없음 → FAIL

재현 방법

어음관리:
1. 어음관리에서 3건 연속 등록 (E2E_TEST_어음_ 접두사)
2. 목록 새로고침
3. E2E_TEST_어음_ 텍스트로 행 검색 → 0건 (실패)

입금관리:
1. 입금관리에서 3건 연속 등록 (E2E_TEST_ 접두사)
2. 1번째 데이터 삭제 → 성공
3. 목록 자동 갱신 후 2번째 데이터 검색 → 미탐지 (다음 페이지로 밀림)

수정 가이드

근본 원인 분석 필요:

어음관리 (데이터 불일치):
1. 어음 등록 API의 request body에 어음번호/거래처명이 어떻게 전달되는지 확인
2. 프론트엔드 입력 필드 name과 API 필드명 매핑 확인
3. 테이블 목록에서 어음번호 컬럼에 표시되는 값 확인

입금관리 (페이지네이션 이슈):
1. 삭제 후 목록 갱신 시 현재 페이지 유지 로직 확인
2. 삭제로 인해 현재 페이지 데이터가 부족해지면:
   - (A) 다음 페이지 데이터를 당겨오거나
   - (B) 총 페이지 수를 재계산하여 적절한 페이지로 이동
3. 현재 구현: 삭제 후 단순 refetch → 항목이 다음 페이지로 밀릴 수 있음

E2E 검증 결과 (상세)

batch-create-acc-bills:

스텝 내용 결과
Step 4 [CREATE #1] 데이터 생성 PASS (13.6초)
Step 8 [CREATE #2] 데이터 생성 PASS (13.5초)
Step 12 [CREATE #3] 데이터 생성 PASS (13.6초)
Step 18 [VERIFY] 3건 생성 확인 FAIL (기대 3건, 실제 0건)
Step 19 [DELETE #1] 데이터 삭제 FAIL (E2E_TEST_어음_ 데이터 없음)

batch-create-acc-deposit:

스텝 내용 결과
Step 4 [CREATE #1] 데이터 생성 PASS (12.5초)
Step 8 [CREATE #2] 데이터 생성 PASS (12.5초)
Step 12 [CREATE #3] 데이터 생성 PASS (12.5초)
Step 18 [VERIFY] 3건 생성 확인 PASS
Step 19 [DELETE #1] 데이터 삭제 PASS (6.5초)
Step 23 [DELETE #2] 데이터 삭제 FAIL (E2E_TEST_ 데이터 없음)

BUG-PERF-001: 품목관리 테이블 로드 10초 초과

기본 정보

항목 내용
우선순위 LOW
카테고리 성능
FAIL 시나리오 workflow-inventory-cycle
영향 페이지 생산관리 > 품목관리

증상

  • 품목관리 페이지에서 wait_for_table 액션이 10초 타임아웃
  • 테이블 데이터 0건 (빈 테이블)
  • 페이지 자체는 정상 로드 (DOM 노드 1488)

재현 방법

1. 생산관리 > 품목관리 접속
2. 테이블 로드 대기
3. 10초 이상 경과해도 테이블 행 미표시
4. 실제 데이터: 0건

수정 가이드

확인 필요:
1. 품목관리 API 호출이 정상적으로 이루어지는지 (Network 탭)
2. API 응답이 빈 배열인지, 아니면 응답 자체가 느린지
3. 빈 테이블 상태에서 "데이터가 없습니다" 안내 표시 여부
4. 초기 로드 시 불필요한 중복 API 호출이 있는지

가능한 원인:
- (A) 품목 데이터가 실제로 0건 → 빈 상태 처리 UI 필요
- (B) API 호출 지연 → 쿼리 최적화 또는 인덱스 추가
- (C) 테이블 컴포넌트가 데이터 0건 시 로딩 상태에 빠짐

E2E 검증 결과 (상세)

스텝 내용 결과 비고
Step 1 [품목관리] 페이지 로드 대기 PASS 1004ms
Step 2 [품목관리] wait_for_table FAIL 10016ms 타임아웃
Step 3 [품목관리] CAPTURE_ITEM PASS 테이블 데이터 0건 (경고)
Step 4-15 입고/재고/출금 워크플로우 전부 PASS

자동 진단: element_timeout (요소 대기 타임아웃)

수정 우선순위 권장

Phase 1 (즉시 수정)

Bug ID 작업량 이유
BUG-REDIRECT-001 소 router.push() 1줄 추가 × 2페이지
BUG-FILTER-001 중 필터 연동 로직 1페이지

Phase 2 (일반 수정)

Bug ID 작업량 이유
BUG-SORT-001 대 공통 테이블 정렬 기능 (8페이지 일괄 적용)
BUG-BATCH-DELETE-001 중 삭제 후 목록 갱신 로직 개선

Phase 3 (모니터링)

Bug ID 작업량 이유
BUG-PERF-001 소~중 데이터 유무 확인 후 판단

검증 방법

수정 완료 후 E2E 재검증 명령:

# 전체 재검증
node C:/Users/codeb/sam/e2e/runner/run-all.js

# 버그별 개별 검증
node C:/Users/codeb/sam/e2e/runner/run-all.js --filter pagination-sort    # BUG-SORT-001
node C:/Users/codeb/sam/e2e/runner/run-all.js --filter search-filter      # BUG-FILTER-001
node C:/Users/codeb/sam/e2e/runner/run-all.js --filter reload-persist     # BUG-REDIRECT-001
node C:/Users/codeb/sam/e2e/runner/run-all.js --filter batch-create       # BUG-BATCH-DELETE-001
node C:/Users/codeb/sam/e2e/runner/run-all.js --filter workflow           # BUG-PERF-001

목표: 184/184 PASS (100%) 달성

참고 자료

자료 경로
E2E 버그 분석 원본 e2e/results/hotfix/BUG-REPORT_quality-improvement-exposed_2026-02-19.md
1차 전체 실행 요약 e2e/results/hotfix/E2E_FULL_TEST_SUMMARY_2026-02-19_21-48-03.md
2차 전체 실행 요약 e2e/results/hotfix/E2E_FULL_TEST_SUMMARY_2026-02-19_23-27-02.md
개별 FAIL 리포트 e2e/results/hotfix/Fail-*.md (9개)
스크린샷 e2e/results/hotfix/screenshots/diag_*.png