플랫폼

요구사항에서 릴리스 판정까지, 한 흐름.

테스트 계획, 케이스 생성, API·UI 검증, 보안 검사, 운영 모니터링이 하나의 프로젝트 안에서 이어집니다. 실행이 끝나면 PASS · CONDITIONAL · FAIL 세 단계 판정과 증거가 남습니다.

데모 요청관리형 QA 상담

저장소 연결부터 첫 실행까지 보통 5분.

기능

여덟 가지 기능, 하나의 프로젝트.

각 기능은 따로 켜고 끌 수 있지만 결과는 같은 프로젝트, 같은 판정 카드에 모입니다.

테스트 계획

요구사항 문서와 활성 케이스를 읽어 이름 · 설명 · 근거 · 계획서 · 선택된 케이스를 갖춘 계획 문서를 만듭니다. 초안 · 활성 · 보관 상태로 관리합니다.

자세히 보기

테스트 케이스 생성

사람 작성, 문서 기반, 코드 기반 세 출처에서 시나리오 · 전제조건 · 입력값 · 기대 결과를 만듭니다. PR 변경을 분석해 케이스 추가·수정·삭제를 제안합니다.

자세히 보기

API 검증

서버·API 프로젝트는 화면 수집 없이 API 계약을 기준으로 바로 실행합니다. 응답 구조와 상태 코드가 계약과 다르면 실패로 기록됩니다.

자세히 보기

UI 검증 · 전문가 UX 검토

Chromium · Firefox · WebKit 세 브라우저 엔진에서 같은 케이스를 실행합니다. 자동화가 놓치는 흐름은 전문가가 UX 검토 노트로 남깁니다.

자세히 보기

보안 검사 · 취약점 관리

연결된 저장소의 코드 스캔·시크릿 스캔·의존성 경보와 공급망·악성 패키지 발견을 릴리스 판정과 같은 화면에 놓습니다. 치명·주요 발견은 판정을 FAIL로 내립니다.

자세히 보기

모니터링 · 운영 이슈 미리보기

운영에서 발생한 오류를 커밋 단위로 받아 재현 검증을 만들고 회귀 검증에 추가합니다. 배포 전 판정과 배포 후 실제 일어난 일을 이어서 봅니다.

자세히 보기

테스트 리포트 · 증거

실행마다 HTML 리포트, 실패 스크린샷, 재현 영상, 실행 로그가 남습니다. 실패한 결과는 Jira 이슈로 발행되어 결과와 연결됩니다.

자세히 보기

프로젝트 · 고객 워크스페이스

조직마다 분리된 워크스페이스에서 자기 프로젝트와 결과만 봅니다. QA 책임자 · 테스터 · 고객 세 역할로 설정, 승인, 릴리스 서명 권한을 나눕니다.

자세히 보기

프로젝트 흐름

요구사항에서 재검증까지, 끊기지 않습니다.

한 프로젝트 안에서 여섯 단계가 이어집니다. 앞 단계의 산출물이 다음 단계의 재료가 됩니다.

  1. 프로젝트 준비

    GitHub 저장소를 연결하고 스테이징 URL과 테스트 계정을 등록합니다. 사이트를 돌아다니며 화면 목록을 모으고(최대 90초), 기능 목록·요구사항·와이어프레임·권한 매트릭스 문서를 첨부합니다.

    저장소 · 대상 URL · 테스트 계정 · 화면 수집 · 문서

  2. 테스트 계획

    문서와 활성 케이스에서 계획 문서를 만듭니다. 무엇을 왜 검증하는지 근거가 계획서에 붙습니다.

    계획서 · 근거 · 선택된 케이스

  3. 케이스 생성

    화면과 문서에서 케이스 초안을 만들고, 검증할 수 없는 초안은 버립니다. 우선순위와 자동화 수준을 매기고 한·영·일로 번역합니다.

    문서 · 코드 · 사람 · PR 제안

  4. API · UI 실행

    저장소 · 브랜치 · 변경 경로 패턴에 맞춰 push와 PR마다 자동 실행합니다. 실패한 케이스에는 스크린샷·재현 영상·로그가 자동으로 남습니다.

    세 브라우저 엔진 · API 계약 · 자동 실행 규칙

  5. 보안 · 운영 이슈

    저장소 보안 경보와 lockfile 기반 공급망 조회 결과가 같은 실행에 합쳐집니다. 배포 후 운영 오류를 회귀 검증으로 되돌리는 운영 모니터링은 미리보기입니다.

    의존성 경보 · 공급망 · 배포 후 오류

  6. 판정 · 리포트 · 재검증

    실행 하나에 판정 하나가 남습니다. 실패가 고쳐지면 같은 케이스를 다시 실행하고, 재검증 결과가 이전 판정에 이어집니다.

    PASS · CONDITIONAL · FAIL · Jira

