애자일 테스팅 회고 (Agile Testing Retrospecitve)

안녕하세요. QA 엔지니어 이승훈 입니다.

애자일 개발 환경에서 QA의 역할은 무엇일까요? 단순히 개발 초기부터 테스트를 수행하는게 ‘애자일 테스트’ 일까요 ? ‘성공을 보장하는 듯’한 방법론과 성공수기.. 그런데 우리 조직에 맞는 답은 어디에 있을까요? 애자일 개발 프로세스에서 생산성과 품질이라는 두 마리 토끼를 쫓아가는 과정에서 고민한 것들에 대해 적어보았습니다.

애자일 테스팅 맛보기 (쓴맛)

위키피디아의 설명을 빌리면 애자일 테스팅이란 “애자일 소프트웨어 개발 프로세스의 원리를 따르는 소프트웨어 테스팅 방법” 이라고 설명되어 있습니다. 개발 주기 안에서 개발과 함께 테스트가 진행되고, 제품의 퀄리티는 전체 팀원의 몫이라 얘기합니다.

스프린트, 칸반, TDD, ATDD, BDD, XP, Lean, 애자일 테스팅 사분면, 테스트 자동화, 테스트 피라미드.. 등 애자일 테스트와 관련된 다양한 개발 방법 및 이론들이 있습니다.

조직에 애자일 개발 프로세스를 도입하게 되면서, 전통적인 테스트 방식과는 다른 이런 ‘애자일한 테스트’ 방법이 요구되는데, 방법론에서 얘기하는 절차 상의 모든 것들 따랐음에도 불구하고 도입 초기의 결과는 대부분 좋지 않습니다.

전체 프로젝트 기획을 작은 단위로 나누는 것도 익숙치 않고, 기획에 대한 명세는 부족하고, 초기에 미쳐 고려하지 못한 부분이 지속적으로 발견됨으로써, 작업의 덩어리는 갈수록 커지고…. 그런 변경이 있을 때 마다, 개발 및 테스트 작업들은 추가적으로 재수행 되어야 하기 때문에 스프린트 일정 안에 소화하기가 벅차게 됩니다.

결국, 정해진 스프린트 기간 안에 완료를 하지 못하는 일이 발생하거나, 완료는 했으나 결과물의 품질이 현저히 떨어지는 상황이 벌어지게 됩니다.

모든 새로운 변화에는 초기 생산성이 저하되기 마련입니다. 그 단계를 얼마나 빨리 극복하고 생산성을 끌어 올릴 수 있느냐가 관건이죠.

안타깝게도, 스크럼 인원들은 스크럼 팀 외 업무 요청을 지속적으로 받으면서 스크럼 팀에 온전히 집중하지 못하게 되는 경우가 많습니다. 더군다나, 조금씩 나아진다 싶을 때 즈음, 구성원의 일부가 퇴사 혹은 보직이동의 사유로 바뀌게 되는 일이 허다하게 발생하게 됩니다. 그러면 처음부터 다시 시작! ㅠㅠ

애자일 방법론의 디테일한 시행규칙을 가지고도 심심찮게 논쟁을 했던 기억도 있는데요. 이렇게 답도 없는 논쟁의 챗바퀴를 돌다보면 결국, 변곡점을 넘어서지 못하고, 애자일은 우리와 맞지 않다거나, 이론적으로만 가능한거야…… 라며 많이 포기를 하게 됩니다.

애자일 테스팅 따져보기

이런 경험이 계속 쌓이면 뭔가 “핵심에서는 멀어진 채 형식의 말단에서만 자꾸 겉돈다..＂라는 생각이 듭니다. 우리가 뭘 놓치고 있는지 알아보고자 애자일 개발 프로세스, 애자일 테스트에 대해 다시 따져 보기로 했습니다.

“애자일 소프트웨어 개발 프로세스의 원리를 따르는 소프트웨어 테스팅 방법”

애자일 개발 프로세스 내에서 테스트 활동을 하는 것이니까 당연히 애자일 개발 프로세스의 원리나 속성에 준하는 것일텐데, “애자일 소프트웨어 개발 프로세스의 원리”, “애자일의 원리”가 정확히 뭘까요?

2001년에 발표된 애자일 선언문의 12가지 원칙에 보면 애자일의 최우선 순위는 “가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.” 라고 되어 있습니다.

결국 애자일의 가치와 원칙을 따른 개발 프로세스가 잘 동작한다는 것은 “얼마나 만족스러운 소프트웨어를 얼마나 빠르게/자주 고객에게 전달하느냐?”로 판단할 수 있을 것 같습니다.

