네 가지 기능
요구사항을 실행으로 바꾸는 순서.
계획이 케이스를 고르고, 케이스가 실행되고, 실행이 증거를 남깁니다.
02 케이스
테스트 케이스 생성
화면, 문서, 코드에서 나온 초안을 검증 가능한 케이스로 다듬고 우선순위와 자동화 수준을 매깁니다. PR이 열리면 바뀐 코드에 맞는 추가·수정·삭제 제안이 승인 대기로 올라옵니다.
자세히 보기04 UI · UX
UI 검증 · 전문가 UX 검토
Chromium, Firefox, WebKit에서 같은 케이스가 돌고 엔진마다 결과와 증거가 따로 남습니다. 화면 흐름과 사용성처럼 자동화가 판단하지 못하는 부분은 전문가가 UX 검토 노트로 남깁니다.
자세히 보기자동 실행 규칙
push마다 스모크, 릴리스 전 회귀.
저장소, 브랜치, 변경 경로 패턴으로 실행 조건을 정하면 push와 PR에 맞춰 알아서 돌아갑니다. 승인이 필요한 실행은 승인 대기 상태로 멈춰 있다가 QA 책임자가 승인하면 시작합니다.
- 저장소 · 브랜치 · 변경 경로 패턴으로 실행 조건 지정
- 실행 유형: 스모크 · 회귀 · 신규 기능 · 릴리스 전 · API 계약 · 권한 · 단위 점검
- 승인 요청, 실행 완료, 판정 FAIL은 브라우저 알림으로
- 실행 이력이 보관되고 최근 실행은 대시보드에 남습니다
증거
실패에는 재현 영상과 로그가 붙습니다.
실패한 케이스마다 그 순간의 화면, 실행 과정을 되감아 볼 수 있는 재현 영상, 실행 로그가 자동으로 남습니다. 개발자는 재현 방법을 묻지 않고 바로 고치기 시작합니다.
- 실행마다 HTML 리포트 · 재현 영상 · 실행 로그 · 증거 파일
- 결과 상태: 통과 · 실패 · 판정 보류 · 건너뜀
- 브라우저 엔진별로 따로 남는 증거
- 실패는 Jira 이슈로 자동 발행되고, 이슈에서 실행 결과로 바로 이동
심각도와 판정
경미한 실패는 FAIL이 아닙니다.
실패는 치명 · 주요 · 경미 · 사소 네 단계 심각도로 분류됩니다. 치명·주요 실패만 판정을 FAIL로 내리고, 경미·사소 실패나 판정 보류는 CONDITIONAL로 남아 사람이 결정합니다.
- 안정된 검증의 치명·주요 실패 → FAIL
- 경미·사소 실패만 있거나 보류·격리된 검증이 있으면 → CONDITIONAL
- 실행한 전부가 첫 시도에 통과 → PASS
- 요구사항 커버리지가 목표 80% 미만이면 전부 통과해도 CONDITIONAL
검증 범위 · 신뢰도 · 추이
무엇을 보지 않았는지도 남습니다.
케이스가 있어도 돌지 않았다면 검증된 것이 아닙니다. 실행이 실제로 뒷받침하는 범위만 셉니다.
검증 범위
요구사항 커버리지는 문서에서 추출한 검증 가능한 진술 중 실행이 뒷받침한 비율이고 목표는 80%입니다. 17개 체크리스트 카테고리별 실행 여부와 수집한 화면 중 한 번도 열지 않은 화면 수를 함께 봅니다. 코드 커버리지가 아닙니다.
검증 범위 보기검증 신뢰도
최근 20회 실행에서 같은 커밋인데 결과가 뒤집힌 검증을 추적합니다. 뒤집힘 비율이 20% 이상이면 자동 격리되어 계속 실행·보고되지만 판정을 FAIL로 만들지 못합니다. 브라우저 엔진별로 따로 측정합니다.
검증 신뢰도 보기품질 추이
주별 통과율, 승인 소요 시간(p50 · p95), PR 제안 채택률, 자동화 비율을 프로젝트별로 봅니다. 한 번의 판정이 아니라 릴리스가 거듭될수록 어디가 좋아지고 있는지 보입니다.
품질 추이 보기자주 묻는 질문
품질 검증을 시작하기 전에.
요구사항 문서가 정리돼 있지 않아도 시작할 수 있나요?
자동으로 만든 케이스를 그대로 실행하나요?
결과가 왔다 갔다 하는 불안정한 검증은 어떻게 처리하나요?
모바일 앱이나 API만 있는 서비스도 되나요?
기존 CI와 테스트 코드는 버려야 하나요?
이 흐름에서 사람은 어디에 개입하나요?
케이스 하나부터 세 엔진에서.
실제 스테이징 환경에서 계획, 케이스, 실행, 증거가 어떻게 이어지는지 데모로 확인하세요.
sales@qoretix.com+82-33-242-0210평일 10:00 – 18:00 KST