재검증은 새 프로젝트가 아니라 같은 프로젝트의 다음 실행입니다.

릴리스 판정

릴리스해도 되는지,
한 줄로.

실행이 끝나면 답은 세 가지 중 하나입니다. 경미한 실패나 격리된 검증, 요구사항 커버리지 미달은 CONDITIONAL로 남겨 사람이 봐야 하는 상태를 통과와 구분합니다.

  • FAIL — 안정된 검증이 치명·주요 심각도로 실패했거나 보안 치명·주요 발견이 있을 때
  • CONDITIONAL — 경미·사소 실패만 있거나, 불안정·격리·보류된 검증이 있거나, 요구사항 커버리지가 목표 80% 미만일 때
  • PASS — 실행한 전부가 첫 시도에 통과했을 때
  • 판정 카드 하나에 통과·실패·격리·건너뜀 수와 보안 발견, 검증 범위가 함께 붙습니다
테스트 리포트 · 증거 보기

제품과 전문가

제품은 같고,
맡기는 범위만 다릅니다.

고객 팀이 직접 운영해도 되고, 합의된 검증 업무를 IXC 전문가가 같은 플랫폼 위에서 수행해도 됩니다. 전문가가 만든 계획, 케이스, 결과 분류는 고객 워크스페이스에 그대로 남습니다.

  • 도입·검증 체계 설정과 테스트 계획 검토
  • 탐색적 QA, UX 검토, 실패 결과 분류와 재검증
  • 릴리스 메모 작성
  • 필요한 업무만 맡기고 나머지는 고객 팀이 운영
관리형 QA 상담

자주 묻는 질문

도입 전에 확인하는 것들.

도입하려면 무엇을 준비해야 하나요?
GitHub 저장소, 스테이징 환경의 대상 URL, 로그인용 테스트 계정 세 가지면 첫 실행까지 갑니다. 요구사항 문서는 docx · xlsx · pptx · pdf · 이미지 · markdown으로 첨부하며, 없으면 화면 수집과 코드 기반으로 시작합니다.
어떤 종류의 애플리케이션을 검증할 수 있나요?
프로젝트를 준비할 때 웹 · Android · iOS · macOS · Windows · 서버·API 중 어디에 해당하는지 자동 판별합니다. 웹은 세 브라우저 엔진으로 UI를 실행하고, 서버·API 프로젝트는 화면 수집을 건너뛰고 API 검증으로 갑니다.
이미 쓰는 CI 파이프라인과 이슈 트래커는 어떻게 되나요?
기존 파이프라인은 그대로 둡니다. GitHub Actions의 push와 PR 이벤트가 실행을 시작하고, 실패는 Jira 이슈가 되어 이슈에서 실행 결과로 바로 갑니다. 그 외 저장소 호스팅과 이슈 트래커, PR 체크로 배포를 막는 릴리스 게이팅은 미리보기입니다.
미리보기 기능은 지금 어떻게 볼 수 있나요?
운영 모니터링, 클라우드 점검, 이메일·채팅·웹훅 알림, API 명세 연동, SSO 로그인 검증은 미리보기입니다. 데모에서 현재 동작하는 범위를 실제 프로젝트로 확인할 수 있습니다.
자동화가 하지 못하는 일은 누가 하나요?
계획 검토, 탐색적 QA, UX 검토, 실패 결과 분류, 릴리스 메모는 사람의 일입니다. 고객 팀의 QA 책임자와 테스터가 직접 하거나, 관리형 QA로 IXC 전문가에게 맡길 수 있습니다.
우리 데이터와 결과는 어디까지 분리되나요?
조직마다 분리된 워크스페이스에서 자기 조직의 프로젝트와 결과만 봅니다. 저장소는 GitHub App 권한으로 연결하며, 배포 방식과 데이터 처리는 배포 · 데이터 처리에서 확인할 수 있습니다.

프로젝트 하나로 시작해 보세요.

저장소 하나, 스테이징 URL 하나, 테스트 계정 하나면 첫 판정을 볼 수 있습니다. 데모에서 실제 프로젝트 흐름을 확인하세요.

데모 요청도입 상담

sales@qoretix.com+82-33-242-0210평일 10:00 – 18:00 KST