애자일을 위한 테스트?, 테스트를 위한 애자일이라는 토픽으로 프랙티스와 사례에 대한 글입니다

1. 애자일 테스트
부제 : 애자일을 위한 테스트 ?
테스트 를 위한 애자일 !

2. 목 차
. 피드백 1
. 피드백 2
. 피드백 3
. 피드백 4
. 피드백 5
. 피드백 6
. 3-Amigos(협업의 힘)
모두 빠른 피드백에 대한 것

3. 테스트는 죽었다?
GTAC 2011: Opening Keynote Address - Test is Dead
(애자일, 스타트업)
“그들은 너무 느려요”
“Product Bug보다
Idea Bug가 더 중요해요”
https://www.youtube.com/watch?v=X1jWe5rOu3g

4. 애자일에서 테스트하기 vs 테스트를 애자일하게 하기?
필요와 리소스에 따른 운용 형태 안
테스트 인력이 같은 스크럼 팀,
같은 스프린트 내에서 테스트를 수행
이상적 현실적
운영방안1
Whole Team 테스터
운영방안2
같은 팀 다른 스프린트
운영방안3
다른 팀 다른 스프린트
팀 전담 테스트 인력은 있으나, 한
스프린트 뒤에서 테스트를 수행
테스트 리소스 활용을 극대화하기
위해 별도의 테스트팀을 구성하고
별도의 테스트 스프린트에서여러
팀과 협업

5. 스프린트 내 애자일 테스트 활동 예
#1) 2주 주기,
GUI/API 테스트 자동화 등
#2)3주 주기,
API 테스트 자동화 등

6. 아!!!아!!!
피드백 1 - 1사용자 스토리와 Acceptance Criteria
사용자 스토리, 완료 기준(Acceptance Criteria)에 대해 미리 검토/상세화하고 공유한다
Early Testing, Shift-left-testing
알죠? 응???
상세화,명료화 효과
Product Planning, N-1스프린트에서 미리 초안 작성
아!!!
기존
이른 피드백
예!!

7. Early Testing, Shift-left-testing
이건 왜죠? 아하...
그렇다면...
전 이렇게 이해했어요.
맞나요?
#사례. 매 스프린트 초기에 사용자 스토리, 완료 기준을 갖고 온/오프라인 리뷰

8. #경험. 사용자 스토리와 Acceptance Criteria
Good pattern
Bad pattern
. 처음에는 온라인(시스템 상에 초안 작성, 질문/댓글)
-> 매 스프린트 초기 오프라인으로 진행
. 스토리에 대한 이해도, 결과물에 대한 예상치가 월등히 높아짐
. 테스터가 제품과 팀에 긍정적인 역할자로 인식
. 테스터가 상황에 따라서는 요건을 명확히 하는 능동적인 역할자가 되기도
. 테스터의 성향에 따라 과도한 개입
. 제품과 고객을 온전히 이해하지 못한 테스터는 엉뚱한 방향을
고집하기도
. 스프린트 초기 시간 LOSS 위험

9. 피드백 2 - pair testing
Defect Prevention > Detection
. 테스터는 개발자로부터테스트 환경 설정, 테스트 대상 파악, 개발 상태 등을 학습합니다
. 개발자는 테스터에게 스토리 관련 구현 내용을 설명함으로써이후 이해 부족으로 인해
발생하는 오류 비용을 최소화합니다
. 개발자는 테스터의 테스트 방식을 배울 수 있습니다
. 테스터는 개발 구성, 기술 구조를 이해함으로써테스트를 더 잘 할 수 있습니다
. 팀의 목표를 공유하고, 공감함으로써전체 커뮤니케이션이좋아집니다
. 짝 테스트에서 발견한 결함은 간략히 메모로 정리하여 개발자에게 전달하며, 같이
테스트했기 때문에 결함 재현, 디버깅, 조치 확인에 걸리는 시간과 주기가 감소합니다
매 스프린트 개발자와 1:1, 30분씩 짝 테스트로 직접적인 피드백&학습
오호~~
아하~!!
개발자 테스터
테스트 대상