그러면 우리는 현재 얼마나 빠르게, 얼마나 자주, 얼마나 만족스러운 소프트웨어를 고객에게 전달하고 있을까요? 이것을 생산성과 품질이라고 하는 두 가지 꼭지로 분리해 보았습니다.

<싸이클 타임>
프로젝트 관리 도구로 Jira를 쓰고 있는데, Jira는 ‘제어차트’라는 보고서를 통해 Cycle Time 정보를 제공합니다.

이 차트를 통해 전반적인 싸이클 타임의 추세를 한 눈에 알아볼 수 있었지만 원하는 개발과 배포, 각 단계별 소요시간에 대한 인사이트를 가질 수는 없고, raw 데이터 형식의 자료를 제공하지 않아 분석을 위한 2차 가공이 가능하지 않습니다.

무엇보다도 유저스토리의 타임라인을 분석하다 보니, 빠르게 진행되는 스프린트 일정에서 아이템들의 상태 관리가 생각만큼 잘 되고 있지 않다는 것을 알 수 있었습니다.

이러한 점을 보완하기 위해서, Python 과 Jira API를 이용하여 스토리의 상태전환이 일어난 히스토리 정보, 그리고 다른 관계된 값들과 비교 판단하여 최종 보정된 스토리의 시작시간/완료된 시간/닫힌 시간/배포된 시간 정보를 모았습니다. (소스코드)

그리고 시작시간 부터 완료된 시간까지를 ‘개발에 걸린 시간’, 완료된 시간 부터 배포된 시간까지를 ‘배포에 걸린 시간’ 으로 보고, 이 둘을 합쳐 최종 “싸이클 타임“으로 산정하였습니다.

<환경별 DDP>
환경별 DDP는 버그 보고 시 ‘발견 환경’이라는 필드를 필수 입력값으로 지정함으로써 쉽게 구할 수 있었는데, 이렇게 모아진 생산성 지표 ‘싸이클 타임’과 품질 지표 ‘환경별 DDP’ 정보를 모아 Google Data Studio에 넣고 대시보드 형식으로 뽑아 보았습니다.

개발 아이템 수/개발에 걸린 시간/배포에 걸린 시간/전체 싸이클 타임/표준편차, 그리고 해당 기간에 총 버그가 얼마나 발생했는지, 개발/배포 어느 시점에 버그가 주로 발견 되는지를 기간별로/ 릴리즈별로 / 프로젝트 팀 별로 볼 수 있게 되었습니다.

전체 조직 또는 각 프로젝트 팀이 개발과 배포 어느 지점에서 잘되고 있는지, 잘 안되고 있는지, 객관적인 지표로 진단해 볼 수 있게 되었습니다. 단순히 방법론적으로 옳으냐 그르냐를 판단하지 않고, 우리의 취약한 지점을 정확히 알고 어떻게 보완할 수 있는가를 얘기할 수 있게 되었습니다. 해결책들을 작게 시도해보고, 모니터링할 수 있게 되었습니다.

“개발 주기 안에서 개발과 함께 테스트가 진행”

개발 주기 안에서 개발과 함께 테스트를 진행하면 싸이클 타임이 낮아져? 운영배포 이후에 발견되는 버그의 수치, DER이 낮아져?….이런 점을 알아보기 위해, 폭포수 개발 모델과 애자일 개발 모델의 생산성을 비교해보는 시뮬레이션을 돌려보았습니다.

폭포수와 애자일의 생산성 비교 시뮬레이션

가정
- 유저스토리가 20개인 단일 프로젝트
- 스프린트 기반 애자일 기법.
- 한 스프린트에 4개의 유저스토리 완료
- 아이템 하나 당 개발 시간 = 1 day
- 아이템 하나 당 테스트 시간 = 1 day
- 개발과 테스트만을 중점적으로 본다. (기획/설계/디자인/배포 부분은 배제)
- 리드 타임 : 전체 프로젝트를 완료하는데 걸린 총 기간

<폭포수 개발 모델>
일단 2001년 애자일 선언문이 발표될 당시의 폭포수 개발 모델과 현재의 폭포수 모델은 상당한 차이가 있다고 개인적으로 생각합니다. 2001년 당시는 많은 경우 전체 개발 아이템이 일괄 개발된 다음 테스트 단계로 넘어가는 형식이었는데, 이 경우 생산성 지표를 따져보면 싸이클 타임과 리드 타임이 동일하게 40일로 나타나는 것을 볼 수 있습니다.

그와는 다르게, 요즘 폭포수 모델에서는 기본적으로 작은 단위의 이터레이션을 통해 개발을 연속적으로 진행하는 것은 일반화되어 있는 거 같습니다.
(이 부분에서 애자일과 폭포수 개발 프로세스의 구분에 대한 이견이 많이 생길 수도 있을 것 같지만, QA의 관점에서 개발 주기 다음에 테스트를 진행함으로(Phased Process) 폭포수 개발 모델이라 간주합니다.)

