QA팀 프로세스 고도화 추진기

들어가며

안녕하세요. 노머스 QA팀의 이승진입니다. (이전 내용은 QA팀의 프로세스 정립기 Part2 를 클릭해주세요.) 그동안 저희 QA팀은 멤버 각자가 개별 프로젝트를 독립적으로 담당하여 진행해 왔습니다. 하지만 조직이 성장하고 프로젝트의 규모가 커짐에 따라, 개별적으로 관리되던 QA 산출물(테스트 케이스, 결함 관리 등)에서 필연적으로 파편화와 관리 비효율이라는 한계 부딪히게 되었습니다. IT 조직 전체가 QA 진행 상황을 한눈에 파악하기 어렵고, 히스토리 추적이 어려워지는 문제도 발생했습니다.

이러한 한계와 비효율을 극복하고, 조직 내 커뮤니케이션을 한층 더 투명하게 만들기 위해 최근 저희 QA팀은 “하나의 시트로 끝내는 효율적인 QA 프로세스”라는 핵심 모토 아래 대대적인 프로세스 개편을 단행했습니다. 이번 글에서는 QA 산출물 관리의 새 시대를 열기 위해 도입한 통합 포맷의 구체적인 모습과, 이를 통해 개선된 주요 변화 및 핵심 프로세스를 공유하고자 합니다. 우리 IT 조직원 모두가 더 쉽고 명확하게 QA 현황을 파악하고 협업하는 데 이 글이 도움이 되기를 바랍니다.

📁 개별 담당 구조가 만든 산출물 관리의 빈틈

기존에는 QA 팀원들이 각자 프로젝트를 전담하다 보니, 배포 전 체크리스트, 새너티 테스트(Sanity Test) 체크리스트, 그리고 TC(Test Case) 등 핵심 산출물들이 표준화되지 못하고 관리의 사각지대에 놓이는 문제가 있었습니다. 이러한 문제를 해결하기 위해 완전히 새로운 포맷의 통합 산출물 양식이 구축되었습니다. 가장 빈번하게 사용하는 TC(Test Case) 시트를 중심으로 어떤 변화가 있었는지 소개합니다.

🛠️ 한눈에 보는 새로운 TC 포맷의 4가지 핵심 변화

1. Summary 탭: 파편화된 기획 맥락과 결함 현황을 한 장으로 종결하기까지

테스트를 진행하다 보면 기획서와 정책서, 화면 설계서가 각기 다른 도구(콘플루언스, 피그마, 노션 등)에 흩어져 있어 최신 히스토리를 파악하는 데 많은 시간을 쓰게 됩니다. 특히 프로젝트 도중 스펙이 변경되면, 변경된 요구사항이 테스트 케이스(TC)에 제때 반영되었는지 추적하기가 매우 어려웠습니다. 결함 관리 역시 지라(Jira) 티켓으로만 파편화되어 있다 보니, 함께 일하는 기획자나 개발자들이 현재 프로젝트의 전반적인 결함 상태나 위험도를 한눈에 직관적으로 파악하기에 한계가 있었습니다.

저희 팀은 이러한 정보의 파편화를 해결하기 위해 산출물 시트 맨 앞에 ‘Summary 탭’을 만들었습니다. 단순히 링크만 모아두는 것을 넘어, 본격적인 TC 작성 전에 제품 요구사항 정의서(PRD)와 정책서의 핵심 요건을 이 탭에 짧고 직관적으로 요약하도록 프로세스를 정립했습니다. 이 과정을 통해 QA 담당자는 기획 요건을 명확히 인지한 상태에서 테스트를 설계할 수 있게 되었고, 기획이 누락되는 일을 사전에 방지하는 효과를 얻었습니다. 또한 발생한 주요 이슈 목록을 이 Summary 영역에 실시간으로 통합 관리함으로써, 이제는 개발자와 기획자 등 프로젝트 구성원 누구나 이 시트 한 장만으로 기획 맥락부터 전체 결함 현황까지 한눈에 파악할 수 있는 투명성을 확보했습니다.

2. 실시간 진척률 반영과 N/T 환경 초기화: 정량적 데이터 기반의 리스크 관리