10. #사례. pair testing
30분(~40분)동안 수십개의 이슈 발견
(결함, 표준 필요, 상세 요건 확인 필요 등)
Defect Prevention > Detection

11. #경험. pair testing
Good pattern
Bad pattern
. 가장 능동적이고, (강제) 참여적인 커뮤니케이션이 발생
. 일회성이 아닌 반영구적인 ‘학습’이 진행
. 개발이 완료되지 않은 상태에서도 수행 가능
. 30분 동안에 생각보다 많은 결함을 찾아서 만족도 높음
. 별도로 결함을 기록하지 않고, 바로바로 결함을 이해하고 디버깅해서 수정
. 테스터의 성향, 역량에 크게 의존적
(테스트를 잘 못하거나, 커뮤니케이션이 안 되는 테스터…)
. 개발자가 자신을 탓하는 걸로 느껴 싫어함 (조언자 역할만 수행)
. 서로 합의 하에 시간을 그때그때 늘리는 경우도 많으나 이런 경우
지나고 보면 시간 LOSS, 불신 발생하기 쉬움

12. 피드백 3 - 점증적인 비즈니스 시나리오 작성/공유
Right product
페르소나, 제품 기획서,
요구사항, 그 외 산출물,
회의내용, 등등등등
개발 기간 내내 피드백 자료,
데모, 인수테스트 시나리오로 활용
시작
완료
feature1 feature2 feature3
feature4 feature5 feature6 feature7
feature8 feature9
Sprint 1.. Sprint 2..
Sprint 3
Sprint ...
시작
완료...
스프린트 초기부터 점증적으로 전체 워크플로우 테스트 시나리오(도식) 작성/공유
초안 작성 및 스프린트 진행에 따라 점증적으로 상세화

13. #사례. 이해와 이해를 공유하기 위한 수단 - 도식화 등
Right product?
초기 요건 검토 - “고객을 공부해 보자”
초기 요건 검토 - “요건을 연구해 보자”
“이번 스프린트 구현 내용을 공부해 보자”
“전체 Product에 맞는 결과일까? 같이
생각해 보자”
_
전체
Product
이번
스프
린트
제품과 고객에 대한 스터디, 스터디, 스터디...

14. #경험. 점증적인 비즈니스 시나리오 작성/공유
Good pattern
Bad pattern
. 도식이 텍스트보다는 공유, 유지/보수가 용이
. 매 스프린트별로 Product Owner 리뷰 효과
. 팀 전체가 제품에 대해 이해 도움 (나무도 보고, 숲도 보고)
. 팀에 잘 공유된 비즈니스 테스트 시나리오 작성 가능
. 팀원 모두가 나무만 생각하고 숲은 잊어버림
. 테스터들의 반발 - ‘전체 흐름은 분석자만 안다!!’
<- 공유와 피드백을 이끌어 내는 것이 핵심
. 도식보다는 텍스트를, 핵심 보다는 상세 절차 나열을 선호
-> 유지보수가 어려움
. 테스터 혼자만의 역할로 간주
. 문서화가 중요시되어 결국에는 핵심이 빠진 일괄 문서 작성

15. 피드백 4 - 코드 레벨 피드백(코드 리뷰, Pair-programming)
Product right!!
코드 리뷰…
하면 좋은 줄은 알겠는데, 언제, 어디서, 누구껄, 어떻게할까…
☞ 테스터가 별도 정보를 기반으로 사전에 대상, 내용, 참석 대상,
방법 등을 정하여 수행
오프라인
세션
1:1
온라인
코드 정적 검사 툴 실행&사전
코드 리뷰 후
테스트 코드 리뷰 후
코드 레벨에서 테스트 커버리지
검토 후
Pair-programming
주로 개발 코드에 대응하는 테스트 코드 작성을 pair로 수행
☞ 테스트 코드 작성 가이드 효과
☞ 테스트 관점으로 개발코드 리뷰, 리팩토링

