QA의 프로세스는 어떤식으로 이루어질까?

📋 팀에 QA프로세스가 정립되어있지 않아 앱 업데이트 이후, 잦은 BugFix로 인해 업무에 피로도가 가중되고 있어 팀 내부에 올바른 QA 프로세스 정립을 하기 위해 작성하였습니다.

QA의 역할

QA의 프로세스를 이해하기 위해서는 QA의 역할에 대해서 알아야 한다. 사실 이전에만 해도 나는 단순히 개발 완료 후에 기능 테스트를 진행하며 버그를 찾고 리포팅하는 역할로 알고 있었다. 하지만 소프트웨어 산업이 발전해 오면서 개발뿐만 아니라 테스팅 관련 분야도 함께 발전해오면서 지금의 QA 영역은 단순 테스트로부터 훨씬 멀리 뻗어 나갔다.

 

QA의 가장 중요한 역할은 물론 품질이다. 프로덕트 품질의 기준을 제시하고 달성하는 것을 목표로 삼고 활동하는 역할이다. 또한, 분석과 관리 역할을 하며 프로덕트 자체 또는 명세서나 개발 아키텍쳐, 이슈를 분석하고 관리하는 역할을 한다. 마지막으로 테스팅 QA단계와 그 전후 과정에서 테스팅을 수행하고, 피드백과 개선하는 역할로, 업부 과정을 평가하며 필요한 것들을 개선하는 역하을 해야 한다. QA는 많은 과정과 절차에 걸쳐서 다양한 역할을 수행하고 각 단계에서 다양한 활동이 필요하다. 배포하는 프로덕트가 원하는 수준의 품질에 도달하게 만드는 모든 역할이 QA의 역할이라고 볼 수 있다. 

일반적인 개발 및 QA 프로세스

기획 단계에서 QA의 역할

킥오프 미팅에는 프로젝트 개요와 필요한 정보를 습득하기 위해 반드시 참여해야 하며, 미팅 후에는 로드맵이나 마일스톤 등을 함께 확인해야 한다. 이와 관련된 문서들은 보통 해당 부서에서 작성하게 되는데, 각 항목의 영향도를 제데로 고려하지 않은 채로 작성하는 경우가 있어 예상 가능한 리스크나 비용, 배포 일정을 고려할 수 있도록 가이드를 해주어야 한다. 그 후에 스펙과 스토리를 리뷰해서 기획 단계에서 작성한 요구 사항을 리뷰하고 개발 진행 전에 시나리오가 가능 한 모든 항목들을 구현할 수 있도록 완성되었는지 확인하는 역할을 해주어야 한다.

분석 단계에서 QA의 역할

킥오프 미팅에서 공유된 새로운 기능에 대해 프로덕트 전체 관점에서 리뷰를 진행하고 결과를 공유한다. 이때 비즈니스 가치가 있는지, 혹여 아직 시기상 이른 기능은 아닌지, 중복된 기능은 없는지 경쟁사와 비교하여 어떠한 장단점이 있는지를 함께 확인하며 잘못 정의했거나 모호한 부분이 없는지 리뷰해야한다.

 

그리고 새로운 기능을 확인하기 위해서 QA 관점에서 어떠한 테스트가 필요한지 확인해야 한다. API 테스트가 필요한지, 자동화 할 수 있는 부분은 없는지, 테스트하기 위해서 어떤 조건이나 환경을 마련해야 하는지 등을 클라이언트와 서버 등 모든 맴버들과 함께 협의해서 개발 단계 때부터 대응할 수 있도록 가이드하는 역할을 해며, 릴리즈 하기 위한 조건을 확인하고 공유한다. 특히 단일 기능이 아니라서 여러 서비스의 도메인을 확인해야 하는 경우에는 담당자들과 함께 세부적인 논의를 진행해야 한다.

개발 단계에서 QA의 역할

개발이 진행되는 동안의 QA의 역할은 리뷰어이다. 기획 관련 문서나 개발 아키텍쳐 등에 대해서 자세하게 확인한 뒤 질문하여 피드백을 제공하는 역할을 한다. 이때 부정적인 내용이라도 다양한 측면에서 도움이 된다면 가감 없이 검토할 수 있도록 피드백 할 수 있어야 한다. 이러한 활동은 복잡성을 줄이고 의미가 모호한 부분을 제거하는 등 기획한 기능이나 피처에 대해서 명확하게 정리할 수 있는 기회를 제공한다.

 

