A
고객 팀이 직접 운영합니다
QA 책임자와 테스터가 프로젝트를 준비하고, 케이스를 승인하고, 실행 결과와 판정을 직접 봅니다.
팀이 하는 일
- 저장소 연결, 대상 URL, 테스트 계정 등록
- 문서·코드·화면에서 만든 케이스 초안 승인
- push와 PR에 맞춘 자동 실행 규칙 설정
- 판정과 증거를 보고 릴리스 결정
적합한 경우자체 QA 인력이 있고 검증 기준을 직접 세우려는 팀
두 가지 방식
필요한 범위만 맡깁니다.
플랫폼은 같습니다. 누가 어떤 업무를 맡는지만 다릅니다.
도입 흐름
상담에서 첫 릴리스 메모까지.
첫 실행까지는 보통 5분이면 됩니다. 그 앞뒤의 사람 일은 이렇게 진행합니다.
-
범위 상담
어떤 프로젝트, 어떤 릴리스 주기, 어떤 업무를 맡길지 정합니다. 상호 NDA 뒤에 서면 용역 계약으로 범위를 적습니다.
-
검증 체계 설정
전문가가 저장소 연결, 대상 URL, 테스트 계정, 요구사항 문서 등록을 함께 마치고 화면을 수집합니다. 자동 실행 규칙과 승인 흐름도 이때 잡습니다.
-
계획 검토와 케이스 승인
플랫폼이 만든 테스트 계획과 케이스 초안을 전문가가 검토합니다. 요구사항에 없는 가정은 지우고, 빠진 경로는 보탭니다.
-
실행과 결과 분류
push와 PR마다 자동 실행이 돌고, 실패는 전문가가 분류합니다. 재현되는 결함은 심각도를 매겨 Jira 이슈에 남기고, 재현되지 않는 실패는 판정 보류로 두고 사유를 적습니다.
-
탐색적 QA와 UX 검토
릴리스 전, 자동 실행이 열지 않은 화면과 흐름을 전문가가 직접 다룹니다. 검토 노트는 화면별로 프로젝트에 남습니다.
-
재검증과 릴리스 메모
수정된 커밋을 다시 실행해 판정을 확인하고, 무엇을 검증했고 무엇이 남았는지 릴리스 메모로 씁니다. 릴리스 결정은 고객 담당자가 합니다.
실행, 결과 분류, 탐색적 QA, 재검증은 릴리스 주기마다 반복됩니다.
전문가 업무
사람이 맡는 여덟 가지 일.
자동 실행이 대신할 수 없는 판단을 전문가가 맡습니다. 모든 결과는 플랫폼에 기록으로 남습니다.
도입·검증 체계 설정
프로젝트 준비, 자동 실행 규칙, 역할과 승인 흐름을 팀 상황에 맞게 잡습니다.
테스트 계획 검토
계획서의 근거와 선택된 케이스를 요구사항과 대조해 빈틈과 과잉을 고칩니다.
탐색적 QA
케이스에 없는 경로를 사람이 직접 다닙니다. 발견은 재현 절차와 함께 기록합니다.
테스트 유지
화면과 API가 바뀌면 깨진 케이스를 고치고, PR 제안을 승인·거절해 세트를 살아 있게 합니다.
결과 분류
실패마다 결함인지, 환경 문제인지, 불안정인지 가립니다. 심각도를 매기고 Jira 이슈에 분류 사유를 남깁니다.
UX 검토
세 브라우저 엔진의 화면을 사람의 눈으로 봅니다. 동작은 맞지만 쓰기 어려운 곳을 적습니다.
재검증
수정 커밋으로 실패 케이스를 다시 실행하고, 판정이 PASS로 바뀌었는지 확인합니다.
릴리스 메모 작성
판정, 검증 범위, 남은 위험, 권고를 한 장으로 씁니다. 릴리스 결정의 근거가 됩니다.
기록
전문가의 판단도 기록으로 남습니다.
메신저나 메일이 아니라 프로젝트 안에 남습니다. 계획 검토 의견, 탐색적 QA 결과, 분류 사유, 릴리스 메모가 실행 이력과 같은 곳에 있습니다.
- 계획 검토 의견은 계획서 버전과 함께
- 탐색적 QA 발견은 화면·재현 절차와 함께
- 분류 사유는 실패 결과와 Jira 이슈에 연결
- 릴리스 메모는 판정 카드 옆에
자주 묻는 질문
맡기기 전에 확인할 것.
어떤 프로젝트부터 시작할 수 있나요?
스테이징 URL과 테스트 계정이 있고 GitHub 저장소를 연결할 수 있는 웹 프로젝트가 가장 빠릅니다. 서버·API 프로젝트는 화면 수집을 건너뛰고 API 검증부터 시작합니다.
전문가가 우리 코드와 데이터에 어디까지 접근하나요?
저장소는 GitHub App 권한으로 읽고, 테스트는 등록한 스테이징 URL과 테스트 계정으로만 실행합니다. 접근 범위와 보관 기간은 상호 NDA와 서면 용역 계약에 적습니다.
우리 팀은 무엇을 해야 하나요?
고객 담당자가 요구사항 문서를 제공하고, 케이스 승인과 릴리스 결정을 합니다. 나머지는 합의한 범위에 따라 나눕니다.
이미 QA 팀이 있는데도 의미가 있나요?
있습니다. 릴리스 전 기간만 탐색적 QA를 맡기거나, 결과 분류만 맡기는 식으로 범위를 좁힐 수 있습니다. 같은 워크스페이스에서 함께 봅니다.
릴리스 판정은 누가 내리나요?
판정은 플랫폼이 규칙대로 냅니다. 전문가는 판정을 고치지 않고 그 위에 릴리스 메모를 쓰며, 릴리스 결정은 고객 담당자가 합니다.
기존에 쓰던 이슈 트래커와 문서는 그대로 쓰나요?
Jira를 연결하면 실패 결과가 이슈로 발행되고 결과와 연결됩니다. 요구사항 문서는 docx · xlsx · pptx · pdf · 이미지 · markdown으로 첨부합니다.
관리형 QA 문의
어떤 업무부터 맡길지 함께 정합니다.
프로젝트, 릴리스 주기, 팀 구성을 알려 주세요. 필요한 검증 업무와 진행 범위를 함께 정합니다.