QA 풀 테스트 진행법과 이슈 트래킹 실무

좋은 이슈 하나가 개발 시간 하루를 아낀다.

한 줄 요약

QA는 버그를 찾는 일이 아니라 이슈를 정확히 기록하고, 닫힐 때까지 따라가는 일이다. 이 글은 다국어 앱 QA를 전담하며 정리한 풀 테스트 진행 절차와 이슈 작성·팔로우업 방식을 다룬다.

---

1. QA와 결함 관리

QA(Quality Assurance)는 결함을 발견하는 데서 끝나지 않는다. 수정되고, 검증되고, 종료될 때까지 관리하는 과정 전체다.

ISTQB(국제 소프트웨어 테스팅 자격 위원회)가 정의하는 결함 관리의 원칙은 세 가지다.

 

하나. 재현 가능해야 한다. 재현할 수 없는 이슈는 수정할 수 없다.

둘. 상태마다 책임자가 있어야 한다. 지금 이 이슈가 누구 손에 있는지 모두가 알아야 한다.

셋. 이슈를 닫는 사람은 등록한 사람이다. 수정한 개발자가 아니다.

 

용어 정리

Defect Lifecycle	결함이 등록되어 종료될 때까지의 상태 변화
Reproduction Steps	결함을 다시 발생시키는 단계별 경로
Regression Test	수정 이후 기존 기능이 깨지지 않았는지 재검증

 

왜 중요한가

이슈 기록이 부실하면 개발팀은 재현에 시간을 쓰고, 끝내 재현하지 못하면 "확인 불가"로 반려된다.

이슈 작성 품질이 곧 수정 속도다.

---

2. 문진표와 같은 구조

이슈 작성은 병원 문진표와 구조가 같다.

문진표 QA 이슈

언제부터 아팠는지	발생 버전, 발생 시점
어디가 아픈지	발생 경로 (화면 이동 순서)
어떤 증상인지	에러 메시지, 화면 상태
나이·기저질환	OS, 기기, 앱 버전, 국가
사진·엑스레이	스크린샷, 화면 녹화

 

"배가 아파요"로는 진단이 안 된다. "어제 저녁부터 오른쪽 아랫배가 눌렀을 때 아픕니다"여야 한다.

이슈도 같다.

---

3. 풀 테스트는 두 단계로 나눈다

1차 — QA 집중 점검

전담 QA가 먼저 걸러내는 단계다.

1. 개발팀으로부터 QA 요청 접수 — 수정·개발된 내용 목록 확보
2. 변경 범위 확인 — 무엇이 바뀌었는지 개발자에게 직접 듣는다
3. 집중 점검 — 변경 지점 위주로 우선 테스트
4. 회귀 테스트 — 변경이 건드렸을 주변 기능 확인
5. 치명적 결함이 없는 수준까지 정리

1차는 필터다. 여기서 걸러지지 않은 이슈가 넘어가면, 다음 단계에서 여러 사람의 시간이 동시에 낭비된다.

 

2차 — 매니저 참여 최종 QA

다국어 서비스는 언어별 검증자가 필요하다. 국가별 매니저가 각자의 언어 환경에서 테스트한다.

이때 QA 전담자의 역할은 테스트 수행이 아니라 진행 주최다. > 단계 QA 전담자가 하는 일

사전	테스트 범위·일정 공지, 대상 빌드 배포
시작	변경 내용 설명, 중점 확인 항목 안내
진행	질문 응대, 이슈 접수 및 중복 정리
종료	결과 취합, 잔여 이슈 우선순위 판단

 

신규 기능일수록 브리핑이 중요하다. 매니저는 사용법 자체를 모르는 상태다. 설명 없이 테스트를 요청하면 기능을 오해해서 생긴 오탐 이슈가 쌓인다.

 

다국어 QA에서 추가로 볼 것

• 번역 누락 — 미번역 원문이 그대로 노출되는지
• 텍스트 길이 초과 — 독일어·러시아어 등 장문 언어에서 UI가 깨지는지
• 형식 — 날짜, 시간, 통화, 숫자 표기
• 국가별 분기 — 특정 국가에만 노출되는 기능이나 약관
• RTL 레이아웃 — 오른쪽에서 왼쪽으로 쓰는 언어 지원 시

로컬라이제이션(L10n): 언어·형식·문화 요소를 각 지역에 맞게 조정하는 작업

---

4. 이슈 작성법

발생 경로

화면 이동 순서를 끊어서 적는다.

마이페이지 > 기본정보 > 전화번호 변경 > 인증번호 발송

경로가 있으면 개발자가 코드 위치를 바로 특정할 수 있다.

 

증상

 

"안 됩니다"가 아니라 관찰한 사실을 적는다.

