애자일 테스팅(Agile Testing)

애자일 테스팅, 리사 크리스핀, 자넷 그레고리 지음. 김도균, 한동준 옮김. 정보문화사

Chapter 1. 애자일이란 대체 무엇인가?

애자일 테스터 : 자신이 속한 팀이 고객이 요구하는 높은 품질의 제품 제공을 보장하는 일을 한다.

TDD(Test-Driven Developer) and (Test-driven design)

테스터에게 있어서 무엇보다 최선은 최고의 품질을 만들어내는데 책임을 느끼고, 테스팅에 모든 것을 집중하는 사람으로 구성된 팀과 함께 일하는 것이다.

애자일 테스팅 : 일반적으로 비즈니스 중심 테스트, 즉 비즈니스 전문가가 바라는 특징과 기능을 정의한 테스트를 의미한다.

테스트 : 제품을 평가하고, 완성된 제품의 부족한 점이 무엇인지를 발견하여 제품을 향상시켜주는 테스트를 의미한다.

애자일 팀에서 테스터의 역활

 - 고객팀 : 테스터는 고객이 요구사항과 예제를 이끌어내고 그들의 요구사항을 테스트를 통해 표현하도록 돕는 고객팀의 필수적인 구성원이다.

 - 개발팀 : 테스팅이 애자일 소프트웨어 개발의 중심 요소이므로 테스터 또한 개발팀에 속하여 고객의 입장에서 품질을 대변하고, 개발팀이 최상의 비즈니스 가치를 만들어내도록 지원한다.

 - 테스터는 기술적인 구현의 복잡성뿐만 아니라 사용자 관점 이해라는 두 영역 모두에 발을 담그고 있다.

애자일은 반복적이고 점증적이다. 테스터가 코드 작성의 매 증분을 완료하자말자 테스트를 한다는 것을 의미한다. 팀은 코드의 일부분을 빌드한 뒤 테스트하고, 제대로 작업했는지 확인하고, 그 뒤 빌드해야 하는 다음 부분으로  넘어간다. 스토리가 테스트되기 전까지는 완료된 것이 아니기 때문에 프로그래머는 절대 테스트보다 앞서 진행하지 못한다.

코드 작성을 염두에 두지 않고, 비즈니스 분성을 이용해 만든 요구사항 문서를 가지고 테스트를 만들어내기보다는 코딩이 시작되기 며칠 전 혹은 몇 시간 전에 각 스토리의 요구사항을 묘사하는 테스트를 작성해야 한다. 이 작업은 종종 비즈니스 또는 도메인 전문가와 테스터, 분석가, 일부 다른 개발팀 멤버간의 협력적 노력이 필요하다. 비즈니스 전문가가 제공한 사례에 기반하는 상세한 기능 테스트 케이스는 요구사항을 더욱 충실하게 만든다. 테스터는 정의된 테스트 케이스가 놓칠 수 있는 중요한 버그를 찾기 위해 수작업으로 탐색적 테스팅을 해야 할것이다. 테스터는 각 스토리의 코드를 작성하면서 테스트 케이스를 자동화하고 실행하기 위해 다른 프로그래머와 짝을 이뤄 함께 작업한다. 자동화된 기능 테스트는 회귀 테스트 수트에 추가된다. 최소한의 기능을 기술하는 테스트가 완료되었을 때, 팀은 스토리가 종료되었다고 간주할 수 있다.

애자일 팀에서 테스터는 코드를 운영 환경에 릴리즈 하는데 있어 전통적인 환경(폭포수 모델)에서 보다 더욱 핵심적인 역할을 하고있다. 테스터는 데이타베이스 업데이트 스크립트와 같이 릴리즈의 모든 요소가 제대로 되었는지 확이하기 위해 스크립트를 실행하거나 직접 테스트한다. 모든 팀 구성원은 모든 이터레이션이나 릴리즈에서 수행되느 검토나 기타 프로세스와 활동을 개선하기 위한 방식을 브레인스토밍한다.

애자일 프로젝트에서 테스터의 가장 중요한 차이점은 테스팅에서 빠른 피드백을 받는다는 것이다. 이 피드백은 프로젝트를 앞으로 나아가게 하며, 일정한 마일스톤에 이르지 못했다고 프로젝트진행을 차단하려는 문지기는 없다.

전체 팀(Whole-Team) 접근 방법

 - 애자일에서는 테스터나 품질 보증팀만 품질에 책임을 지는 것이 아니다. '부서' 단위로 생각하는 것이 아니라 최고의 제품을 도출하는데 필요한 기술과 자원에 대해서만 생각한다. 애자일 개발의 초점은 높은 품질의 소프트웨어를 비즈니스에 최대의 가치를 부여할 수 있는 시간 내에 내놓는 것이다.

 - 전체 팀 접근 방법은 지속적인 협력을 포함한다. 테스터는 테스팅 작업뿐만 아니라 기반 구조를 만들거나 테스트가 가능하도록 설계하는 것 등 테스트 관련된 다른 업무에도 프로그래머와 고객팀, 다른 전문가와 협력한다.

 - 애자일 팀에서 가장 중요한 것은 누구나 질문을 하고 도움을 받을 수 있다는 것이다. 팀은 가능한 최고의 비즈니스 가치를 제공하는 것에 집중하고, 이 가치를 인도하는 데 필요한 것은 무엇이든 지원받는다.

요약

 - 테스터가 애자일 팀에서 수행하는 활동을 이해하면 소속 팀에 테스터가 더할 수 있는 가치를 보여주는데 도움이 된다. 애자일 테스팅의 핵심 실천사항을 배우는 일은 팀이 고객을 기쁘게 할 소프트웨어를 만들어 내는 데 큰 도움이 될 것이다.

Chapter 2. 애자일 테스터를 위한 열 가지 원칙

애자일 테스터 : 전문적인 테스트로 변화를 포용하고 개발자에게 관리자까지 다양한 이해관계자의 의사소통에 능하며 요구사항을 문서화해 테스트를 사용하는 개념을 이해하고 개발을 이끄는 사람. 보통 기술적으로 뛰어나고 테스트를 자동화하기 위해 필요한 협업의 진행방법을 제시할 수 있으며, 또한 풍부한 탐색적 테스팅 경험을 가진 사람. 이들은 고객이 원하는 것을 열성적으로 배우기 때문에 고객의 소프트웨어 요구사항에 대한 이해도가 높다.

애자일 테스터는 정보를 모으고 나누며 고객 또는 제품 소유자와의 협업을 통해 그들이 정확하기 요구사항에 대한 피드백을 모두 제공한다.. 개인적인 측면에서 보면, 지역 사용자 그룹 미팅 등에 적극적으로 참여해 다른 팀은 어떻게 하고 있는지 알아보기도 하고, 새로운 도구를 도입하고, 테스트를 통해 고객 요구사항을 명세화하고 실행하고 자동화나는 팀의 제반 업무를 향상시킬 수 있는 방법을 모색하는 등의 일들이 포함된다.

훌륭한 테스터는 소프트웨어가 어디서 어떻게 잘못된 동작을 하게 되는지 그리고 이와 같은 오류를 추적하는 방법은 무엇인지에 대한 이해와 본능적인 감각을 가지고 있다.

애자일 테스팅 사고 방식은 결과 중심적, 예술가적, 상호 협적적, 배움에 대한 적극성, 일정에 맞춰 비즈니스 가치를 창출하려는 열정 등을 필요로 한다.

애자일 원칙과 가치의 적용

• 끊임없는 피드백 제공
• 고객 가치 창출
• 직접적인 의사소통
• 용기
• 단순함 지향
• 지속적인 개선 실행
• 변화에 대응
• 자기 조직화
• 사람 중심
• 즐기기

끊임없는 피드백 제공

 - 애자일 테스터의 가장 중요한 역할 중 하나는 제품 소유자나 고객으로 하여금 요구사항들을 예시나 테스트의 형태로 이야기할 수 있도록 도와주는 것이다. 테스트는 이와 같이 확인된 요구사항을 팀워들과 함께 실행 가능한 테스트로 만들게 된다. 테스터와 프로그래머, 기타 팀원들은 조기에 이 테스트 수행을 위한 작업을 하고 중요한 피드백을 받아 지속적으로 올바른 개발 방향의 지침으로 삼는다.

고객 가치 창출

각 이터레이션에서 약속한 기능을 확실하게 제공하기 위해서 우리 팀은 요구 기능의 "주 경로"나 "얇은 조각"을 식별하기 위해 각각의 스토리를 분석해 검토한다. 우리는 이렇게 식별된 작업들을 우선적으로 완료하고 나머지 기능을 구현하는 식으로 접근한다. 이와 같은 방식에서 나올 수 있는 최악의 시나리오는 핵심 기능만 구현해 릴리즈하는 것이다. 물론 아무것도 제공하지 못하거나 절반만 제대로 동작하는 것보다는 낫다.

 - 애자일 테스터는 위와 같은 접근법을 취하게 된다. "주 경로(정상 경로)"를 위해 테스트 케이스를 식별하는 것이 필요한 기술 중 하나지만 이 같은 정상 경로가 제대로 동작하는 것인지를 확실히 하는 것부터 시작해야 한다. 정상 경로에 대한 테스트 자동화를 우선 적용하고 비정상 및 경계치 테스트를 이후에 추가할 수 있다. 고객에게 가장 중요한 가치가 무엇인지를 항상 명심하고 목표를 이해해야 한다.

대면을 통한 커뮤니케이션 

 - 애자일 테스터는 커뮤니케이션을 위한 독자적인 방법을 찾아내야 하며 이것은 직무를 잘 수행하는데 필요한 핵심 항목 가운데 하나다. 테스터는 결코 고객과 개발자 간의 직접적인 커뮤니케이션에 끼어드는 역할이 되어서는 안되며 오히려 이와 같은 커뮤니케이션이 잘 이어질 수 있도록 돕는 역할을 할 수 있다.

 - 애자일 테스터는 각각의 스토리나 테마를 고객의 입장에서 바라보는 한편 기술적인 측면과 기능들을 구현할 때의 제한사항들을 이해해야 한다. 또한 고객과 개발자를 토와 서로 이해할 수 있도록 하기도 한다.

용기

 - 용기는 XP의 핵심 가치이며 테스트 자동화나 지속적인 통합 등은 이 가치를 이끌어내는 과정이라고 할 수 있다. 

단순함 지향

 - 애자일 테스터와 팀은 가능한 단순하게 소프트웨어를 구현해야 할뿐만 아니라 고객 요구사항을 확실하게 만족하는지 확인하는 방법에 있어서도 단순한 접근법을 선택해야 한다. 다눈하다고 해서 테마나 스토리 분석과 적절한 아키텍처와 설계 검토에 시간을 적게 투자해야 한다는 것을 의미하는 것은 아니며, 요구사항이 조금 자세하거나 보다 손쉽게 구현할 수 있는 솔루션이 있는 경우 여기에 매달려 시간을 보내기보다는 이런 것은 비즈니스 쪽에서 해결할 수 있도록 미루는 것이 좋다는 의미이다.

 - 팀은 고객이 올바른 결정을 내릴 수 있도록 도울 수 있는 단순하고 단계적인 업무 접근을 취해야 한다. 애자일 테스팅은 가능한 최소한의 테스트를 통해 해당 기능 요소가 포함되어 있는지, 또는 고객의 품질 표준을 만족하는지를 검증하는 것을 의미한다.

 - 테스터들에게 있어서 간단하는 것은 최소한의 도구와 기법을 활용한 "딱 적당한 정도의" 테스팅을 의미한다. 여기서 최소한의 도구는 스프레드시트나 체크리스트다. 빠른 피드백을 얻어내기 위해서는 Regression Test에 대한 자동화를 최대한 세부적인 부분에까지 적용할 필요가 있다. 비즈니스 중심 테스트 자동화는 Smoke Test 정도로 충분할 수 있다.

 - 애플리케이션에 대한 합습과 매우 찾기 힘든 버그를 찾는데 탐색적인 테스팅을 활용할 수 있는데 제한된 일정돠 목적을 확실히 해야 한다. 이와 같은 단순성은 위험, 투자 수익, 그리고 가장 취약한 부분에 있어서의 개선에 계속 집중 할 수 있도록 해준다.

지속적인 개선 실행

 - 테스터는 팀의 과거 업무를 돌아보고 어떤 것이 좋았고, 또 어떤 부분에 개선이 필요한지를 평가하는 미팅에 참여하고 전체 팀이 검토해야 할 테스팅 이슈를 제기한다. 

 - 애자일 테스터와 그가 속한 팀은 항상 고객의 투자에 대해 더 나은 이익을 내고 가치를 창출하는 데 도움이 될 수 있는 도구와 기술, 새로운 기법들을 탐색한다. 애자일 개발에서의 짧은 반복은 이런 도구나 기술의 도입 효과를 확인하고 장기간의 프로젝트에 대한 적용 여부를 판단하는 데 유용하다.

 - 새로운 기술을 배우고 전문가로 성장해 가는 일은 애자일 테스터에게 매우 중요한 부분이다. 테스터들은 각종 모임이나 컨퍼런스에 참석하고, 메일링 리스트에 가입하거나 관련 기사와 블로그, 서적을 통해 새로운 아이디어를 얻는다. 또 일상적이거나 반복적인 업무를 자동화 함으로써 생기는 여유 시간을 자신의 전문적인 가치를 향상시키는데 투자한다.

- 회고하는 과정은 애자일에서 팀이 과거의 경험을 토대로 미래에 더 나은 업무 수행을 할 수 있게 해주는 핵심 요소다. 애자일 테스터는 회고 과정에서 테스팅과 관련된 이슈들을 제기하고 팀은 이슈들을 해결하기 위한 방법을 찾기 위해 진행한다. 이와 같은 과정를 통해 팀은 스스로에게 피드백을 제송하면서 지속적인 개선을 이루어 간다.

 - Episode : 우리 팀은 회고 방법을 매우 유용하게 잘 사용해 왔는데 어느 순간 좀 더 새로운 무언가가 필요하다고 느꼈다 나는 생산성을 저하시키는 항목들을 모아서 "방해 목록"으로 만들자고 제안했다. 이 목록에 첫 번째 항목으로 내가 적은 것은 테스트 환경의 느린 응답속도였다. 그것을 본 시스템 관리자가 어디서 빠르고 멋진 새 서버들을 구해와서 테스트 환경에 투입했고, 데이터베이스 관리자가 테스트 데이터베이스 성능 분석을 통해 하나의 디스크를 이용하는 시스템이 방해 요소라고 결론을 내자 프로그램 과리자는 선뜻 RAID를 설치해주었다. 곧 빌드 배포와 탐색적 테스팅을 훨씬 빨리 수행할 수 있었다.

변화에 대응

 - 변경에 대한 대응은 애자일을 실천하고자 하는 이들에게는 핵심 가치 중 하나인 동시에 테스터들에게는 가장 어려운 개념 중 하나이다. 안전성이야말로 테스터에게 있어서 어쩌면 가장 중요한 가치이며, 그런 의미에서 "그건 내가 테스트했어. 완료된 항목이야"라고 말할 수 있는 것이다. 따라서 계속 변경되는 요구사항은 테스터에게는 악몽이라 할 수 있다. 그러나 애자일 테스터로서 우리는 변경을 기꺼이 받아드려야 한다. 

 - 일부 애자일 팀에서는 상위 수준의 테스트 케이스를 작성 비즈니스 만족도 조사, 예제 작성 등을 통해 다음 반복을 미리 준비하기로 한다. 이런 경우 스토리 우선 순위에 변경이 생기면 시간 낭비가 될 수 있다는 점을 인지해야 하며, 분산되어 운영되는 팀 환경에서는 추가적인 피드백 사이클이 필요하다.

 - 수작업 테스트만 수행해서 성공하는 애자일 팀은 있을 수 없다는 것은 분명한 사실이다. 비즈니스 가치를 적시에 제공할 수 있기 위해서는 강력한 자동화가 필요하다.

자기 조직화

 - 애자일 테스터는 자기 조직화하는 애자일 팀의 한 부분이다. 팀 문화는 애자일 테스팅 철학을 구성원에게 제공하며 프로그래머, 시스템 관리자, 분석가, 데이터베이스 전문가, 고객 팀 모두가 지속적으로 테스팅과 테스팅 자동화에 대해 고려하게 되면 테스터는 완전히 새로운 관점을 경험할 수 있게 된다. 테스트 자동화는 분명 어려운 과제이지만 전체 팀이 참여한다면 훨씬 쉬워진다. 어떤 테스팅 이슈라도 다양한 기술과 관점을 가진 사람들과 함께 대응하면 풀어나가기 용이한다.

 - 애자일 팀이 큰 문제에 봉착했다면 아마도 한사람만 뛰어나거나 빌드가 깨진 경우일 것이다. 이런 중대 이슈는 팀원 전체가 풀어야 할 과제이다.

사람 중심

 - 애자일 팀에 속한 모든 사람들은 기술적인 기량 향상과 사회적인 성장의 기회를 공평하게 가져야 한다. 또한 애자일 팀은 적절한 작업 페이스를 유지함으로써 원칙과 규칙에 따라 업무를 수행하고, 항상 새로운 시각을 유지할 수 있다.

 - 애자일 철학을 충실히 따르는 애자일 팀에서 팀 구성원 간의 우선순위란 있을 수 없다. 애자일 테스터들은 자신이 팀에서 가지는 공유의 가치를 확실히 인식하게 되었고, 개발팀은 특정한 테스팅 기법과 경력을 가진 사람의 도움이 팀의 성공을 위해 필요하다는 것을 알게 되었다. 테스팅 지식은 가치 창출을 위해 모든 개발팀에 필요한 중요한 하나의 컴포넌트라고 할 수 있다.

즐기기

 - 애자일 테스터로서 우리의 직업이 만족스러운 것은 바라보는 관점과 기술이 팀 전체에 진정한 가치를 더할 수 있도록 해주기 때문이다.

가치 부여

 - 모든 원칙은 비즈니스 가치를 창출하기 위한 것이다. 애자일 개발에서 전체 팀은 고품질의 소프트웨어를 개발해냄으로써 고객을 만족시키고 비즈니스 이익을 창출할 수 있도록 하는 책임을 가진다. 이것은 다시 비즈니스에 새로운 이득을 가져다준다.

 - 애자일 개발은 사람들은 전문분야로 구분하는 것을 피하고 있기 때문에 팀 구성원은 대부분 일인다역을 한다.

 - 애자일 테스터는 시스템의 사용자 관점뿐만 아니라 개발팀이 직면한 기술적인 제약이나 세부 구현 측면도 고려해야 한다. 애자일 테스터는 개발 초기부터 고객과 개발자 모두에게 자주 질문을 던져 올바른 테스트를 수행할 수 있도록 한다.

 - 애자일 테스터는 전통적인 폭포수 유형의 개발 프로젝트에서 일하는 테스터에 비해 훨씬 통합적이고 팀 지향적인 접근을 통해 업무를 진행한다. 애자일 테스터는 그들의 기술과 경험을 팀과 프로젝트에 적절하게 도입한다.

요약

 - "애자일 테스팅 사고방식"은 적기에 비즈니스 가치를 창출하기 위한 고객/결과 중심적이고 협력적, 창조적이면서 배움에 열정적인 창조적이면서 배움에 열정적인 자세이다.

 - 업무에 임하는 자세는 매우 중요한 항목이며 테스터, 프로그래머 그리고 기타 다른 역할들 간의 명확한 경계 없이 임해야 한다.

 - 애자일 테스터는 피드백, 커뮤니케이션, 용기, 단순성 등의 애자일 가치와 원칙을 적용하며 팀이 각 스토리에 대한 고객 요구사항을 식별하고 기능을 제공하는 데 도움을 주기 위한 역할을 수행한다.

 - 애자일 테스터는 테스터로서의 고유한 관점과 팀 중심의 접근을 통해 팀과 조직에 가치를 더한다.

Chapter 3. 문화적 과제

조직문화

조직 문화는 조직의 가치, 규범, 가정에 의해 정해진다. 조직의 문화는 애자일 팀의 성공에 영향을 미친다. 애자일 팀은 독립적인 사고가 가능한 조직에 가장 적합하다.

품질 철학

 - 전체 팀이 품질을 책임진다.

 - 기술과 적응력

 - 도움 요인 : 테스터들의 조정을 위해 경험이 많은 애자일 테스팅 코치가 필요하다.

진행 속도 유지

 - 애자일 프로젝트는 일정한 개발 속도를 유지하도록 권장한다. 이는 팀에서 고품질의 기준을 유지할 수 있도록 일정한 진행 속도를 지속해야 함을 의미한다.

 - 단기간 동안 초과 근무가 필요하다면 팀 전체가 초과 근무해야 할 것이다.

고객 관리

 - 애자일 개발에서는 고객의 침밀한 참여가 중요하며 적어도 대리인이라도 참여해야 한다. 애자일 팀은 협력을 위해 고객을 초청하며 개발 과정에 직접 참여할 수 있도록 가능한 한 같이 작업한다. 이렇게 하면 양자는 서로의 강점과 약점을 배울 수 있다.

 - 관계 측면에서 고객이 내부에 있든지 외부에 있던지 이러한 변화를 양쪽 모두 인식해야 한다. 열린 관계는 애자일 프로젝트에 있어 성공의 열쇠가 된다. 고객팀과 개발팀의 관계는 협력사-공급자의 관계가 아닌 파트너와 같다.

 - 몇몇 대표적인 도메인 전문가들은 통해 모든 이해 관계자들이 지속적으로 정보를 제공받는 것은 개발자-고객 간의 성공적인 협력관계를 위한 한 가지 접근 방법이다. 그들이 무엇을 구축할지를 최우선적으로 고려하며 제품의 품질에 있어 최종 결정권을 가진다. 테스터들은 요구사항을 알기 위해서 고객과 친밀하게 작업하고, 만족 조건에 부합하는지를 판별하는 "인수 테스트(Acceptance tests)"를 정의한다. 테스팅 활동은 개발팀-고객팀 관계의 핵심이다. 그것이 테스팅 전문가가 애자일 팀에 필수적인 이유다.

조직 규모

 - 커뮤티케이션 과제 : 큰 규모의 회사에서 더 흔한 문제는 더 작은 규모의 회사처럼 고객에게 접근할 수 없다는 것이다. 이는 요구사항과 예제를 수집하고, 개발 주기에 걸쳐 고객의 참여를 유도하는데 큰 장애가 된다. 해결책은 고객을 대신하는 역할을 수행할 수 있는 전문 지식을 갖춘 테스터나 분석가를 보유하여 문제를 해결하는 것이다. 커뮤니케이션 도구는 이와 같은 상황을 잘 처리하도록 돕는다.

 - 조직 내의 문화 충돌 : 큰 규모의 소프트웨어 개발 부서에서 애자일 개발은 보통 한 팀이나 몇몇 팀에서 적용한다. 애자일 팀에서 단계별 개발과 점진적 개발 같은 서로 다른 접근법을 사용하는 다른 팀과 조정을 해야한다면 일련의 추가적인 어려움이 있다. 또한 자신들의 영역에 방어적인 전문가 팀의 저항을 만날 수 있다. 이런 문화 기반의 차이점을 경감시킬 방법에 대해 생각해 봐야 한다.

• 더 세부적인 계획
• 일반 행동하고 나중에 사과하라

팀에 대한 부여

 - 애자일 프로젝트에서 각 개발팀에게 의사 결정권을 부여하는 것이 중요하다.

테스트/QA팀에서 애자일 채택을 가로막는 장애물

정체성(Identity) 상실

 - 테스터는 많은 이유로 독립적인 QA팀을 고수하지만 분명 주요 원인은 두려움이다.

• 자신의 QA 정체성을 잃을 수 있다는 두려움
• 개발 관리자에게 보고할 경우 지원이 끊기고 프로그래머가 우선시 될까 하는 두려움
• 애자일 팀에서 일에 대한 기술 부족으로 인해 직장을 잃을까 하는 두려움
• 자신과 자신들의 관리자가 새로운 조직에서 적응하지 못할까 하는 두려움

역할 추가

 - 제품의 성공을 위해 필요로 하는 역할이 무엇인지 분석하는데 시간을 들여야 한다.

훈련 부족

 - 우리가 처음 애자일 팀과 일하기 시작했을 때는 애자일 테스터가 해야할 일과 팀 안에서 함께 일하는 방법에 대해 배울 수 있는 자료가 많지 않았다. 오늘날에는 테스터가 애자일 환경에 적응할 수 있도록 훈련시킬 수 있고 테스트 팀이 애자일로 전환할 수 있도록 도와주는 전문가를 쉽게 찾을 수 있다.

애자일 개념에 대한 몰이해

 - 애자일 개발에는 XP, Scrum, Crystal, FDD, DSDM, OpenUP 그리고 이들을 다양하게 혼합한 형태 등의 다양한 접근 방법이 있다. 그러나 애자일 핵심 가치와 원리를 전혀 따르지 않는다면 애자일이란 이름을 내거는 것에 의문을 가질 수밖에 없다. 

 - 사용해야하는 실천법이나 이들 실천법을 훈련시키는 방법과 같은 "애자일"의 구성 요소에 대해 팀의 구성원 서로 간에 반대되는 개념을 가지고 있다면 문제가 일어날 것이다.

 - 팀이 애자일로의 성공적인 전환을 하려면 어떻게 나아갈 것인지에 대한 공감대가 있어야 한다.

 - 제품을 만들어 인도하는 데 관여하는 모든 사람들은 핵심 실천 사항뿐만 아니라 애자일의 기반 개념들을 이해하기 위한 시간과 훈련이 필요하다.

 - XP(eXtreme Programming)는 팀의 핵심 XP 실천 항목에 대한 적응 수준을 측정하기 위해 레이터 차트를 개발했다.

• 팀
• 프로그래밍
• 계획
• 고객
• 짝짓기(두 명의 개발자가 드라이버와 옵저버로 역할을 나눠 함께 개발하는 짝 프로그래밍) 

과거의 경험과 자세

 - 사람들은 자신들의 오래되고 성공적이지 못한 패턴을 고수한다. 새로운 무언가를 시도하려 할 때도 스트레스로 인해 낡고 오래된 습관으로 돌아갈지도 모른다. 애자일 개발로의 전환에 직면했을 때 이런 부류의 사람들은 종종 새로운 프로세스에 기회를 주지 않고 떠나버린다. 애자일 개발이 모두를 위한 것은 아니지만 실험을 위한 훈련과 시간은 이러한 태도를 개선하는데 도움이 될 수 있다.

역할 간 문화적 차이

 - 팀은 의사소통이 원활하도록 규칙과 가이드라인을 제공해 함께 어울려 작업할 수 있다. 

 - 다른 행동을 취하는 사람들에게 무엇이 필요한지 파악하고 제공할 방법을 알아내도록 하라. 

• 고객 : 개발을 어떻게 진행하는지 또는 고객의 만족 조건에 부합하는지 알수 있는 방법이 필요하다.
• 개발자 : 비즈니스 우선 순위와 요구 사항을 알아야 한다.
• 테스터 : 사례를 찾고 그것을 테스트로 변환하는 방법이 필요하다.

 - 각 팀 구성원은 이슈를 제기하고 새로운 아이디어를 시도하는데 있어 편하고 자유로워야 한다. 각 역할의 관점을 이해하면 전화 시 팀에게 도움이 된다.

변화에 대해 알리기

변화를 시행할 때 부작용을 주의하라. 팀은 새로운 프로세스가 무엇인지 확실하지 않으면, 일부 그룹에서는 낡은 방법을 고수하려고 할 수도 있고 일부는 불안해하며 분열될 수 있다. 이를 피하려면 먼저 변화 모델을 설명하고, 기대를 심어줘야 한다. 기대가 있으면 애자일 프로세스 시행 초반의 혼란을 예상하고 받아들인다. 가장 골칫거리인 부분을 찾아 문제를 해결할 수 있는 실천법이 무엇인지 알아내면 혼란에서 벗어나 프로세스를 즉각 진행할 수 있다. 

두려움에 관해 이야기하라

 - 반복적인 개발이 시작될 때, 사람들에게 그들의 두려움에 대해 이야기하고 피드백을 줄 수 있는 장소를 제공하기 위한 회고를 활용하라.

 - 열린 마음으로 두렵거나 불편하다고 말하는 것을 인정하도록 가르치라.

 - 테스터의 권리장전

• 테스터는 테스팅과 품질, 프로세스와 관련된 이슈를 언제든지 제기할 권리가 있다.
• 테스터는 고객과 프로그래머, 다른 팀 구성원에게 질문하고 적시에 답변받을 권리가 있다.
• 테스터는 프로그래머와 관리자, 고객 등 어느 누구에게든지 도움을 요청하고 받을 권리가 있다.
• 테스터는 테스팅 작업을 추정하고 스토리 추정에 포함시킬 권리가 있다.
• 테스터는 시기적절한 방법으로 테스팅 작업을 수행하는데 필요한 도구를 사용할 권리가 있다.
• 테스터는 혼자가 아니라 전체 팀이 품질과 테스팅에 책임이 있음을 기대할 권리가 있다.

