전통적인 소프트웨어 개발 방식을 떠올려 봅시다. 기획, 디자인, 개발이 모두 끝난 후, 마지막 단계에서 QA팀이 완성된 제품을 넘겨받아 테스트를 시작합니다. 이 방식의 가장 큰 문제는, 테스트 단계에서 발견된 버그는 수정하기에 너무 늦었거나 엄청난 비용이 발생한다는 점입니다.
하지만 오늘날 대부분의 IT 기업이 채택한 ‘애자일(Agile)’ 개발 방식에서는 이야기가 완전히 다릅니다.
그렇다면 짧은 주기로 빠르게 개발하고 배포하는 애자일 환경 속에서, QA는 어떻게 일해야 할까요?
Q. 애자일(Agile)에서의 QA, 정확히 무엇이 다른가요?
가장 큰 차이는 ‘테스트가 언제 시작되는가’ 입니다.
- 전통적인 QA: 개발이 모두 끝난 ‘후(後)’에 테스트를 시작합니다.
- 애자일 QA: 개발과 ‘동시에(同時)’ 테스트를 진행합니다.
비유: 전통적인 QA가 ‘완성된 자동차를 마지막에 검수하는 감독관’이라면, 애자일 QA는 ‘자동차 조립 라인에 처음부터 함께 들어가, 각 부품이 조립될 때마다 품질을 확인하고 문제점을 즉시 알려주는 팀원’과 같습니다.
Q. ‘스프린트(Sprint)’ 안에서 QA는 구체적으로 어떤 일을 하나요?
애자일 개발은 보통 1~4주의 짧은 주기인 ‘스프린트’ 단위로 진행됩니다. QA는 이 스프린트의 모든 과정에 깊숙이 참여합니다.
1. 스프린트 계획 단계 (Sprint Planning)
- 무엇을: 이번 스프린트에서 개발할 기능(사용자 스토리)을 팀원들과 함께 리뷰합니다.
- QA의 역할:
- 요구사항이 모호하거나 빠진 부분은 없는지 질문합니다.
- 테스트 관점에서 발생할 수 있는 위험 요소나 예외 케이스를 미리 공유합니다.
- 테스트에 얼마나 많은 시간이 필요할지 대략적인 공수를 예측하여 팀의 계획 수립을 돕습니다.
2. 스프린트 진행 중 (During the Sprint)
- 무엇을: 개발과 테스트가 병렬적으로 이루어집니다.
- QA의 역할:
- 개발자가 특정 기능을 개발하는 동안, QA는 해당 기능에 대한 테스트 케이스를 미리 작성합니다.
- 개발이 완료된 기능이 나오는 즉시 테스트를 시작하고, 버그를 발견하면 실시간으로 개발자에게 공유합니다.
- 이를 통해 버그가 스프린트가 끝나기 전에 빠르게 수정될 수 있도록 ‘빠른 피드백 루프’를 만듭니다.
3. 스프린트 리뷰 및 회고 단계 (Sprint Review & Retrospective)
- 무엇을: 완성된 기능을 팀원 및 이해관계자들에게 시연하고, 스프린트 과정을 되돌아봅니다.
- QA의 역할:
- 테스트 결과를 공유하고, 아직 해결되지 않은 주요 버그나 품질 상태에 대해 보고합니다.
- 회고 시간에는 “테스트 환경이 불안정해서 시간이 지연되었다” 또는 “요구사항이 중간에 바뀌어 테스트 케이스를 다시 만들어야 했다”와 같이, 테스트 과정에서 겪었던 어려움을 공유하고 다음 스프린트에서 개선할 점을 논의합니다.
Q. 애자일 QA에게 특히 중요한 역량은 무엇인가요?
‘협업’과 ‘소통’ 능력이 그 어느 때보다 중요합니다.
- 적극적인 커뮤니케이션: 더 이상 마지막 단계의 ‘문지기’가 아닙니다. 기획자, 개발자와 수시로 대화하며 아이디어를 내고 문제점을 조율하는 팀의 일원으로서 적극적으로 소통해야 합니다.
- 빠른 적응력과 유연성: 스프린트 도중 요구사항이 바뀌거나 우선순위가 변경되는 일은 흔합니다. 이때 유연하게 테스트 계획을 수정하고 대응할 수 있는 능력이 필요합니다.
- 자동화 마인드셋: 짧은 스프린트 안에 모든 회귀 테스트를 수동으로 할 수는 없습니다. 무엇을 자동화해야 팀의 속도를 높일 수 있을지 끊임없이 고민하고, 자동화 테스트를 구축하는 능력이 매우 중요합니다.
결론: 품질은 마지막 단계가 아닌, 모든 과정에 있다
애자일에서 QA는 더 이상 개발의 마지막 단계를 책임지는 ‘품질 부서’가 아닙니다. 개발팀에 속한 ‘품질 담당 팀원’으로서, 프로젝트의 시작부터 끝까지 모든 과정에 참여하며 품질을 함께 만들어나가는 역할을 합니다.
이처럼 테스트 활동을 개발 초기 단계로 끌어오는 것을 ‘Shift-Left Testing’이라고 부르며, 이는 더 높은 품질의 제품을 더 빠르게 만드는 현대적인 애자일 개발의 핵심 원리입니다.