QA Report - Redmine #4081 (dev)

• Generated: 2026-09-03T15:12:50+09:00
• Redmine: https://itsm.bix.bz/issues/4081
• QA Redmine: https://itsm.bix.bz/issues/4113
• Subject: 테넌트별 정산예정일 계산기준 실패 9건 재QA
• Workflow Status: 작업완료
• Status: PASS
• Result JSON: artifacts/result-summary.json
• Roles: ADMIN
• Route Candidates: not recorded

Scope

DEV 빅스페이먼츠 테넌트 ADMIN. 기존 실패 9건만 재검증하며 제품 코드는 변경하지 않는다. USE_SYSTEM 권한과 정산예정일 계산기준은 실행 전 값을 백업하고 종료 시 복구한다. 생성한 승인 거래는 모두 전체 취소한다.

Checklist

1. 업체수정 화면의 정산예정일 계산기준에 통보일, 거래일 선택지가 노출되는지 확인하고 각각 선택한 후 확인 팝업에서 변경을 클릭하면 정상적으로 저장되는지 확인
2. 계산기준 저장 후 업체수정 화면 재진입, 새로고침 및 재로그인해도 마지막 선택값이 유지되는지 확인
3. 계산기준을 통보일로 선택하고 확인 팝업에서 변경을 클릭하여 저장한 뒤 기존 테스트 파일로 과거 승인일시의 거래를 현재 시점에 통보
4. 거래관리 > 거래내역에서 sayhi, sayhello 거래가 MID별로 각각 1건만 생성되고 주문번호, 거래번호, 승인번호, 승인일시 및 금액이 통보 내용과 일치하는지 확인
5. 정산관리 > 정산내역에서 정산예정일이 과거 승인일이 아닌 현재 통보일을 기준으로 계산되는지 확인
6. 통보일을 기준으로 기존 정산 주기와 휴일 정책이 적용되고 거래금액, 수수료 및 정산예정금액이 정상인지 확인
7. sayhi, sayhello 승인거래가 각각 누락 없이 생성되었는지 확인
8. 계산기준을 거래일로 선택하고 확인 팝업에서 변경을 클릭하여 저장한 뒤 거래를 생성하고 거래관리 > 거래내역에서 MID별 거래가 각각 1건만 생성되며 주문번호, 거래번호, 승인번호, 승인일시 및 금액이 통보 내용과 일치하는지 확인
9. 거래일 기준으로 생성한 sayhi, sayhello 승인거래가 각각 누락 없이 생성되었는지 확인

Setup Steps

1. [required] USE_SYSTEM 권한과 업체 정산 기준 백업·복구 (admin/ADMIN / kind: permission-toggle / mutation: temporary / guard: QA_4081_ALLOW_MUTATION / restore: required) - UPDATE_TENANT_SETTLEMENT_DATE_BASIS 권한과 settlementByTransactionDateEnabled를 백업하고 finally에서 원복한다.
2. [required] 수정된 MID로 웰컴 승인·취소 통보 (admin/ADMIN / kind: data-create / mutation: temporary / guard: QA_4081_ALLOW_MUTATION / restore: required) - 로컬 테스트 파일의 sayjhi를 sayhi로 수정한 실행본으로 승인 통보하고 생성한 모든 승인을 전체 취소한다.

Source Text

기존 QA #4113에서 실패한 9건만 재검증한다. 사용자가 제공한 로컬 테스트 파일의 MID sayjhi 오타를 실행용 복사본에서 sayhi로 수정하고, 계산기준 선택 시 확인 팝업의 변경 버튼을 클릭해 저장한다.

Execution Summary

• Passed: 9
• Failed: 0
• Skipped: 0
• Blocked: 0
• Flaky: 0
• Duration: 90497ms

한눈에 보는 결과

실패 또는 확인 불가 상세

• 실패 또는 확인 불가 항목이 없습니다.

수동 재현 필요

• 수동 재현이 필요한 항목이 없습니다.

스크린샷

• 스크린샷 자료가 없습니다.

화면 재현 기록

• 화면 재현 기록 자료가 없습니다.
• 화면 재현 기록은 기본적으로 실패/확인불가 항목에 한해 포함합니다. PASS 항목 trace까지 필요하면 QA_PUBLISH_TRACE=1 npm run qa:report -- --issue <id> --env <env>로 내부 제출용 산출물을 생성합니다.

실행 기록

• 전체 / [4081][dev] 테넌트별 정산예정일 계산기준 실패 9건 재QA / 업체수정 화면의 정산예정일 계산기준에 통보일, 거래일 선택지가 노출되는지 확인하고 각각 선택한 후 확인 팝업에서 변경을 클릭하면 정상적으로 저장되는지 확인: 실행 기록 1
• 전체 / [4081][dev] 테넌트별 정산예정일 계산기준 실패 9건 재QA / 계산기준 저장 후 업체수정 화면 재진입, 새로고침 및 재로그인해도 마지막 선택값이 유지되는지 확인: 실행 기록 1
• 전체 / [4081][dev] 테넌트별 정산예정일 계산기준 실패 9건 재QA / 계산기준을 통보일로 선택하고 확인 팝업에서 변경을 클릭하여 저장한 뒤 기존 테스트 파일로 과거 승인일시의 거래를 현재 시점에 통보: 실행 기록 1
• 전체 / [4081][dev] 테넌트별 정산예정일 계산기준 실패 9건 재QA / 거래관리 > 거래내역에서 sayhi, sayhello 거래가 MID별로 각각 1건만 생성되고 주문번호, 거래번호, 승인번호, 승인일시 및 금액이 통보 내용과 일치하는지 확인: 실행 기록 1
• 전체 / [4081][dev] 테넌트별 정산예정일 계산기준 실패 9건 재QA / 정산관리 > 정산내역에서 정산예정일이 과거 승인일이 아닌 현재 통보일을 기준으로 계산되는지 확인: 실행 기록 1
• 전체 / [4081][dev] 테넌트별 정산예정일 계산기준 실패 9건 재QA / 통보일을 기준으로 기존 정산 주기와 휴일 정책이 적용되고 거래금액, 수수료 및 정산예정금액이 정상인지 확인: 실행 기록 1
• 전체 / [4081][dev] 테넌트별 정산예정일 계산기준 실패 9건 재QA / sayhi, sayhello 승인거래가 각각 누락 없이 생성되었는지 확인: 실행 기록 1
• 전체 / [4081][dev] 테넌트별 정산예정일 계산기준 실패 9건 재QA / 계산기준을 거래일로 선택하고 확인 팝업에서 변경을 클릭하여 저장한 뒤 거래를 생성하고 거래관리 > 거래내역에서 MID별 거래가 각각 1건만 생성되며 주문번호, 거래번호, 승인번호, 승인일시 및 금액이 통보 내용과 일치하는지 확인: 실행 기록 1
• 전체 / [4081][dev] 테넌트별 정산예정일 계산기준 실패 9건 재QA / sayhi, sayhello 승인거래가 각각 누락 없이 생성되었는지 확인: 실행 기록 1

자동화 원본 결과

Notes

• Playwright 실행 결과를 기준으로 작성되었습니다.
• QA PR merge, 공개 보고서 확인, QA subissue 종료 상태 갱신이 반영되었습니다.