이번 스프린트에 테스팅을 넣는 방법

(다음 글은 2025.2.7에 수신한 mountain goat software 뉴스레터를 기반으로 작성되었습니다.) 

테스팅을 이터레이션에 넣는 것은 애자일 팀에게는 도전입니다. 테스터가 이터레이션에서 늦게 작업을 받으면, 가능한 빨리 모든 것을 테스트하기란 어렵죠.

테스터들은 또한 각 이터레이션의 초기에 좌절감을 느끼는 일이 흔한데, 프로그래머들이 테스트할 무언가를 넘기길 기다려야 하기 때문이죠.

이터레이션내에서 테스트할 시간을 가질 수 있는 열쇠는 프로그래머와 테스터간의 핸드오프 크기를 줄이는 것입니다. 

프로그래머가 프로덕트 백로그 (일반적으로 사용자 스토리)로부터 아이템을 잡아서 새로운 기능을 개발하고, 모든 것이 개발된 후에 테스터에게 넘기는 것이 일반적이죠.

이것은 프로그래머가 백로그 아이템을 며칠 동안 혹은 1주일 혹은 그이상 작업할 수 있다는 것을 의미합니다. 테스터가 최종적으로 그것을 받았을 때는, 테스트할 것이 많죠.

전체 프러덕트 백로그 아이템을 끝내고 테스터한테 넘기는 대신, 프로그래머는 아이템의 작은 부분들을 끝날 때마다 넘겨야 합니다.

일반적인 프러덕트 백로그 아이템과 수용 기준 (acceptance criteria)을 생각해 보시죠. 사용자 스토리가 4개의 수용 기준이 있다고 가정해 봅시다. 프로그래머가 각 수용 기준을 충족하도록 코드를 작성하였을 때, 그 작업이 테스팅으로 넘겨져야 합니다. 이렇게 해야 프로그래머와 테스터가 거의 동시에 일할 수 있습니다. 

여기 더 단순한 사용자 스토리 "로그인: 멤버로서, 로그인할 필요가 있으며, 내 계정이 안전하게 지켜짐"에 이것이 어떻게 동작하는지 보여주는 예가 있습니다.

수용 기준은 다음과 같습니다:

- 올바른 credential은 접근 허용

- 잘못된 credential은 접근 거부 및 에러 메세지 표시

- 사용자는 암호 리마인더를 요청할 수 있고

- 3번 로그인 시도 실패후 사용자 잠김

어떤 일을 시작하기 전에, 프로그래머와 테스터는 어디서부터 시작할 지 정합니다. 올바른 credential이 입력되었을 때, 접근 권한 허용부터 시작하기로 결정합니다. 

프로그래머가 이것을 지원하는 코드를 작성하는 동안, 테스터는 전체 스토리에서 이 작은 부분에 대한 테스트 계획과 테스트 데이타를 작성합니다.

얼마나 많은 자동화가 이미 사용중인지에 따라, 테스터는 심지어 코드가 완성되기만하면 바로 실행시킬 수 있는 자동화된 테스트 스크립트를 작성할 수도 있습니다. 

프로그래머와 테스터 둘 다 완료되는 순간, 그들은 그들의 작업을 공식적인 빌드 시스템으로 체크인하고 테스트가 실행됩니다. 

그다음 그들은 다음에 무슨 작업을 할 지 합의합니다. 그들이 스토리의 다른 수용 기준인 사용자가 암호 리마인더를 요구하도록 하는 비트를 골랐다고 합시다.

다시, 프로그래머가 이것만 지원하는 코딩을 하는 동안, 테스터는 테스트 플랜, 테스트 데이타, 자동화 스크립드를 만듭니다. 

여전히 프로그래머와 테스터 간의 핸드오프가 있습니다만, 전체 프러덕트 백로그 아이템의 하나의 커다란 핸드오프 대신, 프로그래머는 한번에 전체 기능 중의 작은 서브셋 하나를 테스터에게 넘깁니다.

이렇게 하기 위해, 프로그래밍과 테스팅 작업에 같은 양의 시간이 걸릴 필요가 없습니다.

예를 들면, 코딩은 테스트가 실행되도록 준비하는 것보다 두배 걸립니다. 그 경우, 같은 테스터가 두번째 프로그래머와 비슷한 패턴을 따르거나, 많은 다른 테스팅 작업중 일부를 할 수도 있습니다.

크기를 줄이고, 핸드오프 빈도를 늘리는 것이 테스가 테스트할 시간이 없는 문제를 해결하고, 팀이 애자일로 성공하게 합니다. 

Mike