팀에게 주인의식 심어주기

 - 자기 조직화된 팀은 자신의 문제를 스스로 발견하고 해결해야 한다.

 - 자기 조직화된 팀을 포함한 모든 팀에서 조직의 관리팀과 효과적으로 상호 작용하는 리더가 필요하다.

성공 축하하기

 - 변화를 시행하면 시간이 걸리고, 혼란스러울 수 있으므로, 팀에서 성취한 모든 성공을 반드시 축하하자.

기대 관리

성공적인 애자일 적용을 위해 관리는 핵심적이다. 단계적인 프로젝트에서 관리란 정기적으로 업데이트를 하고 각 단계의 끝을 나타내는 문서에 서명하는 것이다.

관리자가 겪는 문화적 변화

 - 폭포수 프로젝트에서 "이 기능은 90% 완료됐어"라는 말을 들은 적 있을 수 있지만 이런 수치는 애자일 프로젝트에서 큰 의미가 없다. 단계의 끝을 나타내는 서명은 없으며 프로젝트의 "완성도"를 단계별로 측정하지도 않는다.

 - 의미있는 측정 지표는 각 프로젝트 팀이 결정한다. 테스트 측정 지표는 기능 테슽  범위를 추적하는 데 사용될 수 있지만 승인된 문서(sign-off document)로 제공하지 않는다.

 - 일부 관리자가 받아들이기 힘들어하는 변화 중 하나가 팀이 스스로 기술적인 결정을 내리고 업무 부하를 관리하도록 하는 것이다. 성공적인 어플리케이션을 만들어 내기 위해 필요한 품질 수준을 정의해줄 고객이 포함되어 있는 팀이 하는 것이다.

 - 저수준으로 팀의 활동을 관리하기보다는 애자일 팀의 관리자는 팀 구성원이 최선을 다할 수 있도록 장애물을 제거하는 것에 초점을 맞춰야 한다.

전통적인 폭포수 형식 프로젝트에서는 프로젝트 막바지까지 일이 잘 진행되고 있다고 보고서를 보여주다가 결국 마지막에는 진행된 게 아무 것도 없음을 알고 패닉 상태에 빠지게 될 수 있지만, 애자일 프로젝트에서는 매일 해결해야 되는 문제들이 있고, 애자일 프로젝트에서는 요구 사항에 맞추느라 더 많이 일하게 되었지만 적어도 현실성 있는 보고를 받고 있으며 그렇게 때문에 프로젝트의 후반부에서 당황하는 일은 없다.

태는 애자일로 전환하려는 테스터들을 위해 다음과 같이 조언했다. "일반적으로 애자일 개발은 처음에는 테스터들이 전체적인 요구 사항 문서나 테스팅에 대해 정의된 단계(Stage)에 접근할 수 없을 것이라는 점에서 불만스러울 것이다. 애자일 개발에 대한 나의 견해는 테스터는 언제든지 전통적인 개발 프로세스의 여러 단계부터 작업에 참여해야 할 것이다. 테스터도 엔지니어링, 제품 관리와 함께 디자인 세션에도 참여할 수 있고 당일 제시된 병경 사항에 대해 테스트케이스를 자동화하고 실행할 수 있다.(테스터는 여기에 주목해서 제시괸 코드 변화가 영향을 줄 수 있는 영역의 위험성을 고려하기 시작할 것이다.) 이는 사고 방식의 변화이며 일부는 다른 사람들보다 더 빨리 적응한다."

 - QA 관리자라면 정의된 순차적인 테스팅 단계를 빠른 속도의 이터레이션으로 이동시켜 언제든 다양한 작업을 폭넓게 수행하게 함으로써 테스터의 불만을 극복하는데 도움을 제공하자. 또 테스팅이 더이상 개발 후에 발생하는 별개의 활동이 아니라 테스팅과 코드 작성이 통합된 활동이라는 생각을 받아들이도록 도와야 한다.

관리자의 언어로 말하기

 - 관리자에게서 필요한 지원을 받으려면 그들이 이해할 수 있는 내용으로 여러분의 요구를 표현하도록 하라. 

 - 애자일 팀의 모든 구성원들과 마찬가지로 관리자도 새로운 개념을 학습하고 팀 구성원들과 잘 어울리는 방법을 알아야 한다.

 - 팀이 새로운 과제를 만날 때마다 가치 있는 제품을 생산하기 위해서 개발팀과 관리 조직이 서로 도울 수 있는 새로운 방법을 실험해보도록 하자.

쉽지않은 변화

애자일 개발은 빠른 속도를 가진 것처럼 보이지만 변화는 더디다. 팀에게 긍정적인 변화를 짠~하고 가져다주는 마법은 없지만 자신의 팀이 긍적적인 방향으로 변화하길 바라는 테스터들을 위한 몇가지 팁이 있다.

인내하라

 - 팀이 TDD 같은 신기술들을 익히는데 필요한 시간을 확보할 수 있는 방법을 찾아야 한다. 기다리는 동안 독립적으로 만들어 낼 수 있는 변화를 찾아야 한다.

고통을 느끼게 놔두기

 - 개선을 위한 여러분의 제안이 묵살당하고 팀이 실패한다면, 이때 일부 이터레이션 단계에서만이라도 시도해보도록 다시 제안하자.

신뢰 쌓기

 - 테스터와 일해본 적이 없는 프로그래머들과 함께 작업할 때 그들에게 당신이 어떤 도움을 줄 수 있는지 보여주자.

자신만의 개발 전문성을 갖고 일하기

 - 책이나 신문기사를 읽거나 사용자 그룹 미팅이나 컨퍼런스에 참석하고 새로운 도구나 스크립팅 언어를 배우자.

품질 경찰 정신(Quality Police Mentality) 경계하기

 - 집행자가 아닌 협력자가 되자. 팀과 함꼐 문제를 제기하고 그들에게 도움을 요청해라.

불만 표출하기

요약

 - 어떤 변화든지 우선 조직의 문화를 고려하자.

 - 조직 전체가 품질을 가치있게 여기면 테스터와 애자일 팀이 더 쉽게 융화된다. 하지만 "품질 경찰"의 마음가짐을 가진 테스터들은 어려울 것이다.

 - 변화를 도입하고 의사소통을 촉진하려면 두려움에 대해 논의하고 아주 작은 성공이라도 축하해주어 팀 구성원을 격려하자.

 - 관리자는 그들 자신의 문화적 과제와 직면했을 때, 애자일 팀에서 테스터의 성공을 돕기위해 지원과 훈련을 제공해주어야 한다.

 - 변화는 쉽지 않으므로 인내하고 자신의 기술을 향상시키면서 일하라. 그래야 팀에 도움이 될 수 있다.

Chapter 4. 팀 전략

팀 구조

애자일 팀에서 별개의 기능 그룹을 만들면 삶이 고달파진다. 지속적인 의사소통은 애자일 팀에 있어서 생명과 같다. 팀 구성원은 물리적인 위차의 멀고 가까움에 관계 없이 업무 진행에 있어 서로 밀착되어 있어야 한다.

독립된 QA

 - QA팀이 개발팀과 별개로 유지되어야 하는 이유

• QA팀의 독립적인 확인 및 참관 역활이 중요하다.
• 제품의 품질에 대한 객관적이고 제3자적인 관점을 제공할 수 있다.
• 테스터와 개발자의 관계가 너무 가까우면 테스터가 개발자처럼 생각하게 되고 고객 관점에서 생각하지 못하게 된다.
• 테스터와 개발자가 같은 사람에 보고하는 조직의 경우 테스트 완료된 코드가 아니라 어떤 코드라도 인도하기만 하면 된다는 식으로 흘러갈 수 있다.

애자일 프로젝트와 테스터의 융화

 - 개발자의 경우 짝 프로그래밍, 테스트 주도 개발 등의 애자일 기법을 배우는 기회를 제공받는데 반해 테스터들에게는 아무런 훈련도 제공하지 않는 경우가 적지 않다. 테스터에게 짝 테스팅, 불완전하거나 계속해서 변경되는 요구사항에 대처하는 방법, 자동화 등의 다양한 기법에 대한 습득이 필요하다는 사실을 모르는 조직이 많다. 테스터들에게 이러한 영역에 대한 교육과 지도가 매우 중요하며 이러한 지원을 통해 테스터들은 프로젝트 성공을 위한 각종 기술 습득과 이해를 얻을 수 있다.

 - 프로그래머와 테스터를 함께 엮어두면 제품 품질에 대한 의사소통을 보다 효과적으로 향상시킬 수 있다.

 - 애자일 개발을 위한 조직 개편에 성공하려면 계획단계에서부터 영리하게 대처해야 한다. QA와 개발 관리자에게 새로운 애자일 조직에서 자신의 역할이 무엇인지 스스로 정확하게 인지하도록 요구한다. 그리고 그들이 테스터와 개발자를 도와 새로운 팀의 생산성을 극대화 할 수 있는 방법을 찾아낼 수 있도록 유도한다. 팀원들이 아직 익히지 못한 애자일 기법에 대한 교육을 제공하고 모든 팀원들이 상호 의사소통할 수 있도록 한다. 또한 팀이 성장하면서 스스로 학습하고 프로젝트를 성공적으로 이끄는 방법을 찾아낼 수 있는 프레임워크를 제공하도록 한다. 

관리자의 역할을 우선 확인시키고 빌드 프로세스 프레임워크를 도입하여 소스코드 제어에 대한 모든 것을 관장하도록 하는 것이야말로 애자일 체제로 이행하는 과정의 핵심이다. 다른 핵심요소로는 모든 팀(기술팀, QA, 형상관리, 네트워크, 시스템 관리, 생산팀 등)의 대표자가 일일 업무 회의에 참여하도록 하는것이다. 이렇게 하면 테스팅 이슈 발생시 도울 수 있는 모든 사람이 해결을 위해 힘을 모을 수 있다.

애자일 프로젝트 팀

 - 일반적으로 애자일 프로젝트 팀은 다양한 분야의 전문성을 갖춘 구성원들로 이루어져 있기 때문에 협업이 중심을 이루는 것으로 인식한다. 테스터 역시 팀의 일원으로서 이드의 일일 업무 역시 나머지 프로젝트 팀 업무와 동등하게 관리된다. 테스터는 다양한 프로젝트에 소속되고 일하고 있는 많은 테스터들로 구성된 커뮤니티에 자신의 아이디어를 개진하고, 의견을 교환할 수 있다. 이런 방법으로 테스터들은 서로의 지식과 생각을 교환할 수 있다. 성능 검토를 수행하는 조직의 경우, QA 관리자가 검토를 진행하고 프로젝트 팀의 의견을 수렴한다.

 - 함께 일하는 방법을 알고 팀원 간의 신뢰가 형성된 팀이야말로 최고의 팀이다.

물리적인 실행 계획

애자일 가치와 원칙들을 제대로 지원하는 데는 팀 구성원 간의 접촉이 용이하고 프로젝트 진행 상황판이 보이는 곳에 있고 의사소통을 증진 시킬 수 있는 환경이 유리하다.

팀을 모두 한군데 모아 두는 것이 항상 가능한 것은 아니며 분산된 팀을 꾸려야 하는 경우에는 또 다른 해결 과제가 있다. 분산되어 운영되는 팀은 의사 소통과 협업을 위한 기술이 필요하다. 전화회의, 화상회의, 웹캠, 메신저 등을 이용하면 서로 떨어져 있는 팀이 효과적으로 실시간 협업을 이루는 데 도움이 왼다.

자원

테스터-개발자 비율

 - 단순한 비율만 보기보다는 팀에 필요한 테스팅 기술이 무엇인지 평가하고 적절한 자원을 찾는 노력이 필요하다.

 - 테스팅을 담당하는 팀은 지속적으로 필요한 전문적으로 필요한 기술 수준이나 능력에 대한 목표를 제시하고 발전해 나가야 한다. 효과적인 문제 해결을 위해서 테스터를 더 고용해야 할지를 결정하기 위해서는 회고 회의를 적극적으로 이용할 필요가 있다.

애자일 테스터 채용

 - 팀 내에서 테스터와 프로그래머는 자신의 역할 이상을 해낼 수 있어야 한다. 역할과 무관하게 가장 중요하게 고려해야 할 것은 그 사람이 여러분의 팀에 얼마나 잘 어울릴 것인가를 보는 것이다.

 - 애자일의 전체 팀 접근법에서는 팀 구성원들은 때에 따라 자신의 전문 분야를 벗어난 작업에 대한 협업도 해낼 수 있어야 한다. 각 팀원은 품질, 비즈니스 가치 제공에 대한 강한 의지를 가져야 한다.

팀 구축

자기 조직화 팀

 - 팀은 문제점을 스스로 인지하고 해결할 때 최고의 성과를 낸다. 

 - 새로 꾸려진 애자일 팀이 다양한 문제에 대한 우선 순위를 제대로 파악하고 대처해내기 위해서는 어느 정도 시간이 필요하고 당연히 이 과정에서 수차례 시행착오를 겪을 수 있다.

타 팀과 공조

 - 성공적인 프로젝트 수행을 위해서 다른 팀을 포함시켜야 하는 경우가 있다. 이때 회의를 소집하고 최고의 의사소통을 이끌어낼 수 있는 방법을 찾아야 한다. 

 - 팀이 여러 군데 흔터져있거나 동일 시간대의 지역에 있지 않은 경우라면 최대한 직접적인 으사소통이 가능한 방법을 찾아내도록 한다.

모든 팀원에 대한 동등한 가치 부여

 - 팀의 모든 구성원은 동일한 가치를 갖는다. 테스터라든가 혹은 다른 어느 팀원이라도 소외감을 느끼거나 자신의 가치에 의구심을 가지게 된다면 전체 팀 접근법에 큰 위협이 아닐 수 없다.

 - 테스터는 반드시 모든 회의에 초대되어야 한다.

 - 테스터는 도움을 요청할 권리가 있다.

성과와 보상

 - 개별적 성과를 측정하고 정량화하는 것은 팀 협업을 약화시킬 수 있는 위험을 내포하고 있다.

당신이 할 수 있는 것

 - 애자일 원칙을 따를 때 협업하면서 업무 능률을 높이기 위해 피드백을 활용해야 하고, 또 목표 달성을 위해 항상 새롭고 더 나은 방법을 강구하는 자세를 유지해야 한다. 

요약

 - 팀 구조의 중요성을 고려하자.  테스터는 독립된 사고방식이 필요하지만, 그렇다고 해서 별도의 팀으로 만든느 것은 역효과를 불러올 수 있다.

 - 테스터들은 학습과 새로운 아이디어의 시도를 위해 보다 큰 하나의 커뮤니티에서 활동하는 것이 필요하다. QA팀은 조직 내에서 이런 커뮤니티를 만들어낼 수 있다.

 - 성공적인 협업을 위해 전체 팀이 모두 한 자리에서 위치하는 것은 매우 중요하다. 팀이 분산되어 있다면, 원격 의사소통을 지원하기 위한 도구를 활용하여야 한다.

 - 채용 시 업무에 임하는 자세를 중요시하라.

 - 테스터와 개발자에 대한 황금 비율은 없다 한마디로 "그때그때 달라용~!!"

 - 팀은 자기 조직적일 필요가 있다. 팀이 직면한 문제점을 식별하고, 해법과 개선 방안을 스스로 찾아낼 수 있어야 한다.

 - 경영진은 팀 활력을 높여 비즈니스 가치를 젯공하는 성과에 대해서는 보상해야 하지만 팀이 고전한다고 개인들의 뛰어난 성과에 불이익을 줘서는 안된다.

 - 테스터는 애자일 원칙을 통해 자신의 기술력을 향상시키고 팀 내에서의 가치를 높여갈 수 있다. 그러기 위해서는 자신이 팀을 위해 할 수 있는 것이 무엇인지 주도적으로 찾아낼 수 있어야 한다.

Chapter 5. 전통적인 프로세스 전환하기

가벼운 프로세스 찾기

 - 애자일 프로젝트를 테스팅할 때 모든 것이 새롭고 다르다고 말하는 것은 어불성설이다. 왜냐하면 진행사항을 측정하거나 결함을 추적하거나 테스팅을 계획하는 방법은 여전히 필요하기 때문이다. 또한 조직의 품질 모델에 맞게 준비할 필요도 있다. 중요한 점은 우리가 제시간에 가치를 전달할 수 있도록 이러한 프로세스를 가볍게 유지하는 것이다.

측정 지표

린 측정

 - 근본적인 린 측정 :  "개념에서 현금으로", 즉 고객의 요구사항에서 소프트웨어로 가는데 걸리는 시간 - 메리와 톰 포첸딕의 <린 호스트웨어 개발의 적용 : 속도전쟁에서 승리하기>

 - 린 특정에 대한 특정 값을 "사이클 타임이라고 한다." 가장 중요한 것은 새로운 비즈니스 가치를 만드는 팀의 "반복성과 신뢰성"이다. 그러면 지속적으로 프로세스를 개선하고 회전 시간을 줄이려 노력할 것이다.

 - 개별 역할이나 그룹에 국한된 특정보다 모든 팀이 참여한 사이클 타임과 같은 측정단위가 더욱 성공으로 이끌 것이다.

 - 린 개발은 고객을 만족하게 할 방법을 찾는데, 이는 모든 소프트웨어 개발의 목표가 되어야 한다.

측정지표의 필요성

 - 측정지표는 팀이 정해진 길을 벗어날 때 이정표 역할을 하거나 바른 방향에 대한 피드백을 제공하는데 사용된다. ex) 왜 코드 커버리지(Code Coverage)가 75%에서 65%로 내려갔을까?

 - 측정지표는 팀의 목표를 달성하는 여행에서 마일스톤으로 사용할 수 있다. 바라는 개선을 이뤄냊; 못했다면, 그 결과로 인해 보너스가 삭감되어 애통해하기보다는 이유를 밝혀내는 것이 더욱 중요하다.

 - 측정지표는 팀과 고객에게 해당 이터레이션 내에서나 해당 릴리즈, 또는 에픽 내에서 진행사항을 추적하는 데 도움을 준다.

 - 측정지표를 잘 사용하면 팀에 동기부여를 할 수 있다.

 - 무엇을 측정할지 결정하기 위해서는, 첫 번째로 풀고자 하는 문제가 무엇인지 이해해야 한다. 문제를 알아냈다면 목표를 설정할 수 있다. 목표는 측정가능해야 한다. 목표가 특정 가능하다면 추적하거나 수집할 필요가 있는 측정항목은 명확해질 것이다.

 - 측정지표를 팀의 동기를 부여하는데 사용해야지 사기를 떨어뜨리는 데 사용하면 안된다. 특정지표가 아닌 목표에 집중하자.

측정지표로 하지 말아야 할 일

 - 측정 가능한 목표는 좋은 것이다. 반면에 개인이나 팀의 성과를 측정하는데 측정지표를 사용하는 것은 위험하다. 스스로 통계의 해석을 왜곡하고 해로운 방법으로 사용할 수 있기 때문이다.

측정지표로 의사소통하기

 - 적절한 사람이 적절한 방법으로 측정 지표를 만들어야 한다.

측정지표 ROI

 - 필요한 측정지표를 식별할 때 소요되는 비용은 합리적인 수준이어야 한다. 지속적인 빌드가 유용한 숫자를 제공한다면 결과적으로 좋은 가치를 제공하는 것이다.

결함 추적

결함 추적 시스템(DTS : defect tracking system)을 사용하는 이유

 - DTS는 결함뿐만 아니라 우선 순위, 중요도, 상태를 추적하고 지정된 담당자를 확인할 수 있는 편리한 곳이다. 

• 편리함 : DTS는 화면 출력이나 업로드한 파일처럼 추가적인 모든 문서를 보관하는데도 편리하다.
• 지식 저장소 : 버그 데이터베이스가 지식 저장소(Knowledge base)로 사용되더라도 비즈니스적인 결정과 배경 정보를 저장하는 다른 메커니즘도 될 수 있다. DTS에 보관하는 편이 좋은 버그의 종류는 간헐적으로 발생하거나 추적하는 데 너무 오래 걸리는 버그다. 
• 규모가 크거나 분산된 팀 : 대면 의사소통은 언제나 첫번째 선택이지만 그럴 수 없는 환경이라면 DTS같은 도구ㅏ 필요하다.
• 고객 지원 : DTS는 고객 출시 후 고객에 의해 보고된 결함이 언제 수정되었는지, 무엇을 수정했는지에 대한 정보를 고객에게 알려줄 수 있다.
• 측정 지표 
• 추적성 : DTS를 사용해야 하는 또 다른 이유는 결함을 테스트 케이스에 연결시키는 추적성 때문이다.

DTS 를 사용하지 않아야 하는 이유

• 의사소통 도구 : 결함 추적 시스템은 분명히 프로그래머와 테스터 사이의 의사소통을 촉진시키지는 않는다.
• 시간과 인벤토리 낭비 : DTS는 결함을 재현하는 모든 단계마다 많은 정보를 추가하는 경향이 있다. DTS에서 결함은 큐가 되거나 작은 제품 백로그가 된다. 린 원칙에 따르면 이러한 결함 인벤토리는 낭비다. 팀 차원에서 이러한 낭비를 줄일 수 있는 방법을 생각해야 한다.

결함 추적 도구

 - DTS를 사용하기로 결정했다면 신중하게 선택하자. 요구사항을 이해하고 단순하게 유지하자. 애자일 개발팀에서 사용되는 모든 도구는 모든 팀 전체의 의견을 종합적으로 고려되어야 한다.

 - DTS에 어떤 것이 필요한지, 그 목적이 무엇인지 고민하는 데 시간을 들이고 대안을 신중하게 평가하자.

초점 유지하기

 - 결함을 보고하고 추적하는 작업에 대한 결정은 중요하지만 주요 목적의 추적은 잃지 말아야 한다. 가능한 한 최고 품질의 제품을 만들어내고, 시기적절한 방법으로 비즈니스에 가치를 제공하는 것!!

테스트 계획

 - 테스트 계획은 목적과 범위, 접근 방식을 대략적으로 파악하고 이해 관계자를 위한 소프트웨어 테스팅에 집중한다.

 - 완성된 문서는 테스트 그룹 외부의 사람이 제품 검증을 위한 "이유"나 "방법"을 이해하는데 도움이 되어야 한다.

테스트 전략 VS. 테스트 계획

 - 애자일 프로젝트에서는 테스터가 필요로 하는 것이 무엇인지에 대한 의사소통을 위해 많은 문서에 의존하지 않는다. 테스터는 나머지 팀과 함꼐 작업하고 테스팅 업무는 작업 카드 형태로 모두가 볼 수 있다.

 - 문서에 포함된 정보가 많을 수록 그것을 모두 읽는 사람은 적을 것이다. 이해관계자에게 정말로 필요한 정보가 무엇인지 생각해보자. 얼마나 자주, 그리고 사용되는 목적이 무엇인지 생각하자!

 - 일반적으로 테스트 전략은 정적 문서로 좀처럼 변하지 않는다고 생각한느 방면, 테스트 계획은 새로 만들어지고 각각의 새로운 프로젝트 별로 존재한다고 본다.

• 테스트 전략 : 전략은 장기적 활동 계획이며, 조직에서 프로젝트에 대한 전반적인 테스트 접근 방법에 대한 문서화를 원한다면 시간이 지나도 크게 변하지 않을 내용만 문서에 포함시키도록 하자.
• 테스트 계획 : 팀이 테스트 계획 문서를 작성할 것인지의 결정 여부에 상관없이 계획은 완료되어야 한다.
  

추적성

 - 전통적인 프로젝트에서는 요구사항 전체를 실제로 테스트했는지 여부를 확인하기 위해 추적성 측정지표를 사용했지만 애자일 프로젝트에서는 이러한 제약이 없다. 프로그래머가 작업할 때 각 스토리를 테스트하므로 테스트되지 않는 부분은 없다고 본다.

기존의 프로세스와 모델

감사

 - 애자일 팀의 테스터가 감사를 위한 정보 제공이나 규제 준수에 도움을 주는 정보를 제공해야 한다면, 여기에 대한 스토리를 작성하고 팀의 남은 작업을 그것에 맞춰 계획하자.

프레임워크, 모델, 표준

- CMMI(Capability Maturity Model Integration) : 조직의 프로세스를 개선하는데 목적이 있지만 개선을 이뤄내는 특정한 개발 사례는 기술하지 않는다.

 - ITIL(Information Technology Infrastructure Library) : 조직이 효율적인 품질 프로세스를 개발하기 위해 고안한 IT 서비스 관리의 모범 사례 모음

 - 애자일 개발은 스스로 설정한 표준이나 프로세스 측정 도구에서 빌려온 어떤 표준과도 호환된다.

 요약

 - 올바른 측정 지표는 팀이 목표를 달성하는지 추적하고 높은 ROI를 제공하도록 도와준다.

 - 측정지표는 가시적이어야 하며, 의사 결정을 내릴 수 있도록 필요한 마일스톤을 제공해야 한다.

 - 결함 추적 시스템을 사용하는 이유는 편의성, 지식 저장소로의 활용, 추적성 때문이다.

 - 결함 추적 시스템은 종종 의사소통 도구로 사용되며, 불필요한 버그를 입력하고 추적하는 것은 낭비로 간주된다.

 - DTS를 포함한 모든 도구는 팀 전체가 사용하기 때문에 도구를 고를 때는 모든 견해를 고려해야 한다.

 - 테스트 전략은 정적 문서로 작성되며 장기적인 테스트 접근 방법이다. 하지만 테스트 계획은 해당 프로젝트에만 유효하다.

 - 특정 문서의 필요에 의해 무작정 받아들이기보다 대안을 생각하자. 

 - 전통적인 품질 프로세스와 프로세스 개선 모델은 애자일 개발 및 테스트와 공존할 수 있다. 팀은 새로운 사고를 해야하고, 문제를 해결하기 위해 협업해야 한다.

Chapter 6. 테스팅의 목적

애자일 테스팅 사분면

 

 

위의 그림은 네 개의 사분면 각각이 테스트하는 다른 이유를 어떻게 반영하는지를 보여주는 애자일 테스팅 사분면의 다이어 그램이다. 한 축은 매트릭스를 팀을 지원하는 테스트와 제품을 평가하는 테스트로 나눈다. 다른 한 축은 매트릭스를 비즈니스 관점과 기술 관점 테스트로 나눈다. 이들 사분명에 붙인 번호는 다른 종류의 테스트가 완료된 시기와는 관계가 없다. 다양한 종류의 테스트 시기는 각 프로젝트의 리스크와 해당 제품에 대한 고객의 목적, 팀이 레거시 코드로 작업하는지 신규 프로젝트인지 여부, 테스트를 위한 자원의 이용가능 시기에 달렸다.

 

팀을 지원하는 테스트

• 1사분면
  • 왼쪽 하단 사분면은 테스트 주도 개발을 나타내며, 애자일 개발 실천법의 핵심이다.
  • 1사분면 테스트의 주목적은 테스트 주도 개발(TDD)이나 테스트 주도 설계이다. 테스트 작성의 목적은 먼저 프로그래머가 자신의 코드를 잘 설계하도록 돕는 것이다.
  • 단위 테스트와 컴포넌트 테스트는 애플리케이션처럼 동일한 프로그램 언어로 작성하고 자동화한다.
• 2사분면
  • 2사분면의 테스트도 개발팀의 작업을 지원하지만 더 높은 수준의 지원이다.
  • 이들 비즈니스 중심 테스트도 고객 주심 테스트와 고객 테스트라고 부르며, 고객이 원하는 외부적 품질과 특징을 정의한다.
  • 비즈니스 중심 테스트는 기능 수준에서 실행하고 각 테스트는 비즈니스 만족 조건을 확인한다.
  • 2사분면 테스트는 비즈니스 전문가가 비즈니스 도메인 언어로 쉽게 이해할 수 있는 방식으로 작성된다.

 - 1사분면과 2사분면의 자동화된 테스트가 제공하는 빠른 피드백은 모든 코드 변경이나 코드 추가를 수용하며 애자일 팀의 토대를 형성한다. 이들 테스트는 먼저 기능 개발을 가이드하고, 자동화되었을 때, 리팩토링과 새로운 코드의 도입으로 예기치 않은 결과를 일으키는 문제를 예방하는 안전망을 제공한다.

 - 1사분면과 2사분면에서의 테스트는 고객이 요청한 비즈니스 가치를 제공하는 일을 팀이 돕도록 작성한다. 이들 테스트는 비즈니스 로직과 사용자 인터페이스가 고객이 제공한 실례에 따라 동작하는지 확인한다.

제품을 평가하는 테스트