많은 조직에서 QA 진행 상황을 공유할 때 “전체 80% 정도 진행되었습니다”와 같이 주관적인 추정치에 의존하곤 합니다. 하지만 이러한 감에 의존한 공유는 프로젝트 막바지에 예상치 못한 치명적인 결함이 터졌을 때 출시 일정에 큰 타격을 줄 수 있어 ‘현재 프로젝트의 완성도’를 데이터로 투명하게 보여주어야겠다 생각했습니다.

이를 해결하기 위해 TC 작성이 완료되는 시점에 모든 검증 환경(Status) 값을 ‘N/T(Not Tested, 테스트 전)‘로 명확히 일괄 초기화하고, 이후 테스트 결과(Pass/Fail 등)가 입력될 때마다 전체 진척률과 성공률이 실시간으로 계산되어 대시보드에 반영되는 구조를 설계했습니다. 덕분에 주관적인 판단을 배제하고 정확한 데이터를 바탕으로 출시 리스크를 관리할 수 있게 되었습니다.

3. 단일 시트 구성: 여러 환경 테스트의 비효율과 품질 리스크를 극복한 방법

기존에 저희 팀은 서버 환경(QA, Stage, 운영 등)이 바뀔 때마다 기존 테스트 시트를 복사해서 새 탭을 만들거나 별도의 파일로 복사·붙여넣기하여 관리했습니다. 이 방식은 당장 적용하기엔 편했지만, 테스트 차수가 거듭될수록 심각한 문제를 야기했습니다. 1차 테스트 도중 기획이 바뀌어 QA 시트의 TC를 수정하면, Stage이나 운영 시트에는 이 수정 사항이 누락되는 문제가 있었습니다. 이는 곧 검증 누락이라는 품질 리스크로 직결되기도 했습니다. 그렇다고 모든 환경마다 매번 동일한 대용량 TC를 처음부터 끝까지 반복 검증하는 것은 “테스트 차수 간소화를 통한 효율성 제고”라는 팀의 방향성과 맞지 않았습니다. 리소스를 줄이면서도 품질은 지켜야 하는 고민스러운 상황에서, 저희는 ‘모든 테스트 환경을 단 하나의 시트 안에서 버튼 하나로 전환하고 기록하는 구조’를 고안했습니다.

이 단일 시트 구조를 도입하면서 발생할 수 있는 품질 리스크는 두 가지 장치로 보완했습니다.

첫째, 환경이 바뀌어도 기준이 되는 TC 본문은 단 하나만 존재하므로 기획 변경에 따른 수정 사항이 모든 환경에 실시간으로 동일하게 적용되어 검증 누락을 원천 차단했습니다.

둘째, 이전 환경(QA)에서 이미 합격(Pass)한 안정적인 기능들은 다음 환경(Stage)에서 핵심 기능과 수정 사항의 영향도 범위 위주로 효율적으로 압축 검증할 수 있도록 체크리스트 플래그를 연동했습니다. 결과적으로 작업 공수는 획기적으로 줄이면서도, 환경 전환 시 발생하던 싱크 오류와 결함 유출 리스크를 확실하게 제어할 수 있었습니다.

4. 스마트한 지라(Jira) 링크 연동 자동화: 시트와 툴 사이의 화면 전환 줄이기

테스트 케이스 시트와 이슈 트래커(Jira)의 연동은 필수적이지만, 테스트 도중 수십 개의 결함 티켓 전체 URL을 복사해서 시트 셀에 하나하나 붙여넣는 작업이 의무는 아니었지만, ‘과거에 어떤 결함 때문에 실패했었는지’, ‘개발자가 어떻게 수정했는지’ 그 맥락을 즉시 확인할 수 있기에 tc ‘비고’란에 항상 기록을 남겨왔습니다. 간혹 하나의 테스트 케이스 안에서 여러 개의 작은 결함들이 복합적으로 얽혀있을 때, 셀 하나에 여러 링크를 깔끔하게 정리하는 명확한 규칙이 없었고 담당자마다 작성 스타일이 달라 히스토리를 추적하는 데 혼선이 있었습니다.

