[QA Asset]QA자산화로 불필요한 업무와 테스트 준비 효율화한 사례

[QA Asset Story] 불필요한 반복 업무를 QA 자산화로 해결할 수 있을까요?

👩🏻‍💻프로젝트 경험을 QA 자산으로 만든, 6년차 QA 엔지니어 이야기

6년 차 QA 엔지니어가 프로젝트에서 축적한 QA 히스토리와 API 테스트 경험을 체계적으로 문서화한 사례를 소개합니다. 반복되는 요구사항 분석과 테스트 준비를 줄이고, 프로젝트 경험을 지속적으로 활용할 수 있는 QA 자산으로 만든 과정을 확인해 보세요.

QA는 테스트만 하는 직무일까요?

많은 분들은 외주 QA 엔지니어를 테스트를 수행하고 결함을 찾는 역할로만 생각합니다. 하지만 실제 프로젝트에서는 반복되는 문제를 개선하고, 테스트 경험과 정책 변경 이력을 체계적으로 관리하며, 프로젝트의 지식을 조직의 자산으로 만드는 일도 QA의 중요한 역할입니다. 이번 QA Asset Story에서는 J사의 세무 환급 플랫폼 프로젝트를 수행한 중급 엔지니어가 Confluence를 활용해 QA 히스토리와 API 테스트 가이드를 구축하고, 프로젝트 경험을 지속적으로 활용할 수 있는 테스트 자산으로 만든 사례를 소개합니다.

Interview

Q. 안녕하세요. 자기 소개 부탁드립니다.

안녕하세요. 리드워크 QA 엔지니어 경력 6년 차 이지영입니다.

J사 세무 환급 플랫폼 프로젝트에서 웹·앱 서비스의 기능 테스트와 API 검증, QA 프로세스 개선 업무를 담당하였습니다. 이번 인터뷰에서는 대표적으로 QA 자산화 수행에 대한 내용을 공유하려합니다.

Q. 프로젝트를 진행하면서 어떤 어려움이 있었나?

제가 속한 프로젝트는 정책 변경이 매우 잦았고, 유사한 기능이 반복적으로 개발되는 프로젝트였습니다. 하지만 이전 QA 수행 이력이나 테스트 포인트가 체계적으로 정리되어 있지 않았습니다. 이 때문에 동일하거나 유사한 기능을 테스트할 때마다 처음부터 요구사항을 다시 분석하고 테스트 범위를 처음부터 검토해야 하는 일이 반복되었습니다. 특히 API 테스트를 진행할 때도 참고할 수 있는 가이드가 없었습니다. 또한 API 스펙을 매번 확인하고 테스트 방법을 매번 직접 확인해야 했기 때문에 테스트 준비 과정에도 많은 시간이 소요됐습니다. 프로젝트가 장기간 진행되거나 QA담당자가 변경될 경우에는 이전에 어떤 이슈가 있었는지, 어떤 테스트를 수행했는지, 어떤 정책을 기준으로 검증했는지 확인하기도 어려웠습니다.

Q. 왜 개선이 필요하다고 생각하셨나요?

프로젝트를 진행하면서 동일하거나 유사한 내용을 반복해서 분석하는데 많은 시간이 소요된다는 점이 리스크였습니다. 특히 시간이 지나거나 담당자가 변경되면 이전 QA경험이 개인의 기억니아 일부 문서에만 남아 있어 프로젝트의 맥락을 다시 파악해야 했습니다. 기존 QA 이력과 테스트 경험을 체계적으로 관리한다면 다음과 같은 업무를 줄일 수 있습니다.

1. 유사 기능에 대한 반복적인 요구 사항 분석
2. 기존 이슈와 테스트 이력 확인
3. 정책 변경사항 재확인
4. API 테스트 방법과 스팩 재검토

같은 내용을 반복해서 확인하는 과정은 QA 업무의 생산성을 떨어뜨리는 요소라고 생각했습니다. 프로젝트 경험이 개인의 노하우로 남는 것이 아니라, 프로젝트를 함께 수행하는 모든 구성원이 활용할 수 있는 자산으로 남기는 것이 QA 엔지니어의 역할이기 때문입니다.

Q. 어떤 방식으로 해결하셨나요?

Confluence를 활용해 프로젝트별 QA Knowledge Base를 구축했습니다. QA 히스토리와 API 테스트 가이드, 크게 두 가지를 체계적으로 문서화 했습니다.

1) 프로젝트별 QA 히스토리

프로젝트별로 하기 내용을 체계적으로 기록했습니다.