•  3사분면
  • 3사분면은 소프트웨어가 기대에 못 미치거나 경쟁력이 떨어지는지를 알아보기 위해 동작하는 소프트웨어를 사용해보는 비즈느스 중심 테스트로 분류한다.
  • 비즈니스 중심 테스트를 수행해 제품을 평가할 때, 실제 사용자가 애플리케이션을 작업하는 방식을 평가하는 것이다.
  • 이는 몇 가지 자동화된 스크립트를 사용해 필요한 데이터를 설정하도록 도울수 있지만 감각과 두뇌, 직관력을 사용해 고객이 요청한 비즈니스 가치를 제공하는지를 확인해야 하기 때문에 사람만이 할 수 있는 수작업 테스팅이다.
• 4사분면
  • 4사분면의 기술 중심 테스트는 성능과 견고성, 보안성과 같은 제품 특징을 평가하는 경향이 있다.

 - 팀이 새로운 릴리즈나 프로젝트를 계획할 때, 3사분면과 4사분면에서 어떤 테스트가 필요한지와 이들 테스트를 언제 끝내야 하는지에 관해 논의하자!

스토리 완료 시기 알기

 - 대부분 제품의경우 올바른 가치를 제공하고 있다고 확신하기 위해 네 개의 모든 테스트 범주가 필요하다.

 - 네 개의 사분면 모두에서 테스트를 조합하면 팀은 각 기능이 품질과 긴에 대한 고객의 평가를 만족하는 시기를 알게 해준다.

책임

 - 제품팀은 애자일 테스트 사분면의 모든 부분을 다루기 위해 광범위한 전문성을 필요로 한다.

 - 모두가 제품의 작업에 참여하고, 일이 잘못되어 갈 때도 팀의 내부적인 고통을 모두가 공유해야 성공적인 팀이 된다.

기술적인 채무(TECHNICAL DEBT) 관리하기

 - 기술적인 채무는 개발팀이 지름길을 선택하고, 마구잡이 해결택을 내놓거나, 스트레스를 받는 상황에서 테스트를 작성하거나 자동화하는 일을 건너뛸 때 만들어진다.

 - 애자일 테스트 매트릭스의 각 사분면은 기술적인 채무를 관리 가능한 수준으로 유지하는 역할을 한다.

 - 코드작성과 설계를 지원하는 기술 중심 테스트는 코드를 관리 가능한 상태로 우지하는 데 도움을 준다. 단위 테스트를 실행하는 자동화된 빌드와 통합 프로세스는 기술적인 채무를 최소화하기 위해 꼭 필요하다. 코드를 작성하는 동안 단위 수준 결함을 찾아내는 것은 팀에 방향을 제시하고 제품 개선을 위해 테스터가 비즈니스 중심 테스트에 집중하도록 할 것이다. 시기적절한 부하 테스트와 스트레스 테스트는 팀에게 아키텍처가 본업에 충실한지를 알게 해준다.

 - 기술적인 채무를 최소화하기 위해 시간을 가지고 자원과 실천법을 적용해보면 팀은 품질이 좋은 제품을 제공하는데 필요한 테스트를 다루기 위한 시간과 자원을 얻게 될 덧이다. 애자일 원칙을 적용해 각 수준으로 각가그이 테스트 유형에 맞춰 잘 수행하면 기술적인 채무는 차례로 줄어들 것이다.

정황에 맞춘 테스트

 - 분류와 정의는 다른 종류의 모든 필요한 테스트를 계획하고 달성하고 있는지 확인하도록 도와주지만, 각 조직과 제품, 팀마다 공유한 상황에 처하고, 각각의 개별 상황에 맞게 일을 해야 한다는 것을 명심해야 한다.

 - 각 스토리와 이터레이션, 출시에 대한 테스트를 계획할 때, 맥락 주도 학파의 테스트에서 중요한 원칙을 차용할 수 있다.

• 모든 실천법의 가치는 맥락에 의존한다.
• 정황 속에 좋은 실천법이 있지만, 최고의 실천법은 없다.
• 함께 일하는 사람들은 모든 프로젝트의 맥락에 가장 중요한 부분이다.
• 프로젝트는 시간이 지남에 따라 종종 예상치 않은 방식으로 전개된다.
• 제품은 하나의 솔루션이다. 문제가 풀리지 않으면 제품은 동작하지 않는다.
• 좋은 소프트웨어 테스트는 지능적인 도전 과정이다.
• 전체 프로젝트에 걸쳐 협력을 이끌어 내는 판단과 숙련된 기술을 통해서만 적시에 올바른 일을 수행하고 효과적으로 제품을 테스트할 수 있다.

 - 애자일 테스팅 사분면은 모든 테스트 기반을 다루고 있음을 확인시켜주는 체크리스트를 제공한다.

• 애플리케이션에 적합한 설계를 찾는 것을 돕기 위해 단위 테스트와 컴포넌트 테스트를 사용하고 있는가?
• 신속한 피드백을 위해 자동화된 단위 테스트를 실행하는 자동화된 빌드 프로세스를 가지고 있는가?
• 비즈니스 중심 테스트를 수행해 고객의 기대를 만족하는 제품을 제공하도록 돕고 있는가?
• 원하는 시스템 동작의 바른 예를 잡아내고 있는가? 더 필요한 것은 없는가? 테스트가 이러한 사례에 기반을 두고 있는가?
• 코드를 작성하기 전에 사용자에게 UI 프로토타입을 보여주고 보고하는가? 최종 소프트웨어 가 어떻게 동작할 것인지를 사용자에게 들려줄 수 있는가?
• 탐색적 테스트를 위한 충분한 시간을 확보하고 있는가? 사용성 테스트를 어떻게 해결하고 있는가? 충분한 고객이 참여하고 있는가?
• 성능과 보안같은 기술적 요구사항을 개발 주기 맨처음부터 고려하고 있는가? 테스트의 다양한 측면을 수행하는 적절한 도구를 갖고 있는가?

요약

 - 팀을 지원하는 테스트는 요구사항을 주도해나가는데 사용할 수 있다.

 - 제품을 평가하는 테스트는 애플리케이션 품질의 모든 측면을 생각해볼 수 있도록 도와준다.

 - 사분면을 사용하면 언제가 끝인지를 알 수 있고, 매트릭스의 4개의 사분면을 다룸으로서 전체 팀이 책임을 공유한다는 것을 보장한다.

 - 기술적을 채무를 관리하는 것은 모든 소프트웨어 개발팀의 핵심 근간이다. 

 - 맥락은 테스트 관련 활동에 항상 지침을 제공해야 한다.

Chapter 7. 팀을 지원하는 기술 중심 테스트

애자일 테스팅의 기초

 - 1사분면에서 다룬 단위 테스트와 컴포넌트 테스트는 각 스토리용으로 작성한 첫번째 테스트는 아니지만 설계와 도움을 준다. 

1사분면 테스트의 목적

 - 단위 테스트와 컴포넌트 테스트는 코드가 해야 할 작업을 정확히 이해하도록 개발자를 돕고 올바른 설계에 대한 안내를 제공함으로서 품질을 제공한다. 이들 테스트는 팀이 제공하는 스토리에 초점을 맞추고 잘 먹히는 가장 간단한 접근 방법을 취하도록 도와준다. 단위 테스트는 단일 개체나 메소드 정보의 작은 부분의 동작을 검증한다. 컴포넌트 테스트는 클래스나 메소드 간의 상호 작용을 테스트함으로서 배포할 수 있는 부분의 전체 설계를 공고히 하도록 해준다.

 - 단위 테스트 개발은 TDD를 사용할 때 중요한 설계 도구가 될 수 있다. TDD 코드는 근본적으로 테스트 가능성을 염두에 두고 설계되었다. 1사분면  활동은 내부적인 품질에 가장 주안점을 두고 소프트웨어를 만드는데 목적을 두고 있다.

 - 단위 테스트를 작성함으로써 설계를 생각해 보는 것은 시스템이 고객 요구사항에 부합해 간다는 것을 의미한다.

인프라 차원의 지원

 - 견고한 소스제어, 형상관리, 지속 통합은 개발을 안내하는 프로그래머 테스트로부터 가치를 얻기 위한 핵심이다. 

이들 테스트를 작성하고 실행하는 이유

속도 그 이상의 추구하자

 - 자동화된 단위 테스트와 코드 통합 테스트라는 안정망을 사용하면 프로그래머가 자주 리팩터링 할 수 있다. 이렇게 되면 코드를 합리적인 표준 관리 체계 하에 둘 수 있고, 투자한 시간에 대한 최선의 가치를 제공한다.

테스터의 일을 수월하게

 - 프로그래머 테스트에 관련된 핵심 실천법은 더 많은 테스트를 쉽게 달성하도록 한다. 대개  단위테스트는 속도 측면에서 실제 데이터베이스 대신에 모조/모의 개체로 작업하지만 실제 사용하는 데이터를 대상으로 한다면 나중에 문제가 덜 생길 것이다.

테스팅을 염두로 둔 설계

 - 테스트로 개발을 주도하는 한가지 이점은 그 코드가 테스트 통과의 의지를 담아서 작성된다는 것이다. 테스트 주도 개발은 프로그래머가 코드를 작성해 테스트를 통과하도록 만들기 전에 각각의 테스트를 작성한다는 것을 의미한다.

시기 적절한 피드백

 - 단위 테스트의 가장 큰 가치는 피드백의 속도에 있다. 빌드와 테스트 프로세스가 너무 오래 걸린다면 팀에게 속도가 느려지는 원인을 분석하고 빌드 주기를 더 빠르게 하는 조치를 취하게 하자.

• 데이터베이스 접근은 통상 많은 시간을 소모하므로 가능하면 모조 개체를 사용하고, 특히 단위 수준에서 데이터베이스를 대체하도록 고려하자.
• 더 오랫동안 실행하는 통합과 데이터베이스 액세스 테스트는 주 번째 빌드와 테스트 프로세스를 옮기자.
• 테스트를 별열로 실행해 더 빨리 끝낼 수 있는지 확인하자.
• 시스템의 회귀 테스트에 필요한 최소한의 테스트를 실행한다.
• 다수의 빌드 머신에 작업을 분산한다.
• 빌드를 실행하는 하드웨어와 소프트웨어를 업그레이드한다.
• 빌드 속도를 올리기 위한 점진적인 단계를 취하고 시간을 투자할 영역을 찾는다.

팀에서 이들 테스트를 실행하지 않는다면?

테스터가 할 수 있는 일

 - 피해야 할 함정 중 하나는 테스터가 단위 테스트를 작성하는 것이다. TDD는 실제로 설계 활동이기 때문에 코드를 작성하기 전에 코드를 작성하는 사람이 테스트도 작성하는 일이 핵심이다. 또한 프로그래머는 자동화된 단위 테스트가 제공하는 즉각적인 피드백을 필요로 한다.

 - 새로운 아이디어를 조직에 도입하는 일은 큰 일 이으로 사람들과 자원들을 찾아 여러분의 노력을 돕도록 하라

관리자가 할 수 있는 일

 - 제품 책임자와 함께 일하고 품질을 여러분의 목표로 맞추고 팀과 품질 기준에 대해 의사소통하자.

 - 팀에 학습 시간을 할당하고 전문가와 직접 해보는 훈련을 제공하자.

 - 테스트 관리자는 개발 관리자와 함께 일하고 테스트 용이성을 개선하고 테스터가 실행 가능한 테스트를 작성 할 수 있는 훈련을 장려해야 한다. 또한 테스터가 팀이 사용하기로 결정한 자동화 도구와 프레임워크를 사용하는 방법을 배울 수 있도록 시간적 배려를 해주어야 한다.

팀 문제

 - 효과적인 변화 에이전트가 되는 방법을 찾는 동안 해볼 만한 최선의 일을 해당 문제를 풀어내는 데 전체 팀을 포함시키는 것이다. 

 - 팀의 개발 과정을 지원하는 기술 중심 테스트는 일어나야 하는 모든 테스팅의 중요한 토대다.

 - 기술 중심 테스트는 적절한 도구와 인프라 없이 수행될 수 없다.

도구 키트

 - 알맞는 인프라를 만들어 기술 중심 테스트를 지원하는 것은 중요하다.

소스 코드 제어

 - 소스 코드 제어는 다른 프로그래머가 동일한 모듈에서 서로 다른 작업 변경 작업을 유지할 수 있도록 해준다.

 - 자동화된 테스트 스크립트를 위해서도 역시 소스 코드 제어를 사용한다. 향후의 해당 버전에 대한 테스트를 반환해야 하는 경우에 테스트한 해당 코드 버전과 자동화된 테스트를 묶어두는 것이 중요하다. 빌드에 레이블이나 태그를 달 때 테스트 코드에도 역시 레이블이나 태그를 달았는지 확인한다.

 - 제품 코드에 대한 저장소와 해당 단위 테스트, 고수준 테스트 스크립트를 제공하기 위해 팀의 코드 계층을 구조화 할 수 있다. 이 작업은 올바른 구조를 얻기 위해 약간의 브레인스토밍과 시험이 필요하다.

다양한 IDE

 - IDE(Integrated development environment)는 소스 코드 제어 시스템을 통합해 버전 관련 문제를 막아주고 팀원 서로간의 변경을 용이하게 해준다.

 - 가장 중요한 것은 IDE가 리팩터링에 대한 지원을 제공하는 것이다.

 - IDE들은 다른 언어와 도구들을 지원하는 많은 플러그인들을 지원한다. 이들 도구는 운영 코드를 작업할 때처럼 테스트 스크립트 작업에도 유용하다.

 - 테스트 도구들은 자체의 공유한 IDE로 제공되거나 플러그인 형태로 제공되어 Eclipse와 같은 기존 IDE와 함께 동작한다. 이렇게 시간을 아껴주며, 품질 향상을 촉진하는 강력한 도구들을 이용하자.

빌드 도구

 - ant와 Nant, Maven과 같은 도구를 사용해 프로젝트를 빌드하면 해당 빌드 관리 뿐만 아니라, 빌드 결과를 보고하고, 문서화하는 쉬운 방법을 제공하고, 빌드 자동화 및 테스트 도구와 쉽게 통합된다. 이들 도구는 IDE와도 통합된다.

빌드 자동화 도구

 - 지속 통합은 애달일 팀을 위한 핵심 실천법이다. 하루에도 여러 번 실행하는 완전히 자동화되고 재연이 가능한 빌드는 애자일 팀 성공의 핵심 요인이다. 자동화된 빌드 도구는 빌드 결과의 전자메일 알림과 같은 기능을 제공하고 소스 코드 제어 도구들과 빌드를 통합한다.

단위 테스트 도구

 - 단위 테스트 도구는 코드를 작성하는 언어별로 존재한다. 행위 주도 개발은 테스트 주도 개발의 또 다른 버전으로 Easyb같은 도구들로 테스트를 주도하기 위해 예상되는 동작을 상세히 기술한다. 

 - 프로그래머가 기술 중심 테스트를 작성하는 데 사용하는 도구들은 비즈니스 중심 테스트에도 사용될 수 있다.

요약

 - 프로그래밍을 지원하는 기술 중심 테스트는 해당 팀이 가능한 가장 높은 품질의 코드를 만들도록 도와주고, 기술 중심 테스트는 다른 모든 유형의 테스팅에 대한 토대를 형성한다.

 - 이 사분면의 테스트가 주는 이점에 더 빠른 테스트 진행과 더 많은 테스트 수행이 포함되어 있지만 속도와 품질이 궁금적인 목표가 되어서는 안된다.

 - 프로그래머는 기술 중심 테스트를 작성해 팀을 지원하고 내부적인 품질과 시스템의 용이성을 향상시켜 테스트에게 커다란 가치를 제공한다.

 - 레거시 시스템은 대개 테스트 주도 개발에 가장 큰 장애물로 꼽히지만 이들 문제는 점진적인 접근방법으로 극복될 수 있다.

 - 팀은 가능한 한 신속한 피드백을 제공하기 위해 지속 통합과 빌드, 테스트 프로세스를 설정해야 한다.

 - 애자일 팀은 팀을 지원하는 기술 중심 테스트를 가능하게 하기 위해 작업에 소스 코드 제어와 테스트 자동화, 다양한 IDE, 빌드 관리와 같은 도구가 필요하다.

Chapter 8. 팀을 지원하는 비즈니스 중심 테스트

비즈니스 중심 테스트로 개발 주도하기

 - 전통적인 폭포수 방식에서 개발팀은 모든 기능 집합의 상세한 내용을 포함하는 장황한 요구사항 문서를 받을 수도 있지만 애자일 프로젝트에서 고객팀과 개발팀은 스토리에 기반을 둔 대화를 시작한다. 개발팀은 어떤 종류의 요구사항을 필요로 하고, 이들 요구사항이 거의 즉시 돌아가는 코드를 작성하기 시작하게 해주는 수준이기를 원한다.

 - 비즈니스 중심 테스트는 비즈니스 요구사항을 다루며, 큰 그림과 충분한 상세 내용으로 코드 작성을 안내한다. 또한 사례에 기반을 둔 요구사항을 나타내며, 고객과 개발팀 모두가 이해할 수 있는 언어와 형식을 사용한다.

 - 비즈니스 중심 테스트는 "고객 중심" 또는 "스토리", "고객", "인수" 테스트라고도 한다.

 - 1사분면 활동은 내부 품질을 보장하고 팀 생산성을 극대화하며, 기술적 채무를 최소화하며, 2사분면 테스트는 외부 품질을 정의하고 확인하며 완료 시기를 알 수 있도록 도와준다.

진퇴양난에 빠진 요구사항

 - 애자일 개발에서 새로운 기능은 대개 고객팀이 작성한 스토리 또는 스토리들의 그룹으로 시작된다.

 - 기술팀의 일부 멤버가 스토리 작성 시간에 참여하면 기능 스토리에 조언을 해줄 수 있어서 도움이 된다. 

 - 애자일 팀은 고객과 개발자간의 대화에서 적절한 코드를 작성하기에 충분한 정보를 얻을 애까지 스토리를 확장한다. 테스터는 각 스토리에 대한 사례와 맥락을 이끌어내는 데 도움을 주며 고객에게 스토리 테스트를 작성하도록 도와준다. 이들 테스트는 프로그래머들이 코드를 작성할 때 지침을 주고 팀이 고객의 만족 조건에 부합하는 시점을 알 수 있도록 도와준다. 팀이 유스케이스를 갖고 있다면 사례를 제공하거나 테스트를 지도해 필요한 기능을 명확히 하는데 도움을 줄 수 있다.

 - 애자일 개발에서 작은 단위의 릴리즈와 한 번에 작은 덩어리로 한 부분씩 개발하는 것은 옹호나는 이유 중 하나가 이터레이션이다. 고객이 이 이터레이션에서 인도받은 코드의 동작에 만족하지 않고, 지적한 부분을 중요하다고 여기는 경우 그 다음번에 신속하게 바로작을 수 있다. 요구사항의 변화는 불가피한 일이다.

 

 

 - 테스트에는 고객이 진술한 요구사항 이상을 포함해야 한다. 사후 조건과 시스템에 전체적으로 끼치는 영향력, 다른 시스템과의 통합에 대한 테스트를 해야 한다. 

공통 언어

 - 개발팀과 비즈니스 전문가 모두가 이해하는 공통 언어를 제공하기 위해 테스트를 사용할 수도 있다. 공통 언어는 비즈니스를 하는 사람들이 그들이 원하는 기능을 상상하는 데 도움이 된다. 이것은 프로그래머가 확장하기 쉬운, 잘 설계된 코드를 만들게 해준다.

 - 비즈니스

요구사항 끌어내기

질문하기

 - 질문을 던지는 것으로 시작하자. 테스터는 다양한 질문을 던지는 데 특히 재능이 있다고 할 수 있다. 왜냐하면 항상 머리속에 큰 그림을 염두에 두고 있고 스토리의 비즈니스 중심 측면과 기술적인 측면을 알고 있으며, 항상 최종 사용자 경험을 생각하기 때문이다.

• 이 스토리가 문제를 해결하는가?
• 그렇다면 해결하려는 문제는 어떤 것인가?
• 문제를 해결하지 못하는 솔루션을 구현하고 있지는 않는가?
• 해당 스토리로 어떻게 비즈니스에 가치를 더할 것인가?
• 이 기능의 최종 사용자는 누구인가?
• 그 기능에서 어떤 가치를 얻고자 하는가?
• 그 기능을 사용하기 전후로 사용자는 뭘 할 것인가?
• 이 스토리를 다 처리했는지 어떻게 알까?

사례 사용하기

 - 가장 중요한 것은 고객에게 해당 기능이 어떻게 동작해야 하는지에 대한 사례를 요청하는 것이다.

 - 사례들로 테스트에 대한 기준을 형성할 수도 있다. 일부 고객은 Fit이나 FitNesse와 같은 테스트도구를 사용해서 자신들에게 익숙한 도메인 언어로 테스트를 작성할 수 있게 해주면 사례를 표현하는 것을 편하게 여긴다.

여러 가지 관점

  - 각 사례나 테스트는 하나의 관점을 가진다. 사람들마다 자신의 고유한 관점에 따라 다른 테스트나 사례를 작성할 것이다. 테스터는 최대한 다양한 과점을 수집해야 하니 사용자에 관해 생각해보자.

고객과의 의사소통

 - 고객을 항상 만날 수 있고 통신 수단이 폭넓게 열려 있을 때도 커뮤니케이션은 관리되어야 한다.

명확성 증진

 - 고객팀이 조직의 서로 다른 부서의 사람들로 구성되면 특정 스토리가 의도하는 것이 정확히 무엇인지에 관해 그들 가운데 충돌이 날 수 있다. 

 - 한 사람을 통해 많은 다른 관점의 필요를 얻을 때, 어떤 관점은 잃어버릴 수 있으므로, 개발팀은 고객팀과 함께 앉고, 고객이 어떻게 일하고 있는지를 배우는 것이 가장 이상적인 방법일 것이다.

만족 조건

 - 전체 릴리즈에 대해서뿐만 아니라 각 기능이나 스토리에 대한 만족 조건이 있다. 

 - 고객팀의 요구사항을 이해하는 최고의 방법은 고객과 대면해 대화하는 것이다. 만족 조건은 스토리가 제공하는 기능뿐만 아니라 더 큰 시스템에 주는 영향도 포함해야 한다.

 - 이들 조건은 스토리에 대한 핵심 가정과 고객팀이 내린 결정에 기반을 둔다. 만족 조건의 논의는 위험이 잠재된 가정을 식별하고, 스토리를 완전하게 하는 데 필요한 모든 작업들을 작성하고 올바르게 평가할 때 팀의 자신감을 키운다.

파문 효과

 - 애자일 개발에서 우리는 한 번에 하나의 스토리에 집중한다. 각 스토리는 통상 전체 어플리케이션의 작은 구성 요소이지만 큰 파문 효과를 일으킬 수 있다. 

 - 팀은 어떤 요구사항과 테스트 케이스를 생성할 지 알아보기 위해 각 "테스트 포인트"를 체크할 수 있다. 작은 스토리가 넓은 범위의 영향을 끼치기도 하고, 어플리케이션의 각 부분이 복잡성의 또 다른 수준을 나타나는 경우도 있다. 코드 변경의 잠재적인 모든 영향을 인식해야 한다.

 - 각 스토리가 제공하는 중심 가치를 식별하고 그 스토리를 개발하는 점직전인 접근방법을 알아내는 데 시간을 들이자. 테스트 작성과 코드 작성, 코드 테스트 등의 작은 단위로 조금씩 진행하도록 계획을 세우자. 이런 식으로 2사분면 테스트는 계획에 따라 최소한의 가치를 제공할 것이다.

얇고 작은 조각

 - 개발팀이 새로운 스토리를 평가할 때 일부 스토리들이 너무 크다는 것을 발션하면 고객팀에 다시 돌려보내고 이 스토리를 더 작은 스토리들로 나눠달라고 요청한다. 스토리들이 너무 작은 경우도 있는 데 이 때는 다른 스토리와 합치거나 단순히 작업으로 다뤄야 한다. 테스트를 포함해 애자일 개발은 한 번에 하나의 작은 기능 조각을 취한다.

 - 팀이 새로운 프로젝트나 주제에 착수할 때 그 주제에 대한 첫 번째 이터레이션에 앞서 제품 책임자에게 관련된 모든 스토리를 브레인스토밍 세션에 가져오도록 요청하자. 제품 책임자와 다른 이해관계자들이 그 스토리를 설명하도록 하자.각 스토리가 어떤 가치를 제공해야 하는지, 그리고 이 스토리를 시스템의 맥락에 어떻게 맞춰야 하는지를 이해한 후 스토리들을 더 작고 관리 가능한 조각으로 나눈다. 더 큰 어플리케이션에 끼치는 영향을 염두로 두면서 이들 작은 증분조각을 정의하기 위해 고객 테스트를 작성한다.

 - 이 얇은 조각이 잘 동작하면 다음 조각 또는 기능 계층에 대한 고객 테스트를 작성하고, 그 테스트를 통과하게 만드는 코드를 작성할 수 있다.

작업이 끝났는지 어떻게 알 수  있을까?

 - 팀을 지원하는 비즈니스 중심 테스트는 만족 조건에 부합하는지를 확인하기 위해 작성되었다. 이들 테스트는 주경로로 시작해 그 스토리가 의도하는 필요성을 만좃하는지 보여준다. 이들 테스트는 다양한 사용자 시나리오를 다루고 시스템의 다른 부분이 불리한 영향을 받지 않는지를 확인한다. 이러한 테스트를 싱행하고 테스트를 통과한다.

 - 진정한 테스트는 소프트웨어의 사용자가 그 스토리가 가정하는 동작을 수행할 수 있는지 여부이다. 테스트를 모두 통과하고 빠진 요구사항이 모두 식별되엇을 때, 프로그래머가 "올바른 기능"을 수행하는 코드를 추구하는 목적을 달성한 것이다.

 - 고객 테스트의 또 다른 목적은 고위험 영역을 식별하고 해당 코드가 영역을 확고히 하는 것이다. 리스트 관리는 모든 소프트웨어 개발 방법론에서 핵심적인 실천법이며 테스트는 위험을 식별하고 완화하는 역할을 한다.

테스트가 위험을 완화시킨다.

 - 고객 테스트는 코드의 기대 동작을 정의할 뿐만 아니라 위험을 관리하기 위해 작성한다. 애자일 개발은 비즈니스 가치를 작고 테스트된 인도 가능한 단위로 우선 순위를 정하고 고객을 증분 단계마다 인수에 참여시킴으로써 위험을 완화한다.

심각한 위험 : 큰 그림이 뭐였더라? 개별 스토리들만 테스트하거나 프로그래머가 코드에 관해 이야기 해준 것만 기준으로 테스트하려는 습관에 물들기 쉽다. 각 개별 스토리가 스스템의 다른 부분에 어떤 영향을 주는지를 항상 고려하라. 최종 목적과 큰 그림을 기억하자!

테스트 용이성과 자동화

 - 애자일 팀에서 프로그래머들이 테스트 주도 개발을 하려고 준비할 때 이들은 작성할 코드가 무엇인지를 알기 위해 해당 스토리에 대한 비즈니스 중심 테스트를 진행한다. 테스트를 중심으로 일한다는 말은 모두가 테스트를 좀 더 쉽게 하기 위해 코드를 설계하는 최선의 방법에 관해 생각한다는 의미다. 자동화된 비즈니스 중심 테스트는 이해를 명확히 하고 싱행을 쉽게 해주며 빠른 피드백을 제공하는 데 필요하다.

 - 각 애자일 팀은 개발을 이끌어 내는 비즈니스 중심 테스트를 작성하고 자동화하는 프로세스를 찾아야 한다. 기술 중심 테스트만 자동화하는 팀은 버그가 없는 코드를 만들 수 있지만 정작 고객이 원하는 것을 하지 못하고 있음을 발견할 수 있다.

요약

 - 애자일 개발에서 전통적인 요구사항 문서보다는 사례와 비즈니스 중심 테스트가 어떤 코드를 작성할 지를 더 잘 알려준다.

 - 짧은 이터레이션에서 얇은 기능 조각의 동작을 통해 고객에게 어플리케이션을 직접 보고 사용해 본 다음 필요에 따라 요구사항을 조정할 기회를 제공한다.

 - 테스터가 기여하는 중요한 영역은 고객이 만족 조건을 표시하고 각 스토리에 대해 바라는 동작/바라지 않는 동작의 사례를 만들도록 돕는 부분이다.

 - 열린 질문을 해서 고객이 원하는 모든 기능을 생각하도록 돕고 중요한 가정이 드러나지 않은 채로 넘어가지 않도록 한다.

 - 비즈니스의 다양한 부분의 다양한 관점을 제공하는 스토리에 대해 원하는 동작에 관한 합의를 이끌어내도록 고객을 돕는다.

 - 비즈니스 만족 조건과 같은 정보를 나타내는 도구를 개발해 고객들을 돕는다.

 - 개발팀과 고객팀은 주어진 스토리가 영향을 끼치는 모든 어플리케이션의 모든 부분을 고려하고, 전체 시스템 기능을 계속해서 염두에 두어야 한다.

 - 팀과 함꼐 기능 집합을 작고 관리 가능한 스토리와 스토리 내의 경로로 나누는 작읍을 한다.

 - 단계적인 방식으로 "테스트 작성 - 코드 작성 - 테스트 실행 - 학습"의 패턴을 따르고 각 기능을 통과하면서 만들어 간다.

 - 테스트와 사례를 사용해 기능의 착오나 큰 그림을 망각하는 위험을 줄여 나간다.

 - 비즈니스 중심 테스트로 코드 작성을 주도하면 개발팀이 테스트가 용이한 어플리케이션의 구현에 대한 필요를 지속적으로 인식하게 만들어 준다.

 - 팀을 지원하는 비즈니스 중심 테스트는 피드백을 빠르고 쉽게 하기 위해 자동화되어야 팀이 짧은 이터레이션에서 가치를 제공할 수 있다.

