도입 여정
확인에서 확대까지, 다섯 단계.
진행 중인 프로젝트 하나로 시작해 결과물을 확인하고, 필요한 구성만 결합한 뒤 다음 프로젝트로 넓힙니다.
-
확인할 범위 정하기
진행 중인 프로젝트 중 하나를 골라 저장소, 대상 URL, 테스트 계정, 요구사항 문서가 준비되는지 확인합니다. 웹 · Android · iOS · 서버·API 중 어떤 플랫폼인지에 따라 화면 수집 여부가 정해집니다.
-
데모에서 결과물 보기
테스트 계획서, 케이스 표, 세 브라우저 엔진 실행 결과, 릴리스 판정 카드, HTML 리포트를 실제 화면으로 확인합니다. 고객사에 전달할 산출물 형태를 이 자리에서 정합니다.
-
첫 적용 프로젝트 범위
저장소 1개, 스테이징 URL, 테스트 계정, 테스트 데이터, 요구사항 문서를 기준으로 첫 프로젝트 범위를 문서화합니다. 산출물은 계획서 · 케이스 · 실행 리포트 · 릴리스 메모로 고정합니다.
-
구매 구성 확정
제품 이용, 초기 설정, 전문가 수행을 필요한 만큼 결합합니다. 고객사 환경에 필요한 외부 도구와 테스트 기기는 프로젝트별 항목으로 따로 정합니다.
-
확대와 지원
첫 프로젝트가 끝나면 워크스페이스를 추가해 다음 프로젝트로 넓힙니다. 제품 지원과 도입 지원의 범위, 응답 시간은 계약에서 정합니다.
제품 경험과 결과물
전달하는 건 판정과 증거입니다.
실행마다 HTML 리포트, 실행 로그, 실패 케이스의 스크린샷과 재현 영상이 남습니다. 릴리스 판정은 PASS · CONDITIONAL · FAIL 3단계이고, 요구사항 커버리지가 목표 80%에 못 미치면 PASS 대신 CONDITIONAL이 됩니다.
- 요구사항 · 체크리스트 · 화면 세 축의 검증 범위
- 실패 케이스마다 스크린샷, 재현 영상, 로그
- 실패 결과를 Jira 이슈로 발행하고 결과와 연결
- 고객 역할 계정으로 결과 열람과 릴리스 결정
직접 활용과 위임
직접 할 일과 맡길 일을 나눕니다.
개발사 팀은 저장소 연결, 케이스 승인, 실행, 결과 확인을 직접 합니다. 탐색적 QA, 결과 분류, UX 검토, 재검증, 릴리스 메모처럼 시간이 드는 업무는 전문가에게 맡길 수 있습니다. 두 방식은 같은 워크스페이스에서 섞입니다.
- 직접: 프로젝트 준비, PR 케이스 제안 승인, 자동 실행 규칙, 결과 확인
- 위임: 검증 체계 설정, 계획 검토, 탐색적 QA, 테스트 유지
- 위임: 결과 분류, UX 검토, 재검증, 릴리스 메모
- 프로젝트마다 범위를 다르게 정할 수 있음
구매 구성
필요한 만큼만 결합합니다.
네 가지 구성 중 프로젝트에 필요한 것만 고릅니다. 상호 NDA와 서면 용역 계약을 기준으로 진행합니다.
| 구성 | 포함되는 것 | 정하는 방법 |
|---|---|---|
| 제품 이용 |
| 프로젝트 수와 사용자 역할을 기준으로 상담에서 정함 |
| 초기 설정 |
| 첫 프로젝트 범위에 맞춰 한 번 구성 |
| 전문가 수행 |
| 합의한 업무 범위와 기간으로 서면 계약 |
| 외부 도구 · 기기 |
| 프로젝트별로 별도 항목으로 정함 |
구성은 프로젝트마다 다르게 조합할 수 있고, 확대 시 워크스페이스 단위로 추가합니다.
역할
세 역할이 한 프로젝트를 봅니다.
개발사, 전문가, 발주 고객사가 각자의 권한으로 같은 프로젝트에 들어옵니다.
자주 묻는 질문
도입 전에 확인하는 것
고객사가 여러 곳인데 데이터가 섞이지 않나요?
첫 프로젝트에 필요한 준비물은 무엇인가요?
GitHub 외의 저장소를 쓰는 고객사도 있습니다.
전문가는 어디까지 하고, 개발사 팀은 무엇을 남기나요?
기존에 쓰던 CI와 이슈 트래커는 어떻게 되나요?
산출물을 고객사 보고 형식으로 받을 수 있나요?
다음 고객 프로젝트부터 적용해 보세요.
진행 중인 프로젝트 하나로 데모를 진행합니다. 저장소와 스테이징 URL만 있으면 됩니다.
sales@qoretix.com+82-33-242-0210평일 10:00 – 18:00 KST