1. 주요 이슈와 발생 원인
2. 이슈 해결 내용 및 참고사항
3. 테스트 과정에서 확인한 주요 정책
4. 테스트 중 변경된 정책
5. 유사 기능 테스트 시 참고할 사항
6. 프로젝트별 주요 테스트 포인트

2) API 테스트 가이드

API 테스트를 보다 효율적으로 수행할 수 있도록 API 테스트 가이드도 별도로 구축했습니다.

1. API 테스트에 필요한 사전 정보
2. API 스펙 확인 방법
3. 주요 테스트 절차
4. 테스트 시 확인해야 할 항목
5. 반복적으로 발생하는 오류와 참고사항

필요한 정보를 쉽게 찾을 수 있도록 프로젝트별로 문서를 관리하고, 검색을 통해 기존 QA 이력과 테스트 정보를 빠르게 확인할 수 있도록 구성했습니다.

가장 중요하게 생각한 것은 단순히 업무 내용을 기록하는 것이 아니라, 시간이 지나거나 담당자가 변경되더라도 문서만으로 프로젝트의 맥락과 테스트 포인트를 이해할 수 있도록 만드는 것이었습니다.

Q. 구축 이후 어떤 점이 가장 달라졌나요?

가장 큰 변화는 기존 QA 경험을 빠르게 확인하고 재활용할 수 있게 된 점입니다. 이후 유사한 기능이 개발되거나 유지보수가 진행될 때 기존 QA 히스토리를 참고해 이전 이슈와 정책 변경 내용을 빠르게 확인할 수 있었습니다. 이미 검증한 테스트 포인트도 재활용할 수 있어 요구사항 분석과 테스트 범위를 검토하는 과정의 반복을 줄일 수 있었습니다.

API 테스트 역시 기존 가이드를 활용하면서 테스트에 필요한 정보를 다시 찾거나 테스트 방법을 처음부터 확인하는 시간이 줄었습니다. 또한 담당자가 변경되더라도 기존 문서를 통해 프로젝트의 주요 이슈와 테스트 이력을 확인할 수 있어 업무 인수인계와 신규 인력 온보딩에도 도움이 됐습니다. 무엇보다 프로젝트 종료 후에도 활용할 수 있는 QA 자산을 구축했다는 점이 가장 큰 변화였습니다.

Q. 이번 경험을 통해 가장 크게 느낀 점은 무엇인가요?

처음에는 프로젝트 경험과 업무 내용을 정리하는 문서라고 생각했습니다. 하지만 문서를 지속적으로 작성하고 활용하면서 QA 문서화는 단순한 기록이 아니라, 이후 프로젝트의 시행착오를 줄이고 테스트 효율을 높이는 기반이라는 점을 알게 됐습니다. QA 히스토리와 API 테스트 가이드는 담당자가 변경되더라도 프로젝트의 맥락과 주요 테스트 포인트를 빠르게 이해할 수 있도록 도와줬습니다. 또한 기존 테스트 경험을 재활용할 수 있어 프로젝트가 장기간 진행되더라도 QA 품질의 일관성을 유지하는 데 도움이 됐습니다.

이번 경험을 통해 문서화는 프로젝트가 종료된 이후에도 지속적으로 활용되는 ‘QA 자산’​이라는 점을 다시 한번 느꼈습니다. 앞으로도 반복되는 QA 업무와 프로젝트 경험을 지속적으로 개선하고 축적해, 더 많은 프로젝트에서 활용할 수 있는 QA 자산으로 만들어가고 싶습니다.

➡️[관련글] [QA Asset Story] 반복 QA업무를 줄인 TL 생성 가이드 구축 사례

Q-Meet Insight

QA의 결과물은 테스트 완료 보고서만이 아닙니다.

프로젝트를 수행하며 축적한 테스트 이력, 정책 변화, API 검증 방법, 주요 이슈 역시 다음 프로젝트의 품질을 높이는 중요한 자산입니다.

큐밋은 이러한 경험이 개인의 노하우로 사라지지 않고, 조직의 경쟁력이 될 수 있도록 QA Asset Story를 통해 실무 사례를 공유하고 있습니다. 좋은 QA는 버그를 발견하는 데서 끝나지 않습니다. 프로젝트의 경험을 다음 프로젝트의 자산으로 만드는 것, 그것이 QA가 만드는 또 하나의 가치입니다.

프로젝트에 적합한 QA 파트너를 찾고 계신가요?

큐밋에서 프로젝트를 등록하고, 다양한 산업과 서비스 경험을 보유한 QA 전문 파트너를 비교해 보세요.

➡️ QA 프로젝트 무료 견적 요청하기