품질 검증 현재 제공
지금 릴리스해도 되는가.
요구사항 문서와 수집한 화면에서 테스트 계획과 케이스를 만들고, 세 브라우저 엔진과 API 계약으로 실행합니다. 결과는 PASS · CONDITIONAL · FAIL 판정과 '무엇을 보지 않았는지'를 세는 검증 범위로 정리됩니다.
받는 것릴리스 판정 · 실패 증거 · 검증 범위 · 격리된 검증 목록
자세히 보기 · 품질 검증Qoretix / 커머스 웹스테이징
3개브라우저 엔진
Chromium · Firefox · WebKit
Chromium · Firefox · WebKit
3단계릴리스 판정
PASS · CONDITIONAL · FAIL
PASS · CONDITIONAL · FAIL
17개공통 체크리스트 카테고리
인증부터 내비게이션까지
인증부터 내비게이션까지
5분저장소 연결부터 첫 실행까지
보통 걸리는 시간
보통 걸리는 시간
세 가지 질문, 하나의 답
한 프로젝트, 한 화면, 하나의 판정.
품질·보안·모니터링을 따로 보면 판정이 세 개가 됩니다. Qoretix는 같은 커밋을 기준으로 하나의 릴리스 판정을 냅니다.
보안 검사 · 취약점 관리 현재 제공
무엇이 열려 있는가.
연결된 저장소의 코드 스캔·시크릿 스캔·의존성 경보와 lockfile 기준 악성 패키지 발견을 릴리스 판정과 같은 화면에 둡니다. 치명·주요 취약점은 판정을 FAIL로 내립니다.
받는 것발견 상세 · 수정 방법 · 커밋 시점 의존성 기록
자세히 보기 · 보안 검사 · 취약점 관리모니터링 · 운영 이슈 미리보기
배포 뒤에 무슨 일이 있었는가.
운영에서 발생한 오류·성능·릴리스 이벤트를 커밋 단위로 받아, 그 오류를 재현하는 검증을 회귀 검증에 추가합니다. 배포 전 판정과 배포 후 실제를 이어서 봅니다.
받는 것커밋별 이벤트 · 회귀 검증 추가 · 담당자 알림
자세히 보기 · 모니터링 · 운영 이슈하나의 프로젝트 흐름
요구사항에서 재검증까지, 끊기지 않습니다.
저장소를 연결하고 대상 URL과 테스트 계정을 등록하면, 문서와 화면에서 계획과 케이스가 나오고 push와 PR에 맞춰 실행됩니다. 실행 결과와 보안 발견이 같은 커밋 아래 모입니다.
요구GitHub 저장소 연결, 테스트 대상 URL, 테스트 계정. 요구사항 문서를 첨부하고 사이트를 돌아다니며 화면 목록을 모읍니다(최대 90초).
계획문서와 활성 케이스를 읽어 이름 · 설명 · 근거 · 계획서 · 선택 케이스가 담긴 테스트 계획을 만듭니다. 초안 → 활성 → 보관.
케이스사람 작성 · 문서 기반 · 코드 기반 세 출처. 시나리오 · 전제조건 · 입력값 · 기대 결과 · 우선순위 · 자동화 수준을 채우고, 검증할 수 없는 초안은 버립니다.
API · UI 실행저장소 · 브랜치 · 변경 경로 규칙에 따라 자동 실행. UI는 Chromium · Firefox · WebKit, API는 계약 기준. 실패는 스크린샷 · 재현 영상 · 로그가 남습니다.
보안저장소의 코드 스캔·시크릿 스캔·의존성 경보와 lockfile 기준 악성 패키지 발견이 같은 실행의 판정에 반영됩니다. 치명·주요 발견은 FAIL입니다.
보고 · 재검증HTML 리포트와 증거 파일, 릴리스 판정. 실패는 Jira 이슈로 발행되고, 수정 뒤 같은 케이스로 다시 검증하면 판정이 갱신됩니다.
품질 검증 현재 제공
실패에는 스크린샷,
재현 영상, 로그가 붙습니다.
저장소 · 브랜치 · 변경 경로 규칙에 따라 push와 PR에 맞춰 자동 실행하고, 필요하면 승인 뒤에 돌립니다. 실행 유형은 스모크 · 회귀 · 신규 기능 · 릴리스 전 · API 계약 · 권한 · 단위 점검 중에서 고릅니다.
- UI 검증은 Chromium · Firefox · WebKit 세 엔진에서, API 검증은 계약 기준으로 실행됩니다
- 같은 커밋에서 결과가 뒤집힌 검증은 최근 20회 실행 기준으로 자동 격리되어 판정을 FAIL로 만들지 못합니다
- 요구사항 커버리지가 목표 80% 아래면 전부 통과해도 CONDITIONAL입니다
- 실패 결과는 Jira 이슈로 발행되어 실행 결과와 연결됩니다
보안 검사 · 취약점 관리 현재 제공
0건과 '확인 불가'는 다릅니다.
저장소에서 코드 스캔이나 의존성 경보가 꺼져 있으면 0건이 아니라 '확인 불가'로 표시합니다. 검사하지 않은 항목은 통과가 아닙니다.
- 발견마다 유형(의존성 / 악성 패키지 / 시크릿 / 코드 스캔) · 심각도 · 위치 · 영향 범위 · 수정 방법 · 원문 링크
- lockfile의 패키지 버전을 공개 취약점 DB에 조회하고, 악성으로 신고된 패키지는 치명으로 따로 표시합니다
- 의존성 트리를 커밋 시점 기준으로 기록해 '그때 무엇이 들어 있었는지' 되짚을 수 있습니다
- 치명·주요 발견은 릴리스 판정을 FAIL로 내립니다
모니터링 · 운영 이슈 미리보기
배포 전 판정과
배포 후 실제를 나란히.
운영에서 발생한 오류·성능·릴리스 이벤트를 커밋 단위로 받아옵니다. 어떤 배포 뒤에 무엇이 늘었는지를 그 배포의 릴리스 판정 옆에서 봅니다.
- 운영 오류를 재현하는 검증을 만들어 회귀 검증에 추가합니다
- 실사용 경로를 근거로 어떤 화면부터 검증할지 정합니다
- 담당자에게 알리고 이슈와 연결합니다
제품 + 전문가
직접 쓰거나, 검증 업무를 맡기거나.
두 방식은 함께 쓸 수 있습니다. 같은 워크스페이스, 같은 판정 위에서 사람이 하는 일만 나눕니다.
적용 대상
누가 어떤 화면을 보는가만 다릅니다.
자체 제품을 만드는 팀도, 고객 프로젝트를 수행하는 팀도 같은 플랫폼, 같은 판정을 씁니다.
제품팀 · 개발팀
PR마다 판정이 나옵니다. 변경 경로에 맞춰 자동 실행되고, 실패는 Jira로 갑니다. 릴리스 전에 '한 번도 열지 않은 화면'과 커버리지 미달을 먼저 확인하고, 주별 통과율 · 승인 소요 시간(p50 · p95) · PR 제안 채택률로 팀의 추이를 봅니다.
제품팀 · 개발팀 솔루션개발사 · SI
조직별 워크스페이스에서 고객사는 자기 프로젝트의 결과만 봅니다. HTML 리포트, 증거 파일, 릴리스 판정이 그대로 인수 자료가 됩니다. 케이스의 한·영·일 번역으로 해외 고객 프로젝트도 같은 흐름으로 갑니다.
개발사 · SI 솔루션결과물
실행 한 번마다 남는 기록입니다.
대시보드 한 장이 아닙니다. 실행마다 판정, 증거, 검증 범위가 기록으로 남고, 관리형 QA를 결합하면 전문가의 메모가 더해집니다.
릴리스 판정과 근거
PASS · CONDITIONAL · FAIL과 그렇게 판정한 이유. 격리된 검증, 보류된 검증, 커버리지 미달이 함께 적힙니다.
HTML 리포트와 증거 파일
실행마다 HTML 리포트와 실행 로그, 실패 케이스의 스크린샷 · 재현 영상이 남고 실행 이력이 보관됩니다.
검증 범위
요구사항 · 체크리스트 · 화면 세 기준. 케이스가 있어도 돌지 않았다면 검증된 것으로 세지 않습니다.
보안·공급망 발견과 Jira 이슈 링크
발견 상세와 수정 방법, 커밋 시점 의존성 기록, 그리고 실패 결과에서 발행된 Jira 이슈가 실행에 연결됩니다.
전문가의 릴리스 메모 선택
관리형 QA를 결합하면 계획 검토 의견, 탐색적 QA 결과, 결과 분류, 재검증 기록, 릴리스 메모가 같은 프로젝트에 남습니다.
자주 묻는 질문
도입 전에 확인해 둘 다섯 가지
시작하려면 무엇이 필요한가요?
GitHub 저장소(GitHub App 설치 권한), 테스트 대상 URL(스테이징 권장), 테스트 계정이면 됩니다. 요구사항 문서는 docx · xlsx · pptx · pdf · 이미지 · markdown으로 첨부하고, 문서가 없어도 화면 수집으로 시작할 수 있습니다. 서버 · API 프로젝트는 화면 수집 없이 API 검증으로 갑니다.
이미 쓰는 CI와 이슈 트래커는 어떻게 되나요?
GitHub Actions와 Jira는 그대로 씁니다. push와 PR에 맞춰 자동 실행 규칙이 돌고, 실패 결과는 Jira 이슈로 발행되어 실행과 연결됩니다. 그 외 저장소 호스팅 · 이슈 트래커 연동과 PR 체크로 배포를 막는 릴리스 게이팅은 미리보기로 제공됩니다.
CONDITIONAL은 통과인가요?
아닙니다. 경미·사소 실패만 있거나, 불안정 · 격리 · 보류된 검증이 있거나, 요구사항 커버리지가 목표 80% 아래일 때 나오는 판정으로 '사람이 봐야 한다'는 뜻입니다. PASS는 실행한 전부가 첫 시도에 통과했을 때만 나옵니다.
관리형 QA를 쓰면 저희 팀은 무엇을 하나요?
고객 팀은 결과를 열람하고 릴리스를 결정합니다. 계획 검토, 탐색적 QA, 결과 분류, 재검증, 릴리스 메모는 합의된 범위에서 전문가가 수행하고, 모든 기록은 같은 워크스페이스에 남습니다. 어느 업무를 맡길지는 프로젝트별로 정합니다.
저희 데이터는 누가 볼 수 있나요?
워크스페이스는 조직 단위로 나뉘어 다른 조직의 프로젝트는 보이지 않습니다. 테스트 계정과 저장소 접근 범위는 프로젝트 단위로 관리되고, 실행 증거와 커밋 시점 의존성 기록은 해당 프로젝트 워크스페이스에 보관됩니다. 배포 형태와 데이터 처리 조건은 배포 · 데이터 처리와 도입 상담에서 안내합니다.
어떤 프로젝트부터 시작할지 함께 정합니다.
데모에서 계획 · 케이스 · 실행 · 판정이 만들어지는 과정을 실제 화면으로 보여드리고, 팀에 맞는 도입 범위를 정리해드립니다.
sales@qoretix.com+82-33-242-0210평일 10:00 – 18:00 KST