16. 피드백 5 - 테스트 자동화
Regression testing
“테스트 vs 자동화” 끝나지 않는 논란. 대신 개발과 DevOps 관점에서 ‘빠른 피드백’을 줄 수 있는
( 테스트 자동화 피라미드 기반의 수행 전략 수립 )
가용한 테스트 리소스, 역량, 아키텍처, 비즈니스 중요도
등을 반영하여 자동화 전략 수립
http://www.testingreferences.com/here_be_pyramids.php
http://www.symbio.com/solutions/quality-assurance/test-automation/
. GUI 테스트 자동화 : 느리고, 변경이 심하고… X
. API 테스트 자동화 : 테스트 영역에서 개발과 동시에 작성,수행 O
. 단위 테스트 자동화 : 개발 영역에서 ‘당연하게’ 가이드함 X

17. #사례. REST API 테스트 자동화
(0) 많이 알려진 ‘좋은 REST API 설계’ 팁 가이드
(1) API 스펙에 대한 리뷰와 피드백
(2) 테스트 설계
(3) SOAPUI, Postman, Rest-assured 등의 툴을 이용한 테스트 스크립트 작성
(4) 테스트와 결함 공유 (디버깅 지원)

18. #경험. 테스트 자동화
Good pattern
Bad pattern
. 자동화에 대한 개념 공감대 확산 - “하던 (수동)테스트를 자동화하라”
. 자동화된 테스트가 진짜 ‘수정에 대한 보험’으로 활용
. 초반 러닝커브만 지나고 나면 활용 포인트는 다양함(API 테스트를 디버깅 용도로도)
. (기타) 스프린트 중간에 테스터의 역할로 잘 채워주는 효과
. 테스트 자동화 자체가 목적이 아니라 방법. 목적을 잃어버린… 자동화
. 자동화 구축이 끝이 아니라 시작. 운영/모니터링 방안은 개발 시작부터 수립
. 상위 관리자들의 ‘멋진 자동화’에 대한 개입, 홍보 요청

19. 피드백 6 - 테스트 수행, 리뷰/회고에서의 피드백
지표를 통한 피드백
(예) 스프린트 종료 D-n일전 스토리 개발완료 추이
(예) 스토리별 (실제) Done 추이(1회 테스트, 2회 테스트, 3회 이상 등)
개선
팀원의 한명으로 회고에 능동적으로 참여
“PO와 개발자 사이에 오해가 있었어서, ~~ 했는데 다음에는 ~~하면 좋을 것
같다”
“개발 완료와 테스트 요청을 너무 막바지에 해서 종료를 못했다”
“스프린트 막판에 UI 변경이 많이 발생해서 힘들었다”
DEV PO
DEV
DEV
Tester
이번 스프린트에서는...
이번 스프린트에서는...
이번...
이번...
이번...

20. #사례. 테스트 수행, 리뷰/회고에서의 피드백
To do In progress Test request Resolved Done
A Dev
Tester
(SDET)
...
Story3
Story5
Story4
Story2
Story1
Story6
Story6
테스트 단계가 포함된 Workflow 예시
To do
스프린트 종료 -n일전 테스트 요청 현황 예
D-4 D-3 D-2 D-1 D-0 0회 1회 2회 3회~
스토리별 재테스트 횟수 예
테스터가 포함된 회고의 예

21. #경험. 테스트 수행, 리뷰/회고에서의 피드백
Good pattern
Bad pattern
. 테스터도 같은 목표를 가진 팀원이라는 의식 정착
. 테스트 수행 간의 이슈가 공유되고 바로 해결
. 품질, 테스트는 남의 일이라는 생각이 조금쯤은 개선
. 다양한 역할자가 모인 팀에서 발생할 수 있는 문제점들
. ‘Done’ = “테스트까지 완료”를 100% 인식시킬수 있는 날이 올까?
(80%쯤은 잘 되는 듯?)

