“이번 스프린트, QA로서 할 말이 많다!” QA 애자일 회고

2주간의 스프린트가 끝났습니다. 팀원들이 모두 회의실에 모여 포스트잇을 들고 있습니다. 바로 ‘애자일 회고(Agile Retrospective)’ 시간입니다.

회고는 단순히 “힘들었다”고 푸념하는 자리가 아닙니다. 이는 우리 팀이 더 나은 방향으로 나아가기 위해, 지난 스프린트의 문제점을 솔직하게 공유하고 개선점을 찾아 나가는 가장 중요한 성장 엔진입니다.

특히, 제품의 품질과 테스트 프로세스 전반을 지켜보는 QA는 이 회고의 핵심적인 참여자입니다. 이번 글에서는 QA가 회고에서 어떻게 목소리를 내야 하는지 알아보겠습니다.

이 글에서 다루는 것


  • 애자일 회고와 QA의 중요성
  • 가장 많이 쓰이는 KPT 회고 방법론
  • QA를 위한 회고 발언 실전 예시
  • 회고를 성공으로 이끄는 QA의 소프트 스킬

KPT 회고: 우리의 스프린트를 되돌아보는 세 가지 거울

수많은 회고 방법론이 있지만, 가장 단순하고 강력한 것은 KPT입니다. KPT는 다음 세 가지 관점으로 지난 스프린트를 되돌아보는 방법입니다.

  • Keep (유지할 점): 이번 스프린트에서 좋았고, 앞으로도 계속 이어갔으면 하는 것.
  • Problem (문제점): 불편했고, 아쉬웠으며, 우리를 방해했던 것.
  • Try (시도할 점): Problem을 해결하거나, Keep을 더 강화하기 위해 다음 스프린트에서 새롭게 시도해볼 것.

QA는 이 세 가지 거울을 통해, 팀의 품질 프로세스를 객관적으로 비춰주는 역할을 해야 합니다.

[실전 예시] QA는 KPT 회고에서 어떻게 말해야 할까?

1. Keep (잘한 일은 구체적으로 칭찬하고 격려하기)

단순히 “좋았어요”가 아닌, 구체적인 사실을 바탕으로 칭찬해야 합니다.

  • 나쁜 예: “이번 배포는 안정적이어서 좋았어요.”
  • 좋은 예: “개발자 A님이 단위 테스트를 꼼꼼하게 작성해주신 덕분에, 사이드 이펙트 버그가 거의 발생하지 않아 회귀 테스트가 매우 순조로웠습니다. 앞으로도 이 방식을 계속 유지하면 좋겠습니다.” 👍

2. Problem (비난이 아닌, 현상과 문제에 집중하기)

개인을 공격하는 것이 아니라, 팀이 겪은 ‘문제 상황’ 자체에 초점을 맞춰야 합니다.

  • 나쁜 예: “개발자 B님이 또 깜빡하고 테스트 환경에 배포를 늦게 해주셔서, 테스트할 시간이 부족했어요.”
  • 좋은 예: “이번 스프린트에서는 기능 개발이 완료된 후, 테스트 환경에 배포되기까지 평균 1일 정도의 시간이 소요되었습니다. 이 때문에 QA가 충분한 테스트 시간을 확보하는 데 어려움을 겪는 문제가 있었습니다.”

3. Try (구체적이고 실행 가능한 해결책 제안하기)

문제 제기에서 그치지 않고, 함께 해결할 수 있는 작은 ‘실행 과제(Action Item)’를 제안하는 것이 중요합니다.

  • 나쁜 예: “앞으로는 배포를 빨리 해주세요.”
  • 좋은 예: “혹시 기능 개발이 완료되면, 개발자 B님께서 QA 채널에 바로 알려주시는 건 어떨까요? 슬랙 알림 하나만 추가해도, 저희가 배포 여부를 계속 확인하는 시간을 줄이고 더 빨리 테스트를 시작할 수 있을 것 같습니다.”

현직 QA의 회고 실패 경험담

제가 주니어 QA 시절, 회고 시간에 발견한 버그 목록을 자랑스럽게 늘어놓으며 “이렇게 버그가 많은데, 개발팀에서 좀 더 신경 써야 하는 것 아닌가요?” 라고 말했던 적이 있습니다.

분위기는 싸늘해졌고, 회고는 문제 해결이 아닌 감정적인 방어전으로 변해버렸습니다. 그 경험을 통해, QA가 회고에서 해야 할 일은 ‘버그의 개수’를 보고하는 것이 아니라, ‘버그가 만들어질 수밖에 없었던 프로세스의 문제점’을 함께 고민하는 것임을 깨달았습니다.

예를 들어, “기획서의 예외 케이스 정의가 부족하여, 관련 버그가 많이 발생했습니다. 다음 스프린트부터는 기획 리뷰에 QA가 5분이라도 참여하여 예외 케이스를 함께 논의하는 것은 어떨까요?” 라고 제안하는 것이 훨씬 더 건설적인 접근입니다.

결론: QA는 팀의 ‘건강한 거울’이다

성공적인 애자일 회고에서 QA는 팀의 건강 상태를 비춰주는 ‘거울’과도 같은 역할을 합니다.

문제를 찾아 비난하는 ‘깨진 거울’이 아니라, 문제의 근본 원인을 함께 찾아 개선할 수 있도록 돕는 ‘깨끗하고 건강한 거울’이 되어야 합니다.

QA가 건설적으로 목소리를 낼 때, 우리 팀의 품질 문화는 한 단계 더 성장할 수 있습니다.

부록: QA를 위한 회고 미니 체크리스트 ✅

  • Keep: 이번 스프린트에서 품질에 긍정적인 영향을 준 동료의 행동을 구체적으로 칭찬했는가?
  • Problem: 개인에 대한 비난이 아닌, ‘현상’과 ‘프로세스’의 문제점에 대해 이야기했는가?
  • Try: 내가 제기한 문제에 대해, 작고 구체적이며 바로 실행 가능한 해결책을 함께 제안했는가?
  • 경청: 다른 팀원의 의견을 경청하고, 그들의 어려움에 공감했는가?
  • 데이터: “왠지 그런 것 같다”는 느낌이 아닌, Jira 티켓이나 테스트 결과와 같은 객관적인 데이터를 근거로 이야기했는가?

참고 자료 (References)

  • Atlassian – The Agile Coach: Retrospectives (애자일 회고에 대한 Atlassian의 가이드)
  • FunRetrospectives.com (KPT를 포함한 다양한 회고 방법론을 소개하는 커뮤니티 사이트)

댓글 남기기