Chapter 9. 팀을 지원하는 비즈니스 중심 테스트를 위한 툴킷

비즈니스 중심 테스트 도구 전략

 - 필요한 도구를 선택하기 위한 전략은 티의 기술 집합과 어플리케이션이 사용하는 기술, 팀의 자동화 우선 순위, 시간과 예산 제약 사항, 처한 상황에 따른 특별한 관심사에 기반을 두어야 한다. 

사례와 요구사항을 이끌어내는 도구들

 - 하나의 단순한 스토리가 어플리케이션뿐만 아니라 조직이나 조직의 클라이언트, 동료, 공급업체, 파트너 등의 넓은 영향을 끼칠 수 있다.

 - 사례를 통해 원하는 동작을 설명하도록 해주고, 잠재적인 구현 사항들과 파급 효과를 브레인스토밍하며 요구사항을 테스트로 전환해주는 도구에는 다음과 같이 있다.

체크리스트

 - 체크 리스트는 제품 책임자가 스토리의 모든 측면을 정확하게 판단하고 의사소통하고 있음을 확인하는 방법이다.

 - 체크 리스트는 해당 스토리에서 비즈니스가 필요로 하는 만족 조건을 명시한다.

마인드 맵

 - 마인드맵은 다순하지만 간단한 브레인스토밍 시간을 통해서는 나오지 않는 아이디어들을 찾아내는데 효과적인 방법이다. 마인드맵은 중심 개념에 연결된 개념이나 단어, 아이디어를 나타내기 위해 만드는 다이어그램이다.

시프레드시트

 - 고객들은 몇 가지 체크리스트를 사용해 이터레이션의 시작에 앞서 스토리를 다듬는 데 도움이 될만한 고수준의 테스트케이스를 작성할 수 있다. 일부는 스트레드시트나 작업하기 편하다고 느끼는 형식이면 무엇이든 사용해 더 상세한 사례를 작성한다. 

모형(Mock-Up)

 - 모형은 다양한 형식으로 만들 수 있다. 애자일 개발의 큰 차이점은 몇 주 전이나 몇 개월 전이 아니라 코드를 막 작성하려고 할 때 모형을 만들고 토론한다는 점이다. 모형은 고객이 지금 원하는 것을 나타낸다고 확신할 수 있다. 모형은 고객과 개발팀 둘 다 이해할 수 있어야 한다.

흐름도

 - 흐름도는 두세개의 사용자 스토리를 함께 묶어 내도록 도와주는 사용자 시나리오의 근거가 될 수 있다.
 - 흐름도와 마인드맵 같은 시각 도구는 스토리의 기능 개요를 설명하는 뛰어난 방법이며 특별히 고객 그룹과 프로그래머, 테스터가 이런 시각적인 자료를 그린다면 더 좋다. 애자일 개발에서 테스트와 코드를 작성하기 시작하면서 이들 다이어그램을 생성한다. 

소프트웨어 기반 도구

 - 우리가 고객과 다른 장소에 있다면 고객과 대화하는 데 도움을 줄 도구가 필요하다. 분산된 팀에게는 데스크탑 공유가 서로 떨어진 곳에서 작업할 때 도움을 주는 최고의 도구다. 

 - 일부 팀은 고객과 비즈니스 분석가, 테스터가 바로 실행 가능한 테스트로 전환할 수 있는 사례를 문서화할 수 있는 XUnitm Fit, Selenium, Wair 같은 오픈소수에 기반을 둔 자체 프레임워크를 만든다.

 - 온라인 포럼 도구는 특별히 함께 모여 있지 않은 팀의 경우에 전자 메일로 기능이나 기술적 관심사에 관해 진행 중인 논의에 대한 좋은 대안이다.

 - 위키는 의사소통을 향상시키고 토론과 결정을 기록할 때 사용하는 일반적인 도구다.

사례에 기반을 둔 테스트 자동화를 위한 도구

GUI/API 하부에서 테스트하는 도구

•  단위 수준 테스트 도구
  • 테스트와 고객이  비즈니스 중심 테스트 뿐 아니라 기술 중심 테스트으로 사용하는 JUnit이나 NUnit 같은 XUnit 도구를 편하게 여기고 이들 도구에서 필요한 GUI 배후에 동작하는 모든 기능 테스트를 제공한다면 좋은 도구이다. 이들 도고를 더 고객 친화적으로 만들려면 팀은 테스터와 고객이 테스트를 명시하는데 사용할 수 있는 단위 수준 도구들 위에 프레임워크를 만들어야 할 것이다.
  • GUI 테스트 자동화라는 목적을 위해서 행위 주도 개발이라고 하는 BDD(Behavior-driven development)가 적당한데 이는 테스트 명세용으로 더 자연스런 언어를 사용하기 때문이다.
  • BDD는 도메인 주도 개발과 관련이 있고 기술보다 도메인에 초점을 맞추고 모델을 사용해 설계를 주도한다. 
  • 팀을 지원하는 비즈니스 중심 테스트의 목적은 고객과 객발자 간의 의사소통과 협업을 촉직하고 각 이터레이션에서 팀이 실제 가치를 전달할 수 있도록 하는 것이다. 어떤 팀은 단위 수준 도구로 이 일을 아주 잘 수행할 수 있고 어떤 팀은 기능 수준 테스트 도구에 더 잘 적응한다.
• API 계층 기능 테스트 도구
  • Fit와 FitNesse Fit(Framework for Integrated Tests)는 협업을 촉진하는 오픈소스 테스팅 프레임워크로 요구사항을 정제하는 데 도움을 주는 좋은 도구이다. Fit을 사용하면 고객과 테스터, 프로그래머가 기대하는 시스템의 동작이 무엇인지 지정하는 예를 사용할 수 있다. 테스트를 실행하면 Fit는 자동적으로 고객의 기대와 실제 결과를 비교한다.
  • Fit 테스트는 운영 코드에 테스트 입력을 전달하는 장치로 자동화 된 후 출력을 받고, 이 출력을 기대한 결과값과 비교한다.
  • FitNesse는 Fit를 기반으로 하는 웹 서버와 위키, 소트으웨어 도구다. Robert C. Martin과 Micah Martin이 개발했고, 활동적인 개발자 커뮤니티가 있는 오픈 소스 도구다. FitNesse와 Fit 간의 주요 차이점은 FitNesse 테스트가 HTML 테이블 대신 위키 마크업으로 작성된다는 점인데 일부 사용자는 이것이 더 쉽다고 생각한다. 이 도구는 스프레드시트에서 테스트를 만들고 이들을 테스트로 가져오는 기능을 기원한다.
  • Fit나 FitNesse 형태의 도구가 주는 또 다른 이점은 서로 다른 팀 멤버들 사이에서 협업을 촉진해 개발에 지침을 주는 올바른 테스트를 제시한다는 점이다.
  • 웹 서비스는 다른 어플리케이션이 여러분의 어플리케이션에 접근하게 해주는 또 다른 형태의 API다. 
    • CrossCheck : CrossCheck는 웹 서비스를 테스트하기 위한 도구 중 하나이다. WSDL(Web Service Description Language)를 제공하고 CrossCheck는 해당 페이지를 컴파일한 뒤 여러분이 채워야 할 테스트 상자를 포함하는 탭 메뉴로 표시한다. 이것은 Run 모드를 갖고 있어서 여기에서 Suite에 테스트를 추가한 뒤 그 Suite를 실행할 수 있다. 
    • Ruby Test::Unit : Ruby의 단위 테스팅 프레임워크
    • soapUI : 테스팅 웹 서비스용으로 제안된 도구. 이 도구는 엑셀 스프레드시트나 테스트 파일의 행들을 돌아가면서 선택할 수 있기 때문에 데이터 주도 테스트용으로 사용할 수 있다.
  • 프레젠테이션 계층 아래의 계층에서 동작하는 테슽는 코드 작성을 안내하는 고객 테스트를 자것ㅇ하고 자동화하는데 아주 잘 맞는다.

GUI를 테스트하는 도구

 - 테스트 프레임워크는 해당 코드가 작성되기 전에 GUI 도구에 대한 테스트케이스를 지정하는데 사용될 수 있다.

 - 개발을 주도하기 위해 많은 자동화된 스토리 테스트를 사용하지 않더라도 수작업 탐색적 테스트에서 기능에 관해 배우고 즉시 피드백을 제공하도록 도움을 얻을 수 있다. 

• 기록/재생 도구
  • 기록/재생 도구는 대개 스크립트를 기록하고 다시 신속하게 재생하는 방법을 배울 수 있기 때문에 매력적이며 짧은 시간에 많은 스크립트를 생성할 수 있다.
  • 초기 GUI 테스트 도구는 XY 화면 좌표를 사용해서 위치 변화에 민감하게 반응했지만 현재 GUI 테스트 도구는 그래픽 어플리케이션의 컨트롤들을 인식하는 개체를 사용하며로 변화에 잘 견뎌낼 수 있다.
  • 개체 인식이 향상되기는 했지만 기록/재생으로 생성된 스크립트는 일반적으로 불안정하고 유지 관리에 비용이 많이 든다.
• 애자일 오픈 소스 테스트 도구
  • Ruby와 Watir : Watir(Web Application Testing in Ruby)는 간결한 웹 브라우저 자동화를 위한 오픈 소스 Ruby 라이브러리로 윈도우 운영체제의 인터넷 인스플로러에서 동작한다. 파이어폭스용 FireWatir와 사파리용 SafariWatir처럼 다른 브라우저를 위한 옵션이 있다. Watir는 GUI 테스트 도구 중 한 예로 애자일 프로젝트에 잘 맞는다.
  • Selenium : 테스팅 웹 어플리케이션 용 도구의 모음. Selenium IDE라는 파이어폭스 플러그인은 이 도구를 신속하게 배우는 방법을 제공한다.
  • Canoo WebTest : XML 파일에서 "단계"로 명시되고 웹 UI를 통해 사용자의 동작을 묘사한다. WebTest는 Selenium과 Watir가 하는 것처럼 실제 브라우저를 대상으로 하지 않고 HtmlUnit을 사용해 원하는 브라우저는 시뮬레이션한다. 테스트 스크립트 코드 작성과 대조적으로 테스트를 지정하는 이점은 그 안에 로직이 없기 때문에 해당 테스트를 시험할 필요가 없다.
• "자가 제작 테스트 자동화 도구"
  • 브렛 페티코드(Bret Pettichord, 2004)는 애자일 팀이 그들의 고유한 테스팅 필요사항을 만족하는 애자일 팀이 만드는 도구에 대해 "자가 제작"이라는 용어를 만들어냈다  이들 도구는 대개 기술에 대해 잘 모르는 고객팀 멤버와 테스터에게 실제로 자동화된 도구로 실행할 수 있는 테스트를 작성하는 방법을 제공한다.
• 어떠한 테스트 도구도 성공을 보장하지 않으며, 전체 팀이 최고의 도구를 사용하는 것에 관해 생각하는 것이 큰 도움이 되지만 사용하는 도구가 무엇이든 간에 테스트를 작성하는 데 지혜로운 접근방법이 필요하다.

테스트 작성을 위한 전략

 - 빈약하게 표현된 시나리오와 설익은 테스트 케이스 설계는 문제를 해결하기 보다는 혼란을 야기한다.

테스트를 점진적으로 구축하라

 - 각 테스트는 하나의 비즈니스 규칙이나 조건에 국한하도록 하라. 어느 시점에 더 복잡한 시나리오를 자동화하거나 수작업으로 수행할 수 있찌만 각 조건 처리를 간단한 테스트로 시작하는 것이 좋다. 자동화 테스트를 통과하면 이들 테스트를 회귀 Suite에 포함해 주기적인 빌드 프로세스에서 실행한다.

계속해서 테스트를 통과하도록 유지하라

 - 테스트 통과 후에도 해당 테스트는 요구사항이 변경되지 않느 한 실패하지 않아야 한다. 실패가 일어난다면 그 테스트는 해당 코드가 고쳐지기 전에 업데이트 되어야 한다.

 - 지속 통합과 빌드 프로세스에서 테스트가 실패할 때마다 해당 팀은 가장 높은 우선 순위(중요 제품 외에)에 따라 다시 빌드를 통과시켜야 한다.

 - 리팩토링을 통해 테스트를 현재 상황에 맞고 유지관리가 용이하게 유지하라 이들 테스트가 다른 테스트 케이스까지 다루도록 확장하라.

적절한 테스트 디자인 패턴을 사용하기

 - 테스트를 설꼐할 때 다른 패턴을 살펴보고 알맞은 것을 선택하다. 이들 테스트를 할 수 있는 한 간결하게 유지하라. 테스트를 설계하기 전에 필요한 테스트를 식별해야 한다.

• 빌드/작동/검사
  • 테스트 목저겡 따라 메모리나 실제 데이터베이스에 입력 데이터를 만들어서 운영 코드를 호출해 이들 입력을 작동시켜보고 그 결과를 확인하는 작업
  • 어플리케이션의 데이터 액세스 계층을 테스트해야 한다면 테스트는 실제 데이터베이스를 사용해 실행할 수 있다. 각 테스트는 필요한 테스트 데이터를 넣고 그 데이터로 작동시켜 본 다음 결과를 확인하고 해당 데이터를 삭제한다.
• 시간 기반, 활동, 이벤트 패턴
  • 해당 도메인에 따라 시간 또는 이벤트 기반 접근 방법은 시뮬레이션을 통해 실제 비즈니스 프로세스가 더 나아지고 서술 형식 테스트보다 비즈니스 전문가가 잘 이해하게 할 수 있다. 다른 고객들은 세부적인 절차를 숨겨주기 때문에 서술 테이블 양식이 이해하기에 더 단순해보일 수 있다. 
• 더 배울 것
  • 각 테스트 유형에 따른 올바른 패턴을 찾는 일은 테스트를 명확히 전달해주고 유지, 관리하기 쉬우며 최적의 시간 투자로 실행하도록 보장해준다.
  • 프로그래머와 테스터가 함께 테스트 접근 방법에 대해 브레인스토밍을 해서 어떤 테스트를 자동화하고 테스트를 지원하기 위해 해당 코드를 어떻게 설계해야 할지를 결정하도록 하자.

키워드 주도 테스트와 데이터 주도 테스트

 - 데이터 주도 테스트는 테스트 유지관리를 줄이고 수작업 테스터들과 테스트 자동화를 공유하도록 도와주는 도구이다. Fit에서 지원하는 것 같은 스프레드시트나 표는 입력과 예상된 결과만 반복되는 동일한 테스트 코드를 계속해서 실행하고자 할 때 유용하다.

 - 키워드 주도테스트는 미리 정의한 키워드를 사용해 액션을 정의한다. 이들 액션은 해당 어플리케이션에 관련된 프로세스에 해당한다. 이들 키워드(또는 액션 단어)는 프로그래머가 아닌 사람들이 자동화된 테스트를 개발하는 데 사용할 수 있는 매우 간단한 명세 언어를 나타낸다.

 - 데이터 주도 테스트와 키워드 주도 테스트 기법을 조합하면 매우 강력해질수 있다. 

테크스 용이성

 - 적절한 디자인 패턴으로 만들어졌고 코드 작성 전에 작성된 비즈니스 중심 테스트는 팀이 테스트 가능한 코드 설계를 얻도록 도움을 준다. 

코드 설계와 테스트 설계

 - 테스트 용이성은 프레젠테이션 켸층의 코드를 작성할 때도 고려해야 한다. 

 - 코드 작성과 테스트는 애자일 개발 프로세스의 일부다. 코드 설계와 테스트 설계는 상호 보완적이고 상호 의존적이다. 스토리를 추정할 때 우리는 코드 작성과 테스트 양쪽 모두를 시간에 포함하며 각 이터레이션과 스토리를 계획할 때 테스트와 코드 모두의 설계 시간을 고려한다.

 - 테스트 자동화가 어렵다고 판단되면 해당 코드 설계를 평가하도록 하라.

자동화 vs. 수작업 2사분면 테스트

 - 테스트를 작성할 때  회귀 Suite에서 계속해서 반복하는 것이 중요한 것이 아니라 꼭 해야 할 중요한 한 번의 테스트를 내놓아야 할 것이다.

 - 전체 시나리오나 스프링보드에 관해 일부 자동화가 가능할 수도 있지만 지능적인 인간이 이들 테스트를 자세히 처리하는 탐색적 테스트 세션으로 생각하는 편이 좋다.

테스트 관리

 - 테스트를 자동화한다면 아직은 실행 가능하지 않더라도 자동화 프레임워크에서 이들 테스트를 나타내는 것이 좋다. 심지어 자동화되지 않은 것 조차도 그런 방안을 필요로 한다.

 - 위치는 테스트케이스를 공유하는 일반적인 방법이며, FitNesse 같은 일부 도구는 위키와 비슷한 도구를 사용해 요구사항과 사례, 실행 가능한 테스트를 한 곳에 공존하도록 서술할 수 있다 그리고 소스 코드 제어에 테스트를 포함 시켜야 어떤 버전의 테스트가 어떤 버전의 코드와 진행되는지 추적할 수 있다.  일부 팀은 테스트 관리 도구나 요구사항 관리나 결함 추적, 다른 컴포넌트를 통합할 수 있는 종합적인 테스트 프레임워크를 사용한다.

요약

 - 팀은 큰 그림에서 세부적인 요구사항과 사례를 끌어내기 위한 정확한 도구가 필요하다. 여기에는 체크리스트와 마인트 맵, 스프레드시트, 모형, 흐름도, 다양한 소프트웨어 기반 도구 등이 포함된다.

 - GUI와 관련해 실례를 효현하고 테스트를 자동화하는 도구도 애자일 테스트 자동화에 필수적이다. 이들 도구에는 단위 테스트 도구와 BDD 도구, FitNesse 등이 있다.

 - "자가 제작" 테스트 자동화는 팀의 자동화된 테스트의 총 소유비용을 낮추는 데 도움을 준다.

 - 비즈니스 중심 테스트로 개발을 이끄는 것은 애자일 팀이 테스트 가능한 코드를 설계하는 데 동기를 부여하는 한 방법이 될 수 있다. 

 - 자동화 구축을 위한 테스트 전략은 테스트를 점진적으로 만들어가면서 항상 그 테스트를 통과하도록 해야한다. 디자인 패턴을 사용하면 효과적인 테스트를 만들어 낼 수 있다.

 - 코드 설계에서 테스트 용이성을 고려해야 한다.

 - 테스트를 효과적으로 테스트하고 버전 제어에 넣을 수 있는 테스트 구성 방식이 필요하다.

Chapter 10. 제품을 평가하는 비즈니스 중심 테스트

3사분면 소개

 - 제품을 평가하거나 비평하는 일은 테스터나 비즈니스 사용자가 해당 제품을 가늠하고 그 제품에 관해 판단을 내릴 때 하는 일이다.

 - 제품을 평가하는 비즈니스 중심 테스트는 사람의 지적 능력과 경험, 본능에 의지하기 때문에 자동화하기는 어렵다. 하지만 자동화된 도구들을 사용하면 테스트 데이터 설정처럼 3사분면 테스트의 여러 측면을 도와줄 것이다.

 - 제품을 평가하거나 비평하는 일은 테스트 아래에서 시스템을 조정하고 퇴종 사용자의 실제 경험을 재창조하려는 일에 관한 것이다. 다른 비즈니스 시나리오와 워크플로우를 이해라면 더욱 현실적인 경험을 하는데 도움이 된다.

데모

 - 개발하는 내용을 초기에 고객에게 자주 보여주는 것이 좋다. 임원진이나 상위 관리자에게 하는 데모는 프로젝트에서 신뢰도를 부여해 줄 수 있다. 단꼐적인 프로젝트가 실패하는 이유 중 하나는 마지막까지 어떤 것도 보지 못한 상태에서 개발팀의 보고서만 믿고 관리가 이루어진다는 점이다. 

 - 애자일 개발의 점진적이고 반복적인 본질은 여러분에게 제품을 만들어내고 출시하기전 비즈니스 가치를 보여줄 기회를 제공한다. 새로운 기능에 관해 참여자가 적극적으로 질문할 경우 라이브 데모는 아주 강력한 도구가 될 수 있다.

 - 피드백 루프에서 변경 내용을 릴리즈에 충분히 빠르게 통합해 넣을 수 있도록 팀에서 작업하는 데모의 빈도를 선택하자.

시나리오 테스트

 - 비즈니스 사용자는 최종 사용자 행동을 모방할 수 있는 타당한 시니라오와 워크플로우를 정의하는 데 도움을 줄 수 있다. 실제 도메인 지식은 정밀한 시나리오를 만들 때 중요하다.

 - 드라마 테스트 : 한스 부왈다(Hans Buwalda, 2003). 팀이 비즈니스와 사용자 필요를 이해하는데 도움을 주는 좋은 기법. 개념은 TV 드라마가 행동가 감정을 다소 과장하고, 일련의 사건을 빠르게 압축하는 방식과 유사하게 실생활에 기반을 둔 시나리오를 과장하는 것이다.

 - 종단 간을 테스트를 할 때 임의 추출 조사를 수행해 해당 데이터와 상태 플래그, 계산 등이 기대한 동작을 하는지 확인한다. 흐름도와 다른 시각적 보조물을 사용해 기능을 이해하는 데 도움을 얻도록 하라.

탐색적 테스팅

 - 탐색적 테스팅을 애자일 세계에서 테스팅에 대한 중요한 접근 방법이며 이것은 조사 도구로서 스토리 테스트와 자동화된 회귀 Suite에 중요한 보조 수단이다. 스크립트 없는 테스팅에 대한 복잡하고 깊이 있는 접근 방법이며, 여러분이 이미 테스트한 다양한 변형들을 뛰어 넘을 수 있다. 

 - 탐색적 테스팅은 학습과 테스트 설계, 테스트 실행을 한 가지 테스트 접근법으로 결합한다.

 - 탐색적 테스팅에 익숙하지 않으면 종종 애드혹 테스팅과 혼돈한다. 탐색적 테스팅을 기능의 어떤 측면을 탐색할 덧인지를 선언함으로 시작한다. 여기에서 비판적 사고와 결과에 대한 해석, 기대 시스템이나 비슷한 시스템과의 결과 비교를 필요로 한다.

세션 기반 테스팅

 - 세션 기반 테스팅은 책임 추적성과 탐색적 테스팅을 합쳐 놓은 것이다. 테스터의 탐색적 테스팅 경험에 대한 프레임워크를 제공해 일관된 방식으로 결과를 보고할 수 있다.

 - 세션 기반 테스팅에서 시간 대역을 정해 중요한 것에 집중 할 수 있다. 테스터로서 기존의 관행에서 자주 벗어나 현재 진행하는 테스트에 중요할 수도 아닐 수도 있는 버그를 추적할 수 있다.

 - 세션은 테스트 설계와 실행, 버그 조사와 보고, 세션 설정의 세가지 종류의 작업으로 나눈다. 

자동화와 탐색적 테스팅

 - 테스트 설정이나 데이터 생성, 반복적인 작업을 수행하거나 작업 흐름을 따라 원하는 곳에서 시작하기 위해 자동화를 사용한다. 그 다음에 테스팅 기술과 경험을 사용해 실제적인 버그와 그 외에 주의를 벗어난 은밀한 문제들을 찾는다.

탐색적 테스터

 - 각 테스터는 문제에 대해 다른 접근 방법과 고유한 작업 방식을 갖고 있다.

좋은 테스터란?   - 체계적이지만 일관성이 없는 특이한 조각들을 찾아서 계속 "냄새"를 맡는다. - 여러 가지 조언 장치(문제를 인식하는 원칙이나 메커니즘)를 사용해 문제를 인식하도록 배운다. - 주제나 역할 또는 사명 선언을 선택해 테스트에 집중한다. - 세션과 짧은 일탈을 시간 대역으로 제한한다. - 전문가나 초보자가 하는 일에 관해 생각해본다 - 도메인 전문가와 함께 탐구한다. - 유사 어플리케이션이나 경쟁 어플리케이션을 검토한다.

사용성 테스팅

 - 두 가지 유형의 사용성 테스팅이 있다. 첫 번째 유형은 프로그래밍에 도움을 주는 와이어 프레임 같은 도구를 사용해 사용자 경험 전문가들이 사전에 수행한 테스팅이다. 페르소나와 같은 도구와 직관을 사용해 최종 사용자가 생각하는 제품을 살펴보는 데 도움을 얻는다.

사용자 요구와 페르소나 테스팅

 - 페르소나를 사용하는 접근 방법 중 하나는 다른 경험 수준과 요구를 대표하는 몇 명의 다른 사용자를 만들어 내는 것이다. 각 페르소나로 동일한 시나리오를 차례로 테스트하고 이들이 어떤 다른 경험을 마주하는지를 살펴볼 수 있다.

 - 페르소나 테스팅을 접근하는 또라는 방법은 허구의 인물이나 인기 있는 유명 인사를 선택해 이들을 어플리케이션을 어떻게 사용할 지를 상상하는 것이다. (브라이언 매릭(Brian Marick) & 엘리자버세 핸드릭슨(Elisabeth Hendrickson))

탐색

 - 탐색은 링크를 테스트하고 탭 순서가 합리적인지를 확인하는 아주 중요한 부분이다. 

 - 최종 사용자를 만날 수 있다면 이들을 탐색 테스팅에 참여시켜 실제 사용자와 짝을 이루거나 실제로 어플리케이션을 사용하는 과정을 관찰하고 기록하자

경쟁 제품 확인

 - 경쟁 소프트웨어에 액세스 해 볼 수 있다면, 이들 어플리케이션이 동작하는 방법을 조사해보고 여러분의 제품과 이들 제품을 비교하는데 시간을 들여 보자.

GUI 뒷단

 - 항상 인터페이스를 통해 테스트하는 것만 생각하지말고 다른 방식으로 해당 문제를 공격하는 것도 고려해보자.

API 테스팅

 - API(Application Programming Interface)는 다른 소프트웨어 어플리케이션이나 컴포넌트가 실행할 수 있는 기능의 모음이다. 최종 사용자는 보통 API의 존재를 결코 인식하지 못하고 단순히 그 위의 인터페이스와 상호작용한다.

 - 각 API는 다른 입력을 받는 매개 변수의 개수로 특정 함수를 호출한다. 해당 함수의 변형은 다른 결과를 반환한다.

 - 또 다른 테스팅 방식은 API 호출 순서를 달리하는 것이다. 순서를 변경하면 예상치 못한 결과를 낼 것이고 UI 테스팅을 통해서는 결코 발견되지 않을 버그들이 나타난다.

 - API를 통한 테스팅은 UI가 개발되지 건에 시스템에 신뢰를 줄 수 있다.

웹 서비스

 - 웹 서비스는 거비스 기반 아키텍처로 다른 시스템이 해당 시스템에 액세스할 수 있도록 외부 인터페이스를 제공한다.

 - 웹 서비스 표준의 사용은 현재 테스팅 도구에 대한 다른 영향도 제공한다.

테스팅 문서와 문서화

 - 애자일 개발로서 문서화보다는 동작하는 소프트웨어에 가치를 두지만 여전히 문서화는 가치가 있다. 사용자 메뉴얼과 온라인 도움말은 소프트웨어만큼이나 확인이 필요하다. 해당 제품의 다른 모든 구성 요소와 마찬가지로 팀원 모두가 문서화의 품질에 책임이 있으며, 여기에는 하드 카피와 전자 문서 둘 다 포함된다.

사용자 문서화

 - 자동화 테스트는 사용자 메뉴얼과 같은 문서의 콘텐츠가 정확하거나 유용한지 여부를 평가할 수  없다. 문서화는 많은 주관적인 구성요소가 있기 때문에 문서를 검증하는 것은 비판하는 활동에 가깝다. 

 - 도움말 텍스트 역시 확인해야 한다. 어플리케이션 영역에 추가 도움말 텍스트나 문서화가 필요하다고 느낀다면 팀과 고객에게 문제를 제기하라.

보고서

 - 테스팅 관점에서 종종 간과하는 또 다른 시스템 구성 요소가 보고서다.

 - 보고서를 테스트할 때 가장 큰 도전 중 하나는 서식이 아니라 올바른 데이터를 얻는 것이다.