또한 개발할 때 고려해야 하는 항목을 케이스별로 정리해서 제공하거나, 이전 기능과 새로운 기능의 스펙을 비교하는 등 기능에 대해서 다시 정리할 수 있는 기회를 제공한다. 특별한 테스트가 필요한 경우에는 단위 테스트 진행을 요청하기도 하고 관련 정보에 대해 조언을 하는 역할을 한다.

피드백 수렴 및 개선 역할

지금까지는 QA가 프로세스에서 메인이 아닌 서브의 역할을 했다고 하면 이제는 메인이 되어야 한다. 제품을 배포하거나 진행중인 업무를 완료하는 시점에서 업무 진행 과정 혹은 결과에 대해 여러 기준에 다라 평가하고 개선하는 단계이기 때문이다. 개발된 코드의 품질을 평가하거나 제품 배포 이후 발생한 이슈에 대응하는 절차를 확인하는 등 전체적으로 제품 품질을 평가하는 과정이 꼭 필요하다. QA는 회고를 통해 전체적인 피드백을 수렴하고 각 담당자에게 필요한 개선 사항을 도출해 낸다.

 

회고 미팅에는 주인공이 아닌 조력자의 역할로 참가하여 프로세스와 같은 여러 항목에 대한 피드백을 정리해서 강점과 약점에 대해서 서로가 잘 인식할 수 있도록 도와주는 역할을 하며 개선해야 하는 것들이 무엇인지 적극적으로 참여해서 의견을 도출해낸다. 회고 방향이 실수나 잘못을 비난하는 방향으로 흐르는 것을 방지하는 역할을 하는 동시에 정확하게 문제를 제기하고 해결 솔루션을 도출해 개선 방향을 잡을 수 있도록 적극적인 참여를 유도하는 역할을 한다.  회고 이후에는 회고에서 나온 여러 아이템등를 액션 아이템으로 정리해서 프로젝트에 올바르게 반영되는지 확인해야 한다.

QA가 갖춰야할 역량

조직 내 품질 문화를 전파하는 역할을 해야 한다. 품질은 QA만의 문제가 아니다. 결과물의 품질은 프로젝트에 참여하는 모든 구성원의 공통의 역량이며 책임이다. 따라서 각 단계에서 수행하는 데이터 수집과 수집된 데이터를 해석할 수 있는 역량, 협업 단계에서 개발 구성원과 협업할수 있는 최소한의 기술, 즉 아키텍처에 대한 이해와 코드를 이해할 수 있는 역량, 프로세스 개선과 관련된 테스트 관리 역량, 각 담당자들과 원할히 소통할 수 있는 커뮤니케이션 역량 등이 필요하다.

그래서 QA 

에자일 방법론을 사용하는 조직에서 소프트웨어의 결함을 조기에 발견하고 예방하기 위해서 조기에 테스트나 시프트 레프트 등의 프로세스 과정을 강조하는데, QA만의 특정 업무 영역을 정의하지 않고 업무와 관련된 모든 조직과 협업하고 최신 정보를 공유하고, 더 높은 품질을 달성하기 위해 노력하며, 더 나아가서 이러한 과정을 전파하고 책임지는 역할까지 수행해야 한다.

 

그러나 보통의 스타트업 에서는 제한된 인력으로 기획부터 디자인 개발을 진행해야 하기 때문에 재대로된 QA를 진행하기란 쉽지 않다. 그렇기에 단계적 배포나 Crashlytics를 통해 커버하는 경우가 많고, 회고 미팅도 진행되지 않는 경우도 많다. 하지만 QA가 올바르게 진행되지 않는다면 팀이 발전할수 있는 여지가 줄어들고, 배포 이후에도 계속되는 버그 리포트로 인해 긴습 수정 업무를 진행하게 되면 업무적인 피로도가 증가해서 전체적인 일정에 차질을 초래할수도 있다.

 

하지만 필요하다고 모든 조직에서 QA를 도입할수는 없다. 나는 새로운 프로세스를 만드는것은 조직원 모두가 필요성을 느끼고, 충분한 토론을 거쳐 공감대가 형성되었을때만 프로세스를 성공적으로 팀에 정착할 수 있다고 생각한다. 단순히 윗사람이 도입하라고 해서, 혹은 몇몇의 사람들만의 주도로는 팀에 충분히 정착할만한 동력을 얻을 수 없기 때문에, 이게 꼭 팀에 필요한지, 팀에 다른 사람의 생각은 어떠한지에 대해 충분한 토론을 우선 실행해보자.

함께 보면 좋을 글

소규모팀에 적합한 QA 프로세스 구축기(스타일쉐어팀의 QA방식) by 스타일쉐어(StyleShare)

 

초기 스타트업의 첫 QA프로세스 구축기

 

[원티드 강의] 지그재그의 QA 팀을 만들기까지의 경험