Certified Tester Foundation Level Extension Syllabus Agile Tester (ISTQB 애자일테스터한글실라버스 ) ISTQB CTFL_AT_v.2014_Kr1.0_201505_KSTQB 페이지 1 / 57
Copyright Notice This document may be copied in its entirety, or extracts made, if the source is acknowledged. Copyright (hereinafter called ISTQB ). Foundation Level Extension Agile Tester Working Group: Rex Black (Chair), Bertrand Cornanguer (Vice Chair), Gerry Coleman (Learning Objectives Lead), Debra Friedenberg (Exam Lead), Alon Linetzki (Business Outcomes and Marketing Lead), Tauhida Parveen (Editor), and Leo van der Aalst (Development Lead). Authors: Rex Black, Anders Claesson, Gerry Coleman, Bertrand Cornanguer, Istvan Forgacs, Alon Linetzki, Tilo Linz, Leo van der Aalst, Marie Walsh, and Stephan Weber. Internal Reviewers: Mette Bruhn-Pedersen, Christopher Clements, Alessandro Collino, Debra Friedenberg, Kari Kakkonen, Beata Karpinska, Sammy Kolluru, Jennifer Leger, Thomas Mueller, Tuula Pääkkönen, Meile Posthuma, Gabor Puhalla, Lloyd Roden, Marko Rytkönen, Monika Stoecklein-Olsen, Robert Treffny, Chris Van Bael, and Erik van Veenendaal; 2013-2014. 본 ISTQB 애자일테스터한글실라버스의저작권은 ISTQB 에있습니다. 애자일테스터한글실라버스에 대한모든문의사항은 KSTQB( I info@kstqb.org) 로연락하시면됩니다. 본한글실라버스제작에소중한시간을할애하여번역, 리뷰, 검수, 편집작업을진행하고도움을주신 윤진우님, 송홍진님, 김모세님, 박계홍님, 김희선님, 박준표님, 황상철님, 조현길님, 강성훈님께감사 드립니다. - Korean 페이지 2 / 57
Table of Contents Revision History Table of Contents Acknowledgements 0. Introduction to this Syllabus 0.1 Purpose of this Document 0.2 _ Overview 0.3 _ Examinable Learning Objectives 1. Agile Software Development - 150 mins. 1.1 The Fundamentals of Agile Software Development 1.1.1 Agile Software Development and the Agile Manifesto 1.1.2 Whole-Team Approach 1.1.3 Early and Frequent Feedback 1.2 Aspects of Agile Approaches 1.2.1 Agile Software Development Approaches 1.2.2 Collaborative User Story Creation 1.2.3 Retrospectives 1.2.4 Continuous Integration 1.2.5 Release and Iteration Planning 2. Fundamental Agile Testing Principles, Practices, and Processes 105 mins. 2.1 The Differences between Testing in Traditional and Agile Approaches 2.1.1 Testing and Development Activities 2.1.2 Project Work Products 2.1.3 Test Levels 2.1.4 Testing and Configuration Management 2.1.5 Organizational Options for Independent Testing 2.2 Status of Testing in Agile Projects 2.2.1 Communicating Test Status, Progress, and Product Quality 2.2.2 Managing Regression Risk with Evolving Manual and Automated Test Cases 2.3 Role and Skills of a Tester in an Agile Team 2.3.1 Agile Tester Skills 2.3.2 The Role of a Tester in an Agile Team 3. Agile Testing Methods, Techniques, and Tools 480 mins. 3.1 Agile Testing Methods 3.1.1 Test-Driven Development, Acceptance Test-Driven Development, and Behavior-Driven Development 3.1.2 The Test Pyramid 3.1.3 Testing Quadrants, Test Levels, and Testing Types 3.1.4 The Role of a Tester 3.2 Assessing Quality Risks and Estimating Test Effort 3.2.1 Assessing Quality Risks in Agile Projects 3.2.2 Estimating Testing Effort Based on Content and Risk 3.3 Techniques in Agile Projects 3.3.1 Acceptance Criteria, Adequate Coverage, and Other Information for Testing 3.3.2 Applying Acceptance Test-Driven Development 3.3.3 Functional and Non-Functional Black Box Test Design 3.3.4 Exploratory Testing and Agile Testing 3.4 Tools in Agile Projects 3.4.1 Task Management and Tracking Tools 3.4.2 Communication and Information Sharing Tools 페이지 3 / 57
3.4.3 Software Build and Distribution Tools 3.4.4 Configuration Management Tools 3.4.5 Test Design, Implementation, and Execution Tools 3.4.6 Cloud Computing and Virtualization Tools 4. References 4.1 Standards 4.2 ISTQB Documents 4.3 Books 4.4 Agile Terminology 4.5 Other References 5. Index 페이지 4 / 57
0. Introduction to this Syllabus 0.1 Purpose of this Document This syllabus forms the basis for the Qualification at the Foundation Level for the Agile Tester. The ISTQB provides this syllabus as follows: To National Boards, to translate into their local language and to accredit training providers. National Boards may adapt the syllabus to their particular language needs and modify the references to adapt to their local publications. To Exam Boards, to derive examination questions in their local language adapted to the learning objectives for each syllabus. To training providers, to produce courseware and determine appropriate teaching methods. To certification candidates, to prepare for the exam (as part of a training course or independently). To the international software and systems engineering community, to advance the profession of software and systems testing, and as a basis for books and articles. The ISTQB may allow other entities to use this syllabus for other purposes, provided they seek and obtain prior written permission. 0.2 Overview The Foundation Level Agile Tester Overview document [ISTQB_FA_OVIEW] includes the following information: Business Outcomes for the syllabus Summary for the syllabus Relationships among the syllabi Description of cognitive levels (K-levels) Appendices 0.3 Examinable Learning Objectives The Learning Objectives support the Business Outcomes and are used to create the examination for achieving the Certified Tester Foundation Level Agile Tester Certification. In general, all parts of this syllabus are examinable at a K1 level. That is, the candidate will recognize, remember, and recall a term or concept. The specific learning objectives at K1, K2, and K3 levels are shown at the beginning of the pertinent chapter. 페이지 5 / 57
1. 애자일소프트웨어개발 - 150 분 키워드 애자일선언, 애자일소프트웨어개발, 점진적개발모델, 반복적개발모델, 소프트웨어수명주기, 테스트 자동화, 테스트베이시스, 테스트주도개발, 테스트오라클, 사용자스토리 학습목표 1.1 애자일소프트웨어개발기본 FA-1.1.1 (K1) 애자일선언 (Agile Manifesto) 을기반으로하는애자일소프트웨어개발의기본 개념을상기한다 FA-1.1.2 FA-1.1.3 (K2) 전체팀접근법의장점을이해한다 (K2) 빠르고잦은피드백의장점을이해한다 1.2 애자일접근법 FA-1.2.1 FA-1.2.2 FA-1.2.3 FA-1.2.4 FA-1.2.5 (K1) 애자일소프트웨어개발접근법을상기한다 (K3) 개발자와업무대표자 * 가테스트할사용자스토리를함께작성한다 (K2) 회고를통해애자일프로젝트를개선할수있음을이해한다 (K2) 지속적인통합의목적과방법을이해한다 (K1) 반복주기 (Iteration) 와출시 (Release) 계획의차이를알고, 각각의활동에테스터가 어떻게기여하는지이해한다 * 업무대표자 (Business representatives) 역할에대한설명은 1 장마지막페이지참조 페이지 6 / 57
1.1 애자일소프트웨어개발기본 애자일프로젝트에참여하는테스터는전통적인프로젝트와는다른방식으로일을하게된다. 테스터는애자일프로젝트를뒷받침하는가치와원칙을이해하고개발자, 업무대표자와함께전체팀의일원임을깨달아야한다. 애자일프로젝트의멤버는서로자주소통해야하며, 이를통해결함을조기에제거하고제품의품질을향상시킬수있다. 1.1.1 애자일소프트웨어개발과애자일선언 2001 년에널리사용되던경량소프트웨어개발접근법을대표하는사람들이모여애자일소프트웨어개발을위한선언또는애자일선언으로알려진공통적인가치와원칙에동의하였다. 애자일선언은궁극적으로추구하는가치를다음과같은 4 가지선언으로나타냈다. 프로세스와도구보다개인과그개인들간의상호작용을중시한다 완벽한문서보다작동하는소프트웨어를중시한다 계약의협상보다고객과의협업을중시한다 계획을고수하기보다변화에대한대응을중시한다 이말은, 왼쪽에있는것들도가치가있지만, 우리는오른쪽에있는것들에더높은가치를둔다는 뜻이다. 개인과상호작용 애자일개발은매우인간중심적이다. 팀은소프트웨어를만드는사람들로구성되어있으며, 도구나 프로세스에의존하기보다지속적인의사소통과상호작용을통해더욱효과적으로일할수있다. 작동하는소프트웨어고객의입장에서보면지나치게자세한설명서보다작동하는소프트웨어가훨씬더유용하고가치있으며, 이를통해개발팀은신속한피드백을제공받을수있는기회를얻는다. 비록기능이축소되어있으나제대로작동하는소프트웨어는개발수명주기초기에도완전하게동작하므로애자일개발은타임투마켓전략에이점을제공할수있다. 따라서애자일개발은문제와솔루션이불분명하거나새로운영역에서혁신을원하는등의급격하게변하는비즈니스환경에특히유용하다. 페이지 7 / 57
고객과의협력고객은그들이필요로하는시스템을명세화할때큰어려움을겪는다. 고객과직접협력하여함께일하는것은고객의요구사항을정확하게이해할가능성을향상시킨다. 고객과의계약도중요하지만아울러그들과함께정기적으로긴밀하게협력해서작업하는것이프로젝트의성공가능성을더욱높여준다. 변화대응변화는소프트웨어프로젝트에서불가피하다. 사업운영환경, 법률, 경쟁사의활동, 기술진보및다른여러요인들은프로젝트와프로젝트의목적에중요한영향을미칠수있다. 이러한요소들은개발과정에서수용되어야한다. 이와같이변화를포용하는작업관행에서의유연성을갖는것은단순히계획을엄격하게준수하는것보다더중요하다. 원칙 애자일선언의핵심적인가치는다음 12 가지원칙에잘나타나있다 : 우리의최우선순위는고객을만족시키는것이며, 이를위해조기에지속적으로가치있는소프트웨어를전달한다 비록개발의후반부일지라도요구사항변경을환영하라. 애자일프로세스들은변화를통해고객의경쟁력에도움을준다 작동하는소프트웨어를자주전달하라. 2 주 ~ 2 개월사이에서전달하되그간격이짧을수록좋다 비즈니스쪽의사람들과개발자들은프로젝트전체에걸쳐날마다함께일해야한다 동기가부여된개인들중심으로프로젝트를구성하라. 그들이필요로하는환경과지원을주고그들이일을끝내리라고신뢰하라 개발팀외부, 혹은개발팀내에서정보를가장효율적이고효과적으로전달하는방법은직접얼굴을맞대고대화하는것이다 작동하는소프트웨어를태스크진척의최우선지표로삼는다 애자일프로세스들은지속가능한개발을장려한다. 스폰서, 개발자, 사용자는일정한속도를계속유지할수있어야한다 기술적탁월성과좋은설계에대한지속적관심이기민함을높인다 단순성이, 즉, 안하는일의양을최대화하는기술이창발 ( 創發 ) 한다 최고의아키텍처, 요구사항, 설계는자기조직적인팀으로부터시작한다 팀은정기적으로어떻게더효과적이될지숙고하고, 이에따라팀의행동을조율하고조정한다 페이지 8 / 57
다양한애자일접근법들이이러한가치와원칙을실행으로옮길수있는규정된실천방안을제공한다. 1.1.2 전체팀접근법 전체팀접근법이란프로젝트의성공을보장할수있는지식과기술을가진모든사람이필수적으로팀에포함되어야함을의미한다. 팀에는고객을대표할수있는사람과고객이외의비즈니스이해관계자들이포함되어이들이함께제품의기능을결정한다. 팀은상대적으로작게구성되어야하는데, 관찰에따르면성공적인팀은주로적게는 3 명에서많게는 9 명의인원으로구성된다. 같은공간을공유하는것은의사소통과상호작용을강하게하므로전체팀이동일한작업공간을공유하는것이이상적이다. 전체팀접근법을효과적으로지원하기위한방법으로일일스탠드업미팅 (2.2.1 절참조 ) 을실시하는데, 이미팅에는팀의모든멤버가참여하여현재태스크진척을공유하고, 태스크진행에장애가되는모든 요소들을확인한다. 작업진행상황을공유하고모든문제점을공유하는일일스탠드업미팅 (2.2.1 절참조 ) 을통해전체팀 접근법은지원을받는다. 전체팀접근법은보다효과적이고효율적으로팀의역동성을촉진한다. 제품개발에전체팀접근법을사용하는것은애자일개발의주요장점중하나이다. 전체팀접근법을 통해다음과같은이익을얻을수있다 : 팀내의사소통과협력을강화한다 팀내의다양한스킬셋을활용해프로젝트에기여할수있다 제품의품질을모두의책임으로인식한다 애자일프로젝트에서품질에대한책임은전체팀에게있다. 전체팀접근법의핵심은개발과정의모든단계에테스터, 개발자, 업무대표자가함께참여해서일한다는것이다. 테스터는원하는품질수준에최대한도달하기위해개발자와업무대표자모두와긴밀하게일을해야한다. 이를위해업무대표자가적절한인수테스트를만들수있도록지원하고협력하며, 개발자들이테스트전략에동의할수있도록협업해야한다. 또한테스트자동화접근방법을결정하기도해야한다. 이렇게함으로써테스터는다른팀멤버에게테스트지식을전달하고확장시키며, 제품개발에영향을미칠수있다. 전체팀은제품기능을제시하고, 분석하거나추정하는모든협의나회의에참여한다. 모든기능토론에 테스터, 개발자, 업무대표자가참여하는개념을 3 의힘 (The Power of Three) 이라고한다 [Crispin08]. 페이지 9 / 57
1.1.3 조기에지속적으로얻는피드백 애자일프로젝트는반복주기를가능한짧게설정하여개발수명주기전반에걸쳐프로젝트팀이제품품질에대한피드백을조기에지속적으로받을수있게한다. 이를위한방법의한가지로지속적인통합을사용할수있다 (1.2.4 절참조 ). 순차개발접근법을사용하는경우, 고객은프로젝트가거의완료된단계가되어서야제품을확인할수있으며, 이시점에고객에게문제점이발생하는경우개발팀에게이를해결할충분한시간이주어지지않게된다. 프로젝트가진행됨에따라지속적으로고객의피드백을받음으로써애자일팀은제품개발프로세스에가장새로운변화를통합할수있다. 조기에지속적으로얻는피드백을통해팀은가장높은비즈니스가치를갖는기능이나위험에집중하고, 이를또한가장먼저고객에게전달할수있게된다. 아울러팀의역량즉, 우리가스프린트나반복주기동안얼마나많은일을할수있는가? 우리가더빠르게일을하는데도움을줄수있는것은무엇인가? 우리가빠르게일을하는데방해가되는요소는무엇인가? 등을모든사람에게투명하게내보임으로써팀을더잘관리하는데도움을준다. 조기에얻는지속적인피드백을통해얻을수있는장점은다음과같다. 요구사항에대한잘못된이해를방지할수있다. 요구사항을정확하기이해하지못해서발생하는결함은개발수명주기막바지까지도발견하지못할수있으며이를수정하는데는더많은비용이소요된다. 고객의기능요구를명확히하여제품개발초기에고객이사용해볼수있도록한다. 이를통해고객이원하는것을제품에더명확히반영할수있다. ( 지속적인통합을통해 ) 품질문제를조기에발견하고분리시키며해결할수있다. 애자일팀의생산성및배포능력과관련된정보들을전달한다. 프로젝트를일관성있게추진하도록한다. 1.2 애자일접근법 조직에따라적용할수있는애자일접근법은다양하다. 대부분의애자일조직에서사용하는실천방법으로는사용자스토리도출, 회고, 지속적인통합, 개별반복주기및전체출시계획등이있다. 이섹션에서는일부애자일접근법에대해설명한다. 페이지 10 / 57
1.2.1 애자일소프트웨어개발접근법 많은애자일접근법들이존재하며, 각각의접근법들은서로다른방법으로애자일선언의가치와원칙들을구현한다. 이실라버스에서는애자일방식을대표하는익스트림프로그래밍 (XP), 스크럼과칸반 (Kanban) 세가지접근법을소개한다. 익스트림프로그래밍 켄트벡이처음시작한익스트림프로그래밍은애자일접근법중하나로소프트웨어개발을특정한가치, 원칙및개발실천법으로설명한다. XP 는다섯가지가치즉, 의사소통, 단순성, 피드백, 용기및존중을통해개발을가이드한다. XP 는또한추가적인가이드라인으로일련의원칙들을제공하는데, 그원칙들은다음과같다 : 인간성, 경제성, 상호이익, 자기유사성, 개선, 다양성, 반성, 몰입, 기회, 중복, 실패, 품질, 잔걸음그리고수용된 책임감 XP 는 13 가지실천법을제시한다 : 함께앉기, 전체팀, 정보를제공하는작업공간, 열정적인작업, 짝 프로그래밍, 스토리, 주단위주기, 사분기주기, 여유, 10 분빌드, 지속적인통합, 테스트우선 프로그래밍, 점진적설계 오늘날사용되는애자일소프트웨어개발방식의대부분은 XP 및 XP 의가치와원칙에영향을받았다. 예를들어, 애자일팀은스크럼에 XP 실천법을자주포함시킨다. 스크럼 Scrum 스크럼은애자일관리프레임워크의하나로다음구성요소와실천법들을포함하고있다 [Schwaber01]: 스프린트 : 스크럼은프로젝트를고정된길이 ( 보통 2~4 주 ) 의주기로나눈다. 이주기를스프린트라고부른다. 증분된산출물 : 모든스프린트는잠재적으로출시 / 배포가능한제품 ( 점진적개발 ) 을산출한다. 제품백로그 : 제품오너는계획된제품아이템의우선순위목록 ( 제품백로그 ) 을관리하며, 이목록은스프린트가진행됨에따라계속진화한다 ( 백로그정제 ). 스프린트백로그 : 스프린트시작시점에스크럼팀은제품백로그에서우선순위가가장높은항목집합 ( 스프린트백로그 ) 을선택한다. 제품오너의강제에의하지않고스크럼팀에서스프린트내에구현가능한항목을선택하므로밀기 (Push) 원리가아닌당김 (Pull) 원리를따른다. 페이지 11 / 57
완료의정의 : 각스프린트완료시점에서잠정적으로출시가능한제품이산출되었는지를확인하기위해, 스크럼팀은적절한스프린트종료기준을협의하고정의한다. 종료기준논의를통해애자일팀은백로그아이템과제품요구사항을더깊이이해하게된다. 타임박싱 : 스프린트를진행하는애자일팀이해당스프린트내에서완료할수있을것으로예상하는작업, 요구사항혹은기능들만이해당스프린트백로그의일부가된다. 만약개발팀이스프린트내에서작업을완료할수없다면, 관련제품의기능은스프린트에서제거되고작업은다시제품백로그로이동된다. 타임박싱은다른상황의작업에도적용된다. ( 예 : 회의시작및종료시간 ) 투명성 : 개발팀은일일스크럼이라불리는회의에서매일스프린트상태를공유한다. 일일스크럼회의를통해테스트결과를포함해현재스프린트의내용과진척을팀, 관리자및모든관련담당자에게공유한다. 스크럼에서는다음과같은 3 가지역할을정의한다 : 스크럼마스터 : 스크럼원칙과규칙이구현되고준수되게한다. 팀이원칙과규칙을따르지못하게하는모든요소들, 자원문제또는기타장애물을해결한다. 이사람은팀리더가아닌코치이다. 제품오너 : 고객을대표하고제품백로그를생성, 유지하고우선순위를정한다. 이사람은팀리더가아니다. 개발팀 : 제품을개발하고테스트한다. 개발팀은팀리더없이스스로결정하는자기조직화된팀이다. 또한이팀은복합기능팀이다 (2.3.2 절과 3.1.4 절참조 ). XP 와달리스크럼은특정소프트웨어개발기술 ( 예 : 테스트우선프로그래밍 ) 을강요하지않는다. 또한 스크럼은스크럼프로젝트에서테스트가어떻게수행되어야하는지에대한지침을제공하지않는다. 칸반 Kanban 칸반은관리접근법의하나로애자일프로젝트에서종종사용된다. 일반적인목적은가치사슬내의태스크흐름을시각화하고최적화하는것이다. 칸반은세가지도구를사용한다 [Linz14]: 칸반보드 : 관리되어야할가치사슬은칸반보드를통해가시화된다. 각열은관련된일련의활동단계 ( 예 : 개발또는테스트 ) 를보여준다. 제작되는아아템이나처리할태스크는왼쪽에서오른쪽으로단계별로이동하는카드로표현된다. 진행작업제한 : 병렬로동시에실행되는태스크의양은엄격히제한된다. 단계및보드전체에서허용가능한카드의최대수를제어하는방식을사용한다. 작업자는단계별로여유능력이있을때마다이전단계의카드를가져온다. 페이지 12 / 57
리드타임 : 칸반은완전한가치흐름에대해 ( 평균 ) 리드타임을최소화함으로써작업의연속적인 흐름을최적화하기위해사용된다. 칸반과스크럼은일부유사성을가진다. 두프레임워크는진행중인작업의시각화 ( 예 : 공동의 화이트보드 ) 를통해작업내용과진척상황에대한투명성을제공한다. 예약되지않은작업은백로그에 대기하고있다가새로운공간 ( 생산능력 ) 을사용할수있을때칸반보드로이동한다. 칸반에서의반복주기나스프린트는선택사항이다. 칸반프로세스에서는산출물을출시단위가아니라 항목별로릴리즈할수있다. 따라서동기화메커니즘인타임박싱은칸반에서선택적으로적용된다. 반면스프린트내에서모든태스크를동기화하는스크럼에서는타임박싱이필수적으로적용된다. 1.2.2 사용자스토리공동작업 충분치않은명세는프로젝트의실패를야기하는주요한원인이다. 사용자의실제요구사항에대한스스로의통찰력부족, 대상시스템에대한전체적인비전의부재, 중복되거나모순되는기능및기타커뮤니케이션이슈로명세와관련된문제들이발생할수있다. 애자일개발환경에서사용자스토리는개발자, 테스터및업무대표자관점의요구사항들을모두수집하여작성한다. 기능의비전공유는순차적개발모델에서는요구사항이기록된후공식리뷰를통해수행되지만, 애자일개발환경에서는요구사항이작성되는동안비공식적인리뷰를통해수행된다. 사용자스토리는기능및비기능특성을모두해결해야한다. 각각의사용자스토리는이러한특성에대한인수기준을가지고있어야한다. 이러한조건은업무대표자, 개발자와테스터간의협의에의해정의되어야한다. 인수기준은개발자와테스터에게기능의확장된비전을제공하고업무대표자는유효성을검사하기위한기준을제공한다. 애자일팀은인수기준이충족되었을때작업이완료된것으로간주한다. 일반적으로테스터가다른이해관계자들과다른고유한관점, 가령, 누락된세부사항및비기능적요구사항식별등을통해사용자스토리를향상시킨다. 또한테스터는업무대표자에게사용자스토리와관련된개방형질문을하고, 테스트방법을제안하며인수조건을확인함으로써사용자스토리향상에기여하기도한다. 사용자스토리의공동저자는브레인스토밍과마인드매핑등의기술을사용할수있다. 테스터는 INVEST 기법을사용할수있다 [INVEST]: 독립적이다 협상가능하다 사용자와고객에게가치가있다 페이지 13 / 57
추정가능하다 작다 테스트가능하다 3C 개념 [Jeffries00] 에따르면사용자스토리는다음세가지요소의결합이다 : 카드 : 카드는사용자스토리를기록한물리적매체로, 요구사항, 요구사항의중요도, 예상되는개발및테스트기간, 인수기준을기록한다. 상세설명은향후제품백로그에사용되므로정확하게기술해야한다. 대화 : 대화는소프트웨어를어떻게사용하는지에대해설명한다. 대화는문서또는구두로할수있다. 개발자와업무대표자와다른관점을갖는테스터 [ISTQB_FL_SYL] 는생각, 의견, 경험의교환에있어가치있는의견을제공한다. 대화는출시계획단계에서시작하여스토리의일정이추정될때까지계속된다. 확인 : 대화에서논의된인수기준을사용해스토리가완료되었는지확인한다. 이러한인수기준은여러사용자스토리에동시에적용될수도있다. 인수기준만족여부를확인하기위해긍정적테스트와부정적테스트를모두사용해야한다. 확인과정에는다양한참가자가테스터의역할을수행한다. 참가자에는개발자는물론성능, 보안, 상호운용성및다른품질특성에대한전문가들도포함된다. 정의된인수기준이테스트되고만족되었음이증명되면해당스토리는완료된것으로확인한다. 애자일팀은다양한방법으로사용자스토리를작성한다. 사용자스토리를문서화하는방법에관계없이 문서는간결하고충분히필요한내용이들어가있어야한다. 1.2.3 회고 애자일개발에서회고는각반복주기의가장마지막에수행하는회의로 이번반복주기에서무엇이성공적이었는지, 다음반복주기에서무엇을향상시킬수있는지, 어떻게성공을유지하고개선사항을통합할수있을지 에대해논의한다. 주로프로세스, 사람, 조직, 관계, 도구와같은주제를다룬다. 적절한후속활동을이끌어내는회고모임은조직의개발및테스트의지속적인개선에매우중요하다. 회고를통해테스트와연관된개선관련의사결정을할수있으며여기에는테스트효과성, 테스트생산성, 테스트케이스품질및팀만족여부등이포함된다. 또한응용프로그램, 사용자스토리, 특성또는시스템인터페이스의테스트용이성을해결할수있다. 결함근본원인분석을통해테스팅과개발의개선을추진할수있으며, 일반적으로팀은반복주기를거듭하며조금씩개선을진행함으로써꾸준한속도로개선을수행할수있게된다. 페이지 14 / 57
회고의시기와구성은애자일기법에따라달라진다. 중재자 (Facilitator) 가회의를구성하고진행하는 동안업무대표자및팀참가자는각회고에참석한다. 어떤경우에는팀미팅에다른참가자를초대할수 있다. 테스터는회고에서중요한역할을수행한다. 테스터는팀에소속되어있으며 ISTQB 실라버스 1.5 절에언급된바와같이그만의독특한관점을팀에제공한다. 모든스프린트에서테스팅을수행하고프로젝트의성공에실질적으로기여해야한다. 테스터를포함한모든팀구성원은테스팅을포함한모든활동에입력정보를제공할수있다. 회고는상호신뢰를특징으로하는전문적인환경에서수행되어야한다. 성공적인회고를위해서는다른 리뷰들과동일한특성들을참고해야하며, 이런특성에관한내용은 ISTQB Foundation 실라버스 3.2 절을 참조한다. 1.2.4 지속적인통합 증분산출물을전달하기위해서모든스프린트가완료되는시점에는신뢰할수있고제대로작동하는통합된소프트웨어가완성되어야한다. 지속적인통합은적어도하루에한번소프트웨어의모든변경사항을통합하고정기적으로변경된모든구성요소를통합함으로써이문제를해결한다. 형상관리, 편집, 소프트웨어빌드, 배포및테스트를하나의자동화된반복적인프로세스로통합한다. 개발자는자신의작업을지속적으로통합하고, 지속적으로구축하고, 지속적으로테스트하기때문에코드의결함을더빨리발견할수있다. 개발자가코딩, 디버깅후공유소스코드저장소에코드를체크인하고나면지속적인통합프로세스는다음과같은활동을자동으로수행한다 : 정적코드분석 : 정적코드분석을실행하고결과를보고한다 컴파일 : 코드를컴파일하고링크를걸어실행파일을생성한다 단위테스트 : 단위테스트를실행하고코드커버리지를확인하며, 테스트결과를보고한다 배포 : 테스트환경에빌드를설치한다 통합테스트 : 통합테스트실행과경과를보고한다 보고 ( 현황판 ): 모든활동의상태는오픈된장소에공개하거나, 해당팀에메일을보내상태를공유한다 자동화빌드및테스트프로세스가매일실행되고초기에빠르게통합에러를발견한다. 지속적인통합 환경에서애자일테스터는자동화된테스트를정기적으로수행하며 ( 자동화테스트의어느부분은 지속적인통합환경에서자체적으로제공하기도한다 ), 코드품질에대한즉각적인피드백을팀에제공할 페이지 15 / 57
수있다. 이러한테스트결과는특히자동화된보고서가프로세스에통합되어있을때모든팀구성원에게공개된다. 반복주기가진행되는동안자동화된리그레션테스트를지속적으로수행할수있고, 바람직하게자동화된리그레션테스트는이전반복주기에서전달된사용자스토리를포함하여가능한많은기능을포함한다. 자동화된리그레션테스트에서좋은커버리지는큰규모의통합시스템을구축하고테스트를수행하는데도움이된다. 리그레션테스트를자동화함으로써애자일테스터들은새로운기능과변경된구현사항에대한수동테스트및결함수정확인테스트에집중할수있다. 일반적으로지속적인통합을사용하는조직은테스트를자동화하는것뿐만아니라지속적인품질관리를위해빌드도구를사용한다. 즉, 단위및통합테스트를실행하는것외에도이러한도구는추가적인정적및동적테스트, 성능측정및프로파일링, 소스코드문서화를실행하고수동품질보증프로세스를용이하게할수있다. 이러한응용프로그램의지속적인품질관리는제품의품질을향상시킬뿐만아니라모든개발의완료후에야품질관리를적용하는전통적인방법을대체하여제품출시에걸리는시간을단축시킨다. 빌드도구는자동배포도구에연결하여사용할수있다. 자동배포도구들은지속적인통합서버혹은빌드서버에서적절한빌드산출물을복사하여, 하나혹은그이상의개발환경, 테스트환경, 스테이징환경혹은실제사용환경에배포한다. 이것은해당환경에서출시를담당하는전문직원또는프로그래머와관련된오류및지연을줄일수있게해준다. 지속적인통합을통해얻을수있는이점은다음과같다 : 문제와변경관련충돌의조기발견과근본적인원인분석이가능하다 개발팀에코드가작동하는지에대한정기적인피드백을제공한다 개발중인소프트웨어버전당일내에테스트중인버전을유지한다 코드베이스가변경되는즉시 ( 자동화된 ) 재테스팅을수행함으로써개발자의코드리팩토링과관련된리그레션리스크를줄일수있다 탄탄한기초를기반 ( 빌드및테스트가정상수행되지않으면해당이슈를먼저해결해야한다 ) 으로코드개발작업에대한확신을제공한다 제품의추가개발에대한완료여부를시각화함 ( 테스트주도개발방법론을도입한경우, 먼저작성된테스트코드를지속적인통합환경에서수행하게된다. 자동화된단위테스트가모두성공할때까지제품코드를작성하게된다 ) 으로써개발자와테스터를격려한다 빅뱅통합방법에따른일정상의리스크를제거한다 실행가능한소프트웨어를지속적으로적용함으로써이소프트웨어는스프린트테스팅, 데모, 교육목적등으로활용할수있다 반복적인수동테스트작업을줄일수있다 페이지 16 / 57
품질및테스트를개선하기위해내린결정에대한빠른피드백을제공한다. 그러나, 지속적인통합에도다음과같은리스크와어려움이존재한다 : 지속적인통합도구가도입되고잘유지되어야한다 지속적인통합프로세스를정의하고설정해야한다 테스트자동화는추가적인자원을필요로하며설정이복잡할수있다 자동화된테스트의장점을활용하기위해서는철저한테스트커버리지를만족시켜야한다 팀이단위테스트에지나치게의존한나머지시스템 / 인수테스팅을불충분하게수행할수있다 지속적인통합환경을잘구축하기위해서는테스팅도구, 빌드프로세스자동화도구, 형상관리도구 등을함께사용해야한다. 1.2.5 출시와반복주기계획 ISTQB Foundation 실라버스 [ISTQB_FL_SYL] 에서언급한바와같이, 계획은지속적인활동이며, 이것은애자일수명주기에서도마찬가지이다. 애자일라이프사이클의경우계획활동에는출시계획과반복주기계획두가지가있다. 출시계획은제품의출시를계획하며, 종종프로젝트시작몇개월전에수립된다. 출시계획단계에서는새로운백로그를정의하거나기존백로그를재정의하는활동을실행하며이과정에서작은사용자스토리들을모아큰사용자스토리로만들기도한다. 출시계획은모든반복주기에대한테스트접근법과테스트계획을위한기초를제공한다. 출시계획은상위레벨수준의계획이다. 출시계획에서업무대표자는팀과공동으로출시에대한사용자스토리를설정하고우선순위를정한다. (1.2.2 절참조 ) 이사용자스토리에기반하여프로젝트리스크와품질리스크를식별하고상위레벨 수준에서공수를추정한다 (3.2 절참조 ). 테스터도출시계획에참여하며특히다음과같은활동을통해계획에기여할수있다 : 테스트가능한사용자스토리를정의한다. 여기에는인수기준도포함된다 프로젝트리스크및품질리스크분석에참여한다 사용자스토리와관련된테스트공수를추정한다 필요한테스트레벨을정의한다 출시에대한테스팅을계획한다 페이지 17 / 57
출시계획이완료되면첫번째반복주기를위한계획을수립한다. 반복주기계획은하나의반복주기의 종료조건과반복주기백로그에관한내용을다룬다. 반복주기계획에서팀은출시백로그로부터사용자스토리를선택하고사용자스토리를상세화하고, 사용자스토리를위한리스크분석을실행하고, 각사용자스토리에필요한작업을추정한다. 선택한사용자스토리가너무모호하여명확화할수없는경우, 애자일팀은해당스토리를거부하고우선순위에따라다음사용자스토리를선택할수있다. 업무대표자는각스토리에대한팀의질문에응답해야하며, 이를통해팀은각스토리와관련해무엇을구현하고어떻게테스트해야할지이해하게된다. 팀의속도와선택되고추정된사용자스토리의크기에따라반복주기에서구현되는스토리의수는 달라진다. 반복주기내용이확정된후사용자스토리는작업으로분할되고적절한팀멤버에게할당된다. 테스터역시반복주기계획에참가하며특히다음과같은활동을통해계획단계에기여할수있다 : 사용자스토리와관련된상세리스크분석에참여한다 사용자스토리의테스트용이성을결정한다 사용자스토리와관련된인수테스트를작성한다 사용자스토리를태스크단위 ( 특히테스팅업무단위 ) 로분리한다 모든테스팅업무와관련된공수를추정한다 테스트대상시스템의기능적 / 비기능적측면을식별한다 다양한테스트레벨의테스팅자동화를지원하고이에참여한다 출시계획은프로젝트진행에따라변경될수있으며, 여기엔제품백로그에포함된개별사용자스토리의변경도포함될수있다. 이러한변경은내부또는외부요인에의해유발될수있다. 내부요인으로는배포능력, 속도, 기술적인문제등이포함될수있으며외부요인으로는새로운시작과기회, 새로운경쟁업체발견혹은비즈니스위협에따른출시목표나출시날짜변경이있다. 또한반복주기계획은반복주기중에변경될수있다. 예를들어, 비교적간단하다고간주했던특정사용자스토리가분석결과예상보다더복잡한경우등이다. 이러한변화는테스터에게도전이될수있다. 테스터는테스트계획을위해출시의큰그림을이해해야하며, ISTQB Foundation 실라버스 [ISTQB_FL_SYL] 1.4 절에설명된대로테스트개발을위해각반복주기에서적절한테스트베이시스와테스트오라클을가지고있어야한다. 필요한정보는개발초기에테스터가사용가능해야하고일어날변화는애자일원칙에따라수용해야한다. 이러한딜레마는테스트전략과테스트문서에관한주의깊은결정을필요로한다. 애자일테스팅변화에대한자세한내용은 [Black09] 제 12 장을참조한다. 페이지 18 / 57
출시와반복주기계획은개발계획활동에따른테스트계획을다룬다. 고려해야할특정테스트관련문제는다음과같다 : 테스팅의목적, 목적에따른테스팅의범위, 테스트목표및이러한결정에대한이유 테스트활동을수행할팀멤버 필요한테스트데이터와환경, 그리고테스트환경이나데이터에대한어떠한추가또는변경이프로젝트동안발생할지에대한여부 개발활동과관련이있거나의존적인테스트활동을포함한기능및비기능테스트활동및이를위한타이밍, 순서, 종속성과전제초건 ( 예 : 다른기능또는테스트데이터에따라달라지는기능에대해리그레션테스트를얼마나자주실행해야하는가?) 해결해야하는프로젝트와품질리스크 (3.2.1 절참조 ) 아울러큰팀의공수를추정하는경우에는요구된테스팅활동의완료에필요한시간과공수를 포함시켜야한다. 페이지 19 / 57
[ 참고정보 ] Business Representative( 업무대표자 ) Managing Business relationships and participate in strategy development, or system/application upgrades with stakeholders during concept through delivery Documenting the strategy, roadmap, business case, and oversight model in the execution of solutions assigned Conducting\leading high level solution sessions with IT and Business partners, initiate program through Banamex USA s Program Management Office, and communicating status throughout the program to all levels of the organization Collaborating with Product Managers to document and translate business strategy into technology roadmaps and capability matrixes in coordination with internal IT teams, internal/external vendors, Business, Operations, and other impacted areas to enforce a consistent strategy, roadmap, and standard documentation Actively drive simplification of technology environment while leveraging the necessary platforms where appropriate Directly impact business direction by influencing strategic\functional decisions through advice, counsel and guidance Working closely with the Business, Product Managers & Operations to respond to initiative work driven by regulatory or strategic needs Coordinating with IT Program/Project Managers and internal/external vendor(s) to ensure appropriate integration of functions to meet goals; define necessary system enhancements Tracking and communicating overall technology strategy and progress to the IT Program/Project Manager and all level of the organization as required Understanding overall Business and Information Technology strategic plans for supported applications and upcoming applications Escalating application risks to the IT Program/Project Manager when appropriate 페이지 20 / 57
2. 기본애자일테스팅원칙, 예제 & 프로세스 105 분 키워드 빌드베리피케이션테스트, 형상관리아이템, 형상관리 학습목표 2.1 전통적인테스팅과애자일접근법의테스팅차이 FA-2.1.1 FA-2.1.2 FA-2.1.3 (K2) 애자일프로젝트와다른프로젝트의테스트활동의차이점을설명한다 (K2) 개발및테스트활동이애자일프로젝트에서어떻게통합되는지설명한다 (K2) 애자일프로젝트의독립적인테스트역할을설명한다 2.2 애자일프로젝트의테스팅상태 FA-2.2.1 (K2) 테스트절차와제품품질을포함하여애자일프로젝트에서테스팅의상태를의사 소통하는데사용되는도구와기법을설명하시오 FA-2.2.2 (K2) 다수의반복주기에걸쳐테스트의발전과정을설명하고, 테스트자동화가애자일 프로젝트에서리그레션리스크를관리하는데중요한이유에대해설명하시오 2.3 애자일팀내테스터의역할과기술역량 FA-2.3.1 FA-2.3.2 (K2) 애자일팀에서테스터의역량 ( 사람, 도메인그리고테스팅 ) 을이해한다 (K2) 애자일팀에서테스터의역할을이해한다 페이지 21 / 57
2.1 전통적인테스팅과애자일접근법의테스팅차이 ISTQB Foundation 실라버스 [ISTQB_FL_SYL] 와 [Black09] 에서설명한바와같이, 테스트활동은개발활동과연관되어있고수명주기에따라다양하게변화한다. 테스터는효과적이고효율적인작업을위해애자일수명주기와기존의수명주기 ( 예 : V -모델과같은순차모델또는 RUP 와같은반복적모델 ) 의차이점을이해하고있어야한다. 애자일모델은테스팅과개발활동이통합되어있다는점을포함해프로젝트산출물, 용어, 다양한테스트레벨에서사용되는시작및종료조건, 도구의활용및독립적인테스팅을효과적으로구현하는데있어서기존모델과다르다. 테스터는조직에따라수명주기구현방법이상당히다르다는점을명심해야한다. 특정조직의수명주기구성은특별주문 (Customization) 으로제작된다. 다양한실천방법을적용함으로써애자일수명주기의이상적인형태가달라질수도있다. 테스터는해당조직에서사용하는소프트웨어개발실천방법을포함해주어진환경을적절하게적용할수있어야한다. 그렇지않으면테스터로서직무에실패할수있다. 2.1.1 테스팅과개발활동 전통적인수명주기와애자일수명주기의주요차이점중하나는주기가매우짧은반복이라는개념이며, 각반복주기가완료되는시점에는이해관계자에게가치를전달할주요기능을갖는동작하는소프트웨어가만들어져야한다. 프로젝트시작단계에서출시계획을수립하며, 이후일련의반복주기가진행된다. 각반복주기의시작단계에서반복주기계획을수립한다. 선택된사용자스토리가개발되고시스템에통합되어테스트가실행된다. 이러한반복주기는각반복주기마다상당량의병렬및오버랩 ( 동시발생 ) 을포함한개발, 통합그리고테스팅활동이일어나는매우역동적인활동으로이루어진다. 테스팅활동은반복주기의마지막활동이아니라반복주기를진행하는동안지속적으로수행된다. 테스터, 개발자그리고비즈니스이해관계자모두기존의수명주기에서와마찬가지로테스팅에서각자의역할을가지고있다. 개발자는사용자스토리에서기능을개발하고단위테스트를수행하며, 이후테스터는이러한기능들을테스트한다. 비즈니스이해관계자도구현기간동안스토리를같이테스트한다. 비즈니스이해관계자는작성된테스트케이스를활용하기도하고, 개발팀에게빠른피드백을제공하기위한목적으로기능을사용해보기도한다. 어떤경우에는잔존결함혹은다른형태의기술채무를해결하기위해주기적으로반복주기를 강화 (Hardening) 하거나안정화 (Stabilization) 시키기도한다. 그러나가장좋은방법은모든기능이 페이지 22 / 57
시스템과같이테스트되고통합되어야만완료되었다고간주하는것이다 [Goucher09]. 또다른좋은방법은이전반복주기에서남겨진결함들을다음반복주기시작시모두처리하는것이다. 물론결함들은다음반복주기의백로그에포함된다 ( 이것을 결함먼저수정하기 라고한다 ). 그러나일각에서는이러한접근법을사용하는경우, 해당반복주기에서수행해야할태스크량을전체적으로확인할수없음은물론, 남아있는기능들을구현하는데필요한공수를추정하기는더어렵다는의견을제시하기도한다. 몇차례의반복주기가완료된시점에서소프트웨어인도 (Delivery) 를위한일련의출시활동이발생할수있으며, 하나의반복주기가완료되는시점마다소프트웨어인도가발생할수있다. 테스트전략의하나로리스크기반테스팅전략을사용하는경우, 상위레벨의리스크분석은출시계획중에수립하며, 대개테스터들이리스크분석을주도한다. 그러나, 각각의반복주기와관련된특정한품질리스크는반복주기계획단계에서정의되고평가된다. 리스크분석결과는개발순서는물론, 구현된기능과관련된테스팅의우선순위와깊이에영향을미칠수있다. 또한각기능에필요한테스트공수의추정에영향을미친다 (3.2 절참조 ). 일부애자일방법론 ( 예 : 익스트림프로그래밍 ) 에서는페어링을사용한다. 페어링기법에서는두명의테스터가짝을지어하나의기능을같이테스트하며, 경우에따라개발자와테스터가협업을하기도한다. 테스트팀이분산되어있는경우에는페어링을적용하기쉽지않으나, 분산된페어링을수행하기위해적절한프로세스나도구들을활용할수있다. 분산된환경에서의태스크수행에대한자세한내용은 [ISTQB_ALTM_SYL] 2.8 절을참조한다. 테스터는팀내에서테스팅및품질과관련된코칭역할을수행할수있다. 즉테스팅지식을팀과 공유하고팀의품질보증태스크를지원할수있으며, 이를통해제품품질에대한공동의책임을 독려한다. 많은애자일팀이모든테스팅레벨에서의테스트자동화를수행하고있으며, 이는테스터들이자동화된테스트케이스와수행결과를만들어내고, 실행하고, 모니터링하고유지하는데많은시간을사용해야함을의미한다. 자동화테스트를대량으로수행하기때문에, 애자일프로젝트에서수행되는수동테스팅의대부분은소프트웨어공격, 탐색적테스팅, 에러추정과같은경험기반혹은결함기반기법들이사용된다 ([ISTQB_ALTA_SYL], 3.3 과 3.4 절그리고 [ISTQB_FL_SYL], 4.5 절참조 ). 개발자들은단위테스트생성에집중하며, 테스터는자동화된통합, 시스템, 시스템통합테스트를만드는데초점을맞추어야한다. 이런이유로애자일팀은높은기술및테스트자동화경험을가진테스터를선호하는경향이있다. 페이지 23 / 57
애자일원칙의한가지핵심은변화가프로젝트전반에걸쳐발생할수있다는것이다. 따라서애자일프로젝트에서는가벼운제품설명서를선호한다. 기존기능에대한변경은테스팅특히, 리그레션테스팅에영향을미친다. 자동화된테스팅의사용은변화와관련된테스트노력의양을관리하는하나의방법이다. 그러나변화의양이변화로인해발생가능한리스크에대처할수있는팀의능력을초과하지않도록주의해야한다. 2.1.2 프로젝트작업산출물 애자일테스터는다음과같은세가지작업산출물에특히관심을가져야한다 : 1. 요구사항 ( 예 : 요구명세 ) 과사용방법 ( 예 : 사용자설명서 ) 을설명하는비즈니스중심의산출물 2. 개발작업산출물 : 시스템설계 ( 예 : 데이터베이스개체관계다이어그램 ), 실제구현된시스템 ( 예 : 코드 ) 또는코드의각부분에대한평가 ( 예 : 자동화된단위테스트 ) 3. 테스트작업산출물 : 시스템테스트방법 ( 예 : 테스트전략과계획 ), 실제시스템테스트실행 ( 예 : 수동및자동화테스트 ) 또는테스트결과 ( 예 : 2.2.1 절에서언급된테스트대시보드 ) 일반적으로애자일프로젝트에서는많은양의문서생산을지양하며대신작동하는소프트웨어및해당소프트웨어가요구사항을만족함을입증하는자동화된테스트코드에집중한다. 고객에게가치를전달하지못하는문서는과감히줄일수있다. 애자일프로젝트에서는문서를줄여개발효율성을증가시키는관점과비즈니스, 테스팅, 개발및유지보수활동을지원하기에충분한문서를제공하는관점의균형이맞물려있다. 애자일팀은출시계획을수립하는과정에서필요한산출물의종류와문서작성수준을결정해야한다. 애자일프로젝트의일반적인비즈니스중심산출물에는사용자스토리와인수기준이포함된다. 사용자스토리는요구사항명세의애자일양식으로, 시스템이하나의일관된특성또는기능으로어떻게동작하는지에대해설명이들어있어야한다. 사용자스토리는하나의반복주기에서완료될수있도록작은기능으로정의해야한다. 관련된기능의큰집합혹은하나의복잡한기능으로조합할수있는하위기능의집합을 에픽 이라고부른다. 에픽은다른개발팀을위한사용자스토리를포함할수있다. 예를들어, 하나의사용자스토리에서 API 레벨 ( 미들웨어 ) 에서필요한사항에대해설명하면서다른스토리에서는 UI 레벨 ( 애플리케이션 ) 에서필요한사항에대해설명할수있다. 이러한집합은스프린트전체에걸쳐개발될수있다. 각각의에픽과사용자스토리는연관된인수기준을가져야한다. 페이지 24 / 57
애자일프로젝트의일반적인개발자산출물에는코드가포함된다. 애자일개발자역시종종자동화된단위테스트를만들수있다. 이러한테스트는코드개발이후에작성되기도한다. 그러나개발자가코드의각부분을작성한후제품이예상대로동작하는지여부에대한검증방법을제공하기위해코드의각부분이기록되기전에순차적인테스트를작성하는경우도있다. 이러한방법을테스트우선혹은테스트주도개발이라고일컫지만, 실제이러한환경에서작성하는테스트코드는테스트라기보다실행가능한하위레벨의설계명세에가깝다. 애자일프로젝트의일반적인테스터작업산출물에는자동화된테스트와여러문서들이포함된다. 이문서에는테스트계획, 품질리스크카탈로그, 수동테스트케이스, 결함리포트, 결함결과로그들이포함된다. 이러한문서들은가능한간단히작성한다 ( 전통적인개발라이프사이클에서도이러한문서들은일반적으로간단히작성된다 ). 또한테스터는결함리포트와테스트결과로그로부터테스트통계를도출하며, 통계역시가능한가벼운방식으로접근한다. 일부특별한경우, 가령, 규제, 안전우선, 분산된환경혹은매우복잡한프로젝트나제품을구현하는경우, 일부애자일팀은이러한작업산출물을보다공식적으로작성해야할수있다. 예를들어, 일부팀은사용자스토리와인수조건을좀더공식화된요구사항명세의형태로기술해야할수도있다. 2 차원매트릭스 ( 예 : 수직및수평추적 ) 보고서를작성해서감사, 규정및기타요구사항만족여부를확인해야할수있다. 2.1.3 테스트레벨 테스트레벨은대개테스트대상의성숙도와완성도에관련된테스트활동들을논리적으로묶은것이다. 순차주기모델에서는테스트레벨이종종어느레벨의종료기준이다음레벨의시작조건의일부라는 식으로정의되기도하지만, 일부반복적모델에서는이규칙이적용되지않는다. 테스트레벨은 오버랩 ( 중첩혹은동시발생 ) 된다. 요구명세, 설계명세및개발활동은테스트레벨과오버랩될수있다. 일부애자일라이프사이클에서는요구사항, 설계, 코드에대한변화가반복주기상의모든지점에서발생할수있기때문에오버랩 ( 중첩또는동시발생 ) 이발생한다. 스크럼에서는이론적으로반복주기계획이완료된이후의사용자스토리가변경되는것을허용하지않으나, 실제상황에서는때로변경이발생한다. 반복주기가진행되는동안, 일반적인경우모든사용자스토리를대상으로다음과같은테스팅활동을순차적으로적용한다 : 단위테스팅 : 일반적으로개발자가수행한다 페이지 25 / 57
기능인수테스팅 : 두가지활동으로구분되어수행되기도한다 기능검증테스팅 : 주로자동화되어개발자나테스터에의해수행되며, 유저스토리에대한인수기준검증을포함한다 기능확인테스팅 : 보통수동으로개발자, 테스터, 비즈니스이해관계자가함께진행하며구현된기능이사용목적에적합한지확인하기위해개발자, 테스터그리고비즈니스이해관계자의협업이포함될수있다 이와함께반복주기가진행되는동안리크레션테스팅이병렬로진행되는경우가있다. 이병행테스트 과정에는현재반복주기와이전반복주기에서의자동화된단위테스트와기능베리피케이션테스트가 수행되며, 지속적인통합프레임워크가리그레션테스트를포함한다. 일부애자일프로젝트에서는시스템테스트레벨을적용하며, 해당테스트대상사용자스토리가 준비되는즉시시작된다. 시스템테스트에는기능테스트는물론성능, 신뢰성, 사용성및다른관련된 테스트유형이포함되기도한다. 애자일팀은다양한형태의인수테스트를적용할수있다 (ISTQB Foundation 실라버스 [ISTQB_FL_SYL] 에서설명한용어사용 ). 각반복주기마다, 각반복주기가종료된이후또는일련의반복주기가종료된이후내부알파테스트, 외부베타테스트, 사용자인수테스트, 운영인수테스트, 규제승인테스트및계약승인테스트를수행할수있다. 2.1.4 테스팅과형상관리 애자일프로젝트에서는무거운자동화도구들을많이사용해소프트웨어개발, 테스트및관리를수행한다. 개발자들은도구를사용해정적분석, 단위테스팅, 코드커버리지측정을수행한다. 개발자들은지속적으로코드와단위테스트코드를형상관리시스템에입력하며, 자동화된빌드및테스팅프레임워크를사용한다. 이프레임워크는기존시스템과새로운소프트웨어를지속적으로통합하도록해주며, 통합과정에서새롭게체크인된코드에대한정적분석과단위테스트를자동으로수행한다 [Kubaczkowski]. 자동화된테스트는통합및시스템레벨에서수행되는기능테스트를포함할수있다. 이러한기능자동화테스트케이스는테스팅하네스, 오픈소스사용자인터페이스기능테스트도구, 혹은상용도구들을사용해생성할수있으며, 지속적인통합프레임워크의한부분으로실행되는자동화테스트와통합되기도한다. 기능테스트에시간이오래소요되는경우에는단위테스트와별도로실행하기도 페이지 26 / 57
하는데, 예를들어새로운소프트웨어 ( 코드 ) 가체크인될때마다단위테스트를실행하는반면기능 테스트는며칠을주기로실행할수도있다. 자동화테스트의목적중하나는빌드가작동가능하고설치가능한지를확인하는것이다. 자동화테스트가실패하는경우팀은다음코드를체크인하기전에발견된결함들을모두수정해야한다. 이러한자동화테스트결과를효과적으로표시하기위해실시간보고에대한투자가필요하다. 이러한접근법은빌드가깨지거나소프트웨어설치가실패하는원인을빠르게감지하기때문에많은전통적인프로젝트에서발생할수있는 빌드 -> 설치 -> 실패 -> 재빌드 -> 재설치 과정에서발생하는비용의낭비와효율성저하를줄일수있다. 자동화테스팅과빌드도구는종종애자일프로젝트에서발생하는잦은변경과관련된리그레션리스크를관리하는데도움이된다 [Jones11]. 그러나단위테스트의제한된결함검출효율성 [Jones11] 때문에이러한리스크를관리하기위해과도하게자동화된단위테스트에만의존하는것은문제가될수있다. 통합레벨과시스템레벨의자동화테스트도요구된다. 2.1.5 독립적테스팅을위한조직구성옵션 ISTQB Foundation 실라버스 [ISTQB_FL_SYL] 에서설명하고있는바와같이, 개발팀과별도로독립적으로구성된팀의테스터들은결함을더효과적으로발견할수있는장점이있다. 일부애자일팀에서는개발자가자동화테스트형식으로여러테스트를생성한다. 각팀에는한명혹은그이상의테스터가포함될수있으며이들은다양한테스팅작업을수행한다. 그러나개발팀내에테스터가포함되는경우독립성과객관적인평가를하지못하게되는위험요소가존재하게된다. 이와달리어떤애자일팀은완전히독립적이고개별적인테스터팀을유지하며각스프린트의마지막날에필요에따라테스터를할당한다. 이는독립성을보장할수있으며, 이러한테스터들은소프트웨어의공정하고객관적인평가를제공할수있다. 그러나이러한방법을사용할경우시간이나제품의새로운기능에대한이해가부족할수있으며비즈니스이해관계자와개발자사이의관계에서문제가발생할여지도있다. 세번째옵션은, 장기적인관점에서는독립되고분리된테스트팀을운영하고프로젝트가시작되는시점에각테스터들을애자일팀에할당하는방법이다. 이방법을통해테스트팀은독립성을유지하면서도제품에대해깊이이해할수있으며다른팀멤버들과도강력한관계를유지할수있다. 또한전문적인역량을가진테스터들을애자일팀에할당하지않고, 이들이보다장기적이거나반복주기와별개로수행하는태스크즉, 자동화테스트도구개발, 비기능테스팅수행, 테스트환경및 페이지 27 / 57
데이터구축및지원, 하나의스프린트에서완료할수없는레벨테스트수행 ( 예 : 시스템통합테스트 ) 등을수행하도록할수있다. 2.2 애자일프로젝트의테스팅상태 애자일프로젝트에서는빠르게변경사항이발생하며, 이는테스트상태, 테스트진행및제품의품질이끊임없이진화한다는것을의미한다. 테스터는이와관련된정보들을애자일팀에전달해서팀이각반복주기의성공적완료를위해적절한의사전달을할수있도록지원해야한다. 또한변화는이전반복주기에서기존의기능들에영향을줄수있다. 따라서수동및자동화테스트를지속적으로업데이트하여리그레션리스크를효과적으로처리해야한다. 2.2.1 테스트상태, 진행및제품품질커뮤니케이션 애자일팀은각반복주기의마무리지점에적절히동작하는소프트웨어를제공하며프로세스를진행한다. 동작하는소프트웨어의제공가능시점을결정하기위해개발팀은반복주기와출시의모든아이템진행상황을예의주시해야한다. 애자일팀의테스터들은다양한방법을활용해테스트진척과상태를기록한다. 여기에는테스트자동화결과, 애자일태스크보드상의테스트태스크와스토리진행내용, 팀의진척을보여주는번다운차트등이포함된다. 기록한테스트진척과상태는팀내다른멤버들과위키대시보드나대시보드스타일의이메일혹은스탠드업미팅시에구두로공유한다. 애자일팀은위키스타일대시보드와이메일을업데이트하여작업진행과테스트결과에기반한상태보고서를자동으로생성하는도구를활용할수있다. 이러한의사소통수단을통해프로세스개선에사용할수있는테스트프로세스에서메트릭을수집할수있다. 또한자동화된방식으로테스트상태를의사소통하는것은더많은테스트케이스를설계하고실행하는데집중할수있도록테스터의시간을절약해줄수있다. 팀은번다운차트를활용해서전체출시기간과각반복주기기간중의진척상황을추적하기도한다. 번다운차트 [Crispin08] 는출시또는반복주기에할당된시간및그안에수행할남아있는작업의양을 나타낸다. 테스트상태를포함해전체팀의현재상태를즉각적이고도자세하게시각화하기위해애자일태스크보드를사용할수있다. 스토리카드, 개발태스크, 테스트태스크, 반복주기계획중만들어진다른태스크들 ( 섹션 1.2.5 참조 ) 은태스크보드에표시하며, 각각다른색상의카드를사용해태스크종류를구분한다. 반복주기가진행되는동안이태스크들의진행상황은해당태스크의카드를 To do, WIP, Verify, Done 와 페이지 28 / 57
같이태스크보드위의열위에서이동하면서관리된다. 애자일팀은대시보드나상태업데이트를 자동화하는도구를사용해서스토리카드와애자일태스크보드를관리하기도한다. 작업보드의태스크작업은사용자스토리에대해정의된인수기준에관한것이다. 테스트작업에대한테스트자동화스크립트, 수동테스트그리고탐색적테스트가완료기준을달성하면작업은작업보드의 done 열로이동한다. 전체팀은정기적 ( 주로일일스탠드업미팅에서 ) 으로태스크보드의상태를리뷰함으로써적절한속도로태스크들이진행되고있는지확인한다. 전혀진행되지않거나계획보다너무느리게진행되는태스크가있는경우, 팀은해당태스크를리뷰하고태스크의진행을방해하는이슈들이없는지확인한다. 일일스탠드업회의에는테스터를포함해애자일팀의모든구성원이참여한다. 이회의는각구성원의현재상태공유를목적으로하며각멤버는다음사항들을공유한다 [Agile Alliance Guide]: 지난일일미팅이후완료한작업은무엇인가? 다음회의까지완료할작업은무엇인가? 현재하고있는작업은무엇인가? 테스트진행을방해할수있는모든문제도일일스탠드업회의에서다루어지므로, 전체팀은해당문제를함께인식하고적절하게해결할수있다. 전반적인제품의품질을향상시키기위해많은애자일팀은고객만족도조사를통해제품이고객의기대를충족시키는지에대한피드백을수집한다. 팀은테스트성공 / 실패율, 결함발견율, 확인과리그레션테스트결과, 결함밀도, 결함발견과수정률, 요구사항커버리지, 리스크커버리지, 코드커버리지그리고제품품질을향상하기위한코드변동과같은기존개발방법론에서다루던것과유사한다른기준을사용할수있다. 다른라이프사이클과동일하게매트릭의수집과보고는의사결정을할수있도록적절한연관관계를가지고이루어져야한다. 메트릭은어떤경우에도구성원에대한보상, 처벌또는구분 ( 차별 ) 을목적으로사용되어서는안된다. 2.2.2 수동및자동화된테스트케이스갱신을통한리스레션리스크관리하기 애자일프로젝트에서는각반복주기가종료됨으로써제품이완성되어가며, 이와함께테스팅범위역시 증가한다. 현재반복주기에서발생한코드변경테스팅과함께, 테스터는이전반복주기에서개발되고 테스트된기능에리그레션이발생하지않았는지확인해야한다. 애자일개발에서발생하는리그레션 리스크로인해코드가광범위하게변경될확률이높다 ( 현재버전에서다른버전으로코드라인이추가, 수정, 삭제됨 ). 변경에대응하는것이애자일원칙의핵심이기때문에, 비즈니스요구를만족시키기위해 페이지 29 / 57
이미고객에게전달된기능에도변경사항이발생할수있다. 많은기술부채를발생시키지않으면서개발속도를유지하기위해, 팀은가능한조기에모든테스트레벨에서테스트자동화에투자해야한다. 또한모든테스트자산들, 예를들어자동화테스트케이스, 수동테스트케이스, 테스트데이터및다른테스팅산출물등은매반복주기가수행될때마다최신상태로유지되어야한다. 모든테스트자산들은형상관리도구를통해관리하는것이바람직하다. 이를통해버전을컨트롤하고모든팀멤버가해당자산에쉽게접근하게할수있으며기존테스트자산의이력정보를유지하면서도기능변경으로인한변화내용을적절하게반영할수있다. 시간압박이강한애자일프로젝트의경우모든테스트를완전하게반복하는것이거의불가능하다. 따라서테스터는매반복주기마다별도의시간을할당해이전반복주기와현재반복주기에서수행한수동테스트케이스와자동화테스트케이스를리뷰해서리그레션테스트스위트에할당가능한테스트케이스를선택해야하고, 더이상수행할필요가없는테스트케이스는제거한다. 초반의반복주기에서특정한기능을테스트하기위해작성한테스트케이스는반복주기후반에서는그가치가작아질수있는데, 이는기능자체가변경되거나새로운기능이해당기능의동작방식을변경할수있기때문이다. 테스트케이스를검토하는동안, 테스터는자동화에대한적합성을고려해야한다. 팀은이전과현재반복주기에서가능한많은테스트를자동화할필요가있다. 이를통해자동화된리그레션테스트를수행함으로써리그레션테스트를수동으로수행했을때보다적은공수를사용해리그레션리스크를줄일수있고, 테스터는남은시간을현재반복주기의새로운기능을더철저하게테스트하는데사용할수있다. 테스터는현재반복주기에서발생한변경에의해영향을받은이전반복주기및출시테스트케이스를확인하고신속하게업데이트할수있는역량을반드시가지고있어야한다. 팀이테스트케이스를어떻게설계하고작성하고저장할지의결정은출시계획동안수립한다. 테스트설계및구현과관련된좋은실천방법을조기에채택해일관적으로적용해야한다. 각반복주기에대한짧은테스팅일정과지속적으로발생하는변경은부족한테스트설계와구현실천방법의영향을증가시킬것이다. 자동화테스트를적용함으로써애자일팀은모든테스트레벨에서제품품질관련피드백을빠르게얻을수있다. 잘작성된자동화테스트는현재시스템의기능을생생하게기술한다 [Crispin08]. 자동화된테스트케이스와해당테스트케이스의결과를해당제품의빌드버전과함께형상관리시스템에저장함으로써애자일팀은언제든테스트기능과그결과를확인할수있게된다. 페이지 30 / 57
자동화된단위테스트코드에서소스코드를형상관리시스템의메인라인에체크인하기전에수행하여, 변경한코드가소프트웨어빌드를중단시키지않도록해야한다. 빌드가깨지면전체팀의업무속도가떨어지며, 이를방지하기위해서자동화된단위테스트를모두통과한코드만을메인라인에체크인해야한다. 자동화된단위테스트결과는코드와빌드품질에대한즉각적인피드백을제공하기는하지만, 제품품질의좋고나쁨에대한피드백을제공하지는못한다. 지속적인통합을전체시스템빌드에적용하는경우, 자동화된인수테스트를정기적으로실행한다. 전체시스템을대상으로최소한 1 회이상실행하며, 일반적으로개별적인코드체크인이발생하는경우에는실행하지않는다. 이러한테스트는자동화된단위테스트를수행할때보다많은시간을필요로하며결과적으로코드체크인속도를저하시킬수있기때문이다. 자동화된인수테스트시험결과는마지막빌드의리그레션에대한제품품질피드백은제공하지만전반적인제품품질상태를제공하지는않는다. 자동화테스트는전체시스템을대상으로지속적으로실행할수있다. 핵심적인시스템기능과통합지점을검증하기위한자동화테스트의초기집합은새로운빌드가테스트환경에배포되는즉시생성되어야한다. 이러한테스트는일반적으로빌드베리피케이션테스트로알려져있다. 빌드베리피케이션테스트결과는배포된소프트웨어에대한즉각적인피드백을제공하므로팀은불안정한빌드를테스트하기위해시간을소모하지않아도된다. 리그레션테스트셋에포함된자동화테스트는지속적통합환경에서매일주요빌드의일부로실행되고, 테스트환경에새로운빌드가배포될때다시실행된다. 자동화된리그레션테스트가실패하는즉시, 팀은다른작업을멈추고테스트가실패한이유를조사한다. 현재반복주기에서정상적인절차에의해변경된기능으로인해테스트가실패할수있으며, 이러한경우테스트케이스및사용자스토리는새로운인수기준에맞게업데이트되어야한다. 이와반대로다른테스트가이미변경된내용을커버하는경우, 해당테스트는더이상필요하지않을수도있다. 어떤경우든결함으로인해테스트가실패하게되면, 새로운기능을추가하기전에결함을조치할수있으므로팀에게도움이된다. 테스트자동화와더불어다음의테스트업무들도자동화가가능하다 : 테스트데이터생성 시스템의테스트데이터기록 테스트환경에빌드배포 테스트기준점으로테스트환경 ( 데이터베이스혹은웹사이트데이터파일등 ) 복원 데이터결과비교 페이지 31 / 57
이러한태스크들을자동화함으로써해당태스크를수행하는데필요한오버헤드를줄일수있으며, 팀은 개발과새로운기능테스트에집중할수있다. 2.3 애자일팀의테스터역할과역량 애자일팀에서테스터는반드시모든다른팀구성원및비즈니스이해관계자들과협력해야만한다. 이는 테스터가가지고있어야할역량과애자일팀에서테스터들이수행해야하는활동과관련하여많은 시사점을제공한다. 2.3.1 애자일테스터의역량 애자일테스터는 ISTQB Foundation Level 실라버스에서언급된모든역량을보유하고있어야한다. 이뿐아니라테스트자동화, 테스트주도개발, 인수테스트주도개발, 화이트박스, 블랙박스테스팅은물론경험기반테스팅역량도보유해야한다. 애자일방법론은협업, 팀멤버및팀외부이해관계자화의상호작용을매우중시하기때문에애자일팀의테스터는다음과같은뛰어난대인관계역랑을가지고있어야한다 : 팀멤버들및이해관계자와협업시긍정적이며문제해결중심적인태도로임한다 제품과관련해핵심적이고, 품질중심적이며, 비판적인생각을제안한다 작성된명세에전적으로의존하기보다는이해관계자로부터적극적으로정보를획득한다 테스트결과, 테스트진척및제품품질등에대해정확하게평가하고보고한다 고객대표자및이해관계자들과의효과적인협업을통해테스트가능한사용자스토리, 특히인수기준을정의한다 프로그래머및다른팀멤버등팀내에서협업한다 변경, 추가또는테스트개선등변화에빠르게대응한다 스스로작업을조직화하고계획을수립한다 애자일팀에소속된테스터를포함하여모든테스터는대인관계역량을지속적으로키워나가야한다. 2.3.2 애자일팀의테스터의역할 애자일팀의테스터는테스트상태, 테스트진척, 제품품질에대한피드백을생성하고제공하는것뿐만 아니라프로세스품질에대한피드백도함께제공해야한다. 이실라버스에서기술된활동들뿐만아니라 다음과같은활동도수행해야한다 : 페이지 32 / 57
테스트전략을이해하고실행하며업데이트한다 적용가능한모든커버리지영역에서테스트커버리지를측정하고보고한다 적절한테스팅도구의사용을보장한다 테스트환경과테스트데이터를구성하고활용하며관리한다 결함을보고하고해당결함을해결하게위해팀과협업한다 팀멤버들에게테스팅관련코칭을제공한다 출시계획및반복주기계획에적절한테스팅업무를반영한다 개발자및비즈니스이해관계자들과능동적으로협력해요구사항, 특히테스트가능성, 일관성, 완전성측면을명확화한다 팀회고에적극적으로참여하여개선안을제안하고구현한다 애자일팀의모든멤버는제품품질에대해책임을지며테스트와관련된태스크들을수행한다. 애자일조직은다음과같은테스트와관련된조직적인리스크를마주할수있다 : 테스터가개발자와너무밀접하게작업하여적절한테스터사고방식을잃을수있다 테스터가팀내에서비효율적, 비효과적또는낮은품질관행에대해관용또는침묵할수있다 테스터가제한된시간의반복주기에서발생하는변화의속도를따라갈수없다 이러한리스크를완화하기위해 2.1.5 절에서언급했듯이테스터의독립성을보장할수있는조직형태를 고려해야할수있다. 페이지 33 / 57
3. 애자일테스팅방법, 기법및도구 480 분 키워드 인수조건, 탐색적테스팅, 성능테스팅, 제품리스크, 품질리스크, 회귀테스팅, 테스트접근법, 테스트 차터, 테스트추정, 테스트자동화, 테스트전략, 테스트주도개발, 단위테스트프레임워크 학습목표 3.1 애자일테스팅방법 FA-3.1.1 FA-3.1.2 FA-3.1.3 FA-3.1.4 (K1) 테스트주도개발, 인수테스트주도개발, 행위주도개발의개념을상기한다 (K1) 테스트피라미드의개념을상기한다 (K2) 테스팅사분면과각사분면의테스팅레벨및테스팅종류와의상관관계를설명한다 (K3) 애자일프로젝트의스크럼팀에서테스터역할을수행할있다 3.2 품질리스크식별및테스트노력추정 FA-3.2.1 FA-3.2.2 (K3) 애자일프로젝트의품질리스크를식별한다 (K3) 품질리스크와반복주기내용에기반하여테스팅에필요한자원을추정한다 3.3 애자일프로젝트의기법들 FA-3.3.1 FA-3.3.2 FA-3.3.3 FA-3.3.4 (K3) 테스팅활동을지원하기위한관련정보를이해한다 (K2) 비즈니스이해관계자들이테스트용이성이있는인수조건을정의하도록설명한다 (K3) 주어진유저스토리에대해인수테스트주도개발의테스트케이스를작성한다 (K3) 주어진유저스토리에대해블랙박스테스트설계기법을활용하여기능적, 비기능적 행위의테스트케이스를작성한다 FA-3.3.5 (K3) 탐색적테스팅을수행하여애자일프로젝트의테스팅을지원한다 3.4 애자일프로젝트의도구들 FA-3.4.1 (K1) 애자일프로젝트에서의테스팅목적과활동에맞춰적용가능한다양한도구들을 상기한다 페이지 34 / 57
3.1 애자일테스팅방법 애자일적용여부와관계없이높은품질의제품을만들고자하는모든개발프로젝트에적용가능한테스팅실천방법들이있다. 이실천방법들은적절한동작을표현하기위해미리테스트를작성하고, 초기결함의예방, 발견및제거에초점을맞추고, 적절한테스트가적절한시간에올바른테스트레벨의활동으로수행되는것을보장한다. 이런실천방법을널리전파하고자하는것이애자일실천가들의목표이다. 애자일프로젝트에서테스터는전체개발수명주기에걸쳐테스팅방법을안내하는핵심적인역할을하게된다. 3.1.1 테스트주도개발, 인수테스트주도개발, 행위주도개발 테스트주도개발, 인수테스트주도개발, 행위주도개발은다양한테스트레벨의테스트를수행하기위해애자일팀이사용하는세가지상호보완적인방법이다. 코드작성전에테스트가정의되어있기때문에각각의기술은개발초기의테스트및 QA 활동이주는효과에대한좋은사례가된다. 테스트주도개발테스트주도개발 (TDD) 는자동화된테스트케이스에맞추어코드를개발하는방법이다. 테스트주도개발을위한프로세스는다음과같다 : 테스트 ( 코드 ) 를추가한다. 테스트코드는구현되어야할기능에대한프로그래머의개념을확인하기위한작은코드이다 ; 테스트를실행한다. 코드가존재하지않기때문에테스트는실패한다 ; 코드를작성하고테스트가통과할때까지계속테스트를실행하고이를반복한다 ; 테스트가통과되면코드를리팩토링한다. 리팩토링이후의정상동작여부를파악하기위해테스트를실행한다 ; 코드의다음조각에대해서이과정을반복한다. 테스트는주로코드에집중된단위테스트레벨위주지만, 통합또는시스템테스트레벨에서도진행될 수있다. 테스트주도개발은익스트림프로그래밍을통해인기를얻었지만, 다른애자일방법론이나 폭포수방법론에서도사용가능하다. 테스트주도개발은개발자가명확하게정의된예상결과에초점을 맞출수있도록해준다. 작성된테스트는테스트자동화와지속적인통합에사용된다.. 인수테스트주도개발 인수테스트주도개발은사용자스토리를작성하는동안인수기준및테스트방법을정의한다 (1.2.2 절 참조 ). 인수테스트주도개발은모든이해관계자가소프트웨어구성요소가동작하는방식을이해하고, 페이지 35 / 57
개발자, 테스터및업무대표자가이동작을보장하기위해필요한테스트를함께만드는공동접근 방식이다. 인수테스트주도개발의과정은 3.3.2 절에설명되어있다. 인수테스트주도개발은회귀테스트를위한재사용가능한테스트를만든다. 지속적인통합프로세스내부에서이러한테스트의생성및실행을지원하는도구들도있다. 이런도구는시스템테스트또는인수테스트레벨에서실행할수있도록프로그램의데이터및서비스층을연결할수도있다. 인수테스트주도개발은결함과기능동작의검증을신속하게해결할수있다. 이때인수기준은기능에대한완료여부를결정하는데도움이된다. 행위주도개발행위주도개발 [Chelimsky10] 에서는개발자가기대하는소프트웨어동작에기반하여코드를테스트하는데초점을맞출수있다. 테스트가소프트웨어의특정행위를기반으로하기때문에, 일반적으로다른팀구성원및이해관계자가이해하기쉽다. 특정행위주도개발프레임워크는 Given/When/Then 의형식으로인수기준을정의할수있다 : Given 특정상황에서, When 이벤트가발생하면, Then 다음몇가지결과를확인한다 행위주도개발프레임워크는요구사항으로부터도출된테스트케이스를개발자가사용할수있는코드로변환한다. 행위주도개발은개발자가비즈니스요구사항에초점을맞추어정확한단위테스트를정의하여테스터등다른이해관계자들과협력하는것을돕는다. 3.1.2 테스트피라미드 소프트웨어시스템은다양한레벨에서테스트될수있다. 일반적인테스트레벨 ([ISTQB_FL_SYL] 2.2 절참조 ) 은피라미드의맨아래부터위로순차적으로단위, 통합, 시스템및인수테스트순으로존재한다. 피라미드는하위레벨 ( 피라미드의바닥 ) 에서는테스트의양이강조되고, 상위레벨 ( 피라미드의상위 ) 로올라갈수록테스트의양은감소한다. 보통단위및통합레벨의테스트는자동화및 API 기반도구를사용하여생성된다. 시스템및인수레벨에서자동화된테스트는 GUI 기반도구를사용하여생성된다. 테스트피라미드개념은조기결함검출의원리 ( 즉, 가능한한빨리결함을찾아서제거 ) 에기초한다. 페이지 36 / 57
3.1.3 테스팅사분면, 테스트레벨, 테스트유형 브라이언머릭이정의한테스팅사분면은각테스팅레벨을애자일방법론에서사용하는테스팅유형으로잘분류하고있다. 테스트사분면모델및그변종은모든중요한테스트유형과테스트레벨이개발수명주기에포함되어있는지확인하는데도움이된다. 또한, 이모델은개발자, 테스터, 업무대표자등모든이해관계자에게테스트의유형을구별하고설명하는방식이된다. 테스트사분면에서테스트는비즈니스에직면 ( 사용자 ) 하거나또는기술 ( 개발자 ) 에직면한것으로분류될수있다. 일부테스트는애자일팀에의해수행된작업을지원하고, 소프트웨어의동작을확인한다. 다른테스트는제품을확인할수도있다. 테스트는완전수동혹은완전자동혹은자동과수동의조합으로만들어질수있다. 네개의사분면은다음과같다 : 1 사분면은단위레벨, 기술적측면이며, 개발자를지원한다. 여기에는단위테스트가포함된다. 1 사분면의테스트는자동화되어야하고, 지속적인통합절차에포함되어야한다. 2 사분면은시스템레벨에서비즈니스에직면하고있다. 여기에서는제품의동작을확인한다. 따라서, 기능테스트, 스토리테스트, 사용자경험프로토타입및시뮬레이션이포함되어있다. 2 사분면의테스트는인수기준을확인하며, 수동또는자동으로수행된다. 인수기준은종종사용자스토리를개발하는동안생성되고, 이는스토리의품질을향상시키는데도움이된다. 또한, 자동화된회귀테스트스위트를만들때에도유용하다. 3 사분면은시스템또는제품인수테스트레벨에서비즈니스에직면하고있다. 여기에서는사실적인시나리오와데이터를사용하여제품을비판하는테스트가포함되어있다. 3 사분면은시나리오및프로세스흐름테스트, 사용성테스트, 사용자인수테스트, 알파테스트, 베타테스트를포함한다. 이런테스트는종종수동이며사용자중심적이다. 4 사분면은시스템또는운영인수테스트레벨에서기술에직면하고있다. 여기에서는제품의비판테스트가포함되어있다. 4 사분면은성능, 부하, 스트레스, 및확장성테스트, 보안테스트, 유지관리, 메모리관리, 호환성및상호운용성, 데이터마이그레이션, 인프라및복구테스트를포함한다. 이런테스트는보통자동화되어있다. 반복주기를반복하는동안, 모든사분면에걸쳐테스트를진행해야할수도있다. 테스트사분면은정적 테스트보다는동적테스트에더적합하다. 페이지 37 / 57
3.1.4 테스터의역할 실라버스전반에걸쳐애자일방법론과기법, 다양한애자일수명주기내에서테스터의역할을참조했다. 이번섹션은스크럼수명주기 [Aalst13] 를따르는프로젝트에서테스터의역할에대해특별히살펴볼것이다. 팀워크팀워크는애자일의기본원칙이다. 애자일는함께일하는개발자, 테스터및업무대표자로구성된전체팀접근방식을강조한다. 모범적인스크럼팀의특징은다음과같다 : 교차기능팀 : 각팀구성원이팀에다양한기술영역을제공한다. 이팀은테스트전략, 테스트계획, 테스트설계, 테스트실행, 테스트평가및시험결과보고를함께진행한다. 자기조직화 : 팀은개발자로만구성할수도있지만, 2.1.5 절에서언급한바와같이최소한명이상의테스터를포함하는것이이상적이다. 공간공유 : 테스터는개발자및제품소유자와같은공간에서함께일한다. 협업 : 테스터들은자신의팀구성원, 다른팀, 이해관계자, 제품소유자및스크럼마스터와공동작업을수행한다. 위임 : 필요한경우설계와테스트에관한기술결정은제품소유자및다른팀과협력하여팀전체 ( 개발자, 테스터, 그리고스크럼마스터 ) 가만든다. 헌신 : 테스터는질문과기대와고객과사용자의요구사항과관련하여제품의동작및특성을평가하기위해최선을다한다. 투명성 : 개발및테스트의진행상황을애자일상황판에서볼수있다 (2.2.1 절참조 ). 신뢰 : 테스터는테스트설계및실행전략에대한신뢰를확보해야한다. 그렇지않으면이해관계자가테스트결과를신뢰하지않는다. 이는종종테스트프로세스에대한정보를이해관계자에게제공함으로써만들어지기도한다. 열린피드백 : 피드백은특히애자일프로젝트에서성공의중요한기초이다. 회고는팀이성공과실패에서배우고성장하도록만든다. 탄력성 : 테스팅는애자일프로젝트의다른모든활동과마찬가지로변화에기민하게대응할수있어야한다. 이러한모범적인팀의특성은스크럼프로젝트에서테스트의성공가능성을극대화하는데도움이된다. 스프린트제로 스프린트제로는프로젝트의첫번째반복주기로많은준비활동을포함하고있다 ( 1.2.5 참고 ). 테스터는 스프린트제로에서팀과협업해다음활동을수행한다 : 페이지 38 / 57
프로젝트의범위정의 ( 예 : 제품백로그 ) 초기시스템아키텍처와프로토타입생성 필요한도구를계획, 수급, 설치 ( 예 : 테스트관리, 결함관리, 테스트자동화, 형상관리 ) 모든테스트레벨에걸쳐테스트범위, 기술적리스크, 테스트종류 ( 섹션 3.1.3 참고 ), 커버리지목표를포함한초기테스트전략수립 초기품질리스크분석수행 ( 섹션 3,2.1 참고 ) 테스트프로세스, 진척율, 제품품질을측정하기위한품질지표정의 " 완료 " 의의미정의 태스크보드생성 ( 섹션 2,2,1 참고 ) 고객에게제품을전달하기전에테스팅의지속및중단여부정의 스프린트제로에서는전체스프린트가진행되는동안어떤테스팅이수행되어야하는지, 어떻게 테스팅을진행할지에대한방향을설정한다. 통합애자일프로젝트에서이상적인목표는 ( 가능한모든스프린트에서 ) 지속적으로고객에게가치를전달하는것이다. 이를위해서통합전략은설계와테스트를모두고려해야한다. 출시할기능과특징을지속적으로테스트하려면, 기본기능과기능사이의모든종속관계를확인하는것이중요하다. 테스트계획 테스트가애자일팀에완전히통합되면, 테스트계획은릴리즈계획시시작되고각스프린트동안 업데이트된다. 각릴리즈와스프린트의테스트계획은섹션 1.2.5 에서제시한내용을다루어야한다. 스프린트계획의결과, 모든일은하루나이틀분량의태스크로정의되어태스크보드에기재된다. 또한, 모든테스팅이슈는테스팅의흐름을지속적으로유지하기위해추적되어야한다. 애자일테스팅실천방법스크럼팀에서테스터는많은실천방법들을적용할수있으며, 여기에는다음과같은실천방법들도포함된다 : 페어링 : 두명의멤버 ( 예 : 개발자와테스터, 테스터와테스터, 테스터와제품소유자 ) 가테스트또는다른작업을수행하기위해하나의동일한작업공간앞에함께앉아공동으로태스크를수행한다. 점진적인테스트설계 : 사용자스토리및기타테스트베이시스로부터만들어진테스트케이스및차터가점진적으로간단한테스트에서시작해서더복잡한테스트를향해발전한다. 페이지 39 / 57
마인드맵 : [Crispin08] 테스트할때마인드맵은유용한도구이다. 예를들어, 테스터는테스트 전략을표시하거나, 테스트데이터를설명하거나, 수행된테스트세션을식별하기위해 마인드맵을사용할수있다. 위에언급된실천방법들을포함한다른실천방법들은 ISTQB Foundation 실라버스 4 장에설명되어있다. 3.2 품질리스크식별및테스트노력추정 테스팅의일반적인목적은릴리즈이전에허용가능한수준으로품질문제의리스크를감소시키는것이고, 애자일이든전통적인프로젝트이든이러한목적은동일하다. 그러나, 짧은반복주기와애자일프로젝트의잦은변화에대응하기위해서일부변형이필요하다. 3.2.1 애자일프로젝트에서품질리스크식별하기 테스팅에서직면하는도전중하나는테스트컨디션을적절하게선택하고, 할당하며우선순위를선정하는것이다. 이것은각시험조건을커버하기위해할당할적절한노력의양을결정하고, 테스트작업의효율성및효율을최적화하기위한테스트절차를포함한다. 많은제약사항과변수를고려해야하지만, 리스크식별, 분석및리스크완화전략은애자일팀의테스터가실행할테스트케이스의수를결정하는데도움이된다. 리스크란부정적이거나원하지않는결과혹은이벤트가발생할수있는가능성을의미한다. 리스크의 수준은발생가능성과영향도를평가함으로써파악할수있다. 제품의품질에잠재적인문제가있는경우, 이잠재적인문제는품질리스크또는제품리스크로나타난다. 프로젝트에잠재적인문제가있는경우, 이잠재적인문제는프로젝트의리스크또는계획과정의리스크로나타난다 [vanveenendaal12] [Black07]. 애자일프로젝트에서품질리스크분석은두군데에서이루어진다 : 릴리즈계획 : 기능의리스크에대해전반적으로파악하고있는업무대표자와테스터를포함한전체팀이리스크를식별하고평가한다. 반복주기계획 : 전체팀이품질리스크를식별하고평가한다. 시스템품질리크스에는다음사항들이포함된다 : 보고서의잘못된계산식 ( 기능적리스크로정확성과관련됨 ) 사용자입력에대한느린응답 ( 비기능리스크로효율성및응답시간과관련됨 ) 이해하기어려운화면구성및입력필드 ( 비기능리스크로사용성및이해도와관련됨 ) 페이지 40 / 57
앞서언급한바와같이반복주기는반복주기계획에서시작하며, 반복주기계획은추정한태스크들을태스크보드에붙임으로써마무리된다. 이태스크들은해당태스크들과관련된품질리스크의수준에기초해우선순위를정할수있다. 높은리스크과관련된작업은빠르게시작하고더많은테스트노력을배정해야하며, 낮은리스크와관련된작업은나중에시작하고테스트노력을상대적으로덜배정해야한다. 다음은반복주기계획시애자일프로젝트의품질리스크의분석과정을예로든것이다 : 1. 애자일팀원전체를모은다. 물론테스터도포함된다 ; 2. 현재반복주기의모든백로그아이템을나열한다 ; 3. 적절한품질특성을고려하여각아이템에대한품질리스크를식별한다 ; 4. 식별한리스크를진단한다. 리스크를분류하고영향도와발생빈도에따라리스크의수준을파악한다 ; 5. 리스크의수준에따라테스트의수준을결정한다 ; 6. 리스크, 리스크수준, 품질특성을고려하여각리스크를해결하기위한적절한테스트기법을선택한다. 이후테스터는테스트설계, 구현, 실행을통해리스크를완화한다. 테스트는고객, 사용자, 이해관계자의 만족도에영향을미치는기능, 행동, 품질특성및속성전체를포함한다. 프로젝트전반에걸쳐팀은리스크또는알려진품질리스크수준을변화시키는정보에대해항상파악하고있어야한다. 테스트에대한결과를반영하여주기적으로품질리스크를분석하고조절한다. 조절단계에는기준리스크수준의재평가, 새로운리스크의식별, 리스크완화활동에대한효과평가등이포함된다. 테스트실행전에도품질리스크를완화시킬수있다. 예를들어, 사용자스토리관련문제가리스크식별 과정에서발견된경우, 프로젝트팀은완화전략으로사용자스토리를철저하게리뷰할수있다. 3.2.2 리스크와내용을근거로테스트노력추정하기 출시계획과정에서애자일팀은출시를완료하기위한공수를추정하며, 여기에는물론테스팅을위한 공수도포함된다. 애자일프로젝트에서는일반적으로플래닝포커기법을사용해공수를추정하는데, 이 기법은참여자의합의에기반을두고있다. 제품소유자또는고객은공수를추정해야할사용자스토리를 읽는다. 스토리의공수를추정하는인원들은피보나치수열 (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 99, ) 과 같은값혹은다른방식의순차적으로증가하는값 ( 예 : 가장작은것부터가장큰셔츠의크기 ) 이적힌한 세트의카드를가지고있다. 카드의각숫자는해당팀이추정한공수를의미하며, 스토리의크기에따라 페이지 41 / 57
공수에대한불확실성이기하급수적으로증가할수있으므로, 피보나치열을사용할것을권장한다. 높은 추정치는일반적으로스토리가잘이해되지않거나여러개의작은스토리로분해되어야한다는것을 의미한다. 추정에참여하는사람들은기능에대해논의하며필요하다고생각되는모든질문을제품소유자에게던져야한다. 추정을함에있어서개발및테스팅공수, 스토리의복잡성, 테스팅범위등의내용도고려해야한다. 따라서, 플래닝포커가시작되기전에, 제품소유자가정한우선순위에추가로백로그항목의리스크레벨을표기하는것이바람직하다. 기능을논의할때, 각추정자는개인적으로자신의추정치를대표하는하나의카드 ( 숫자 ) 를선택한다. 모든사람이카드를다고르면카드를동시에공개한다. 모든추정치가같은카드일경우그값을추정치로사용하고, 같은추정치의카드가아닌경우, 추정에참여한사람들은추청치가상이한이유에대해논의하고동일한추정치에도달할때까지추정을반복한다. 포커라운드수를제한하기위해카드사용규칙 ( 예를들면, 최종적으로평균값을사용하거나최대값을선택할수있다 ) 을별도로정의할수있다. 이토론은제품소유자가요청한제품백로그항목에서해야할작업에대한집단의식을향상시키고, 추정의신뢰성을높이는데도움이된다 [Cohn04]. 3.3 애자일프로젝트의테스트기법들 전통적인프로젝트에적용된테스트및테스트기법의대부분은애자일프로젝트에도적용할수있다. 다만테스트기법, 용어및문서화와관련해조금더주의를기울여야할차이점들이있다. 3.3.1 인수조건, 적절한커버리지, 테스팅을위한기타정보 애자일프로젝트는프로젝트의초기요구사항을백로그우선순위에따라사용자스토리에기재한다. 초기요구사항은짧고일반적으로미리정의된형식을 (1.2.2 절참조 ) 따른다. 사용성및성능과같은비기능요구사항역시똑같이중요하며, 이들은고유의사용자스토리혹은다른기능사용자스토리에연결하여명세를작성할수있다. 비기능요구사항은미리정의된형식이나 ISO25000 과같은국제표준또는특정산업표준을따를수있다. 사용자스토리는중요한테스트베이시스의하나이며, 이외에다음과같은요소들을테스트베이시스에 포함시킬수있다 : 이전프로젝트의경험 페이지 42 / 57
해당시스템에이미존재하는기능및품질특성 코드, 아키텍처, 디자인 사용자프로파일 ( 컨텍스트, 시스템설정및사용자행동 ) 현재및과거프로젝트의결함정보 결함사전의결함분류 적용되는표준 ( 예 : DO-178B, 등 ) 품질리스크 ( 섹션 3.2.1 참고 ) 각반복주기동안, 개발자는사용자스토리에서설명하는특정한품질특성과관련된기능 / 특징의구현을위해코드를생성하고, 이코드는확인및인수테스트를통해검증된다. 테스트가가능하기위해인수기준은다음과같은주제를반드시포함해야한다 [Wiegers13]: 기능동작 : 특정설정에서입력된사용자의행위에대해외부에서관찰가능한동작결과 품질특성 : 시스템이지정된동작을수행하는방법. 특성은품질속성또는비기능요구사항을포함할수있다. 일반적인품질특성으로는성능, 안정성, 사용성등이있다 시나리오 ( 유스케이스 ): 특정목표또는비즈니스작업을수행하기위한외부액터 ( 주로사용자 ) 와시스템사이의작업순서 비즈니스규칙 : 외부절차나제약사항에의해정의된특정조건하에서시스템에서수행할수있는활동 ( 예 : 보험청구를처리하도록보험회사에서사용하는절차등 ) 외부인터페이스 : 개발된시스템과외부세계의연결에대한설명. 외부인터페이스는서로다른유형으로구분할수있다 ( 사용자인터페이스, 다른시스템인터페이스등 ) 제약사항 : 개발자의옵션을제한하는모든설계및구현의제약사항. 임베디드소프트웨어를탑재한장비들은일반적으로크기, 무게, 인터페이스연결과같은물리적제약을준수해야한다 데이터정의 : 고객이복잡한구조의비즈니스데이터에대해서각항목의포맷, 데이터종류, 허용되는값및디폴트값을기술할수있다 ( 예 : US 우편주소의 ZIP 코드등 ) 사용자스토리및이와관련된인수조건외에도테스터는다음과같은부가적인정보를고려해야한다 : 시스템의의도된동작방식및사용방식 시스템을테스트하는데사용할수있는시스템접근 / 사용인터페이스 현재사용하는도구지원의충분성여부 테스터가시험을수행하는데필요한충분한지식과기술이있는지의여부 반복주기가진행되는과정에서테스터들은종종추가적인정보 ( 예 : 코드커버리지등 ) 의필요성을 발견하게되므로다른애자일팀멤버들과의협업을통해이러한정보들을수집해야한다. 관련정보는 페이지 43 / 57
특정작업을완료로간주할수있는지의여부를결정하는역할을한다. 애자일프로젝트에서완료정의는 매우중요하며, 이어지는절에서논의할바와같이다양한방식으로적용된다. 테스트레벨 각테스트레벨은레벨고유의종료조건을가지고있으며다음리스트의예를종료조건으로적용할수 있다 : 단위테스팅 불가능한경로에대한강도높은리뷰및결정커버리지 100% 만족 모든코드에대한정적분석수행 해결되지않는메이저결함없음 ( 우선순위및심각도를고려하여분류 ) 설계와구현시수용불가능한기술적부채없음 [ 존스 11] 모든코드, 단위테스트, 단위테스트결과리뷰 모든유닛테스트자동화 중요한특성에대한제약사항에동의 ( 예 : 성능 ) 통합테스팅 크기 / 복잡도리스크에기반한다수의긍정 / 부정테스트를포함한모든기능요구사항테스트 단위간모든인터페이스테스트 합의한테스트강도에따라모든품질리스크대응 해결되지않은메이저결함없음 ( 리스크와중요도에따라 ) 발견된모든결함보고완료 가능한모든회귀테스트자동화및자동화된테스트의공용저장소저장 시스템테스팅 사용자스토리및기능의엔드-투-엔드테스트 모든사용자페르소나고려 시스템의가장중요한품질특성 ( 예 : 성능, 안정성, 신뢰성 ) 커버완료 가능한지원되는환경구성에대한모든하드웨어및소프트웨어를포함하여실제사용환경에서테스트완료 테스트에서커버하기로한모든품질리스크커버완료 가능한모든회귀테스트자동화및자동화된테스트의공용저장소저장 발견된모든결함보고및가능한수정완료 해결되지않은주요결함없음 ( 리스크과중요도에따라우선순위화 ) 페이지 44 / 57
유저스토리 User Story 유저스토리완료조건은다음과같다 : 반복주기에서선택된사용자스토리가팀에의해완료되고, 테스트가능한상세한인수기준을가짐 인수테스트를포함한사용자스토리의모든요소가구체화되어리뷰되고구현이완료됨 선택한사용자스토리의테스트에필요한작업을식별하고팀에의해추정완료 기능 Feature 여러유저스토리와에픽을포함하는기능에서완료의정의는다음을포함할수있다 : 인수기준이있는모든사용자스토리가정의되고고객에의해승인완료 알려진기술부채없이설계완료 알려진기술부채또는미완성리팩토링없이코딩완료 단위테스트가수행되고, 정의된커버리지수준달성 기능의통합테스트및시스템테스트가정의된커버리지기준에따라수행완료 주요결함수정완료 릴리즈노트, 사용자설명서및온라인도움말기능을포함한기능설명서완성 반복주기 Iteration 반복주기에서완료의정의는다음을포함할수있다 : 반복주기에대한모든기능은기능수준의기준에따라준비되고개별적으로테스트완료 반복주기의제약내에서해결할수없는중요하지않은결함을제품백로그에추가하고우선순위에따라분류 반복주기에대한모든기능의통합을완료하고테스트완료 문서의작성, 검토, 승인완료 반복주기가완료되었기때문에이시점에서소프트웨어는잠재적으로출시가가능하지만, 출시의모든 반복주기가완료된것은아닐수있다. 출시 ( 릴리즈 ) 여러반복주기를포함하는출시에서완료의정의는다음을포함할수있다 : 커버리지 : 출시의모든내용에대한모든관련테스트기준이테스트에포함되어있다. 커버리지의적정성은복잡성과크기, 그리고실패와관련된리스크및변경사항에의해결정된다 페이지 45 / 57
품질 : 결함강도 ( 예 : 하루또는트랜잭션당발견되는결함의수 ), 결함밀도 ( 예 : 사용자스토리, 노력, 또는품질특성의수에비례해발견된결함의수 ), 결함허용범위내에있는잠재결함의수, 해결되지않거나남아있는결함 ( 예 : 심각도및우선순위 ), 식별한각각의품질리스크와관련된리스크의잔류수준이이해하고허용할만한수준인가 시간 : 미리정해진납기에도달한경우, 연관된비즈니스사항을고려하여출시를결정한다 비용 : 예상된수명주기비용은출시시스템에대한투자대비수익률을계산하는데사용된다 ( 즉, 계산된개발및유지보수비용이제품의예상총매출보다상당히낮아야한다 ). 제품생산이후에발생한결함으로인해수명주기비용의주요부분은종종유지보수단계에서발생하기도한다 3.3.2 인수테스트주도개발적용하기 인수테스트주도개발은테스트우선접근법이다. 테스트케이스들은해당사용자스토리를구현하기전에작성된다. 테스트케이스는개발자, 테스터, 업무대표자 [Adzic09] 를포함한애자일팀에의해생성되고, 수동또는자동으로수행된다. 첫번째단계로사용자스토리를분석 / 논의하고, 개발자, 테스터및업무대표자가요구사항을작성하는워크숍을진행한다. 사용자스토리의모든불완전성, 모호성, 오류가이과정에서보완된다. 다음단계는테스트케이스를생성하는것이다. 테스트케이스작성은모든사람이참여하거나테스트팀에의해개별적으로진행될수있다. 테스트케이스의작성방식과관계없이, 비즈니스대표자와같은제 3 자가테스트케이스를검증한다. 테스트케이스는사용자스토리의특정한특성을기술하고있는예제들이며, 애자일팀이해당사용자스토리를정확하게구현하도록도움을준다. 예제와테스트는동일한대상을지칭하며, 이용어들은대부분은동일한의미로사용된다. 테스트케이스생성작업은기본적인예제와개방형질문에서시작한다. 통상적으로, 첫번째테스트는예상했던대로실행되면동작단계에서예외또는오류없이올바르게동작함을확인하는긍정테스트이다. 긍정적인경로에대한테스트를완료한후, 팀은부정적인경로에대한테스트뿐만아니라비기능적특성도추가해야한다 ( 예 : 성능, 가용성 ). 테스트케이스는모든이해관계자들이이해할수있도록기술되어야하며, 필요한사전조건, 예를들면입력및해당입력에대한출력값등을자연어문장으로포함할수도있다. 예제는사용자스토리의모든특성을포함해야하며임의의내용을덧붙여서는안된다. 즉, 예시는스토리 자체에서설명하지않은측면을다루지말아야한다는것을의미한다. 또한, 두개의예시가사용자 스토리의동일한특성을설명해서도안된다. 페이지 46 / 57
3.3.3 기능및비기능블랙박스테스트설계 애자일테스팅에서수행되는많은테스트는테스터에의해생성되며, 이는개발자가프로그래밍활동을하는시기에동시에이루어진다. 개발자가사용자스토리및완료기준에따라프로그래밍을하는것처럼, 테스터는사용자스토리와완료기준에따라테스트를설계한다 ( 섹션 3.3.4 에설명한대로탐색적테스트및다른경험기반테스트와같은일부테스트는테스트실행중에테스트를설계한다 ). 테스터는동등분할, 경계값분석등기존의블랙박스테스트설계기법을활용할수있다. 결정테이블테스트및상태전이테스트를통해서도이러한테스트를설계할수있다. 예를들어, 경계값분석은고객이구입할수있는항목의수가한정되어있는경우, 테스트데이터를선택하는데사용될수있다. 많은경우, 비기능적요구사항은사용자스토리와같이문서화된다. 경계값분석과같은블랙박스테스트설계기법도비기능적품질특성에대한테스트를작성하기위해사용될수있다. 사용자스토리에서성능이나신뢰성요구사항을포함할수도있다. 예를들어, 주어진실행제한시간을초과할수없다거나특정작업의실패는특정횟수보다적어야한다고명시하는것이다. 블랙박스테스트설계기법의사용에대한자세한내용은 Foundation level 실라버스 [ISTQB_FL_SYL] 및 Advanced level_test Analysis 실라버스 [ISTQB_ALTA_SYL] 를참고하자. 3.3.4 탐색적테스팅과애자일테스팅 탐색적테스팅은애자일프로젝트에서매우중요한데, 이는테스트분석에사용가능한시간과사용자스토리의세부사항들이제한되어있기때문이다. 최상의결과를얻기위해서는탐색적테스팅을다른경험기반테스팅기법과조합함은물론, 리스크분석기반테스팅, 요구사항분석기반테스팅, 모델기반테스팅및리그레션회피테스팅과같은다양한테스팅전략을적절히혼합해서활용해야한다. 테스트전략및이전략들의조합과관련된자세한내용은 Foundation level 실라버스를참조한다. 탐색적테스팅에서테스트설계와테스트실행은미리준비한테스트차터에기반해동시에실행된다. 테스트차터는주어진테스팅세션시간동안커버해야할테스트조건들을제공하며, 탐색적테스트를진행하는동안가장최근의테스트결과즉, 이전세션의테스트결과에따라다음테스트의방향을조정한다. 미리설계된테스팅을수행할때사용하는화이트박스, 블랙박스기법을테스트케이스를설계하는경우에도동일하게사용할수있다. 테스트차터는다음정보들을포함할수있다 : 액터 : 시스템을사용할것으로예상되는사용자 목적 : 액터가달성하고자하는특정목적즉, 테스트조건을포함한차터의전체목적 페이지 47 / 57
준비 : 테스트실행의시작을위해필요한준비사항 우선순위 : 해당테스트차터의상대적인중요성으로, 관련된사용자스토리혹은리스크수준에따라결정함 참조 : 요구사항 ( 예 : 사용자스토리 ), 리스크, 그외다른정보들 데이터 : 테스트에필요한데이터 활동 : 액터가시스템에서수행할수있는것 ( 예 : " 슈퍼사용자로시스템에로그온 "), 흥미로운테스트항목 ( 긍정적테스트와부정적테스트모두포함 ) 오라클 : 결함인지여부를판단할수있는제품의올바른동작결과 ( 예 : 화면에일어나는캡처와사용설명서에기록된화면을비교 ) 변화 : 대안활동및활동을보완할수있는아이디어 탐색적테스팅을관리하기위해세션기반테스트관리기법이사용될수있다. 테스팅세션은 60~120 분사이의시간으로정의되며, 이시간동안에는외부로부터의어떠한방해도받지않아야한다. 테스트세션은다음사항을포함한다 : 조사세션 ( 작동방법에대한세부내용학습 ) 분석세션 ( 기능이나특징평가 ) 커버리지확장 ( 예외또는경계케이스, 시나리오, 상호작용 ) 테스트의품질은대상제품에대해질문할수있는테스터의능력에따라달라진다. 다음과같은질문이포함될수있다 : 이시스템에서가장중요한것은무엇인가? 어떤방식으로시스템이실패할수있는가? 만약 ~ 하면어떤일이생길까? 일때어떤일이발생해야하는가? 고객의니즈, 요구사항, 기대가모두충족되었는가? 시스템설치 ( 혹은제거 ) 시모든업그레이드경로에서정상적으로설치 ( 및삭제 ) 가수행되는가? 테스트를실행하는동안, 테스터는창의성, 직관, 지식과모든역량을동원해제품에서발생가능한 문제점들을찾아낸다. 테스터는또한테스트대상, 비즈니스영역, 소프트웨어사용방법, 시스템의실패 여부결정방법에대한충분한지식과이해를가지고있어야한다. 테스트중, 다음의휴리스틱항목을적용할수있다. 휴리스틱은경험기반테스트를수행하는방법및 결과를평가하는방법을안내해줄수있다 [ 헨드릭슨 ]. 휴리스틱의예는다음과같다 : 페이지 48 / 57
경계값 CRUD ( 쓰기, 읽기, 갱신, 삭제 ) 설정변경 의도치않은장애상황 ( 예 : 로그오프, 종료, 혹은시스템재부팅 ) 테스터는테스팅과정을최대한문서화해야한다. 그렇지않으면시스템에서문제가발견된경로를재현하기어렵다. 다음은문서에포함할유용한정보의예시이다 : 테스트커버리지 : 어떤입력데이터가사용되었고, 어느만큼의영역을커버했는지, 앞으로테스트해야할부분이얼마나남았는지에대한정보 평가노트 : 테스트하는동안관찰한내용. 시스템과기능은안정적인지, 현재관찰에따라다음에어떤부분을테스트하면좋을지에대한아이디어등 리스크및전략 : 어떤리스크가해소되었는지, 가장중요한리스크중테스트안된부분은어디인지, 초기테스트전략이지켜지고있는지, 어떤변화가필요한지에대한정보 문제, 질문, 이상한점 : 예상치못한결과, 접근방식의효율성에관한질문, 아이디어및테스트시도에대한우려사항, 테스트환경, 테스트데이터, 기능, 테스트스크립트또는테스트중인시스템에대한오해 실제동작 : 시스템의실제동작에대한기록 ( 예 : 비디오, 화면캡처, 출력데이터파일등 ) 기록된정보는저장되고특정한상태관리도구 ( 예 : 테스트관리도구, 태스크관리도구, 태스크보드 등 ) 에적합한형태로요약되어이해관계자가수행된모든테스팅의현재상태를쉽게이해할수있도록 해야한다. 3.4 애자일프로젝트를위한도구들 ISTQB Foundation level 실라버스에소개된도구들은애자일팀의테스트와무관하지않으며, 실제로프로젝트에서테스터들이사용한다. 모든도구가동일한방식으로사용되지는않으며, 몇몇도구들은특히애자일프로젝트와더욱밀접하게관련되어있다. 예를들어, 테스트관리도구, 요구사항관리도구, 결함관리도구 ( 결함추적도구 ) 는애자일팀에서사용될수있지만, 일부애자일팀은작업보드, 번다운차트, 사용자스토리와같은애자일개발과관련된기능을포함하는도구를선택하기도한다 ( 예 : 애플리케이션라이프사이클관리또는작업관리도구 ). 모든수준에서자동화된테스트및관련된테스트아티팩트를관리할필요가있으므로애자일팀에서형상관리도구는중요하다. 페이지 49 / 57
ISTQB Foundation level 실라버스에설명된도구이외에도애자일프로젝트에서테스터는이번장에서 설명하는도구를활용할수있다. 이도구들은애자일실천방법의핵심인팀협업및정보공유를 보장하기위해사용된다. 3.4.1 작업관리및추적도구 일부애자일팀은각스프린트가진행되는동안물리적인스토리 / 태스크보드 ( 예 : 화이트보드, 코르크보드등 ) 를사용해사용자스토리, 테스트및다른태스크들을관리하고추적한다. 다른팀들은애플리케이션수명주기관리및태스크관리소프트웨어를사용하기도하며, 여기에는소프트웨어태스크보드가포함된다. 스토리및스토리와관련된개발및테스트작업을기록하여스프린트가진행되는동안태스크가누락되지않도록한다 각태스크에팀구성원의공수추정치를기재하고사용자스토리를구현하기위해필요한공수를자동으로계산함으로써, 효율적인반복주기계획을수립하도록한다 동일한사용자스토리와연관된개발 / 테스트작업을묶음으로써해당스토리를구현하는데필요한팀의전체적인공수를파악하도록한다 개발자및테스터의작업완료상태를태스크에반영함으로써, 각각의스토리, 반복주기및전체적인릴리즈진행상태의스냅샷을제공한다 지리적으로분산된팀원을포함한모든이해관계자들이각사용자스토리, 반복주기, 릴리즈의현재상태를통계, 차트및대시보드를통해신속하게파악할수있도록돕는시각적자료를제공한다 태스크와형상관리도구를연동한다. 이들형상관리도구는코드체크인및해당태스크과관련된빌드내역을자동으로기록하며, 일부도구들은태스크의업데이트상태도기록한다 커뮤니케이션및정보공유도구 이메일, 문서, 구두커뮤니케이션외에도애자일팀은종종커뮤니케이션과정보공유를강화하는세 가지추가적인도구 ( 위키, 메신저, 데스크탑공유 ) 를사용한다. 위키를사용하면팀은프로젝트의다양한관점에대한지식을온라인상에서생성하고공유할수있으며, 다음정보들을포함할수있다 : 제품기능다이어그램, 기능관련토론, 프로토타입다이어그램, 화이트보드상에기록된토의내용의사진및기타정보 팀의다른구성원에게유용할수있는개발및테스트를위한도구또는기술 페이지 50 / 57
제품상태와관련된지표, 차트및대시보드. 이러한요소들은위키가제품상태를자동으로 업데이트해주는빌드서버및작업관리시스템등과연동된경우특히유용하다. 인스턴트메신저및이메일등의방식으로팀의다른사람들과공유된팀구성원간의대화 인스턴트메시징, 컨퍼런스콜, 화상채팅도구는다음과같은이점을제공한다 : 팀구성원, 특히지리적으로분산된팀원사이의실시간대면커뮤니케이션이가능 스탠드업미팅에지리적으로분산된팀참여가능 VoIP 기술을활용해통신비를줄임으로써, 분산된팀구성원의커뮤니케이션을물리적으로줄어들게하는비용문제를줄임 데스크탑공유및캡처도구는다음과같은이점을제공한다 : 분산된팀에서제품시연, 코드리뷰및페어작업가능 각반복주기의끝에서제품시연을캡처하여팀의위키에게시가능 이러한도구들은대면의사소통을대처하는수단이아니라보완하고확장하는수단으로만사용해야 한다. 3.4.3 소프트웨어빌드및배포도구 본실라버스의앞에서이미설명한바와같이, 소프트웨어를매일빌드하고배포하는작업이애자일팀에게는매우중요하다. 이작업을수행하기위해서는지속적인통합및빌드배포도구가필요하며, 이러한도구들의장점과리스크는 1.2.4 절에서설명되었다. 이는분산빌드도구및지속적인통합도구의사용을필요로한다. 이러한도구의사용으로인한장점및리스크은 1.2.4 절앞부분에서설명되어있다. 3.4.4. 형상관리도구 애자일팀에서형상관리도구는소스코드저장및자동테스트에사용될뿐만아니라수동테스트및기타테스트산출물또한종종제품소스코드와같은저장소에저장된다. 형상관리도구는소프트웨어버전과테스트산출물버전사이의추적성을제공하고, 기록된정보의손실을없애빠르게변화에대응할수있게한다. 버전관리시스템의주요유형은중앙소스제어시스템및분산버전제어시스템을포함한다. 팀의크기, 구조, 위치, 타른도구와의연동요구사항을바탕으로특정애자일프로젝트에적합한형상관리도구를결정한다. 페이지 51 / 57
3.4.5 테스트설계, 구현, 실행도구 몇몇도구들은소프트웨어테스팅프로세스의특정지점에서애자일테스터에유용하다대부분의도구들은애자일에특화되어있거나애자일을위해서만만들어진것은아니지만, 애자일프로젝트의빠른변화에대응할수있는중요한기능들을제공한다. 테스트설계도구 : 마인드맵과같은도구를사용해새로운기능과관련된테스트를빠르게설계하고정의하는것이보편화되었다 테스트케이스관리도구 : 애자일에서사용하는테스트케이스관리도구는팀전체의개발수명주기관리또는작업관리도구의일부가될수있다 테스트데이터의준비및생성도구 : 데이터및데이터의조합이많은애플리케이션을테스트하는경우, 애플리케이션의테스트데이터를생성해주는도구는매우유용하다. 이러한도구는또한애자일프로젝트도중에변경이발생했을때, 데이터베이스구조를재정의하기위한데이터를생성하는스크립트의리팩토링에도도움이된다. 이를통해변경사항이발생한경우테스트데이터를신속하게업데이트할수있다. 원본데이터를초기입력자료로사용하는일부테스트데이터준비도구는민감한데이터를제거하거나익명화하기위한스크립트를지원하기도한다. 또한, 대규모데이터입력또는출력의유효성검증도가능하다. 테스트데이터입력도구 : 테스트데이터를생성한후에는해당데이터를어플리케이션에입력해야한다. 수동데이터입력에는보통많은시간이소요되고많은에러가발생하므로데이터입력도구를이용하여이를안정적이고효율적으로만드는것이가능하다. 사실, 데이터생성도구의대부분은데이터입력기능을지원한다. 지원하지않는경우, 데이터베이스관리시스템을사용하여직접접근하는방식 ( 벌크로딩 ) 도가능하다. 자동화테스트실행도구 : 애자일테스팅에좀더최적화된테스트실행도구들이있다. 이런도구들은행위주도개발, 테스트주도개발및인수테스트주도개발과같은테스트우선접근방식을지원하며, 상용또는오픈소스로사용이가능하다. 또한일부도구는테스터및비즈니스관련인력이테이블이나자연어키워드를사용하여시스템의예상동작을표현할수도있다. 탐색적테스트도구 : 탐색적테스트세션동안응용프로그램에서수행된내용및로그를기록하여테스터및개발자에게도움을주는도구이다. 오류가발생하기전에취해진행동을기록함으로써개발자가결함을재발생시키고분석하는데유용하다. 궁극적으로자동화된회귀테스트스위트가구축되어있는경우, 탐색적테스트세션에서행동을기록하는것이더욱더도움이된다는것은이미증명되어있다. 페이지 52 / 57