탐색적 테스팅에 도움이 되는 도구

 - 탐색적 테스팅은 수작업 테스팅이다. 몇몇 최고의 테스팅은 사람이 종종 스크립트를 따라가면서 간과하는 세부적인 부분에 주의를 기울이기 때문이다. 직관은 컴퓨터가 배울 수 없는 것이지만 탐월함을 추구하는데 도움을 주는 도구가 있다.

 - 도구는 사람의 상호작용을 대체하지 못하기 때문에 사람의 경험을 향상 시켜야 한다. 이들 도구는 테스터에게 더 강력한 힘을 제공할 수 있으므로 다루기 어려워서 종종 무리를 지어 나타나는 재현이 어려운 버그를 찾을 수 있다.

테스트 설정

 - 세션 기반 테스팅을 사용한다면 일정한 시간을 낭비하는 사람을 추적했기 때문에 그 때 이미 테스트 설정에 어느 정도의 시간이 걸리는지 알 수 있다. 이는 자동화를 위한 훌륭한 기회이다.

 - 사용하는 도구가 어떤 것이든 계속해서 관계가 있는 다른 입력으로 시나리오를 실행할 때 이들 도구를 어떻게 적용할 수 있는지 생각해보라.

테스트 데이터 생성

 - PerlClip는 다른 유형의 입력으로 텍스트 필드를 테스트하는 데 사용할 수 있는 도구의 예다. 이는 필드의 유효성을 검증하는데 아주 유용하다. 

모니터링 도구

 - 유닉스/리눅스 명령어 tail -f나 제임스 바흐의 LogWatch 등의 도구는 오류 조건에 대한 로그 파일 모니터링을 도와준다.

시뮬레이터

 - 시뮬레이터는 테스트 중인 시스템에 대한 주요 특징과 실제 데이터의 동작을 나타내는 데이터를 생성하는데 사용된다. 시뮬레이터를 사용할 때의 또 다른 이점은 시간의 경과에 따라 시스템으로 데이터를 쏟아부어 준다는 것이다. 시뮬레이터는 일반적인 환경 아래 생성하기 어려운 오류 조건을 생성하는 데 사용될 수 있고 경계 값 테스팅에 드는 시간도 줄여줄 수 있다.

에뮬레이터

 - 에뮬레이터는 한 시스템의 기능을 복제한 것으로 테스트할 때 해당 시스템처럼 동작한다. 다른 시스템이나 장치와 연동하는 코드를 테스트해야 할 때 매우 유용하낟.

 - 에뮬레이터는 테스팅과 코드 작성이 함께 협력하며 진행되도록 도와주는 도구다. 에뮬레이터 사용은 짧은 이터레이션에서 개발에 맞추어 테스트를 하는 한 방법이다.

요약

 - 올바른 기능을 만드는 데 직접적인 도움을 줄 빠른 피드백을 얻기 위해 이해 관계자에게 소프트웨어의 데모를 시연하라.

 - 시나리오와 작업 흐름을 사용해 시스템의 전체 기능을 테스트하라.

 - 탐색적 테스팅을 사용해 자동화를 보강하고 사람의 지적 능력과 통찰력을 이용하라.

 - 테스팅과 코드를 작성할 때 사용성을 염두해 두지 않으면 어플리케이션은 셀프웨어(selfware)가 될 수 있다. 항상 시스템이 어떤 식으로 사용되는지를 인식하도록 하라.

 - GUI 뒷단에 대한 테스팅은 어플리케이션 기능성에 가장 효과적으로 접근하는 방법이다.

 - 좋은 회귀 Suite를 만들기 위해 모든 종류의 테스트를 통합하라.

 - 테스팅 문서화와 보고서에 관한 부분을 잊지 않도록 한다.

 - 자동화 도구는 데이터와 테스트 시나리오 설정 같은 지루하고 반복적인 작업을 수행하고 중요한 수작업 탐색적 테스팅에 더 많은 시간을 할애할 수 있게 해준다.

 - 기능 테스트를 자동화하는 데 이미 사용한 도구는 탐색적 테스트에도 유용하다. 

 - 운영체제와 IDE들에 내장된 모니터링과 자원 사용량, 고드 분석 도구는 테스터가 어플리케이션의 동작을 살펴보는데 도움을 준다.

 - 시뮬레이터와 에뮬레이터를 사용하면 정확한 운영 환경을 복제할 수 없을 때도 탐색적 테스팅을 할 수 있다.

 - 테스트들을 사용해 개발을 안내할 때도 원하는 동작이나 다른 시스템과의 상호작용에 대한 요구사항이 누락되거나 잘못 이해할 수 있다. 3사분면 활동은 팀이 제품에 지속적으로 가치를 더하도록 도와준다.

Chapter 11. 제품을 평가하는 기술 중심 테스트

4사분면 소개

 - 제품을 평가하는 기술 측면의 테스트는 기능적 요구사항보다 비기능적 요구사항과 더 관련이 있다.

 - 비기능 요구사항은 설정 이슈, 보안, 성능, 메모리 관리, "~성"(안전서으 상호운영성 등), 복구, 심지어 데이터 변환까지 포함하고 있다. 이러한 이슈와 관련되지 않은 프로젝트는 없기 때문에 이 이슈에 대해 생각한 내용을 체크리스트로 만들어 고객이 각가의 이슈를 얼마나 중요하게 생각하는지 문의하는 것도 좋은 방법이다.

 - 많은 고객이 비즈니스 측면의 어플리케이션에 대해서만 생각하고 비기능 요구하항에서 제품에 필요한 품질 수준의 정의를 지원하는 고객 역할의 중요성에 대해서는 이해하지 못하고 있다.

 - 많은 비기능 이슈는 여러 어플리케이션에서 영향도가 낮은 위험으로 간주되어 테스트 계획에 포함되어 있지 않지만 프로젝트를 계획할 때 이 부분의 위험에 대해서 생각하고 테스트 계획에 포함시키고 테스팅 하는데 필요한 도구와 자원을 프로젝트 계획에 포함시켜야 한다.

왜 애자일 관련 논의에서는 부하 테스팅과 같은 중요한 고려사항이 포함되지 않는가? 이는 애자일 개발은 고객에 의해 주도되고 사용자 스토리로 개발되기 때문이다.

누가 비기능 테스트를 하는가?

 - 비기능 테스트의 많은 작업에서 특별한 지식이 필요하다. 프로젝트마다 필요한 자원을 식별하자. 팀에 있는 누군가가 팀에 필요한 특별한 지식을 배울 수 있다면 아주 좋지만 그 외의 경우에는 필요한 전문가를 데려와야 한다.

 - 팀이 이러한 테스트를 위해 추가적인 자원을 지원하는 것에 무고나심하다면 팀이 최소한의 테스팅이 완료되었는지 확인할 책임이 있다. 

 - 테스팅 4분면의 4사분면에 있다고 해서 마지막에 하는 테스트라는 의미는 아니다. 팀이 언제 성능, 보안 등 "~성" 테스트를 수행할 지 생각해보고 제품이 올바른 비즈니스 가치를 전달하도록 보장해야 한다.

언제 테스트를 하는가?

 - 성능 테스트의 기준선이 전체 종단 간 작업 프름에 대한 것이라면 어플리케이션이 더 많이 개발될 때까지 기다려야 할 수도 있다 성능과 안정성이 가장 중요한 우선 순위라면 프로젝트에서 이 테스트를 초기에 시작해야 한다. 강철 스레드나 작은 조각은 초기에 완료될 수 있도록 스토리의 우선 순위를 결하자 성능 테스트는 지속적으로 실행하면서 계속해서 더 많은 기능이 필요할 수도 있다 이는 성능 이슈과 개선이 필요한 시스템 아키텍처를 조기에 발견할 수 있다.

 - 릴리즈나 테마 계획 기간에 비기능 테스트에 대해 생각해보아야 한다.

"~성" 테스팅

보안

 - 모든 조직은 소프트웨어의 기밀성과 무결성에 대한 보증이 필요하다. 어플리케이션은 각 사용자 ID에 대한 인증 및 사용자에게 허락한 서비스에만 접근 가능한 권한에 따라 정확히 수행해야 한다.

 - 보안 테스팅 기술이 있는 테스터는 구조적 위험 분석, 공격 패턴, 오남용을 처리할 수 있는 보안 위험 기반 테스팅을 수행할 수 있다.

 - 보안 검증을 도와주는 여러 자동화된 도구들이 있다. 어플리케이션 실행 없이 코드로만 검사하는 정적 분석 도구는 나타내는데 몇년이 걸릴지 모른느 잠재적인 보안 취약점을 찾아낼 수 있다.또한 보안에 대한 지식이 있는 테스터가 수작업으로 하는 탐색적 테스팅은 자동화된 테스트가 찾지 못하는  이슈를 발견하지 때문에 필수적이다.

보안 테스팅은 두 가지 관점에서 수행할 수 있다. 안에서 찾아 보는 것(화이트박스 테스팅) : 테스터가 테스트 대상 어플리케이션의 소스코드 활용이 가능하다고 가정해서 버퍼 오버 플로(buffer overflow)나 포맷 스트링 공격(format string attack)과 같이 어플리케이션의 취약점을 공격하게 만들 수 있는 공통적인 코딩 에러를 발결하도록 다양한 정적 도구로 코드를 분석한다. - 공격 표면(the attack surface) : 테스트 대상 프로그램이 사용하는 모든 입력값과 자원에 대한 목록을 매핑할 수 있다는 의미로 오류 주입(fault injection)을 기초로 한 퍼징(fuzzing : 공격 표면에 대한 지식으로 무장한 테스터가 어플리케이션 보안을 깨기 위해 사용하는 다양한 기법의 클래스)을 사용할 수 있다. 바깥에서 찾아보는 것(블랙박스 테스팅) : 대부분이 어플리케이션의 서버나 네트워크 호스팅에 침입하려는 공격

유지보수성(Maintainability)

 - 전통적인 프로젝트에서 유지보수성은 전체 코드 검토나 검사(inspection)을 이용해 수행되었다. 애자일 팀은 지속적인 코드 검토인 짝 프로그래밍을 이용한다.

 - 우리는 어플리케이션 코드, 테스트 프레임워크, 잔체적인 테스트에서 개발 표준과 가이드라인을 따르도록 한다. 표준의 종류에는 메소드나 테스트명에 대한 명명 규칙(naming convention)도 포함하고 있다. 모든 가이드라인은 간단하게 따라할 수 있고 쉽게 유지. 관리할 수 있게 만들어야 한다.

 - 데이타베이스 유지보수성 역시 중요하다. 데이터베이스 설계는 유연하고 유용해야 한다. 각각의 이터레이션은 테이블, 컬럼, 제약조건, 트리거를 추가하거나 데이터를 변환을 해야 한다. 이러한 작업은 데이터베이스 설계가 제대로 되어있지 않거나 데이터베이스가 잘못된 데이터로 뒤죽박죽되어 있다면 진핼할 때 병목현상이 생길 것이다.

상호 운용성(Interoperability)

 - 상호 운용성은 다양한 시스템과 조직의 함께 작업하고 정보를 공유하는 역량과 고나련이 있다. 상호 운용성 테스팅을 두 개 이상의 종단 간 기능을 살펴본다.

 - 애자일 개발에서 상호 운용성 테스팅을 개발 주기의 초반에 수행할 수 있다. 애자일 개발에서는 각각의 이터레이션의 마지막에 동작하고 배포 가능한 시스템을 가지고 있으므로 다른 시스템과의 배포와 설정을 테스트 할 수 있다.

 - 작업하고 있는 시스팀에 외부 시스템과 함께 작업하고 있다면 다른 시스템이나 장비의 동작을 가장한 스텁(stub)이나 드라이버(driver)를 제외하고는 모든 테스트 환경을 사용하기 어려울 것이다. 개발 후에 테스트하는 이 상황을 피할 수 없다 여러 팀과 테스트 환경을 공유하기 위해 테스트 시간을 계획해야 한다.

호환성(Compatibility)

 -  사용자 인터페이스 스토리의 일부로 각각의 새로운 화면이 개발될 때마다 지원하는 모든 브라우저에서 동작을 확인하는 것은 좋은 방법이다.

 - 테스트해야 하는 다양한 운영체제와 브라우저 또는 타사 어플리케이션에 사용 가능한 테스트 장비가 있으면 테스터가 각 스토리나 이터레이션의 마지막 부분에 호환성을 검증하는 작업이 수월해진다.

신뢰성(Compatibility)

 - 소프트웨어의 신뢰성은 일반적인 상황 뿐 아니라  예상치 못한 상황에서도 시스템의 기능이 수행되고 유지되는 능력과 관련이 있다. 또한 시스템 기능은 지속적이고 반복적으로 수행 및 유지되어야 한다. 

 - 통계적인 방법을 사용하여 신뢰성을 다음과 같이 말하기도 한다.

• 첫 실패까지의 평균 시간 (Mean time to failure) : 최초 운영과 첫 번째 실패 또는 오작동이 발생한 평균 시간. 즉 시스템이 첫 번째 실패가 일어나지 전까지 얼마나 오랫동안 실행되었는가?
• 실패 사이의 평균 시간 (Mean time between failure) :  안전성에 대한 통계적 측정. 각 실패 사이의 예상되는 평균 시간으로 계산됨. 길수록 좋음

 - 신뢰성 테스트를 수행하기 위해서는 자동화된 단위 테스트와 인수 테스트를 계속해서 실행하면 된다.

 - 천번의 테스트가 심각한 문제 없이 실행되었다는 사실이 신뢰성 있는 소프트웨어라는 의미는 아니다. 반드시 올바른 테스트를 실행해야 한다.

 - 올바른 프로그래머 테스트와 고객 테스트로 개발을 주도하면 더 나은 설계와 더 적은 결함으로 어플리케이션의 안정성을 향상시킨다.

 - 제품을 가동하고 실행하는것 뿐만 아니라 모든 사용자가 사용 가능하도록 모든 환경에서 설치가 가능해야 신뢰를 얻을 수 있다.

설치 용이성(Installability)

 - 성공적인 애자일 팀의 토대 중 하나는 지속적인 통합이다. 이 의미는 빌드가 어느 때라도 테스팅을 할 준비가 되었다는 것이다. 많은 팀이 하루 단위로 하나 이상의 성공적인 빌드를 테스트 환경으로 배포한다.

 - 배포 자동화는 반복적으로 수행되고 배포를 일상으로 만들어 주므로 초기에 가능하면 프로세스를 자동화하기 권한다.

"~성" 요약

 - 어떤 "~성" 테스트가 필요하든지 점증적인 접근 방법을 이용하자. 

성능, 부하, 스트레스, 확장성 테스트

확장성(Scalability)

 - 확장성 테스팅은 어플리케이션에 더 많은 사용자가 추가되었을 때에도 여전히 신뢰할 수 있는지를 검증하는 시스템이다. 실제의 의미는 "늘어나는 고객에 기반을 둔 용량을 시스템이 처리할 수 있는가?" 라는 것이다. 이 문제는 어플리케이션 자체가 아닌 전체 시스템의 관점에서 생각하는 것이 중요하다.

성능과 부하 테스팅

 - 성능 테스팅은 시스템의 병목 현상을 식별하거나 이후 테스팅의 기준선을 수립하기 위해 사용된다. 또한 성능 목표와 요구사항에 대한 수락을 보증하고, 이해 관계자가 테스트된 어플리케이션의 전반적인 품질과 관련한 의사 결정을 지원한다.

 - 부하 테스팅을 동 시간에 시스템에 점점 더 많ㅇ느 사용자가 접근할 때의 시스템 동작을 평가한다. 스트레스 테스팅은 예상치보다 높은 부하를 이용해 어플리케이션의 견고성을 평가한다. 

 - 게오르규 (Grig Gheorghiu, 2005) : 시스템이 어느 방향으로 가야 할지 모른다면 본인이 장소를 결정하는 것이 낫다.

성능 테스팅과 부하 테스팅 도구

 - 성능 목표를 정의하고 나면 시스템에 부하를 주고 병목 형상을 확인하는 다양한 도구를 사용할 수 있다. (JUnitPerf, httprerf, JMeter, The Grinder, Pounder, ftptt, PenWebLoad)

 - 이런 도구를 성능 병목 현상을 찾아내는 데 사용하자.

기준선(Baseline)

 - 성능 튜닝은 그 자체가 대형 프로젝트가 될 수 있으므로 새로운 버전의 소프트웨어 성능과 비교할 수 있는 기준선을 제공하는 것은 필수적이다. 성능 기준선을 수립하는 것은 나중에 어느 기능의 응답 시간이 가장 빨랐는지 알 수 있는 좋은 아이디어이다.

 - 특정 기능을 위해 정의된 특정 성능 기준이 있다면 수정이 힘들어지기 전에 이슈를 찾아낼 수 있도록 이터레이션의 한 부분으로 성능 테스팅을 포함시키는 것이 좋다.

테스트 환경

 - 성능 테스트의 마지막 실행은 고객이 제품의 인수를 결정하는 데 도움을 준다. 정확한 결과를 위해 테스트는 운영 환경과 유사한 장비에서 실행되어야 한다.

메모리 관리

 - 메모리 관리는 일반적으로 RAM, ROM, 하드 드라이브 등에서 사용되는 메모리의 양(보통 최대 또는 최소)를 의미한다. 운영 환경의 어플리케이션이 최대 사용량이 되면 끔찍한 실채의 원인이 되기 때문에 메모리의 사용량이나 누수에 주의를 기울여야 한다.

 - 가비지 수집(Garbage collection)은 프로그램에 대해 메모리를 다시 해제할 때 이용하는 하나의 도구다. 그러나 가비지 수집은 메모리 이슈를 제공하기도 한다. 

- 반드시 자신이 기술 측면의 테스팅을 계획하고 실행을 통해 제품을 평가하는 전문가가 돼야 하는 것은 아니다. 팀은 이 사분면을 통해 팀에 필요한 테스트가 무엇인지 평가할 수 있다.

요약

 - 개발팀은 이 테스트를 수행하는 전문가를 이미 보유했는지 또는 투입 가능한지, 외부 자원을 확보하는 계획이 필요한지 여부를 평가해야 한다.

 - 점증적인 접근 방법은 이 테스트를 각 이터레이션에서 완료해서 발생한 이슈를 처리하고 제품 문제를 예방할 수 있게 한다.

 - 팀은 보안, 유지보수성, 상호 운용성, 호환성, 안정성, 설치 용이성 테스팅 등 다양한 종류의 "~성" 테스팅을 고려해야 하고 적절한 시점에 이 테스팅을 실행한다.

 - 성능, 확장성, 스트레스, 부하 테스팅은 프로젝트 초반부터 수행되어야 한다.

 - 제품에 영향을 미치는 메모리 관리 이슈에 대해 조사하고 어플리케이션의 메모리 해제 이슈를 검증하는 테스트 계획을 세우자.

Chapter 12. 테스팅 사분면 요약

테스트 주도 개발(TDD)

 - TDD(test driving development)는 단위 테스트와 인수 테스트를 포함한다.

단위 테스트

 - 단위 테스트는 프로그래밍을 지원하는 기술 중심 테스트다. 이 테스트는 테스트 주도 개발의 한 부분으로 개발된 것으로 프로그래머가 정확한 스토리를 작성하는 것 뿐만 아니라 시스템을 설계하는데도 도움이 된다.

인수 테스트

 - 인수 테스트는 3가지 목적으로 제공됐다. 우선 이들 테스트는코딩이 시작되기 전에 팀에게 테스트를 주었기 때문에 개발을 지원하는 비즈니스용 테스트였다 둘째로 테스트 팀에서 회귀 수트에 반영하고 탐색적 테스트에 차후 아이디어를 제공하는 자동화의 기반으로 이들 테스트를 사용했다. 세 번째 목적은 해당 구현이 고객의 요구사항과 부합하는지를 확인하기 위해서였다. 

자동화

 - 자동화에는 기능 테스트 구조와 웹 서비스, 임베디드 테스팅을 포함한다.

비즈니스 중심 테스트로 제품 평가하기

탐색적 테스트

 - 자동화된 테스트를 보완하고 가능한 한 넓은 범위를 검사하기 위해 탐색적 테스팅을 시행한다. 이러한 시스템과 인간과의 상호작용을 통해 자동화로 발견하지 못한 문제점을 알 수 있다.

데이터 공급 테스팅

 - 시스템 데이터는 웹 브라우저와 마찬가지로 JMS 큐에서 확인 할 수 있다.

종단 간 테스팅(The End-to-End Tests)

 - 3사분면은 시스템의 모든 부분에 대한 원하는 동작을 시연하는 종단간 기능 테스트를 포함한다.

사용자 인수 테스팅

 - 사용자 인수 테스팅(UAT)는 프로젝트 초기부터 포함된 고객에 의한 최종 제품 평가다.

문서화

테스트 코드 문서화 하기

 - 테스트 코드의 문서는 테스트를 문서화하고 우리가 테스트할 것과 테스트한 것을 쉽게 알아내는 데 도움이 된다.

요약

 - 전체 팀은 각 테스팅 문제를 해결하는 도구를 선택하거나 만들어야 한다.

 - 스프레드시트와 고객이 작성한 테스트 스크립트 처럼 공통 비즈니스 도구의 조합은 복잡한 테스트를 해내는데 필요하다.

 - 팀의 모든 구성원이 작업하는 정확한 테스트 아키텍처를 구룩하는데 시간을 투자하자.

 - 고객이 멀리 떨어져 있더라도 모든 유형의 테스팅에 참여할 방법을 찾자

 - 이터레이션과 프로젝트 진행에 관해 모든 이해관계자가 알도록 중간에 테스트 결과를 보고하자.

 - 문서화하는 것을 잊지말자. 그러나 도움이 되는 것만 하자.

 - 개발 주기 동안 네 가지 모든 테스팅 사분면에 대해 고민해보자.

 - 제품을 평가하는 테스트를 수행하는 동안 배운 교훈을 후속 이터레이션에서 개발 주도하기 위해 사용해보자.

Chapter 13. 테스트를 자동화하는 이유와 자동화의 장애물

자동화하는 이유

 - 수잡업 테스트는 오래 걸린다.

 - 사람이 수작업으로 테스트하다보면 실수가 생기기 마련이다.

 - 자동으로 테스트를 하면 사람은 본연의 개발 업무에 좀 더 집중 할 수 있다.

 - 자동화된 회귀 테스트를 하면 좀 더 안전하다.

 - 자동화된 테스트가 피드백이 더 자주, 많이 온다.

 - 테스트가 코딩을 주도하면 더 많은 일을 할 수 있다.

 - 테스트 자체가 휼륭한 문서이다.

 - 자동 테스트가 투자 대비 얻는 것이 더 많다.

자동화의 장벽 - 방해물

브렛의 리스트

 - 남는 시간에만 테스트 자동화를 한다면 필요한 곳에 집중하지 못한다.

 - 분명한 목표가 없다.

 - 경험 부족

 - 경험이 축적되지 않으므로 이직률이 높아진다.

 - 절망적인 상황에 대한 반응으로 어쩔수 없이 자동화를 채택하는 경우 현실적인 요구를 반영하지 못한다.

 - 마지못해 테스트를 생각하는 경우 자동화는 재미있지만 테스트는 재미없다.

 - 기술적인 문제의 해결에만 집중하다 보면 테스트가 원하는 결과가 뭔지 간과할 수 없다.

우리의 리스트

 - 프로그래머의 태도 : 정통적인 환경 즉, QA팀이 테스트를 수행하는 것을 본 적 없이 독립적으로 일해 온 프로그래머라면 기능 테스트의 자동화에 대해 별로 생각해 본적이 없을 것이다.

 - "고통의 고객나루" : 테스트의 자동화를 배우는 것은 어렵다.특히 투자 대비 많이 얻는 방법은 더 그렇다.

 - 초기 투자 : 자동화에는 투자가 많이 필요하며 이 투자의 결과가 바로 나타나지 않는다. 테스트 자동화가 당장 효과가 있을지는 전적으로 테스트의 설계 기술에 달렸다.

 - 끊임없이 변화하는 코드 : 사용자 인터페이스(UI)를 통해 테스트를 자동화하는 것은 까다로운 것이다. 

 - 레거시 시스템 : 기존 코드를 리팩터링하려고 테스트를 자동화하려는데 기존 코드는 테스트를 고려하지 않고 설계된 것이라면 단위 수준에서조차 테스트 하기 어렵다.

 - 공포감 : 테스트 자동화는 이를 마스터라지 못한 사람뿐만 아니라 마스터한 사람에게도 겁나는 일이다.

 - 오래된 습관들 : 개발 진행이 삐걱거리거나 개발 일정이 끝나도록 프로그래밍과 테스트 업무가 완료되지 못한다면 팀원들은 패닉 상태에 빠질지 모른다. 이런 상태가 되면 오래된 편한 습관에 안주는 경향이 있다.

이런 장애물을 극복할 수 있을까?

 - 팀원 모두가 기술 관련 테스트와 비즈니스 관련 테스트 모두를 작성, 사용, 실행하는 방법을 고민하도록 하려면 리더쉽과 품질에 대한 책임감이 필요하다.

요약

 - 자동화는 안전망이며 꼭 필요한 피드백을 주고 꼭 해야할 기술적 업무를 최소화하며 코딩을 진행하는 데 도움이 된다.

 - 공포심, 지식의 부족, 과거 자동화에 대한 안좋은 기억들, 코드의 잦은 변경, 과거에 만들어 놓은 코드 등이 자동화의 장애물이 된다.

 - 회귀 테스트를 자동화하고 이를 자동화된 빌드 프로세스에서 실행하고 결함의 근원을 바로잡으면 기술적 업무가 줄어들고 코드를 만드는 것도 가능하다.

 - 회귀 테스트와 지루한 수작업을 자동화하면 팀이 탐색적 테스팅과 같은 보다 좋은 일에 집중하게 된다.

 - 자동화된 테스트와 자동화된 빌드 프로세스가 있는 팀이 개발에 속도가 더 붙는다.

 - 자동화된 회귀 테스트가 없이 수작업으로 테스트하다 보면 테스트 범위가 점점 늘어나서 끝내는 아예 빼먹고 지나갈 수 있다.

 - 팀 문화와 전통 때문에 개발자들이 새로운 기능을 코딩하는 것보다 비즈니스 관련 테스트에 더 우선순위를 두는 것이 어려울 수 있다. 애자일의 원착과 가치를 모든 팀원들이 테스트 자동화의 장애물을 극복하는 데 도움이 된다.

Chapter 14. 애자일 테스트 자동화 전략

테스트 자동화를 위한 애자일 접근법

테스트 자동화 피라미드

 - 애자일 테스트 자동화 피라미드는 세 가지 계층으로 구성되어 있다.

 - 단위 테스트/컴포넌트 테스트 : 가장 아래쪽에 있는 것이 기반 계층으로 상부 계층을 지원한다. 여기에는 단위 테스트, 컴포넌트 테스트 등 팀이 지원할 기술적인 내용과 관련된 것들이 주로 포함된다. 이 계층에서는 자동화된 테스트 자체를 표현하기도 하는데 대개 이들은 테스트 대상 시스템과 같은 언어로 작성되고 xUnit 등의 테스트 도구를 사용하기도 한다.

 - 인수 테스트(API 계층) : 애자일 개발 기법에서는 이 계층에 최대한 많은 테스트를 밀어넣으려고 노력한다.  성능 테스트 같은 기술 중심 테스트는 단위 수준에서도 가능하다.

 - GUI 테스트 : 대부분 팀을 지원하는 비즈니스 중심 테스트의 자동화로 구성되어 있다.  이 계층은 "스토리 테스트", "인수 테스트" 등 작은 단위 테스트보다는 좀 더 거시적 관점의 테스트로 구성된다. 이 계층은 투자 대비 이익이 가장 낮으므로 최소한의 자동화 노력만 있음 된다.

 - 수동 테스트 : 아무리 테스트 자동화가 이루어진다고 해도 대부분의 시스템에서는 아직도 수작업 테스트, 이를 테면 탐색적 테스트나 사용자 인수 테스트 같은 것들이 필요하다.

무엇을 자동화할 것인가?

 - 생각할 수 있는 거의 모든 테스트는 자동화를 통해 이익을 얻을 수 있다.

지속적인 통합, 빌드, 배포

 - 자동화된 배포 프로세스는 테스트의 속도는 빠르게 하고 오류도 줄여준다.

 - 지속 통합과 빌드 프로세스를 빠르게 하는 열쇠는 한 번에 작은 단계 하나씩 취하는 것이다. 각 단계별로 성공을 측정하고 옳은 방향으로 가고 있는지를 알 수 있도록 변경은 한번에 하나씩만 한다.

 - 지속적인 통합과 빌드 프로세스를 빠르게 실행하는 것이 그 어떤 자동화 노력보다도 투자 대비 이익이 가장 높다. 

단위 테스트와 컴포넌트 테스트

 - 프로그래머가 TDD를 테스트 작성 메커니즘으로 사용하면 휼룽한 회귀 수트뿐만 아니라 이를 활용해 고품질의 안전된 코드를 만들어낼 수 있다.