인증번호 발송 버튼 클릭 시 에러 발생
에러 문구: "요청을 처리할 수 없습니다"
재클릭해도 동일. SMS 미수신.

 

환경 정보

구분 기록 항목

앱 버전	빌드 번호까지
OS	Android / iOS 및 버전
기기	제조사·모델명
국가·언어	계정 설정 기준
계정 조건	신규/기존, 권한, 요금제 등

 

발생 범위

한 줄이 원인 분석 방향을 바꾼다. - 범위 의심할 지점

전체 국가 공통	공통 로직, 서버
특정 국가 한정	국가별 설정, 통신사, 번호 체계, 번역 데이터

 

첨부 자료

스크린샷이나 화면 녹화를 붙인다. 다음 경우는 사실상 필수다.

• 재현이 간헐적일 때
• UI가 깨지거나 레이아웃이 틀어졌을 때
• 애니메이션·화면 전환 중 발생할 때

 

이슈 템플릿

[제목] (화면) 인증번호 발송 시 에러 발생 - 특정 국가 한정

■ 발생 경로
마이페이지 > 기본정보 > 전화번호 변경 > 인증번호 발송

■ 증상
인증번호 발송 버튼 클릭 시 에러 문구 노출, SMS 미수신
에러 문구: "요청을 처리할 수 없습니다"

■ 재현율
5회 중 5회 (100%)

■ 환경
- 앱 버전:
- OS / 버전:
- 기기:
- 국가 / 언어:

■ 발생 범위
- 전체 공통 여부:
- 확인된 국가:

■ 기대 동작
인증번호 SMS 정상 발송

■ 첨부
스크린샷 / 녹화 파일

---

5. 이슈 팔로우업

이슈는 등록으로 끝나지 않는다. 닫을 때까지 따라가는 것이 QA의 일이다.

상태 흐름

할 일	QA	이슈 등록 완료, 착수 전
진행 중	개발팀	수정 작업 중
배포 대기	개발팀	수정 완료, 반영 대기
배포 완료	QA	반영됨, 재검증 필요
완료	QA	재검증 통과, 종료

원칙은 하나다. 이슈를 닫는 사람은 등록한 QA다. 개발자가 "수정했음"으로 종료하면 검증 단계가 통째로 사라진다.

 

재검증에서 문제가 남아 있다면

새 이슈를 만들지 않는다. 기존 이슈를 '진행 중'으로 되돌린다.

- 되돌릴 때 댓글에 남길 것

• 재검증한 앱 버전
• 남아 있는 증상 (달라진 부분이 있다면 그 차이도)
• 새로 좁혀진 조건 (특정 기기·국가에서만 남는지)
• 추가 첨부 자료

한 이슈에 히스토리가 쌓이면 나중에 원인 분석과 회고가 쉬워진다. 새 이슈로 쪼개면 맥락이 끊긴다.

 

댓글 원칙

• 상태를 바꿀 때는 반드시 이유를 남긴다.
• 구두나 메신저로 합의한 내용도 이슈에 옮겨 적는다. 기록되지 않은 결정은 없는 결정이다.
• 재현 불가로 반려되면, 조건을 더 좁혀 다시 기록한다.

---

핵심 정리

• 풀 테스트는 QA 집중 점검 → 매니저 참여 최종 QA 두 단계로 나눈다. 1차가 필터다.
• 다국어 서비스는 언어별 검증자가 필요하고, 신규 기능은 먼저 설명한 뒤 테스트를 시작해야 오탐이 줄어든다.
• 이슈에는 발생 경로, 증상, 환경, 발생 범위, 첨부 자료를 빠짐없이 넣는다.
• 전체 공통인지 특정 국가 한정인지가 원인 분석 방향을 가른다.
• 상태 흐름은 **할 일(QA) → 진행 중(개발) → 배포 대기(개발) → 배포 완료(QA) → 완료(QA)**이며, 닫는 주체는 QA다.
• 문제가 남으면 새 이슈 대신 기존 이슈를 되돌리고 댓글로 기록해 히스토리를 한곳에 모은다.

 

참고 자료
- ISTQB Foundation Level Syllabus — Defect Management
- Atlassian Jira 공식 문서 — Workflow 및 Issue Status 구성
- W3C Internationalization — 다국어 UI 및 텍스트 처리 고려사항

 

주의사항

• 상태명과 워크플로우는 조직마다 다르다. 위 흐름은 실무 사례이며, 사내에 정의된 워크플로우를 우선한다.
• 심각도(Severity)와 우선순위(Priority)는 다른 개념이다. 심각도는 기술적 영향, 우선순위는 수정 순서를 뜻한다. 분리해 운영하는 편이 관리에 유리하다.