애자일과 QA
Jake Kim
애자일을 도입해서 사용하고 있다는 회사들의 QA 매니저들을 만나보면 한결같이 하는 불만이 반복주기 마지막에 테스트가 몰린다는 것
이었습니다.
스크럼을 하는 팀에서 스토리를 정해서 한 반복주기를 진행할 때, 언제부터 테스트를 하는 것이 좋으며 테스트 과정에서 발견되 버그
에 대한 처리를 어떻게 해야하는가에 대한 문제입니다. 그 반복주기내에 모든 것이 완료가 되어야 하는 상황에서 발견된 모든 버그
를 수정을 하고 다시 테스트를 하려면 막판 몰아치기가 된다는 거죠. 그 버그들을 다음번 반복주기로 넘기는 것은 모든일이 연장이
된다는 말과 같고요. 이 부분을 받아들일 고객도 없다는 거죠.
다른 분들께서는 어떻게 하고 계신지 궁금합니다.
Do-Hyung Jin
--
--
DO-HYUNG JIN
Engineer
S/W Platform Group 1
Mobile Communication Division Telecommunication Network
SAMSUNG ELECTRONICS CO.,LTD
Mobile : +82-(0)10-9530-0772
Office : +82-(0)31-301-0772
dh....@samsung.com
Hubert Shin
하지만, 고객 시연을 한다면 한 가지 집고 넘어가야 하실 것이 있을 것 같습니다.
1) 만약 고객 시연을 개발 주기와 맞물려 하신다면, 한 이터레이션 늦게(테스트와 결함 조치가 종료된 후) 제품을 시연하시거나
2) 개발 주기 마지막에 시연하고 품질을 높이기 위해 테스트를 하신다면
테스트의 기준과 제품 완료의 기준을 명확히 세워야 할 것이라 생각이 듭니다.
아니면, "테스트가 잘 되지도 않은 제품이 무슨 완료냐?"
라는 말을 들을 수도 있습니다.
현길조
참고로 작년 10월에 STEN에서 진행했던 애자일 테스팅관련 세미나에서 스튜어트씨가
한 이야기에 따르면 테스트를 어떻게 가져갈지 3가지 방식으로 정리를 해놓은 내용이 있어 첨부합니다.
1. In the development sprint (Whole Team)
- 개발 스프린트안에 테스팅 활동들(Story Test, Acceptance Test, Regression Test등)를 진행함.
- 장점 : 개발자와 테스터가 품질에 대한 책임을 공유하고 즉각적인 커뮤니케이션이 가능함.
- 단점 : 테스팅의 독립성을 잃을 수 있음. 테스팅이 스프린트 막판에 몰림.
2. Separate Paralled Activities (개발 스트린트보다 한 템포 늦게 가져감, 도형님과 Hubert 님이 말씀해주신 것과 동일합니다.)
개발 스프린트와 병렬로 별도의 테스트 스프린트를 가져감
- 장점 : 테스팅 활동을 개발 스프틴트의 의존성을 낮추어서 진행가능.
- 단점 : 테스팅과 디버깅을 위한 버전 관리과 복잡해짐. 개발자와 테스터의 커뮤니케이션 비용 증가.
3. Occasional Full Test Srpint
개발 스프린트 사이에 별도의 테스트 스프린트 추가 ex) 개발 스프린트1 > 개발 스프린트 2> 테스트 스프린트 1 > 개발 스프린트 3>
- 장점 : 개발팀이 병렬로 여러 스프린트를 진행시 통합하는 스프린트로 유용함.
- 단점 : 개발 스프린트 동안 테스트가 할일, 테스트 스프린트 동안 개발자가 할일에 대한 고려가 필요함.
참고 부탁드리며, 항상 에너지 넘치는 하루 되세요.
조현길 올림.
--
I always try to find defect for customer. I also want to work with fun.
박응주
주기의 마지막에 테스트가 몰리는 이유는 몇 가지가 있습니다.
주기의 마지막에 완료되는 기능이 많도록 계획했다. 주기 마지막에 테스트할 기능이 완료되면 테스트도 마지막에 몰릴 수 밖에 없습니
다. 주기 중간 중간에 완료되는 기능을 빨리 테스트를 할 수 있어야 막판에 몰리지 않습니다. 기능의 크기를 줄이거나, 구현 속도
를 높여서 완료되는 기능을 주기의 시작부터 끝까지 골고루 분포되도록 만들어야 합니다.
구현에 오류가 많다.
구현에 오류가 많으면 수정하고 다시 테스트해야 하기 때문에 테스트에 많은 시간이 소모 됩니다. 단위 테스트나 짝 프로그래밍 등으
로 개발 단계에서 오류가 유입되는 것을 최대한 막아야 합니다. 특히 개발 단계에서 오류가 많이 유입되면 테스터와 개발자의 관계
가 악화될 가능성이 높습니다. 테스터와의 원활한 협업을 위해서라도 구현 단계에서 발생하는 오류를 줄여야 합니다.
테스트에 시간이 많이 걸린다.
첫 번째 테스트는 수동으로 하더라도, 수정 후 확인 테스트는 자동화 할 수 있는 방법이 있으면 테스트 시간을 줄이는데 많은 도움
이 되겠죠. 이것은 저도 적용해보지 않아서 확신은 없습니다만 반복적인 테스트를 줄이는 방법도 찾아야 합니다.
Hubert Shin
독립된 테스트 팀을 개발 이터레이션 시작 후, 어느정도 시간이 지난 후 도입하고
테스트 대상을 점점 줄여가며, 테스트 하여,
부가적인 테스트가 나올 Workload 를 조정하는 방법도 있더군요
matthew
Jake Kim
'완료되는 기능을 주기의 시작부터 끝까지 골고루 분포되도록' 한다고 하셨는데, 그렇다면 기능이 끝날 때 마다 주기에 상관없이 릴
리즈가 되어야 한다는 말씀이신지요?
그리고 구현단계에 오류를 줄여야 한다고 하신부분에도 근본적으로는 동감을 합니다만 현실적인 실현방법이 쉽지가 않습니다. 모든 개발
자의 능력이 뛰어난 것도 아니고 또 그 많은 코드를 하나 하나 리뷰한 다는 것도 쉬운 일은 아닌 것 같구요.
> > 다른 분들께서는 어떻게 하고 계신지 궁금합니다.- Hide quoted text -
>
> - Show quoted text -
June Kim (김창준)
애자일에서 QA 의 부분에 대해 질문을 드려볼까합니다.
애자일을 도입해서 사용하고 있다는 회사들의 QA 매니저들을 만나보면 한결같이 하는 불만이 반복주기 마지막에 테스트가 몰린다는 것
이었습니다.
우선 스토리의 완료조건이 명확해야 하는데, 예컨대 QA 팀에서 테스트 완료까지 한 것을 완료로 봐야 합니다.
그리고 반복주기 마지막에 테스트가 몰리는 것은 제 경험상 대부분 1) 10명의 팀원이 있고 10개의 스토리(혹은 태스크)가 있을 때 각자에게 하나씩 할당하고 알아서 진행하는 경우 혹은/그리고 2) 개발팀과 QA팀이 협력하지 않고 거래나 바톤터치하는 상황입니다.
애자일에서는 3) 처음에 스토리 한 3개 정도를 10명이 함께 완료하고, 그리고 나서 또 3개를 하고 하는 식으로 진행해야 하고, 4) 개발팀과 QA팀이 상황을 공유하고 서로의 어려운 점을 매일 함께 고민하며 풀어나가도록 합니다.
번다운 차트를 그리면 1), 2) 경우 수평선을 긋다가 후반부에 급격히 떨어지는데 전형적인 Bad Smell(나쁜 냄새)입니다. 3), 4)는 지속적으로 떨어집니다. 따라서 마지막에 갑자기 테스트가 몰리거나 하는 일이 적어집니다.
서민석
슬픈 얘기일 수 있는데,
테스팅은 그 태생적으로 개발 이후에
실행될 수 밖에 없는 운명을 타고난 것 아닐까요.
하지만 아무리 그래도 그렇지..
테스팅이 과도하게 개발주기 말미에 몰린다는 것은
어딘가 문제가 있다는 뜻일텐데요.
애자일을 도입한다고는 했으나,
문제를 간단히 하기 위해, 다음과 같이 3가지를 가정해 보죠.
1. 한 개발주기(iteration)는 2주(근무일수 10일)의 길이다.
2. 그 개발주기 동안에 단 1개의 스토리만 개발한다.
3. 그 1개의 스토리의 완료 조건은 총 10개의 테스트를 통과하는 것이다.
단순하게 생각해서 개발자는
매일 1개의 테스트를 통과할 분량만큼 개발하고,
테스터는 매일 1개씩만큼 테스트를 완료하는 것이지요.
그러면, 테스트가 완료일에 집중되지 않을 수 있겠군요.
(비록 개발자보다는 늦게까지 일을 하기는 하겠지만요.)
1. 단 1개뿐인 스토리지만 그 스토리의 size가,
개발팀의 개발 speed로는 도저히 개발주기내에 완료할 수 없었다.
2. 사실 한 개발주기내 1개의 스토리만 개발하는 건 아니다.
3. 통과해야할 테스트가 사전에 명확히 확정되고 공유되지 않았다.
4. 개발주기 후반부가 되어서야 아! 이거 테스트해야는데 아! 아! 하면서 조금씩 분명해진다.
5. 그러다 보니, 아! 저걸 개발해야 했었네? 하며 빼먹었던 개발사항을 알게 된다.
심지어 개발할 이유가 전혀 없었던 코드도 다수 발견된다.
6. 시간이 촉박하긴 하지만, 뒤늦게 발견된 개발된 사항을 뒤늦게 테스트해야만 한다.
그래서 제가 이해한 애자일에서는 다음 3가지 역량을 조직적으로 갖춰야 한다고 얘기합니다.
1. 각 개발 조직의 개발 speed에 대한 냉철한 측정 역량.
2. 각 스토리의 규모(size)에 대한 추정 역량.
3. 각 스토리별 통과해야할 테스트를 사전에 명확히 파악하는 역량.
과연 우리 각자는 위의 3가지 역량을 얼마나 갖추고 있을까요?
과연 나의 동료들은요?
애초부터 6달, 3달에 얼마 줄께! 미리 정해집니다.
뭘 개발해야 하는지 요구사항? 없습니다.
원활한 개발과 테스트에 대한 고객의 협조? 없습니다.
애자일은 애석하지만 이런 현실을 어떻게 대응하라고 말해주지 않습니다.
그럼에도 IT 프로젝트로 계속 밥먹고 살려면
위의 3가지 역량은 어떻게든 훈늉하게 갖춰야 하지 않을런지요..
--
****************************************
* 서민석(Seo Min Seok)
* e-mail : elro...@gmail.com
* phone : +82-10-5660-8190
* Living, Loving, and Learning
****************************************