API와 웹 서비스의 테스트

 - 자동화를 활용하는 데 API나 웹 서비스 어플리케이션이 가장 쉽다.

GUI 내부 테스팅

 - 프로젠테이션 계층의 영향을 받지 않고 좀 더 안정된 비즈니스 로직 코드에서 테스트가 실행되기 때문에 GUI 내부 테스트는 GUI 자체의 테스트보다 자동화하기 더 쉽다.

GUI 테스트

 - 매번  새로운 기능이 추가도며 빠르게 진행하는 애자일 개발에서는 어느 프로젝트에서나 GUI 수준의 자동화된 회구 테스트가 꼭 필요하다.

 - 성공적인 GUI 테스트 자동화를 위해서는 도구의 선택이 중요하다.

 - 테스트는 실제 인터페이스에 국한해야 한다. 비즈니스 기능까지 테스트하려 하지 않도록 하자.

부하 테스트(Load Test)

 - 부하 테스트는 자동화하지 않으면 불가능 하다.

비교(Comparison)

 - 의도하지 않은 변경사항이 있는지를 알려주는 스크립트가 있으면 사람이 직접 읽어보고 일일이 비교하는 것보다 더 빠르고 정확하다.

데이터 생성 또는 설정

 - 데이터를 끊임없이 설정하고 있다면 이과정을 자동화하자

자동화가 적절하지 않는 분야

사용성 테스트

 - 사용자가 수행한 액션을 기록하는 것은 사용자 테스트에 큰 도움이 된다.

탐색적 테스팅

 - 테스트 데이터를 생성하고 설정 단계로 넘어가는 것은 스크립트로 빠르게 진행할 수 있지만 테스트를 설계하고 실행하는 것은 테스트의 기술이 필요하다.

결코 실패하지 않는 테스트

 - 한 번의 수작업 테스트로 테스트가 끝나고 미래에 있을 실패에 대한 위험성이 회귀 테스트 자동화를 정당화하지 못한다고 생각한다면 자동화를 하지 않아도 된다.

일회성 테스트

 - 대부분의 경우 일회성 테스트는 수작업으로 해도 충분하다.

자동화하기 어려운 분야

 - 테스트 주도, 아니면 최소한 테스트 자동화를 고려하고 코드를 작성한 것이 아니라면 자동화는 매우 어렵다.

 - 어느 장동화 프로젝트나 마찬가지로 자동화하기 어려운 코드는 하 ㄴ번에 하나씩 접근해나가고 가장 위험도가 높은 것부터 먼저 해결해 나간다. 테스트 가능성 문제를 해결하고 단위 수준의 테스트를 작성할 방법을 찾아보라.

자동화 전럅 수립 - 어디서부터 시작할까?

 - 팀에서 테스트 문제를 들여다보면서 어디서 자동화를 할 것인지를 고려해봐야 한다. 

 - 풀려는 문제가 무엇인지 이해해야 한다. 

 - 처음부터 시작하도록 하자.

가장 아픈 곳은 어디인가?

 - 가장 아픈 분위가 어느 곳이든 그곳이 바로 자동화 노력을 시작할 지점이므로 팀에게 물어봐라

 - 테스트 자동화는 휼륭한 개발 실천방법이 병행되지 않는다면 소득이 없다. 잘만든 단위 테스트를 실행하는 연속적 통합이야 말로 다른 테스트를 자동화하는 첫걸음이다.

다계층 접근방법

 - 필요에 딱 맞는 도구를 써야 한다. 

 -  자동화 노력의 결실을 평가할 때는 도구로 인해 기술 부서와 고객 지원부서의 협력이 증진되는 것과 같은 무형적인 효과도 고려해야 한다. 자동화된 인수 시험 테스트를 작성하면서 비즈니스 요구사항을 철저히 이해하게 되었다면 테스트로 회귀 버글르 전혀 잡아내지 못했어도 큰 소득을 얻은 것이다.

테스트 설계와 유지. 보수 고려

• 테스트 설계 : 테슽 하려는 기능의 최소 단위나 중요 실행결로에서부터 시작해야 한다는 것을 잊어서는 안된다. 테슽 패턴을 철저히 선정한다. 테스트 목적을 이해해야 한다.
• 옵션을 고려하라 : 테스트 자동화를 미라미드에서 가능한 가장 낮은 수준까지 몰고가자
• 사용자 인터페이스 : 좀 더 높은 수준에서의 자동화를 한다면 시스템을 통해 가능한 모든 경로를 자동화해야 한다. 단위, 코드 통합, 기능의 각 수준에서 모든 주요 경로를 다 포함하도록 노력하는데 집중하자.
• 균형을 유지하라 : 균형 유지는 애자일 원칙이 아니라 그냥 상식이다.

최적의 도구를 선택하기

 - 개발 초기 위험이 높은 스토리를 작업할 수도 있는 시기에 도구를 선정하고 테스트 환경을 구축해야 할 수도 있다. 도구를 검토하고 빌드 프로세스를 준비하고 여러 가지 테스트 방법을 시험하기 위한 계획을 세우자.

테스트 자동화에 애자일 원칙 적용

단순함을 유지하기

 - 테스트 설계를 간단히 하자. 테스트 범위는 최소한으로 가고 가능한 도구 중 가장 간단한 것을 사용한다.

반복적 피드백

 - 반복 단위가 짧으면 다양한 자동화 접근법을 실험해 결과를 평가해볼 수 있고 필요에 따라 빠르게 변결할 수도 있다. 각 이터레이션 후에 효과가 있는 것과 그렇지 않은 것을 살펴보고 문제를 극복할 아이디어를 생각해서 다음번 테스트에 시험해보자.

전체 팀(Whole-Team) 접근법

 - 팀 접근법은 유용한 자동화 전략을 찾아내고 구현하는데 필요한 기술과 자원이 다양하게 있는 것을 의미한다. 팀단위로 문제를 공략하면 테스트를 고려해서 코드를 설계할 수 있는 가능성이 더 많아진다. 프로그래머와 테스터를 비롯한 팀원들이 협동하고 다양한 관점에서 기술을 동원해 테스트를 자동화한다.

 - 전테 팀 접근법은 두려움의 벽을 극복하는데 도움이 된다.

제대로 작업할 시간 확보하기

 - 문제를 해결하고 좋은 해결책을 구현하는 데는 시간이 필요하다.일을 제대로 하는데 필요한 충분한 시간이 없이는 기술적 부담이 점점 늘어나기만 하고 작업 속도도 느려진다는 사실을 경영진에 이해시켜야 한다.

 - 데드라인은 언제나 있고 우리는 늘 시간적 압박을 받고 잇다 효과가 없다는 것을 알면서도 예전에 늘 하던 방식으로 돌아가서 수작업으로 회귀 테스트를 수행하고 최선의 상황을 기대하고픈 유혹이 언제나 있다. 예전으로 돌아가서 문제를 해결할 시간은 절대 없다. 다음 번 계획 회의 때는 자동화 노력에 의미있는 진전을 이루어낼 시간을 투자하자.

 - 스스로가 성공을 경험하자. 지속 가능한 속도로 일하고 일이 진행되는 동안 계속 리팩토링을 하자.

 - 비즈니스 이해 관계자들이 여러분의 팀이 "깔끔하게 끝내기"를 초조하게 기다리고 있다면 그들과 함께 문제를 분석하자.

실천하면서 배우자

 - 배우는 방법이 각자 다르지만, 테스트 자동화를 어떻게 할 것인지 결정했다면 일단 시작하고 보자.

애자일 코딩 실천방법을 테스트에 적용하기

 - 운영 코드는 이를 뒷받침하는 테스트가 없으면 그다지 가치가 없다. 테스트도 코든 코드와 똑같이 취급하자. 특정 버전의 코드와 함께 돌아가는 버저느이 테스트를 언제나 유지해야 한다.

 - 좋은 품질의 코드는 좋음 품질의 자동화된 테스트에서 나온다. 자동화 업무는 엄격한 통제 하에 조금씩 단계적으로 각 단계가 성공적인지 확인하면서 진행해야 한다.

테스트용 데이터 제공하기

 - 어떤 도구를 사용해 테스트 자동화를 하든 테스트에는 처리할 데이터가 필요하다.

데이터 생성 도구

 - 몇가지 멋진 도구들은 모든 종류의 입력 필드와 한계 조건에 맞는 테스트 데이터를 생성해준다. (Data Generator, databene benerator, testgen, Datatect, Turbo Data)

 - Ruby나 Python 같은 스크립트 언어, Fit나 FitNesse 같은 테스트 도구, Shell 스크립트 등의 사용해 테스트 데이터를 생성하는 것도 비교적 쉽다.

데이터베이스 액세스는 피하자

 - 데이터베이스를 액세스하면 디스크 I/O 때문에 느리게 실행되서 테스트가 느려진다. 메모리에서 동작하는 가짜 데이터베이스를 활용하면 원하는 테스트를 하면서도 빠른 피드백을 얻을 수 있다.

 - 데이터에비스 없이 테스트를 하도록 하고 이 것이 어려우면 시스템 아키텍처를 개검토하고 테스트를 위해 더 잘 구성할 수 없는지 살펴본다.

 - 테스트를 위한 데이터를 생성할 때는 가능한 테스트가 의도한 바를 반영할 수 있는 값을 사용하자.

데이터베이스 접근이 불가피하거나 오히려 바람직한 경우

 - 테스트 대상 시스템이 데이터베이스에 강하게 의존하고 있다면 당연히 테스트해야 한다. 테스트하는 코드가 데이터베이스에 자료를 읽거나 쓰고 있다면 특정 시점에서는 테스트를 해야하고, 최소한의 회귀 테스트를 해서 코드의 데이터베이스 계층을 검증해야 한다.

필요를 이해하자

 - 테스트의 목적을 이해한다면 필요한 것들이 더 잘 검토할 수 있다.

자동화 도구 평가하기

자동화 도구에 필요한 요구사항 식별하기

 - 도구에 대한 요구사항은 개발 환경과 관련이 있다. 도구에 대한 요구조건을 나열하는 체크리스트를 작성하자

한 번에 도구 하나씩

 - 서로 다른 목적을 위해 서로 다른 도구가 필요할 것이다. 한번에 하나씩 가장 힘든것부터 해결해 나가자. 충분한 시간을 들여 잘 검토하고 그 결과를 평가해보자.

  - 도구를 평가해볼 시간을 투자하자.기술적 채무를 줄이고 좋은 테스트 인프라를 구축하는 것이 미래에 작업 속도를 빠르게 하고 탐색적 테스트를 할 시간을 확보할 수 있게 한다.

도구 선택하기

 - 도구를 선택하는 데 중요하는 것은 많은 선택 사항 가운데 우리의 필요에 맞는 도구를 어디에서 찾을지를 아는 것과 이들 도구가 요구사항을 만족하는지를 살펴볼 시간을 확보하는 것이다. 

• 직접 만들까? : 직접 구축한 도구는 확실히 프로그래머 친화적이며 개발팀이나 고객 지원팀의 요구에 맞춰 수정하는 것이 가능하고 기존 빌드 프로세나 다른 개발 인프라와 연동하는 것도 가능해서 실행하고 그 결과를 원하는 방식으로 해석하는 것이 가능하지만 소규모 개발팀은 운영 코드를 만들고 동시에 테스트 도구를 만들고 유지 관리하기 어렵다.
• 오픈 소스 도구 : 비용 측면에서 적절해서 다른 도구를 구매하는 것과 비교하면 훨씬 비용이 적지만 모든 오픈 소스 도구가 잘 문서화된 것이 아니라 교육에 문제가 될 수 있다.
• 상용 도구 : 상용 도구는 대개 매뉴얼과 사후 지원, 교육 과정 등이 함께 제공되는 편이며 기술적 배경이 약한 테스터나 사용자가 초기에 빨리 적응할 수 있다. 그러나 이런 도구는 대개 무겁고 테스트 스크립트가 취약해 사소한 변화에도 큰 영향을 받는데다 유지 관리에도 비용이 많이 든다.

애자일 친화적 도구

 - 애자일 테슽 자동화 도구의 특징 (엘리자베스 핸드릭슨)

• 테스트 우선(Test-first) 접근법을 이용해 테스트 자동화 업무를 바로 시작해볼 수 있는 방법 지원
• 테스트 본질과 세부적 구현의 분리
• 테스트 자동화에 있어서 코드 부분을 프로그래밍하는 좋은 예제를 지원
• 실제 IDE를 통해 실제 언어로 자동화 작성 가능
• 협업 장려

자동화의 구현

 - 도구를 검토할 때는 자동화의 과제를 얼마나 빠르게 해결할 수 있는지를 생각해야 한다.

 - 좋은 객체 지향 설계는 유지 보구가 쉬운 테스트를 만드는 것이 핵심이기만 한 것은 아니다. 팀이 원하는 피드백을 얻을 수 있을 만큼 자주 실행해야 한다. 도구를 선택했으면 이를 빌드 프로세스와 연계시켜야 한다. 해석하기 쉬운 결과물로 자동으로 나와야 한다.

 - 선택한 도구는 우리의 플랫폼에서 동작해야 하고 테스트 도구와 맞물려서 잘 동작해야 한다.

자동화된 테스트 관리

 - 자동화된 테스트는 제품 소스코드와 마찬가지 방법으로 유지 보구하고 통제되어야 한다.

테스트의 조직화

  - 테스트 관리는 다음의 질문에 대한 대답을 하는데도움이 된다.

• 지금까지 어느 테스트케이스가 자동화되었는가?
• 어느 테스트가 아직도 자동화가 필요한가?
• 회귀 테스트의 일부분으로 동작하는 테스트는 어느 것인가?
• 기능 영역을 다루는 테스트는 어느 것인가?
• 이 테스트 케이스는 누가 언제 작성하였는가? 누가 가장 최근에 변경했는가?
• 이 테스트는 얼마나 오랫동안 회귀 테스트 Suite의 일부로 있었는가?

 - 테스트를 작성하는 주된 이유 중 하나가 개발에 가이드를 주는 것이므로, 모든 팀원이 각 스토리에 대한 적절한 테스트를 찾고 이 테스트가 커버하는 기능이 어떤 것들인지를 식별할 수 있도록 테스트를 조직화 해야 한다.

테스트 결과 구성하기

 - 소프트웨어에 관련된 모두가 테스트와 그 결과에 쉽게 접근할 수 있어야 한다. 테스트를 관리하는 또 다른 관점은 앞 단계에서 한 테스트이면서 계속 통과중인 테스트와 현 단계에서의 테스트이면서 아직 통과하지 못한 테스트를 구분하는 것이다. 지속적인 통합과 빌드 프로세스에서는 진행 상황에 대한 , 빠른 피드백과 회귀 오류를 잡아야는 테스트를 실행한다.

 - 테스트를 통해 개발을 진행하고 있으면서 아직 통과못한 테스트가 있다면 이것 때문에 빌드가 실패하면 안된다.

 - 테흐트 관리는 조금씩 차근 차근 실험을 해서 소스 코드 통제와 저장소, 테스트와 운영 코드의 동기화를 유지할 수 있는 빌드 관리의 최적 조합을 찾아내자.

요약

 - 애자일 테스트 사분면을 활용해 언제 어디서 테스트 자동화가 필요한지 확인하자.

 - 애자일의 원칙과 가치, 기법을 적용하면 테스트 자동화의 추진력을 얻을 수 있다.

 - 반복되는 작업, 지속적인 통합과 빌드 프로세스, 단위 테스트, 기능 테스트, 부하 테스트, 데이터 생성 등이 자동화의 우선 고려 대상이다.

 - 단순하고 팀 전체가 움직이며, 반복적인 피드백을 받고 충분한 시간이 있으면 좋은 솔루션을 선전하는 데 도움이 된다.

 - 자동화 전략을 세울 때는 고통이 가장 큰 영역부터 시작하고, 다층 접근법을 고려하고, 한 번에 완벽을 추구하기 보다는 끊임없이 개선해 나가도록 노력하자.

 - 무엇을 자동화할지 결정할 때는 위험과 투자 대비 이익을 고려하자

Chapter 15. 릴리즈와 테마 계획에서 테스트의 활동

릴리즈 계획의 목적

 - 소프트웨어 개발팀이 애자일 개발을 시도하는 이유 중 하나는 오랜 시간 계획해도 제대로 진행되지 않음을 알기 때문이다. 애자일 개발팀은 "중요 설계를 선행하는 일"을 방지해야 한다.

 - 고객이 바라는 것이 무엇이고 휼룽한 시작을 위해서는 우리가 어떻게 인도할 것인지 어느 정도 이해해야 한다.

 - 매 이터레이션마다 몇 개의 스토리를 완료할 수 있는지 정확하게 예측하는 것은 불가능하기 때문에 상세히 계획하려는 의도는 아니지만 릴리즈 계획 미팅에서 평균적인 개발 속도에 대한 생각은 가지고 있어야 하고 이를 통해 릴리즈에서 가능한 범위에 대한 적절한 아이디어를 얻을 수 있다.

 - 비즈니스가 원하는 스토리를 서로 비교하여 크기를 정하고, 개발팀이 인도하는 가치에 따라 기능의 우선 순위를 결정한다. 팀은 어떤 스토리가 반드시 완료되어야 하고, 범위가 어느 정도이고 나중까지 미룰 수 있는 "괜찮은 부분"은 어디인지 결정하기 위하여 기능에서 "작은 조각"을 확인할 수 있다. 그리고 스토리 간의 의존성, 관련된 위험, 그 밖의 다른 요건들에 주의를 기울일 것이다. 우선순위에 따라 정해진 스토리의 코딩 순서는 때때로 스토리의 크기보다도 중요하다. 그리고 팀은 릴리즈의 첫 번째 이터레이션에서도 충분한 가치를 인도해야 한다.

 - 릴리즈 계획은 개발자와 고객이 거대한 시스템을 위해 계획한 기능의 영향도를 고려하고 가정을 명확화하고 먼저 완료되어야 하는 스토리가 무엇인지에 대한 의존성 확인을 할 수 있는 기회이다. 그리고 상위 수준의 테스팅과 필요한 테스트 환경과 소프트웨어 같은 자원에 대해 생각할 것이다.

크기 결정하기

 - 애자일 팀은 각 스토리의 상대적인 크기를 측정한다. 신규 애자일 팀이라면 스토리의 크기를 알아가는 데 보다 많은 실행과 경험이 필요하다. 각각의 스토리 크기를 정확하게 결정하는 것이 중요하진 않으나 고객이 더 좋은 정보를 이용하여 큰 스토리 안에서 우선 순위를 정할 수 있도록 가급적 유사한 값으로 추적하는 것이 좋다. 시간이 지나 각각의 스토리에 대한 시간 차이가 동일 수준이 된다면 테마나 관련된 스토리가 시간이 얼마나 필요한지 알아낼 수 있다.

스토리의 크기를 알아내는 방법

 - 각각의 스토리에 대한 상대적인 크기는 중요한 요소이다. 비즈니스가 평균 개발 속도(팀이 각각의 이터레이션을 완료할 수 있는 스토리 점수의 숫자)를 알고 완료하고 싶은 스토리의 초기 크기를 추정했다면 주어진 테마를 구현하는 데 얼마나 걸릴지에 대한 아이디어를 발견할 수 있다.

스토리의 크기 결정에 테스트의 역할

 - 보통 스토리의 크기를 추정할 때 테스팅을 포함하지 않고 진행한다. 어떤 경우에는 기능을 테스트하는 데 이 기능을 코딩하는 것보다 더 많은 시간이 소요된다.

 - 테스터는 보통 업무 영역에 대해 광범위한 이해를 가지고 있고 하나의 스토리가 나머지 시스템에 미치는 "파급 효과"를 빠르게 식별할 수 있다. 그리고 사용자 교육이나 신규 또는 변경된 인터페이스와 같이 개발과 직접적으로 관련되지 않았으나 수행이 필요한 활동을 잘 생각해 낸다.

 - 스토리가 테스팅할 요소는 많은데 코딩은 적은 노력만 필요할 때가 있다. 그리고 그 반대의 경우도 있다. 그래서 모든 관점을 고려하는 것은 중요하다.

우선순위 결정하기

 - 릴리즈 날짜에 맞추어 어느 스토리를 완료해야 하는지에 대한 아이디어를 얻는 것 역시 릴리즈 계획 회의의 목적이다. 고객은 스토리의 우선 순위를 정하지만 의존성이 있는 스토리가 있을테고, 제일 높은 우선순위가 아니라 할지라도 이런 스토리를 먼저 하는 것이 좋다. 릴리즈 날짜에 모든 스토리를 완료한다는 것은 불가능하다는 것을 팀이 이해하는 것이 중요하다. 애자일의 기본적인 가정 하나는 동작하는 소프트웨어를 인도한다는 것이고 고객이 필요한 우선순위가 제일 높은 스토리를 먼저 완료하는 것이 중요하다.

왜 스토리의 우선 순위를 정해야 하는가?

 - 우리 모두의 목표는 각 이터레이션에서 실제 가치 있는 소프트웨어를 인도하는 것이다. 테스터는 반드시 동작해야 하는 핵심 기능을 선택하는 데 도움을 줄 수 있다.

우선순위 결정 시 테스팅 고려 사항

 - 팀이 큰 그림이나 테마를 이해하는 것이 중요하다.

 - 릴리즈 계획 동안 스토리의 상대적인 위험에 대해서도 고려해야 한다. 어떤 스토리에 모르는 부분이 많다면 스토리가 엉망이 되거나 추정보다 많은 시간이 필요할 때 조치할 시간까지 고려해야 가급적 초기 이터레이션에 포함해야 한다.

 - 새로운 기술이나 소프트웨어가 필요하다면 이후 더 어려운 스토리를 위해 간단한 스토리와 계획을 진행하여 학습하자. 기능이 완전히 새롭고 팀이 어떻게 작업해야 하는지 이해하는 데 더 많은 시간이 필요하다면 척 번째 이터레이션은 평균 개발 속도보다 적게 계획하자.

 - 테스팅 관점에서 스토리를 살펴보는 것은 필수적인 일이다. 

 -  테스팅이 어려울 것으로 예상되는 스토리가 있다면 일찍 테스트를 시작하는 것이 좋다.

범위에는 무엇이 있는가?

 - 애자일 팀은 품질을 유지하며 비즈니스 마감일에 맞춰 지속적으로 범위를 관리한다.

마감일과 타임라인

 - 새로운 기능을 판매 성수기에 임박해서 구현하는 것은 위험하다.

가치에 집중

 - 팀이 복잡한 스토리를 대한 의논을 하면서 어떤 가치를 실제 인도해야 하는지에 대한 시각을 놓치기 쉽다.

시스템 전반적인 영향

 - 애자일 테스터는 각 스토리가 시스템의 일부분으로써 또는 같이 동작하는 다른 시스템이 어떤 영향을 미치는지 생각해야 한다.

외부 업체의 참여

 - 벤더 도구나 협력 업체, 기타 계약 관계의 팀과 큰 프로젝트에서 함께 일한다면 릴리즈 계획은 복잡해 진다.

 - 릴리즈에 팀의 고유 범위를 넘어서 고객이나 협력업체가 관여할 수도 있다.

테스트 계획하기

 - 상세한 테스트 계획은 이터레이션 계획까지 기다려야 하지만 상위 수준의 테스팅에 대해 생각한 것은 필요하고 이 테스팅을 위한 충분한 시간을 계획해야 한다. 릴리즈 계획 회의에서 릴리즈 테스팅 전략을 위한 별도의 시간이 필요하다.

시작할 곳

 - 릴리즈 계획을 하는 동안 각 스토리에 대한 비즈니스의 만족 조건과 상위 수준의 사용자 인수 테스트 케이스를 알고 있는 것이 도움이 된다. 

 - 애자일 테스터는 스토리를 명확하게 하기 위해 예제를 요청한다. 이 단계의 예제는 상위 수준이고 기본적인 부분만을 다루겠지만 스토리의 크기와 우선순위를 결정하는 것은 가능하다. 화이트보드에 흐름도나 예상 결과를 작성하고 이 내용에 대해 의논하는 것은 프로젝트에 대한 테스팅 이슈를 식별하는데 도움이 된다.

 - 최소한 최소에 수행하기로 계획한 최고 우선 순위의 스토리에 대해 팀이 이해하고 있어야 한다. 가벼운 계획은 추가적인 테스트를 정의하는 데 더 많은 시간이 필요한 핵심 스토리를 살펴보는 것만이 포함될 것이다.

왜 테스트 계획을 작성해야 할까?

 - 릴리즈 계획에서 릴리즈의 목적, 범위, 우리가 생각한 가정에 대해 대화를 나눈다. 그리고 위험을 빠르게 분석하고 이 위험에 초점을 맞춘 테스트 접근 방법을 계획한다. 자동화와 필요한 테스트 환경 및 데이터를 고려해서 마일스톤을 식별한다. 이것이 테스트 계획이 필요하다는 이야기다.

 - 애자일 개발에서 테스트 계획은 필요한 부분만 작성한다. 테스트 계획은 간결하고 가볍게 유지하자. 이번 릴리즈 동안 목적을 충족시키기만 하면 된다.

 - 이번 릴리즈나 프로젝트의 특정한 테스팅 이슈를 다루자. 위험 분석을 포함하고 가정을 제시하자. 고객이 제시한 핵심 성공 요인을 작성하자. 테스팅의 이해관계자가 누구인지 생각해보고 관계없는 모든 것은 삭제하자.

 - 공식적인 테스트 계획을 만들지 않더라도 릴리즈에 포함된 모든 테스팅 요소에 대해 작성해야 한다. 그리고 매 이터레이션 회의에서 이 내용들을 생각해야 한다.

 - 테스트 계획의 가장 큰 장점은 이 자체가 계획이라는 것이다. 그래서 테스트 계획은 테스트 데이터 요구사항, 기반 구조, 필요한 테스트 결과를 고려하고 다룬다. 테스트 계획은 위험 완화 전략이다.

테스팅의 종류

 - 릴리즈 계획에서는 프로젝트 동안 수행할 수 있는 모든 종류에 테스팅에 대해 고려해볼만한 시간이다.

기반 구조 

 - 기반 구조는 지속적인 통합 장비, 테스트 환경, 테스트 데이터베이스와 빌드를 테스트 장비로 옮기는 것을 의미한다. 그리고 테슽 랩이 있다면 테스트 랩이나 모든 자동화된 테스트를 실행할 수 있는 분리된 서버를 의미할 수 있다.

테스트 환경

 - 다음 릴리즈의 기능을 살펴보면 우리가 필요한 전체적으로 새로운 테스트 환경을 확인할 수 있다.

 - 첫번째 릴리즈를 계획하고 있는 중이라면 테스트 환경은 중요한 고려사항이다.

테스트 데이터

 - 실제 데이터는 탐색적 테스팅의 다양한 시나리오에 훌륭한 기반이 된다.

 - 지속적으로 필요한 테스트 데이터를 검토하자.

테스트 결과

 - 실제 보고를 해야할 대 효과적으로 할 수 있도록 각 단계의 테스트 결과를 어떻게 작성할지 생각해보자.

 - 팀은 자동화된 빌드 프로세스에서 각 빌드의 테스트 결과를 제공하는 메일이나 온라인으로 확인할 수 있는 피드밷 유틸리티 또는 웹 인터페이스를 구성할 수 있다. 시간 흐름에 따른 결과는 진행사항을 표시하는 다양한 방식으로 요약할 수 있다.

 - 간단하고 가시성 높은 결과가 훨씬 효과적일 수 있다.

테스트 대안

가벼운 테스트 계획

 - 테스트계획은 프로젝트의 테스팅 위험을 생각하도록 도와주는 도구일 뿐 고객이나 다른 팀원과 얼굴을 맞대며 하는 대화를 대체하지 못한다. 그러므로 조직이나 고객이 SOX 규제나 다른 규정을 만족하는 테스트 계획을 고집한다면 필요한 것만 다루는 가벼운 테스트 계획을 고려해보자.

테스트 매트릭스 사용하기

 - 테스트 매트릭스는 큰 그림과 관련하여 어느 기능을 테스트하기 원하는지 의사소통할 수 있는 간단한 방법이다. 테스트 메트릭스는 테스트 요구사항의 개요를 빠르게 검토할 수 있다. 

 - 테스트 매트릭스는 기능 목록과 테스트 조건에 불과하다. 테스트 조건과 기능을 생각할 때 신규/변경된 기능이 애플리케이션의 다른 부분에 미칠 영향을 고려하자.

 - 테스트 매트릭스는 커버리지를 추적하는 기법이 될 수 있고 원하는 만큼 상세해질 수도 있다. 상위 수준의 테스트 매트릭스는 팀이 고객팀이나 관리자에게 어떤 테스트가 이미 수행되었고 어떤 것이 남았는지 보여줄 때 사용된다. 더 상세한 테스트 매트릭스는 팀이 계획한 테스트를 파악하고 테스팅의 진행사황은 어떤지 추적하기 위해 사용된다.

