테스트 문서·관리 도구·프로세스 개선

학습 목표

이 모듈 한 줄 요약 — "혼자 기억하지 않고 팀이 굴러가게 만드는 법". 테스트 케이스가 수백 개가 되면 머리와 엑셀로는 안 된다. 무엇을 어디에 적어 두고, 환경과 데이터를 어떻게 관리하고, 팀의 방식 자체를 어떻게 한 단계 올리는지 — 도구와 절차를 다룬다.

이 모듈을 마치면 테스트 케이스를 체계적으로 관리하는 도구(TestRail·Zephyr 등)의 역할을 이해하고, Confluence 같은 문서 협업 도구로 결정의 근거를 남기는 법과, 테스트 데이터·환경을 안정적으로 관리하는 방법을 익힌다. 워터폴부터 애자일까지 개발 방법론에 따라 테스트의 시점과 역할이 어떻게 달라지는지, BDD/TDD에서 QA가 어떤 역할을 하는지, 그리고 TMMi·TPI Next 같은 프로세스 개선 모델로 우리 팀의 테스트 성숙도를 가늠하는 법을 다룬다. 마지막 두 레슨은 애자일 이벤트마다 QA가 실제로 하는 일(스토리 추정·완료의 정의·회고 데이터)과, 프로세스를 넘어 사람과 조직 을 다루는 영역(스킬 매트릭스·팀 배치·아웃소싱 판단·품질 비용)까지 확장한다.

완료 후 할 수 있는 것

• 테스트 관리 도구(TestRail·Zephyr 등)가 이슈 추적 도구와 어떻게 다른 역할을 하는지 설명할 수 있다
• Confluence 같은 문서 협업 도구로 QA 결정의 근거를 남기고 공유할 수 있다
• 테스트 데이터를 안전하고 재현 가능하게 관리하는 방법을 설명할 수 있다
• 테스트 환경을 격리하고 실제 운영 환경과의 차이를 관리하는 방법을 설명할 수 있다
• 워터폴·애자일(스크럼·칸반) 방법론에 따라 테스트 활동이 어떻게 달라지는지 설명할 수 있다
• BDD의 Given-When-Then과 TDD 사이클에서 QA의 역할을 설명할 수 있다
• TMMi·TPI Next 같은 프로세스 개선 모델의 기본 개념을 설명할 수 있다
• 스크럼 이벤트별 QA의 역할을 알고, 인수기준과 완료의 정의를 구분해 팀 합의를 이끌 수 있다
• 스킬 매트릭스로 팀 역량과 버스 팩터를 진단하고, 아웃소싱 여부와 품질 비용을 근거로 논증할 수 있다

채용시장에서의 위치

"애자일 환경 경험", "TestRail 사용 경험", "BDD 작성 경험" 같은 문구가 QA 채용공고에 자주 등장한다. 이 모듈은 특정 도구나 방법론 하나를 깊게 파기보다, 왜 회사마다 다른 도구·방법론을 쓰는지, 그 배경 논리를 이해하는 데 초점을 맞춘다 — 그래야 이력서에 없는 도구를 쓰는 회사에 가서도 "이건 결국 무엇을 위한 도구인가"를 빠르게 파악할 수 있다.

경력이 쌓이면 프로세스보다 사람 이 문제가 된다 — 자동화 담당이 한 명뿐이거나, 도메인을 아는 사람과 기술을 아는 사람이 다른 팀에 있거나. 마지막 레슨이 그 영역을 다룬다. 리드가 아니어도 값이 있다 — 스킬 매트릭스를 그려보면 내가 어느 축을 맡으면 팀에 기여하면서 나도 성장하는지 가 보인다.