이러한 사소한 비효율과 화면 전환 비용을 줄이기 위해, 풀 URL 입력 없이 Jira의 키값(BTB-이슈번호)만 입력해도 하이퍼링크가 자동으로 활성화되는 연동 자동화를 구축했습니다. 특히 난제였던 ‘하나의 셀 내 다중 이슈 매핑’ 문제 역시, 콤마(,)를 구분자로 하여 BTB-101, BTB-102와 같이 입력하면 각각의 독립된 Jira 하이퍼링크로 쪼개어져 활성화되도록 구현했습니다. 이 작은 자동화 덕분에 QA 엔지니어는 단순 문서 작업 시간을 아껴 결함의 원인을 분석하고 탐색적 테스트에 더 집중할 수 있는 리소스를 확보했습니다.

5. 일관성 유지를 위한 표준 가이드라인 및 프레임워크 확립: 개인의 주관을 넘어 팀의 표준으로

QA 팀이 성장하고 멤버가 늘어남에 따라, 각자의 방식이나 편의에 맞춰 TC를 작성하는 스타일이 점차 다르게 나타나기 시작했습니다. 어떤 멤버는 테스트 단계를 지나치게 상세히 적어 나중에 수정할 때 많은 양의 tc가 수정되어 시간이 많이 소요되기도 하고, 어떤 멤버는 핵심만 지나치게 축약하여 다른 멤버가 대신 테스트를 수행할 때 내용을 다르게 해석하여 검증 퀄리티가 떨어지는 등의 문제가 발생했습니다. 검증의 본질과 방향성이 흔들리면 팀 전체의 품질 산출물 신뢰도가 낮아질 수밖에 없었습니다.

이를 극복하기 위해 단순히 말로 “작성 가이드”를 알려주는 대신, 테스트 템플릿 마지막 시트에 정형화된 틀과 명확한 표준 가이드라인을 심어두었습니다. 어떤 프로젝트를 맡더라도 누구나 동일한 수준의 고품질 테스트를 설계할 수 있도록 입력 규칙과 세부 수준의 기준을 시스템적으로 제한한 것입니다. 이를 통해 개인 역량에 의존하던 품질 검증 수준을 팀의 표준 프로세스로 상향 평준화할 수 있었고, 이는 새로 합류한 멤버의 적응 기간을 단축시키는 긍정적인 효과로도 기대하고 있습니다.

⏱️ 테스트 차수 간소화를 통한 효율성 제고

새로운 시트 도입과 더불어, 전체적인 QA 테스트 프로세스 단계도 한층 능률적으로 개편되고 있습니다.

• 기존 방식: QA 1차 → QA 2차 → STG 1차 → STG 2차 → 운영 환경

• 개선 방식: QA 1차 → STG 1차 → 운영 환경

그동안 각 환경별로 진행되었던 2차 테스트 단계를 제외하였습니다. 반복 수행으로 인해 발생했던 불필요한 수행 시간을 줄이고, 보다 집중도 높은 테스트를 통해 효율적인 프로세스를 구축하게 되었습니다.

🌱 변화는 자연스럽게, 업무는 더 효율적이게

현재 이러한 프로세스 변화가 원활하게 진행되고 있는 것은 팀원들의 업무 부담을 덜어주기 위한 세심한 조율 덕분입니다. 팀원들이 급격한 변화를 느끼지 않으면서도 편하게 업무에 바로 녹여서 실행할 수 있도록, 작은 부분부터 차근차근 체계를 잡아가는 중입니다. 덕분에 현업에서는 업무 방식을 크게 바꾸지 않고도 더 정돈된 환경에서 자연스럽게 효율을 높여가고 있습니다.

💡 마치며

이번 프로세스 개편과 가이드 배포는 단순히 문서 양식이나 절차가 바뀐 것을 넘어, IT 팀 전체의 협업 비용을 줄이고 서비스의 완성도를 투명하게 공유하기 위한 우리 QA 팀 모두의 고민과 노력이 담긴 결과물입니다. QA 팀은 앞으로도 더 효율적인 프로세스와 탄탄한 검증을 통해 제품의 든든한 버팀목이 되겠습니다. 새로워진 포맷과 효율적인 프로세스를 적극적으로 활용해 주시길 바라며, 앞으로 더 빠르고 견고해질 배포 프로세스를 기대해 주시면 감사하겠습니다.