테스트 스프레드 시트

 - 스프리드시트와 같이 유연한 형식은 업무에 맞게 조정해서 사용할 수 있다.

화이트 보드

 - 팀이 비공식적이고 작은 릴리즈를 진행하고 있다면 작성하는 문서의 종류가 너무 많을 수 있다 때때로 위험이나 가정의 목록을 화이트보드나 색인카드에 작성하는 것으로도 충분하다.

자동화된 테스트 목록

 - 팀이 테스트 케이스 이름의 목록을 추출할 수 있는 도구를 가지고 있다면 누군가 이 목록이 필요할 때마다 손쉽게 제공할 수 있다.

잘 보일 수 있게 준비하기

 - 팀이 애자일 개발을 시작하고 이터레이션 초반에 필요한 기반구조가 잘 준비되어 있다면 진도에 대한 진행상황 추적 방법을 변경하고 회고는 이슈를 해결하는 데 도움을 줄 것이다. 각 이터레이션에서 계획했던 업무가 완료되엇는지 확인하는 데 문제가 있다면 진행상황을 확인하고 이터레이션 중반에 초치를 할 수 있게 도와 주는 더 눈에 잘 보이는 차트를 활용하자.

테스트 작업과 상태 추적하기

 - 유능한 애자일팀은 "테스트되기 전까지 어느 스토리도 완료된 것이 아니라"라는 규칙을 따른다. 이 규칙은 단지 스토리가 테스트되어야 한다는 말 외에도 빌드는 체크인되어야 하거나, 지속적 빌드 프로세스에서 자동으로 테스트되거나, 문서화되거나, 팀이 "적당하다"고 정의한 기준으로 확장할 수 있다. 이터레이션 기간의 언제라도 각 스토리의 대한 테스팅 작업이 얼마나 남았고 어느 스토리가 완료되었는지 빠르게 확인할 필요가 있다.

테스트 결과에 대한 의사소통

 - 테스트 결과는 진행상황을 측정하고, 각 스토리에 대한 신규 테스트가 작성되고 실행되었는지 확인하고, 모두 테스트를 통과했는지 확인하는 중요한 방법이다. 

 - 테스트 결과는 팀의 진행상황을 정확히 보여줘야 한다. 진행된 테스트에 대한 숫자가 매일 또는 매 이터레이션마다 상승하지 않는다면 무엇인가 문제가 있다는 표시이다. 이 문제는 팀이 테스트 주도 개발을 하지만 테스트를 작성하지 않았거나 코딩을 완료하지 못했기 때문이다.

 - 팀이 진행상황에 대해 이야기하길 원한다면 모두가 필요한 정보를 얻을 수 있을지 미리 확인하자.

릴리즈 측정지표

 - 릴리즈 초반에 어떤 측정 지표를 모으고 싶은지 이해하는게 중요하다. 이 측정지표는 개발 진행이 어떻게 되었는지 지속적으로 피드백을 주고, 이를 이용해 기대하지 않았던 사건에 대응하고 필요하다면 프로세스를 변경할 수 있다. 

• 테스트 통과 개수 : 많은 애자일 팀은 단위, 기능, 스토리, 부하 테스트 등 각 단계의 테스트에 대해 추적한다. 추세는 개수보다 중요하다.
• 코드 커버리지 : 코드 커버리지는 전통적인 특정 지표의 하나지만 테스트가 얼마나 효과적인지 알려주지 않고, 어플리케이션이 다른 경로로 실행되어도 알려주지 않는다.
• 결함 측정지표 : 팀이 결함 관련한 목표를 설정한다면 이 목표에 대한 진행상황을 측정하는 적절한 특정 지표를 사용하자.

 - 측정지표는 퍼즐의 한 조각일 뿐이다. 릴리즈, 테마, 프로젝트 계획 회의를 비즈니스 가치 제공에 초점을 맞추는 데 사용하자.

요약

 - 스토리의 크기를 결졍할 때, 비즈니스 가치, 위험, 기술적 구현방법, 기능이 활용되는 방법 등 다양한 시각을 고려하자. 명확한 질문을 하되 너무 상세한 부분까지 하지는 말자.

 - 테스터는 기능의 "작은 조각"과 "요주의 경로"를 식별하므로 스토리의 우선 순위를 결정하는 데 도움을 준다. 추가적인 테스팅이 일찍 시작되어야 한다면 높은 위험의 스토리를 초기에 시작하도록 계획하자.

 - 스토리 테스팅 노력의 정도는 스토리가 릴리즈의 범위인지 여부를 결정하는 데 도움이 된다.

 - 테스터는 새로운 스토리가 기존의 시스템에 미치는 영향을 팀이 생각하는데 도움을 준다.

 - 팀이 릴리즈의 범위를 식별하면 시간과 자원이 테스팅의 범위와 예정된 시간에 충분한지 평가하자.

 - 기반구조, 테스트 환경, 테스트 데이터 관련 내용의 검토를 릴리즈 계획 기간동안 하자.

 - 가볍고 애자일한 테스트 계획은 모든 테스팅 고려사항이 릴리즈나 프로젝트 기간 동안 진행되는지 확인하는데 도움이 된다.

 - 팀이 더 적절하게 사용할 수 있는 테스트 계획 작성 방법을 고려해보자. 테스트 측정지표, 스트레드시트, 심지어 화이트보드도 괜찮을 수 있다.

 - 공식적인 릴리즈의 계획이 상황에 따라 적절할 지 않을 수 있다. 릴리즈의 계획을 하지 않는 상태에서 최조에 완료해야 하는 몇 개의 스토리를 식별하고 논의하는 것을 고려하자.

 - 릴리즈 동안 특정하기 원하는 특정 지표에 대해 계획하자. 해결해야 하는 문제는 무엇인지 생각하고 팀에 의미있는 측정지표를 사용하자.

Chapter 16. 본격적인 시작

능동적으로 하자.

 - 이을 기다리는 시간 대신 기여할 수 있는 것을 찾는 능동적인 자세를 가져야 한다. 팀이 새로운 일에 착수하거나 복잡하고 위험이 예상되는 스토리를 진행할 때 이터레이션 이전에 하는 몇 가지 일은 팀의 개발 속도를 최고로 하고 방해를 최소화하는 데 도움이 된다.

혜택

 - 점증적으로 스토리를 인도하고 테스트할 충분할 시간이 있고, 고객의 요구사항과 일치하는 소프트웨어를 인도하고, 이터레이션이 항상 유연하게 진행된다면 이터레이션을 사전에 준비할 시간은 필요 없을 수 있다. 그러나 팀이 스토리를 종료하는 데 어려움이 있거나 기능에 요구된 동작과 실제 동작 사이에 큰 차이가 있다면 더 일찍 계획하는 것이 이터레이션 수행 시간을 줄일 수 있다.

정말 이것이 필요할까?

 - 짧은 사전 이터레이션 논의와 테스트 작성 세션을 시험해보자. 팀의 리듬을 찾기 위해 여러 번의 이터레이션을 겸험하게 될 것이고, 그 리듬을 찾았다면 이터레이션 기간에 더욱 생산성이 높아진 것을 확인할 수 있을 것이다.

사전 준비의 잠재적인 단덤

 - "앞서 작업하는" 것은 위험이 따른다. 스토리를 사전에 의논하는 단 하나의 이유는 이터레이션 계획과 개발 기간을 줄이려는 것이다. 기능 동작에 대한 깊은 이해는 테스팅과 코딩 속도를 높여주고 제대로된 기능을 인도하도록 도와준다.

 - 이터레이션을 시작하는 날 다시 스토리에 우선순위를 매기는 등의 역동적인 상황이라면 위에서 설명한 내용을 시도하는 것은 의미가 없다 대신 계획 회의동안 이런 의논을 할 시간을 계획해보자.

명확성 사전 확보

 - 많은 수의 서로 다른 할인 가운데 누군가는 어떤 스토리가 다른 이터레이션에서 구현되어야 하는지 결정이 필요하다. 스토리를 구현할 많은 방법이 있기 때문에 누군가는 명세할 요구사항을 결정해서 예제, 만족 조건, 테스트 케이스를 양식에 맞게 작성해야 한다.

하나의 목소리로 말하는 고객

 - 스크럼은 모든 고객이 "하나의 목소리로 말하기"라는 유용한 제품 책임자의 역할이 있다. 스크럼 팀인지 여부에 상관없이 고객이 스토리의 우선 순위와 각 스토리의 구현될 구성 요소에 동의하는 데 도움이 되는 방법을 찾아야 한다. 이 역할을 하는 어떤 사람이든 모두가 합심하게 만들 시간과 능력이 필요하므로 경영층으 지원은 필수적이다.

 - 하나의 스토리에 대해 서로 다른 의제를 가진 각 고객의 요구사항이 있기 때문에 테스터는 다양한 스토리의 다양한 관점을 고려해야 한다. 이것은 서로 다른 역할의 사람들에게 스토리가 의미있다는 것은 무엇인지 이해하는데 도움이 된다. 

스토리의 크기

 - 고객팀과 다음 이터레이션의 스토리에 대해 논의하면서 그들에게 질문하는 것은 각 스토리가 필요한 가치를 인도했는지 확인하는데 도움이 된다. 이때가 작성이 필요한 새로운 스토리를 식별하기 좋은 시간이다.

지리적으로 분리된 팀

 - 여러 지역에 나뉘어 있는 팀은 전화 회의, 온라인 회의, 원격 회의를 통해 이터레이션 계획을 할 수 있다.

 - 고객이 질문에 답하거나 의사결정하는 것이 순조롭게 진행도기ㅣ 어렵다면 항상 접속할 수 있는 도메인 전문가가 우선순위를 결정하고 예제를 통해 요구된 시스템의 동작을 표현함으로써 팀을 안내할 수 있는 권한을 주어야 한다.

사례

 - 사례는 개발 주기 전반에 요구받은(또는 요구받지 않은) 기능에 대해 이해하고 표현하는 효과적인 방법이다.
 - 사례를 사용하여 각 스토리를 조금 더 구체화하는 상위 수준 테스트를 작성할 수 있다. 이터레이션 시작 전에 이런 작업이 필요 없을 수도 있지만 복잡한 스토리라면 최소한 하나의 정상 경로와 비정상적인 경로의 테스트 케이스를 사전에 작성하는 것이 좋다.

 - 고객에게 이터레이션 전에 사례와 상위 수준 테스트 케이스를 작성해달라고 요청하자. 이것을 통해 사용자는 스토리에 대해 더 생각해볼 수 있고 그들의 만족조건을 좀 더 쉽게 정의할 수 있다. 또한 어느 기능이 중요한지 식별하는 데 도움이 된다. 그리고 언제 스토리가 완료되어야 하는지를 정의하는 것과 고객들의 기대를 관리하는 것 역시 도움이 된다.

테스트 전략

 - 팀이 새로운 종류의 소프트웨어를 사용하기 시작하면 어떻게 대발할지 학습하기 위해 스파이크 개발을 결정해야 한다. 동시에 개발을 어떻게 주도하고 어떻게 테스트해야 하는지 확인하기 위해 테스트 스파이크를 시도해야 한다.

결함 우선순위 정하기

 - 다음 이터레이션 직전에 고객과 눈에 띄는 이슈를 검토하고 이것을 시스템에 남겨둘 것인지 고칠것인지를 결정하는 것이 가장 좋다. 결함을 고치는 것은 다음 이터레이션에 포함될 수 있다.

자원

 - 이터레이션 전에 팀이 높은 위험의 스토리 완료에 필요한 모든 자원을 가지고 있는지 여러 번 확인해야 한다.

요약

 - 질문하고 예제를 얻는 것을 통해 고객이 사전에 명확하게 하는 것을 지원하자. 각 스토리의 기대되는 행위에 대한 의견을 일치시키자.

 - 능동적인 자세를 취하고 이터레이션에 앞서서 복잡한 스토리를 학습하고 크기가 적절한지 확인하자.

 - 항상 다음 이터레이션의 사전 준비가 필요하지는 않다. 이터레이션을 통해 시간을 아낄 수 없거나 고객 요구사항을 성공적으로 만족시킬 수 없다면 사전에 준비하지 말자.

 - 다른 지역에 있는 팀원들과 협력하고 효과적으로 의사소통하자. 이를 지원하는 많은 도구가 있다.

 - 각 스토리를 설명하는 데 도움이 되는 예제를 확보하자.

 - 다음 이터레이션에 앞서서 새로운 기능이나 일반적이지 않은 기능에 대한 테스트 전략을 개발하자.

 - 현재의 결함을 선별하고 우선순위를 정하여 다음 이터레이션에 포함시킬지를 결정하자.

 - 필요한 테스팅 자원이 있는지 확인하자.

Chapter 17. 이터레이션 킥오프

 - 애자일 테스터는 테스팅과 개발 업무 계획을 지원하는 등 이터레이션 계획 동안 중요한 역할을 수행한다. 이터레이션이 진행 중이면 테스터는 적극적으로 고객과 개발자와 협력하고, 개발을 가이드 하는 상위 수준 테스트를 작성하고, 예제를 발굴하여 보여주고, 스토리가 테스트 가능한지 확인한다.

이터레이션 계획하기

 - 대부분의 팀은 새로운 이터레이션을 계획하면서 시작한다. 계획은 이전 이터레이션에서 무엇이 잘되었고 잘못되었는지 돌아보기 위해 회고나 "교훈(lessions learned)" 세션 다음에 수행된다.

 - 이터레이션에서 할 일을 계획하는 동안 개발팀은 스토리 구현에 필요한 업무를 작성하고 추정하면서 한 번에 하나의 스토리에 대해서만 의견을 나눠야 한다.

상세한 내용 학습하기

 - 제품 책임자나 다른 고객 팀 구성원이 이터레이션 계획에 참가하여 질문에 답해주고 각 스토리의 요구사항에 대한 예제를 제공해주는 것이 가장 이상적이다. 

 - 팀에 도움이 되는 실습 방법은 각 스토리의 사용자 인수 테스트를 작성하는 것이다. 제품 책임자와 참여 가능한 다른 이해관계자와 함꼐 하고, 그들이 상위 수준의 테스트를 작성하여 테스트가 통과하면 그 스토리가 완성된다. 

모든 관점 고려하기

 - 테스터는 거대한 시스템의 맥락에 각각의 스토리를 더하고 다른 부분에 의도하지 않은 영향이 있는지 평가한다. 이것을 릴르즈 계획 미팅에서 하기 위해서는 사용자, 비즈니스 이해관계자, 프로그래머, 기술 작가, 기능을 만들고 사용하는 모두와 다른 사고방식을 가져야 한다. 그래야 상세한 수준에서 일하는 것이다.

작업 카드 작성하기

 - 팀이 스토리에 대해 잘 이해하고 있다면 작업 카드의 작성과 추정을 시작할 수 있다. 애자일 개발은 테스팅과 함꼐 코딩을 진행하기 때문에 테스팅 작업 카드와 개발 작업 카드를 동시에 작성한다.

 - 만약 사전 계획이 완료되었다면 이미 작성한 작업 카드가 있을 수 있다. 그게 아니라면 이터레이션 계획 회의 기간에 작업 카드를 작성하자. 누가 작업 카드를 작성하든지 상관은 없지만 팀 구성원 모두가 작업 카드를 검토하고 조언할 수 있다.

 - 스토리에 외부 관계자나 공유 자원이 깊이 관련되어 있다면 이러한 업무를 잊지 않게 확인하는 작업 카드를 작성하고 팀 통제 밖의 의존성이나 사안을 감안하여 넉넉하게 추정하자.

작업량 결정하기

 - 기술팀은 스스로 작업량을 조절해야 한다. 각 스토리에 대해 작업 카드를 작성하고 스토리 게시판에 붙였으면 추정된 시간을 합산하거나 카드의 숫자를 눈으로 점검해야 한다.

 - 테스터로서의 작업은 테스팅하기 위한 충분한 시간이 주어졌는지 확인하고 테스팅과 품질이 전체 팀의 책임이라는 것을 상기시키는 것이다.

테스트가 용이한 스토리

 - 스토리를 살펴보았을 때, 그리고 프로그래머가 어떻게 구현할지 생각하기 시작했을 때, 항상 어떻게 테스트할지를 생각하도록 하자.

 - 테스트 용이성이 이슈가 되면 이 이슈를 팀이 풀어야할 문제로 만들자.

고객과 협업하기

 - 고객이나 기능 분석가 같은 고객 대리인과 가까이서 일하는 것은 애자일 테스터에게 매우 중요한 활동의 하나이다. 고객에게 예제에 대해 묻고, 각 스토리의 기능과 동작에 대해 개방형 질문을 하고, 화이트보드를 이용하여 논의하고, 예제를 코딩을 주도하는 테스트로 변환하자.

 - 제품 책임자와 다른 고객이 이터레이션 계획 이전과 진행 중에 스토리에 대해 설명을 할지라도 이터레이션 시작 후 한번 더 검토하는 것이 효과적이다. 왜냐하면 모든 구성원이 그 설명을 이전에 듣지 않았을 것이고,고객 역시 더 전달할 필요가 있을 것이다.

상위 수준 테스트와 사례

 - "큰 그림" 테스트는 프로그래머가 스토리를 올바른 방향으로 시작할 수 있도록 도움을 준다. 

 - 상위 수준 테스트는 스토리의 주요 목적을 전달해야 한다. 

 - 이터레이션을 시작할 때 중요한 것은 각 스토리의 기본적인 요구사항을 빠르게 습득하고 전체 팀이 일할 수 있는 방식으로 표현하는 것이다.

 - 업무 영역과 환경에 딱 맞는 방식의 상위 수준 테스트를 발굴하고 표현하는 여러 방식을 테스트하는 데 시간과 노력을 들이자.

고객과 검토하기

 - 고객과 상위 수준의 테스트를 검토하는 것은 특히 새로운 애자일 팀이 협력을 강화하고 의사소통을 하게 하는 좋은 기회이다.

프로그래머와 검토하기

 - 프로그래머와 같이 앉아서 상위 수준의 테스트와 요구사항을 검토하자. 팀 구성원이 상위 수준 테스트나 요구사항을 이해하는데 문제가 있다면 다른 접근방법을 사용하도록 도와주자.

 - 프로그래머와 함께 하는 테스트 검토의 유익한 효과 중 하나는 서로에게 배울 수 있다는 것이다. 테스터는 프로그래머의 생각을 접할 수 있고, 프로그래머는 접하지 못했던 테스팅 기법을 배울 수 있다. 프로그래머는 고려하지 못했던 상위 수준의 테스트에 대해 더 잘 이해할 수 있다.

문서로서의 테스트 케이스

 - 이터레이션 기간에 작성할 실행 가능한 테스트와 마찬가지로 상위 수준 테스트도 어플리케이션 문서의 중요 유형이 될 수이다. 요구사항은 이터레이션 도중이나 이터레이션 이후에 변경될 것이므로 싱행 가능한 테스트 케이스는 유지 보구사 쉬워야 한다.

 - 요구사항 문서의 한 부분으로서 실행 가능한 테스트가 갖는 큰 장점은 그 결과에 대해 반박하기 어렵다는 것이다.

요약

 - 이터레이션 기간 동안 테스터는 궁금증에 대해 질문과 모든 관점의 고려를 통해 팀이 스토리에 대해 학습하는 데 도움을 준다.

 - 작업 카드는 개발 작업 카드와 같이 작성되고 실제적으로 추정되어야 한다.

 - 테스팅 작업 카드를 다루는 또 다른 방법은 개발 작업 카드에 직접 작성하는 것이다.

 - 전체 테스트가 완료되기 전까지는 어떤 스토리도 완료된 것이 아니기 때문에 팀이 모든 테스트가 완료된 업무를 수용할 것이다. 

 - 이터레이션을 시작할 때가 스토리가 테스트 가능하고 적절한 테스트 데이터가 제공되었는지를 확인할 마지막 기회다.

 - 테스터는 고객과 함께 스토리의 상세한 부분을 분석하고 프로그래머의 코딩 착수를 위하여 상위 수준 테스트 케이스를 작성해야 한다.

 - 테스터는 의사소틍이 잘되었는지 확인하기 위하여 상위 수준 테스트와 요구사항을 프로그래머와 검토해야 한다.

 - 테스트는 어플리케이션 문서의 중요 유형이다.

Chapter 18. 코딩과 테스팅

개발 주도

 - 이터레이션 전이나 이터레이션의 첫 이틀간 작성한 상위 수준의 테스트는 프로그래머가 테스트 주도 개발을 하기 위한 충분한 정보를 제공해야 한다.

단순하게 시작하기

 - 핵심 기능이 동작하는 가장 단순한 주경로 테스트를 작성하자.

복잡성 추가하기

 - 주경로의 테스트가 동작하면 경계값 테스트와 같은 더 많은 테스트케이스를 추가하자. 테스트는 프로그래머가 요구사항에 대해 이해하지 못했던 부분이나 모두가 잘못 알고 있었던 요구사항의 정확한 의미를 알려줄 것이다. 중요한 것은 모두가 이 내용에 대해 대화를 나누고 제자리를 잡아가도록 해야 한다는 것이다.

 - 테스터가 실행가능한 테스트로 검증할 새로운 시나리오를 생각하는 것처럼 수작업 탐색적 테스팅에 사용될 시나리오의 가능성에 대해서도 생각해봐야 한다.

 - 테스트의 목적을 기억하자. 테스트는 프로그래머가 어떻게 코드를 작성해야 하는지 알려주는 예제가 되어야 한다. 코드가 점점 진전될 수록 여러분이 작성한 테스트는 더 많은 도전을 할 수 있지만 극한의 케이스까지 작성하는 유횩에 빠지지 않도록 해야 한다.

위험 평가하기

 - 위험 수준이 높은 스토리는 더 큰 크기로 추정되고, 릴르즈나 이터레이션을 계획할 때 스토리의 위험을 우선적으로 고려한다.

 - 위험에 대한 신속한 분석은 어떤 테스팅이 먼저 수행되고 어느 부분에 노력이 집중되어야 하는지 결정하는 데 도움이 된다.

코딩과 테스팅을 함께 진행하기

 - 테스터와 프로그래머, 데이터베이스 전문가 및 다른 팀원들은 스토리를 개발하기 위해 서로 협력하고 제공된 예제와 테스트를 가이드라인으로써 따라야 한다.

3의 힘

 - 의견 충돌이나 문제가 발생했을 때, 세 개의 서로 다른 관점을 갖는 것은 좋은 해결책을 얻고 나중에 동일한 이슈를 반복하지 않는 효과적인 방법이다.

하나의 스토리에 집중

 - 테스터는 모든 스토리를 완료하도록 독려하고, 또 테스터도 그러기 위해 노력해야 한다. 프로그래머가 스토리의 구현을 시작했을 때, 누군가는 그 스토리의 테스팅 업무를 시작하면서 균형을 맞추어야 한다. 다름 스토리를 시작하기 전에 하나의 스토리를 완료하는 것이 테스터의 목표여야 한다.

제품을 평가하는 테스트

 - 제품을 평가하는 기술적인 측면의 테스팅은 코딩 기간에 하는 것이 좋다 디자인이 변경되지 않거나 보안에 대한 구멍이 있으면 지금 알아내야 한다.

프로그래머와 협업하기

 - 테스터와 프로그래머의 협력은 코딩과 테스팅에 계속 진행되며 이는 제대로 된 제품을 인도하는 팀의 능력을 향상시켜주고 기술 이전의 많은 기회를 준다. 프로그래머는 테스팅에 대한 새로운 방법을 배우고, 작성하는 코드의 대한 테스팅도 더 잘할 것이다. 테스터도 코딩 절차와 제대로 테스트하는 방법에 대해 배우게 된다.

짝 테스팅(Pair Testing)

"내게 보여줘"

고객과 대화하기

 - 코딩을 시작하기 전에 고객이나 고객을 대신할 수 있는 사람과 테스트케이스를 검토하는 것이 필요하다.

고객에게 보여주기

 - 아직 기본적인 기능만 있고 모든 기능이 완성되지 못했거나 하드 코딩된 데이터가 보이더라도 사용자 인터페이스나 리포트 기능이 준비되면 즉시 고객에게 보여주자.

 - 이터레이션 비류 회의는 팀이 무엇을 인도할지 보여주고 다음 이터레이션을 위한 피드백을 받을 수 있는 좋은 기회이다.

비즈니스 이해하기

 - 협업에서 일하는 사람들과 그들의 업무에 대해서 또 새로운 소프트웨어 기능의 어떤 점이 향상되었는지 대화하는 시간을 갖자. 고객의 비즈니스에 대해 더 많이 이해한다면 더욱 좋은 제품을 제공할 수 있다.

테스팅 작업 완료하기

 - 애자일 테스터는 능동적이며 앉아서 일이 오기만을 기다리지 않는다.

 - 팀의 모든 구성원이 수작업 테스트 업무를 하지 못할 이유는 없다. 팀을 이제 막 구성하고 시작해서 아직 자동화를 다루는 것이 쉽지 않다면 전체 팀은 새로운 기능에 대한 수작업 테스트에 더하여 수작업 회귀 테스트 스크립트를 실행할 시간을 계획해야 한다.

버그 다루기

 - 톰 포펜딕 & 메리 포펜딕 <린 소프트웨어 개발의 적용 : 속도 결쟁에서 승리하기> : 대기 중인 결합은 "대기중" 자체가 재작업을 의미하므로 낭비의 관점에서 수집해야 한다.

결합인가? 아니면 정상 기능인가?

 - 애자일 개발에서는 고객 만족을 위해 고객과 함께 일하며 그들이 원하는 대로 수정할 기회가 있다. 고객은 모든 기능과 세부 사항들에 대해 먼저 생각해보려 시도하지 않는다. 단지 고객이 어떤 기능을 봤을 때 그들의 생각을 바꾼다면 그것으로 만족할 뿐이다. 고객이 우선순위와 가치제안(value proposition)을 선택한다. 고객의 소프트웨어 품질에 대한 우선순귀가 모든 새로운 기능을 얻는 것보다 높다면 여러분이 찾은 모든 결함을 수정하도록 노력해야 한다.

기술적 채무

 - 버그를 코드 안에서 곪아 터지도록 남겨두는 것은 코드 품질, 시스템 직관성, 시스템 유연성, 팀 사기, 개발 속도에 좋지 않은 영향을 끼친다.

버그 무관용 정책

제로 버그 이터레이션 (NT Service QA 관리자; 야쿠프 올레즈키에비트, 2008) 나는 테스터, 개발자, 비즈니스 분석가 사이의 이 훌륭한 의사소통 방법이 정말 버그를 없얀 원인이라고 생각한다. 우리는 폭포수 방법론의 함정에 빠지지 않을려고 노력했다. 그러면서도 이터레이션 종료될 때 기능이 모두 개발되고, 동작하고, 배포 가능하고, 결함이 없어야 한다는 것이 목표였기 때문에 원칙적인 부분 역시 핵심적인 사항이었다.폭포수 방법론을 피한다는 의미는 코드 작성과 테스트 관련 활동이 동일선상에서 진행되어야만 한다는 뜻이었다. 그래서 주어진 기능의 코드가 작성되는 시점에 테스트 케이스 디자인과 자동화도 진행되도록 이터레이션 계획을 작성하려 했다. 그리고 테스트 주도 개발에서 우리가 취해햐 하는 것들도 빨리 찾아냈다. 스크럼 기간 동안 우리 팀은 매일 아침 간단한 대화를 통해 기능 그룹들이 서로 불일치함이 없다는 것을 확인했다. 우리는 서로 옆에 앉고 종종 같은 컴퓨터도 사용했다. 결함이 발견되면 개발자는 자진해서 분석하고, 기록하고, 요구사항에 대해 설명했다. 비즈니스 분석가는 언제나 가까이서 우리의 생각을 확인해줬다. 해결책은 종종 몇 분안에 체크인되고, 테스트 환경에 배포되고 검증되었다.

결국 선택의 문제다.

 - 적절한 조합은 팀이 애자일 방식과 얼마나 차이가 나는지, 그리고 제품이 얼마나 성숙한 모습인지에 달려있다.

어떤 버그를 기록할지 결정

 - 실제 사람과 먼저 대화를 하고 제품의 변경이 필요하거나 프로그래머가 바로 해결할 수 없을 때에만 결함 보고서를 작성하자.

• 단위 테스트 실패 : 테스트 주도 개발을 싱행하는 팀이면서 단위 테스트 범위가 적절하다면 빌드 도중에 실채한 테스트는 기록하지 않는다.
• 상위 수준 회귀 테스트 실패 : 실패한 테스트는 원래 기록해야 하는 버그가 맞다.
• 현재 이터레이션 내의 스토리 버그 : 팀이 프로그래머와 긴밀하게 작업하고 스토리가 완료되자마자 짝 테스팅을 수행한다면 프로그래머가 바로 조치할 수 있는 버그는 기록하지 말것을 강력히 권장한다.
• 이터레이션 이후 버그 (또는 즉시 고치지 못하는 버그) : 즉시 수정할 수 없는 버그는 기록하자.
• 레거시 시스템 관련 버그 : 제품 책임자가 생각하기에 이 버그가 고칠 가치가 있다면 버그를 기록하고 제품 백로그에 포함시켜 우선순위를 결정해야 한다.
• 운영 환경에서 나온 버그 : 어플리케이션이 운영 중이라면 고객이 발견한 모든 버그를 기록해야 한다.