22. 결론. 세 친구들(3-Amigos)
Destructor vs Constructor
개발팀
Developer(s)
Business Analyst,
Product Owner
Tester(s)
빵야
빵야
빵야
(수상소감) 저희 팀이 이 상을
받게되어,너무 감사하고..영광이구요
저희 개발할 때 많이 도와주신
테스트팀에도 감사드립니다.
현실은... 테스트팀의 평가는 개발완료 후 제품에 얼마나
(결함갯수) 지적을 많이했고, 이슈화 했는지...

23. 숨겨진 결론.
Destructor or Constructor ?
애자일을 위한 테스트? No!
테스트를 위한 애자일!!!
Early Testing,
Shift-left-testing
Defect Prevention > Detection
Making the RIGHT things vs(and)
Making things RIGHT
Regression testing,
Practical Test Automation

24. Reference. 애자일 테스팅”, 리사 크리스핀, 자넷 그레고리(정보문화사)
애자일 테스터
: 자신이 속한 팀이 고객이 요구하는 높은 품질의 제품 제공을 보장하는 일을 한다.
테스터는 기술적인 구현의 복잡성뿐만 아니라 사용자 관점 이해라는 두 영역
모두에 발을 담그고 있다
애자일 테스터의 원칙
1) 끊임없는 피드백 제공
2) 고객 가치 창출
3) 직접적인 의사소통
4) 용기
5) 단순함 지향
6) 지속적인 개선 실행
7) 변화에 대응
8) 자기 조직화
9) 사람 중심
10) 즐기기

25. 감사합니다.

26. 별첨1. 애자일 테스트 운용 방식 다른 사례(1/2)
Testing in Agile Development Projects” by Stuart Reid

27. 별첨1. 애자일 테스트 운용 방식 다른 사례(2/2)
구분 1) Whole Team 테스트
2) 분리되고 병렬적인
테스트 수행
3) 비정기적 Full
테스트 스프린트
4) 뒷 단계에 팀 통합된
테스트 스프린트
설명 테스트 인력이 같은 스크럼 팀, 스프린트
내에서 테스트를 수행
개발팀과 테스트 인력이 팀은 분리되어
병렬로 스프린트 테스트 수행
(*도식참조)
2-3번의 개발 스프린트 이후 개발자,
테스트 인력이 모두 같이 테스트하는
테스트 스프린트 운용(*도식참조)
3)번 유형과 유사하나 한 개의
스크럼 팀이 아닌 여러 스크럼
팀의 내용 통합해서 수행
장점 - 개발자와 테스터간에 직접적이고
즉각적인 의사소통 가능
- 개발자와 테스터가 동일한 품질 목표를
공유
- 환경적 제약사항 등으로 필요해 질 수
있음
- 실제적으로는 종종 이런 형태의
테스트를 수행 함
- 환경적 제약사항 등으로 필요해 질
수 있다
- 정기적 인수 테스트를 조직하기
어려울 때 적용 가능하다.
- 여러 스프린트 프로젝트를 통합하는
것이 가능하다
(좌동)
제약
사항
- 각 팀별로 배치할 테스트 인력 부족
- 개발자와 가깝게 협업하기 위해 더
많은 역량이 필요
- 덜 즉각적인 형태로 피드백이 전달
- 기존 개발분의 테스트와 신규 개발이
동시에 이루어 지기 때문에 버전
관리가 복잡해 짐
- 기존 개발분의 디버깅이 얼마나 될지
알 수 없기 때문에 Planning이 어려워
짐
- 개발자와 테스터 간의 의사소통
비용이 커진다
- 더 즉각적이지 못한 형태로 고객의
추가 요구사항 발생
- 개발 스프린트에서는 테스터가 할
일이, 테스트 스프린트에서는
개발자가 할 일이 명확하지 않다
- 2)와 동일
(좌동)