어쨌든 이런 요즘 폭포수 모델의 개발 생산성 지표를 보면, 옛날 폭포수보다는 개발과 테스트가 일정 부분 중첩되면서 싸이클 타임=8일, 리드타임=24일로 많이 단축된 것을 볼 수 있습니다.

<애자일 : 스프린트>
마지막으로 사람들이 “애자일 하다”라고 여기는 개발과 테스트가 스프린트 안에서 함께 진행되는 경우를 보면, 싸이클 타임=5일, 리드타임이 25일로 나타나는 것으로 볼 수 있습니다.

!의문점
폭포수와 비교해보면 싸이클 타임은 5일로 짧아졌는데, 전체적인 배포 주기는 8주 이후 폭포수 모델이 더 빨라지는 것을 볼 수 있습니다. 더군다나 최종 프로젝트 리드 타임이 폭포수 보다 하루 더 긴 것으로 나타났습니다!?

“왜 이렇지?”, “개발 프로세스 내에서 같이 테스트를 시작하면 우리는 더 빨리, 더 자주 개발 결과물을 생산할 수 있는 거 아니였어?”…..

이 답은 환경별 결함발견율(DDP)를 통해 짐작해 볼 수 있었는데요. 폭포수로 진행하는 프로젝트의 경우, 개발 스프린트 후 QA 테스트 단계에서 발견되는 버그의 수치가 개발 환경에서 발견되는 수치보다 3배 넘게 높게 나타나는 것으로 파악됐습니다. 그 말인 즉, 개발자가 현재 Test환경에서 테스트 진행 중인 지난 스프린트 아이템의 버그를 수정하는 데 많은 시간을 쓰고 있다 → 그로 인해, 현재 스프린트의 생산성이 떨어지고 있다라고 판단할 수 있었습니다.

이를 반영하여 다시 시뮬레이션 해보면,

위 그림에서 폭포수 모델 시뮬레이션 두 번째 표를 보면 지난 아이템의 버그 수정에 리소스가 일정 부분 쓰이면서, 스프린트 당 생산성이 떨어지는 것을 볼 수 있습니다. 그래서, 싸이클 타임은 동일한 8일 이지만, 프로젝트 리드 타임은 29일로 길어지는 것을 볼 수 있습니다.

이러한 버그의 수치가 높으면 높을수록, 혹은 기획의 변경, 기술적인 큰 변경이 필요한 버그가 QA 테스트 단계에서 발생하게 되면, 이런 비용은 더욱 증가하게 되고, 현재 스프린트의 생산성은 더욱 더 떨어지게 되는데요. 폭포수 세 번째 표를 보시면 현재 스프린트의 절반 정도를 버그 수정에 쓰고 있는 경우, 프로젝트 리드 타임이 40일 정도로 나타나는 것을 볼 수 있습니다.
(이는 2001년 전통적인 폭포수 모델에서 시뮬레이션해 본 것과 같은 수치입니다.)

이와 같이 생산성과 품질에 관한 지표를 동시에 분석해 봄으로써, 개발 프로세스의 이른 단계에서 테스트 활동을 수행하는 것이 스프린트의 생산성과 어떤 상관관계가 있는지, 어떤 지표를 통해 현상을 파악할 수 있는지 이해할 수 있었습니다.

마치며

너무도 당연한거라 생각할 수도 있으나, 팀에서 이러한 분석과 내부 논의를 통해서 우리의 주변 상황을 좀 더 이해할 수 있게 되었고, 앞으로 나아가야 할 방향에 대한 막연함을 많이 덜 수 있었던 과정이었다 생각합니다.

지금까지는 ‘애자일 방법론’이 목표인양 맹목적으로 쫓아갔었다면, 이제는 애자일 방법론을 도구 삼아 우리 조직이 가려는 목표를 좀 더 정확히 볼 수 있게 되었다 생각하고, 애자일을 흉내 내는 것이 아니라(Doing Agile), Being Agile 할 수 있게 되었다 생각합니다. 그리고, 애자일 개발 프로세스 안에서 수행하는 테스트 활동들이 개발조직의 생산성에 어떠한 영향을 미치는지를 좀 더 잘 설명할 수 있게 되었습니다.

만약 개발조직에 아직 이러한 이해가 부족하다면, 만약 조직의 목표를 담아내고 모니터링 할 수 있는 지표와 도구가 없다면, 먼저 그것을 갖추어 둘 것을 추천해 봅니다. 애자일이라는 망망대해에서 길잡이가 되어줄 것이라 생각합니다.