버그 수정할 시기 선택하기

 -  다음 이터레이션을 위한 다른 스토리가 있다면 발견한 버그를 지금 수정할지, 나중에 할지, 수정하지 않을 것인지 결정을 제품 책임자와 의논해서 결정해야 한다.

• 즉시 수정 : 즉시 수정할 수 있는 버그가 늘어나면 늘어날수록 어플리케이션이 만든 기술적 채무는 감소하고 "결함" 재고는 줄어든다.
• 나중에 수정하기 : 팀마다 결함을 다루는 방법이 다르다.
• 수정하지 않음 : 수정하지 않을 버그가 발생한다면 그냥 버그를 조욜하라고 제안한다.

버그 기록에 사용할 매체 선정

• 색인카드(실제 카드이거나 온라인 계획/추적 시스템의 가상 카드) : 자세한 내용을 적기에는 충분하지 않지만 서로 다른 색을 사용하면 아직 남아있는 이슈가 스토리 게시판에 붙어있을대 확실하게 표시해준다.
• 결함 추적 시스템 : 팀이 서로 떨어져 있을 때, 감사 목적이나 릴리즈 노트에 담기 위해 버그 추적이 필요한 경우, 이터레이션에서 수정하지 못한 버그가 있거나 나중에 수정하려고 기억하기 위한 경우, 많은 경함이 있는 레거시 시스템이 있는 경우에 사용하자
• 아무것도 기록하지 않음 : 테스트가 버그를 잡아낼 수 있다면 버그를 기록할  필요가 없다.
  • 버그를 잡기 위한 테스트 : 팀이 잘 훈련되어 있고 발견된 모든 버그에 대해 테스트를 작성하는 경우

버그를 다루기 위한 대안과 제안

• 규칙 정하기
• 모든 버그 수정하기 : 나중에 크고 복잡해진 버그가 되기 전에 작고 독립적일 때 수정하자.
• 버그 결합하기 : 한 부분에서 많은 버그를 반경했다면 이 버그를 하나의 스토리로 결합하는 것을 생각해보자.
• 스토리로 다루기 : "버그"가 실제 기능에서 빠진 거라면 버그 카드를 작성하고 하나의 스토리로써 일정을 계획하자.

단순하게 시작하기

 - 프로그래머가 바로 코드 품질에 대한 피드백을 얻을 수 있도록 짧은 코딩, 통합, 테스팅의 짧은 개발 주기를 시도해보자.

의사소통 잘하기

 - 일일 미팅은 팀의 밀접한 의사소통을 유지시켜준다. 팀 구성원 모두가 업무와 스토리의 현재 상태에 대해서 알게되고 걸림돌에 대해서는 서로 도와줄 수 있다. 또한 프로그래머가 작업 중인 기능을 설명하는 것을 들어보면 종종 고객의 요구사항을 잘못 이해하고 있음을 알 수 도 있다.

 - 일일 미팅은 진행 상황을 살펴보기에도 좋다. 스토리 게시판, 소멸 차트, 다른 잘 보이는 신호와 같이 진행상황에 집중하고 알려주는 데 도움이 되는 크고 잘 보이는 차트를 이용하자.

테스터가 의사소통을 쉽게 만든다.

 - 테스터는 모두가 충분히 의사소통하게 함으로써 이터레이션 진행이 자연스럽게 진해오디도록 지원한다. 스토리가 시작되면 프로그래머와 대화를 통해 스토리를 제대로 이해했는지 확인한다.

 - 프로그래머가 비즈니스와 스토리에 대해 잘 안다고 해도 스토리 개발에 대한 문의사항이 있을 것인디 그 문의에 고객과 직접 의사소통하는 것이 좋으므로 테스터가 여기에 방해하지 않는 것이 좋다. 하지만 비즈니스 전문가와 프로그래머 사이에 이해하지 못하는 상황이 있다면 테스터는 고객과 프로그래머가 공통된 언어를 사용하도록 도와 줄 수 있다.

 - 의사소통을 쉽게 하는 것에는 보통 화이트보드에 그림 그리기, 모의 객체, 이해관계자 의견 청취, 실제 예제의 활용이 포함된다. 팀이 시스템의 다양한 모습에 충분히 이해할 때까지 많은 예제를 사용하자.

분산된 팀

 - 팀 구성원이 서로 다른 지역에 있거나 다른 표준 시간대에 있다는 것은 커뮤니케이션 때문에 일하기 어렵다는 의미이다. 협력과 의사소통에 개선이 필요하지 않은지 평가하고 개선하는 방법을 브레인스토밍하는데 회고를 이용하자.

회귀 테스트

빌드를 "초록색"으로 유지하기

 - 팀은 빌드의 상태를 "초록색"으로 유지하기 위해 각기 다른 접근 방법을 취한다. 팀 구성원 모두는 빌드가 재수행될 때까지 필요하다면 하던 일을 모두 멈춰야 한다.

빌드를 빠르게 유지하기

 - 빌드가 피드백을 즉시 제공하기 위해서는 빌드가 짧게 유지되어야 한다. 빌드가 코드 체크인하는 평균 빈도보다 오래 걸린다면 빌드는 계속 쌓이기 시작하고 테스터는 테스트할 코드를 얻지 못한다.

 - 데이터베이스를 업데이트하는 테스트, 단위 수준의 기능 테스트, GUI 테스트 스크립트와 같이 너무 오래 걸리는 테스트는 독립된 빌드 프로세스에서 실행되어야 한다.

회귀 Suite 만들기

 - 회귀 테스트는 버전 통제를 받아야 한다. 가장 좋은 방법은 회귀 테스트를 같은 제품 코드를 매긴 동일한 소스 코드 통제 시스템으로 유지하는 것이다. 이 방식은 제품 릴리즈를 위해 코드에 태그를 달면 코드와 함께 수행되는 모든 버전의 테스트에 태그가 포함된다. 그리고 최소한 일일 테스트 코드 백업을 유지하자.

 - 테스트가 회귀 Suite에 추가되면 테스트의 목적은 변경된다. 더이상 개발을 주도하고 새로운 버그를 찾는 것이 아니라 유일한 목적은 예상하지 못한 변경이나 부작용을 발견하는 것이다.

자원

 - 이터레이션이 시작되면 테스트 환경과 테스트 데이터, 테스트 도구가 이번 이터레이션 스토리를 테스트하기 위해 준비되었는지 확인하자.

이터레이션 측정지표

 - 특정지표는 코딩과 테스팅 활동이 어떻게 진행되는지 이해하는 것이 중요하다. 데이터를 측정하고 결과를 분석하기 전에 해결해야 하는 문제점이 무엇인지 알아야 한다.

진행상활 측정

 - 스토리나 업무 게시판을 색깔로 표시한다면 이터레이션의 상태를 시각적으로 표현하는 훌륭한 방법이 된다. 

 - 그러나 너무 많은 테스트 작업 카드가 여전히 "해야 할 일" 항목에 있거나 "완료"나 "테스트되었음" 항목에 충분하지 않은 코딩 작업 카드가 있다면 모든 테스트를 완료하기 위한 방법으로 가상 스토리 게시판을 이용할 수 있다.

 - 팀이 각 이터레이션에서 얼마나 많은 업무를 할 수 있는가(이터레이션 개발 속도)를 아는 것은 전체적인 리리즈 계획을 하고 각각의 이터레이션 우선 순위를 정하는 데 도움이 된다. 이터레이션에서 완료할 수 있는 스토리의 개수가 평균적인 동일한 수가 된다면 충분히 예측이 가능해진다.

결함 측정지표

 - 결함에 대한 측정지표를 수집하는 것은 많은 시간이 걸리기 때문에 측정을 시작하기 전에 늘 목표에 대해 고려해봐야 한다.

요약

 - 코딩과 테스팅은 이터레이션에서 프로세스의 일부분이다.

 - 코딩이 시작하자말자 스토리에 대한 상세한 테스트를 작성하자.

 - 단순 테스트를 시작하는 것으로 개발을 주도하자. 간단한 테스트를 통과하면 이후 개발의 가이드가 되는 더 복잡한 테스트 케이스를 작성하자.

 - 테스팅 활동에 집중하기 위해 단순한 위험 평가 기법을 사용하자.

 - 요구사항을 명확하지 않거나 의견이 다양하면 "3의 힘"을 사용하자

 - 하나의 스토리를 제시간에 완료하는 데 집중하자.

 - 테스팅과 코딩이 통합되므로 프로그래머와 밀접하게 같이 일하자.

 - 제품을 평가하는 테스트도 개발의 일부분이다.

 - 이터레이션 동안 고객을 포함시키자. 그리고 일찍, 자주 검토하게 하자.

 - 테스터는 고객팀과 개발팀 사이의 의사소통을 원활하게 할 수 있다.

 - 버그 수정을 위한 최선의 방법을 결정하자. 가장 좋은 목표는 릴르즈에 버그가 없는 것이다.

 - 새로운 자동화된 테스트를 회구 Suite에 추가하고 바로 피드백을 제공할 수 있도록 자주 실행하자.

 - 수작업으로 하는 탐색적 테스팅으로 모든 어플리케이션이 코드로 작성된 후에도 빠진 요구사항이 없는지 찾을 수 있다.

 - 테스팅 완료를 위한 자원과 인프라 확보를 위해 외부 전문가와 같이 일하자. 

 -어떤 측정지표가 이터레이션 수행에 필요한지 고려하자. 진행상황과 결함 측정 지표가 대표적인 예다.

Chapter 19. 이터레이션 마무리

이터레이션 데모

 - 애자일 개발에서 느끼는 즐거움 중 하나는 각 이터레이션의 마지막에 완료된 스토리를 고객에게 보여줄 수 있다는 것이다. 고객은 실제 사용할 수 있는 어플리케이션을 보게되고 이 어플리케이션에 대한 질문을 받고 다시 개발팀에 피드백을 준다. 이를 통해 비즈니스 측과 기술 측 구성원 모두 성취감을 느끼게 된다.

 - 데모에 참여한 고객이 언급한 것들을 누군가는 적어 두어야 하는데 테스터가 이 역할을 하는 것이 좋다. 테스터는 우리가 사전에 찾아내지 못했던 것을 데모 중에 발견할 수 있기 때문이다.

 - 이터레이션 데모 (스크럼에서는 스프린트 검토라 부르는)는 어플리케이션에 대해 누구나 생각하고 말할 수 있는 좋은 기회이다. 검토 회의는 일반적으로 30분 이내로 짧게 진행하며, 새로운 스토리에 대한 데모가 끝난 후 시간이 남는다면 고객들이 우려하는 부분, 기능 사용법에 대한 도움의 필요 여부, 새로 발생한 이슈 등 이번 릴리즈에서 고객이 느낀 특별한 문제가 없는지 물어보자.

회고(RETROSPECTIVES)

 - 애자일 개발은 일하는 방식에 대한 끊임없는 개선을 의미하고 회고는 무엇이 어떻게 더 나아지는지 찾아내는 활동이다. 회고하는 방법은 여러 가지가 있을 수 있지만 어느 방법을 사용하더라도 팀원 모두가 안온한 분위기에서 서로 존경하는 태도로 고발이나 비난은 하지 말아야 한다.

시작, 중지, 계속

 - 이터레이션 회고에서 하나의 공통적인 활동은 "시작, 중지, 계획"이다. 각각의 팀 구성원은 개선할 것은 시작하고, 제대로 되지 않은 일은 중지하고, 계속하도록 도움을 줘야할 일을 제안할 수 있다.

 - "시작, 중지, 계속" 목록이 많다면 새로운 이터레이션에서 집중해서 할 한두 개의 항목을 선택하는 것도 좋다.

개선을 위한 아이디어

 - 애자일 팀은 자체적으로 문제를 해결하기 위해 노력하고 스스로 개선하기 위한 가이드라인을 구성한다. 작업 항목은 하나의 문제를 목표로 한다.

 - 다음 회고는 어떤 작업 항목이 유용했는지 검토하는 것으로 시작해보자.

성공 축하하기

 - 매 2주 간격으로 릴리즈 하는 애자일 팀은 꾸준한 코딩과 테스팅 리듬을 유지하고 이터레이션 검토와 회고 후 충분히 숨을 돌린 후 다음 스토리를 시작한다. 이것도 괜찮긴 하지만 모두 일에 대한 내용이지 노는 것이 아니라는 것을 알 것이다. 팀이 최소한 스스로 성취한 일을 인지할 어느 정도의 시간을 주어야 한다. 작은 성공일지라도 보상을 누려야 한다. 즐거움은 필수적인 애자일 가치이고 작은 동기는 팀이 지속적으로 성송적인 길을 가는 데 도움을 준다.

 - 성공응 축하하는  시간을 통해 계혹해서 제품을 개선할 수 있도록 지난 시간을 되돍아보고 새로운 시각을 갖고, 에너지를 충전하자. 팀원들에게 서로의 공헌에 대해 축하하는 기회를 주자. 팀원 모두가 줄곧 고객을 숙이고 일만 하는 지루한 일상을 만들지 말자.

요약

 - 이터레이션 검토는 고객으로부터 피드백을 받을 수 있는 좋은 기회이다.

 - 회고는 팀을 개선하는 데 도움이 된느 중요한 활동이다. 

 - 팀이 개선할 수 있는 모든 영역을 살펴보되 한번에 한 두개에 집중하자.

 - 이터레이션 기간 동안 개선 항목을 생각하고 있도록 하는 방법을 찾자.

 - 작은 성공이든 큰 성공이든 축하하고 다른 역할이나 활동의 공헌을 감사하자.

 - 각 이터레이션 완료 후 테스트 관련 장애물을 식별하는 기회를 갖고 장애물을 극복하는 방법을 찾자.

Chapter 20. 성공적인 인도

제품을 만드는 것

 - 우리의 목적은 제때에 비즈니스 가치를 인도하는 것이다. 단지 요구사랑에 대처하는 것에 그치지 않고, 고객에게 기쁨을 주어야 한다. 릴리즈 전에 인도할 모든 제품이 적절하게 준비되었는지 확실하게 준비되어야 한다.

충분한 테스트 시간 계획하기

 - 개발 속도 유지를 유ㅣ해 개발팀은 추가적인 테스트, 도구 업그레이드, 기술적 채무 감소를 위한 리책토링 이터레이션을 일정 주기로 계획해야 한다.

 -  각가의 이터레이션에서 작성되는 코드가 운영 준비 상태가 되도록 하고 테스팅과 코딩을 통합하는 방법을 배울 수 있는 회고와 프로세스 개선 실천 방법을 이용하자. 제품으로 릴리즈 가능한 안정화빌드라는 것이 매일 보장되어야 한다.

최종 게임(The End Game)

 - 최종 게임 : 제품이 최종적으로 인도되기 전 단계. 최종적으로 완성될 때. 종료 지점에 닿기 전 마지막 도움닫기

 - 최종 게임 기간을 최종 탐색적 테스팅을 하는 데 사용해보자. 한걸음 물러서서 전체 시스템과 일부 전체를 아우르는 시나리오를 살펴보자. 이러한 테스팅을 통해 어플리케이션이 제대로 동작함을 확인할 수 있을 것이고, 제품에 대한 신뢰와 함께 다음 이터레이션이나 릴리즈에 대한 정보를 제공한다.

릴리즈 후보 테스팅

 - 모든 릴르즈 후보에 대한 자동화된 회귀 테스트의 수행을 권고한다.

스테이징 환경 테스트

 - 전통적인 프로세스를 이용하든, 애자일 프로세스를 이용하든, 운영 환경과 유사한 스테이징 환경은 릴르즈 전의 최종 테스트에는 필수적이다. 

 - 스테이징 환경은 외부 어플리케이션이 써드 파드의 테스트 환경에 연결하거나 접근할 때 더 나은 통제를 할 수 있다. 또한 스테이징 환경은 부하/성능 테스트, 모의 화면, 장애조치(Fail-over) 테스팅, 수작업 회귀 테스트, 탐색적 기능 테스트에 활용할 수 있다.

최종 비기능 테스팅

 - 테스트 환경은 보통 환경 설정 작업이 필요 없기 때문에 내결함성과 복구 테스팅은 스테이징 환경에서 최적으로 수행된다. 같은 이유로 보안성 테스트도 이 환경에서 수행이 가능하다.

외부 어플리케이션과의 통합

 - 프로젝트와 통합할 제품을 개발하는 다음 팀이나 외부 파트너와의 사전에 잘 조정하자.

데이터 변환과 데이터베이스 업데이트

 - 어플리케이션에서 데이터는 제품의 일부분으로 간주되어야 하낟. 애자잎 개발이 많은 경우에서 데이터베이스 전문가, 프로그래머, 테스터의 협럭은 데이터베이스 변경의 선공적인 릴리즈를 보장하는데 필요하다.

설치 테스팅(Installation Testing)

 - 설치 테스팅에 대한 요구사항을 검토하는 시간을 갖자. 결국 고객을 만족시키는데 도움이 될 것이다.

의사소통

 - 개발 팀원들이 끊임없이 의사소통하는 것은 언제나 중요하지만 릴리즈를 마무리 할 때는 중요성이 더욱 커진다. 필요하다면 릴리즈를 위한 모든 것이 준비되어 있는지 추가 일일 회의를 하자.

아직 준비되지 않았다면?

 - 하나의 이터레이션에 임시 일정을 추가하지 말기를 강력히 권고한다. 왜냐하면  추가된 임시 일정은 다음 이터레이션이나 릴리즈 개발 일정을 부족하게 만들기 때문이다. 2주마다 릴리즈를 한다면 현재의 릴리즈를 건너뛰고 아음 이터레이션에 문제를 수정한 후 마무리할 시간을 계획하고 다음 일정에 릴리즈하는 것이 좋다. 납기일이 정해졌고 아직 위험이 남았다면 팀은 릴리즈 범위를 줄여야 한다.

 - 좋은 계획을 세우고, 민접하게 의사소통을 하고, 테스트와 코딩을 병행하고 테스팅의 코드화를 통해 프로젝트의 "진행불가" 상태를 방지하자.

고객 테스팅

사용자 인수 테스팅(UAT)

 - 사용자 인수 테스팅은 내부 어플리케이션과 같이 사용자의 요구에 따라 수정된 어플리케이션에 중요하다. 인수테스팅은 시스템의 사용성에 영향을 받는 모든 비즈니스 부서가 수행하며 기존에 있었거나 새로 개발된 비즈니스 기능을 확인한다.

 - 테스터는 사용자 인수 테스팅을 진행하는 고객에게 테스트 수행이나 결함 기록을 검토하는 것과 결함이 조치 완료되었는지 추적하는 것을 지원할 수 있다. 

알파/베타 테스팅

 - 알파 테스팅은 새로운 버전의 소프트웨어를 조기에 배포한다. 여기에는 주요 버그들이 포함되어 있을 것이고, 개발팀은 고객을 현명하게 선택할 필요가 있다. 고객을 피드밷을 받기 위해 알파 테스팅을 사용한다면 그들의 역할에 대해 확실히 이애시켜야 한다. 알파테스팅은 버그를 찾는 것이 아니라 기능에 대한 피드백을 받는 것이다.

 - 베타 테스팅의 릴리즈는 꽤 안정화된 상태이고 실제 사용이 가능할 것이다. 모든 사용자에게 "출시 단계"는 아니지만 많은 사용자들은 새로운 기능이 위험을 감수할 만한 가치가 있다고 생각할 것이다. 고객들은 이 릴리즈가 공식적인 릴리즈가 아니라는 것과 개발팀이 그들에게 제품 테스트와 버그 결과에 대해 물어보는 것임을 이해해야 한다.

개발 이후 테스팅 주기

 - 거대한 조직에서 일하거나 큰 컴포넌트나 복잡한 시스템을 개발하고 있다면 개발 단계 이후에 테스팅하는 계획이 필요할 수 있다. 이럴 경우 어플리케이션과 상호작용하는 다른 어플리케이션개발팀과 테스팅 시간에 대한 조정이 필요하면 어떤 이유가 되든 전체 개발팀이 참여하는 테스팅에 대한 추가 시간이 필요하다.

산출물(DELIVERABLES)

 - 산출물은 항상 최종 사용자를 위한 것은 아니면 또한 언제나 소프트웨어의 형태도 아니다. 

 - 많은 애자일 팀은 온라인 도움말이나 전자 문서를 작성하는 테크니컬 라이터를 둔다. 어떤 어플리케이션은 첫 사용을 지원하기 위해 교육 비디오를 포함하기도 하고 다른 팀원들은 교육 담당자로 참여한다. 이것이 성공적인 제품을 만드는 팀의 책임이다.

제품의 릴리즈

릴리즈 인수 기준

 - 기준은 각 이터레이션 시작 시 각각의 스토리에서 포착해 내고, 테마나 에픽을 시작할 때 더 큰 기능 세트로써 명세해야 한다.  고객은 제품이 충분한 가치가 있는 상태인지 알 수 있는 방법을 결정해야 하며 테스터는 고객들이 목적을 달성하기 위한 릴리즈 기준을 정의하는 것을 지원할 수 있다.
 - 애자일 팀은 단지 말뿐이 아닌 품질 목표를 달성하기 위한 태도를 가져야 한다. 

릴리즈 관리

 - 릴리즈를 지휘하는 담당자는 준비 상태를 평가하기 위해 이해 관계자와 릴리즈 준비 회의를 주관해야 한다.

 - 릴리즈 준비 체크리스트는 팀에서 무엇이 중요한지 검토할 때 사용할 수 있는 좋은 도구이다. 이 체크리스트의 목적은 무엇이 완료되었는지와 만약 완료되지 않았다면 이와 관련된 위험은 무엇인지 객관적인 평가를 지원하는 것이다.

 - 릴리즈 노트는 다른 팀에서 준비한 도움말 파일이나 사용자 메뉴얼처럼 여러분의 팀이 인도하지 않은 컴포넌트에 대한 고려사항도 제공해야 한다.

패키징

 - "빌드는 한번에 배포는 여러번에"는 릴리즈에 신회를 주는 방법 중 하나이다.

고객의 기대

 - 고객에게 새로운 소프트웨어를 인도하기 전에 고객이 인도받을 준비가 되었는지 확인해야 한다.

제품 지원

 - 많은 조직에서 제품 인도 후 코드를 유지, 보수하고 고객을 지원하기 위한 제품 지원이나 운영 지원팀을 운영한다. 이들이 작업을 잘 할 수 있도록 만들자.

비즈니스에 대한 영향 이해하기

 - 애자일 팀은 비즈니스 가치를 최대화하기 위해 자주 릴르즈하고 작은 규모의 릴리즈는 부정적인 영향의 위험을 낮춘다. 작동 중지 시간을 최소화하도록 배포 시기를 업무 시간과 조정하는 것은 상식적인 일이다. 자동화되고 능률적인 배치 프로세스는 작동 중지 시간을 가능한 적게 만들 수 있다. 그리고 빠른 배치 프로세스는 하루에 여러 번 배포하는 짧은 이터레이션 개발에 유용하다.

 - 새로운 릴리즈는 가급적 고객에게 명백하게 알려져야 한다. 릴리즈 후에 진행되는 긴급 릴리즈나 패치는 고객이 개발팀 모두를 더 신뢰하게 할 것이다.

요약

 - 제품의 성공적인 인도는 구현하 어플리케이션 그 이상을 포함한다. 문서, 법적 고지, 교육과 같이 비 소프트웨어적인 부분에 대한 인도를 계획하자.

 - 최종 게임은 제품을 마지막으로 다음을 수 있는 기회이다. 

 - 다른 그룹도 최종 게임이나 릴리즈의 환경, 도구 등에 책임이 있다. 그들과 계속 협력하자.

 - 테스트 데이터베이스의 스크립트, 데이터 변환, 다른 설치 부분의 업데이트를 확인하자.

 - 사용자 인수 테스트는 운영 환경에서 사용자의 데이트를 이용하여 제품에 대한 신뢰를 쌓을 수 있는 기회이다.

 - 필요하다면 다른 조직과 같이 테스트하는 개발 후의 주기와 같은 추가적인 주기를 계획하자.

 - 릴리즈 계획 동안 릴리즈 준비가 되었는지 파악할 수 있는 릴리즈 인수 기준을 수립하자.

 - 테스터는 패키징을 릴리즈하고 테스트하는 것을 관리하는 데 종종 참여한다.

 - 제품을 릴리즈할 때 고객이 필요로 하고 기대한 것이 무엇인지 전체 패키지를 고민하자.

 - 각각의 릴리즈에서 배우고 프로세스를 개선하고 적용하자.

Chapter 21. 핵심 성공 요인

성공요인 1 : 전체 팀 접근법 이용하기

 - 애자일 개발팀의 목적은 높은 품질이지 빠른 속도가 아님을 기억하자. 여러분의 팀은 고객이 요구사항을 명확히 하는 것을 도와주고 견고한 제품을 단계적으로 인도하기 위한 특별한 관점을 가진 테스터가 필요하다. 테스터의 기술과 전문지식이 다른 팀원들에게 전수되어야 하며 테스터를 단지 수작업 테스팅을 하는 역할로 구분해야서는 안된다.

 - 여러분의 문제를 팀의 문제로 만들고 팀의 문제도 여러분의 것으로 만들어야 한다. 

성공요인 2 : 애자일 테스팅 사고방식 적용

 - 애자일 테스팅의 자세는 능동적이고 창조적이며 새로운 아이디어에 열려있고 어느 업무든 기꺼이 처리하는 것이다.

 - 애자일 테스터는 항상 협업할 준비가 되어 있고 그들의 본능을 믿고 팀과 비즈니스의 성공을 위해 열정적으로 그들의 기술을 끊임없이 연마할 것이다.

 - 애자일 테스트 사고방식의 중요한 요소는 업무 개선을 지속적으로 추진하는 것이다. 성공적인 애자일 테스터는 끊임없이  그들의 기술을 연마한다.

성공요인 3 : 자동화된 회귀 테스팅

 - 테스트 자동화는 팀의 노력이 필요하다. 그리고 처음에는 어렵고 넘어야 하는 고통이 따르게 된다.  관리자와 팀 구성원으로부터 자동화의 작은 노력을 시작하기 위해 각기 다른 형식의 지원을 요청하자.

성공 요인 4 : 피드백 주고 받기

 - 애자일의 짧은 이터레이션은 팀이 정상 궤도에 올라선 것을 유지하기 위해 지속적인 피드백을 제공하도록 설계되어 있다. 테스터는 자동화된 테스트 결과의 형태, 탐색적 테스팅을 통한 결함의 발견, 시스템의 실제 사용자의 관찰로 피드백을 제공하도록 도와주는 유일한 방법이다.

 - 여러분이 배울 수 있는 가장 가치있는 기술 중의 하나는 여러분이 하는 이렝 피드백을 제공하도록 부탁하는 방법이다.

성공 요인5 : 핵심 실천사항의 기초를 구축하기

지속적인 통합

 - 개발팀은 소스코드 관리와 지속적인 통합을 성공적으로 운영해야 한다.

테스트 환경

 - 통제할 수 있는 테스트 환경이 없다면 생산적인 테스트를 할 수 없다.

기술적 채무 관리

 - 팀은 지속적으로 기술적 채무의 양을 평가해야 하며 채무를 감소시키고 채무 발생을 방지하도록 해야 한다.

 - 자동화된 회귀 테스트에서의 적절한 커버리지는 기술적 채무를 최소화하는 열쇠이다.

점진적으로 일하기

 - 애자일 팀이 높은 품질의 제품을 만들 수 있는 이유 중 하나는 작은 규모로 일하기 때문이다.

코딩과 테스팅은 한 프로세스의 일부

 - 테스트를 통해 코딩을 항상 가이드하고 테스틍과 코딩이 동시에 진행된다면 고객이 원하는 대로 동작하고 고객이 원하는 가치를 제공하는 데에 좀 더 가까워질것이다.

실천법 간의 시너스효과

 - 지속적인 통합과 같은 하나의 애자일 개발 실천사항은 변화를 만들 수 있으나 여러 애자일 실천사항의 조합은 더 큰 효과를 줄 수 있다.

성공요인 6 : 고객과의 협업

 - 고객이 요구사항을 명확하게 하고 우선 순위를 결정하도록 지원하고 사용자 시나리오의 구체적인 사례와 요구사항을 설명하고 이러한 사례를 실행가능한 테스트로 전화하도록 도와주는 것이 테스터가 애자일 팀에 기여하는 최고의 가치중 하나이다.

성공요인 7 : 큰 그림을 보기

 - 애자일 테스팅 사분면을 지침으로 사용해서 모든 부분을 커버하는 테스트를 계획하자.