이번달에는 http://www.ddj.com/dept/debug/196603549에 기고된 아티클을 번역해 보았다. 전반적으로 애자일 프랙티스에 대해 언급하고 있는데, 역시나 아직 개념 정리가 명확히 되지 않았으므로 또는 역자의 한계로 내용이 조금 어설픈 감이 있다. ^^
12/12, 2006
Agile Testing Strategies
Scott Ambler
스코트가 여기서 보인 바와 같이, 당신 시스템의 품질은 당신이 행한 테스팅 활동의 품질 만큼만 좋아진다.
스코트는 DDJ 선임 기고 편집자이며 수많은 IT 서적의 저자이다. 그는 www.ambysoft.com/ scottAmbler.html에서 연락할 수 있다.
지난 몇개월 전부터 나는 애자일 프로젝트에서의 테스팅에 대해서 우리가 어떻게 해야 하는지 수많은 사람들로 부터 질문을 받아왔다. 애자일 개발자들은 명백하게 "테스트에 중독된" 사람들이다. 이번 기고에서 나는 애자일 소프트웨어 개발 프로젝트에서 사용되는 테스팅에 대한 몇가지 전략을 탐색할 것이다. 경고의 말: 비록 우리가 명백히 이전의 우리 전세대들로 부터 물려받은 일련의 테스팅 방법론을 따르지 않더라도, 나는 이전의 고전 방식에서 몇가지 트릭을 여전히 배울 수 있다고 생각한다.
철학적인 기초를 다지면서 시작해 보자.
* 첫째, 당신은 가능한 한 빨리 테스트를 하기 원할 것인데, 이것은 시간이 지나면서 결함 한 개의 잠재적인 영향력이 기하급수적으로 커지기 때문이다 (이것이 항상 사실은 아니다. 하지만, 신경써야 하는 문제이다.) 사실상, 많은 애자일 개발자들은 테스트 우선 접근법 (test-first approach)을 선호한다.
* 둘째, 당신은 가능한 한 자주, 더 중요한 것들을, 가능한 한 효과적으로 테스트하기 원할 것인데, 이것은 결함을 발견할 가능성을 높이기 위한 것이다. 비록 이러한 짧은 기간의 반복에서 비용이 증가하더라도, 이전의 연구들은 테스팅에 많은 투자를 할 수록 향상된 품질로 인해서 시스템의 TCO(total cost of ownership)가 감소된다는 것을 보여주고 있다.
* 셋째, 당신은 당신의 상황에서 충분한 테스팅을 하고 싶을 것이다. 즉, 상업적인 뱅킹 소프트웨어는 지역내 걸 스카우트의 회원 관리 소프트웨어 보다는 더 테스팅에 많은 투자를 해야한다.
* 네째, 페어 프로그래밍이나 다른 사람과 함께 모델링하는 것 같은 페어 테스팅(pair testing)은 대단히 훌륭한 아이디어이다. 나의 일반적인 철학은 소프트웨어 개발은 수영과 많이 닮아 있다는 것이다. 즉, 홀로 수행하면 극도로 위험하다.
라이프싸이클 전체를 통틀어 테스팅하기
그림 1은 테스팅의 의도를 위한 애자일 라이프싸이클의 고수준 레벨을 보여준다. (상세한 설명은 www.ddj.com/dept/architect/188700850의 "Initiating an Agile Project"에서 찾아보라). 애자일 프로젝트는 우리가 그 프로젝트의 기초를 세우는 단계인 짧은 초기화 단계 (반복 0)를 종종 겪는다. 이후, 진화적인 방식으로 (반복적이거나 점진적인) 그 시스템을 개발하는 제작 단계가 이어진다. 결국 시스템을 선보이는 End Game 단계를 거쳐, 그 시스템을 운영하고 유저를 지원하는 프로덕션 단계로 나아간다. 일련의 부기맨(boogeyman)을 두려워 말라. 초기화 단계는 요구사항 정의 단계가 아니며, End Game 단계는 테스팅 단계가 아니다.
그림 1: 애자일 라이프싸이클 동안의 테스트 활동들
테스팅 활동들은 라이프싸이클 동안에 각기 다르다. 통합 0 단계동안에 당신은 초기 셋업 작업들을 수행한다. 이것에는 외부 "조사" 테스팅 팀이 될 수 있는 사람들을 식별하고, 테스팅 툴을 식별하며 잠재적으로 설치하고, 필요한 경우 사용성 테스팅 랩 같은 희귀한 리소스들의 일정을 잡기 시작하는 것이 포함된다. 만일 당신의 프로젝트에 데드라인이 존재한다면, 그 프로젝트가 End Game에 진입해야 하는 프로젝트의 일정을 확인하기 원할 것이다. 좋은 소식은 제작 반복 기간 동안에 증가된 테스팅이 End Game 동안에 덜 테스팅하도록 만든다는 것을 발견할 것이라는 점이다.
상당한 양의 테스팅이 제작 반복 기간 동안에 발생한다. 기억하라. 애자일 주의자들은 자주 테스트하고, 일찍 테스트하며, 대개 테스트 우선의 개발 방식을 취한다. 이것은 이해관계자의 현재 관심사에 대해서 confirmatory testing을 하는 것으로, 대개는 유닛 레벨에서 마일스톤 단위로 수행된다. 이것은 훌륭한 출발점이다. 하지만, 테스팅 과정 전체를 의미하는 것은 아니다. (이것이 우리가 왜 다수의 통합 레벨에서 위험 기반의 조사식 테스팅을 필요로 하는지에 대한 이유이다.) 스타일에 상관없이, 당신의 진정한 목적은 테스트 하는 것이어야 한다. 테스트를 계획하는 것이 아니다. 그리고, 확실히 어떤 시점에서 희망적으로 테스트를 어떻게 할 것인지를 기술한 문서에 있지 않다. 애자일주의자들은 여전히 계획하고 있고 우리는 여전히 문서를 작성한다. 하지만, 우리의 초점은 실제 테스팅과 같은 높은 가치를 지닌 활동들에 있다.
End Game 동안에 당신은 아마도 그 릴리즈에 대해서 전체 시스템/인수 테스팅을 포함하여 최종 테스팅 활동을 수행하여야 할 것이다. 당신이 그렇게 하도록 미리 정했다면 (의료 소프트웨어 개발과 같은 생명 중시의 환경에서는 일반적이다) 또는 당신의 조직이 그것을 필요로 하는 고객과 서비스 레벨의 협약을 맺었다면 진실이된다. 운좋게도, 당신이 제작 반복 기간 동안에 효과적으로 테스트해왔었다면, 당신의 최종 테스팅 활동들은 직관적이며 빠른 것이 증명될 것이다. 만일 당신이 End Game 기간 동안에 "심각한 테스팅"의 유형을 일부라도 수행하고 있다면, 당신의 팀은 당신이 찾은 결함에 대해서 조치를 취할 시간이 충분치 않기 때문에 곤란을 겪을수도 있다.
제작 반복 기간 동안의 테스팅
애자일 프로젝트에서 대다수의 테스팅은 제작 반복 기간 동안에 발생한다. 당신의 테스팅 활동은 시스템과 마찬가지로 제작 과정을 거치면서 진화한다. 그림 2는 2개의 제작 반복 기간을 묘사하며, 팀에 의해 병렬적으로 수행되는 confirmatory testing과, 이상적으로는 독립적인 테스트 팀에 의해 수행되는 investigative testing 활동을 나타낸다. (나는 테스팅 커뮤니티 내에서 사상적 리더인 Michael Bolton으로 부터 "confirmatory"와 "investigative" 테스팅의 개념을 가져왔다.) 비록 작은 프로젝트의 경우 독립적인 테스트 팀이 항상 가용한 것은 아니지만, 적극적으로 추천된다. Confirmatory testing은 이해관계자들이 최근까지 정의한 대로 시스템이 충족하는지 확인하는데 집중한다. 반면에 investigative testing은 개발팀이 고려하지 못한 문제들을 발견하는데 집중한다.
그림 2: 애자일 개발 라이프싸이클 동안의 점진적인 테스팅
두가지 측면의 confirmatory testing이 있다. 애자일 인수 테스팅과 개발자 테스팅이 그것인데, 이 두개 모두 라이프싸이클 동안에 지속적인 리그레션 테스팅을 할 수 있도록 자동화된다. Confirmatory testing은 애자일에서 스펙에 대한 테스팅과 같은 것이다. 사실상, 우리는 요구사항 명세의 주요 부분이 작동하도록 인수테스트를 고려하고, 우리 개발자 테스트는 디자인 스펙의 주요 부분들이 작동하도록 고려한다. 이 두 가지 개념 모두는 가능할 때마다 하나의 근원적인 정보인 애자일 프랙티스에 적용된다. (?)
애자일 인수 테스팅은 전통적인 기능 테스팅과 전통적인 인수 테스팅을 혼합한 것인데, 개발팀과 그 이해관계자들이 집합적으로 작업 하기 때문이다. 개발자 테스팅은 전통적인 유닛 테스팅과 전통적인 클래스/컴포넌트/서비스 통합 테스팅의 혼합이다. 개발자 테스팅은 어플리케이션 코드와 데이터베이스 스키마 양쪽을 (자세한 정보는 www.ddj.com/architect에서 나의 기고 "Ensuring Database Quality"를 찾아보라) 확인하려고 노력한다. 당신의 목표는 코딩 에러를 찾고, 전체 패스(path) 테스팅이 불가한 경우 최소한의 커버리지를 수행하고, 시스템이 그 이해관계자들의 의도를 만족하는지 확인하는 것이다. 개발자 테스팅은 종종 하나의 테스트가 작성되고 충분한 제품 코드가 그 테스트를 충족하기 위해서 작성되는 테스트 우선적인 방식으로 수행된다 (상세 내용은 www.agiledata.org/essays/ tdd.html을 보라). 흥미롭게도, 이러한 테스트 우선 접근법은 상세 디자인 활동이 먼저이고 테스팅 활동은 그 다음인 것으로 고려된다.
자동화는 진화적인 프로젝트 상에서 리그레션 테스팅에 대한 필요가 계속 증가하기 때문에 제작 테스팅의 관점에서 중요하다. 맞춤 테스팅 프레임워크 (www.fitnesse.org) 는 아마도 요구사항 문서 툴일 텐데, 종종 애자일 인수 테스트를 자동화하는데 사용된다. 또한 유즈케이스와 시나리오 정의 또는 UML 액티비티 다이어그램이나 플로우 차트와 같은 프로세스 다이어그램으로 부터 인수 테스트 케이스를 생성할 수도 있으며, 툴은 정확하게 이것을 하기위한 시작점이 된다. Java를 위한 JUnit (www.junit.org)과 비주얼 베이직을 위한 VBUnit (www.vbunit.org) 같은, XUnit 프레임워크는 개발자 테스트를 자동화하는데 사용된다. HP의 Mercury's TestDirector (www.mercury.com/us/products/quality-center/testdirector) 또는 IBM의 Rational's TestManager (www-128.ibm.com/developerworks/rational/ products/testmanager)는 종종 오픈 소스의 대체물들보다 더 세련된 것으로 입증되었기에 고려하기 좋은 옵션들이다. FindBugs (findbugs.sourceforge.net) 같은 정적 코드 분석 툴은 가끔 소스 코드 내의 잠재적인 품질 문제를 확인하는데 도움을 주기 위해 실행되는 자동화 테스팅(툴)에 해당된다.
조사식 테스팅 (Investigative Testing)
내가 이 컬럼을 작성하고 있었을 때, 운좋게도 Dr. Cem Kaner가 발표하는 Toronto Association of Systems and Software Quality (TASSQ)에 참석할 수 있었다. Kaner는 Lessons Learned in Software Testing (Wiley, 2001)의 공저자로, 이 책은 소프트웨어 테스팅에서의 그의 사상과 경험이 기술되어 있다. 결과적으로, 내 자신의 아이디어를 개념화하는데 도움이 되었다. 특히, 나는 제작 반복 기간 동안의 조사식 테스팅 활동을 올바르게 기술하는데 어려움을 겪고 있었다. 하지만 Kaner의 발표는 내 경험과 합쳐져서 도움이 되었다.
별도의 테스트 팀이라고? 당신은 터무니 없는 소리를 하고 있군! 실제로, 독립적인 테스트 팀이 당신의 작업의 결과를 확인하기 위해 라이프싸이클 동안에 간격을 두어 시스템을 제출받는 것을 통해 상당한 가치를 제공한다. 애자일 팀은 각 제작 기간의 끝단에서 작동하는 소프트웨어를 만들어낸다. 그러므로, 당신은 그 시점에 테스트해야 할 새로운 것을 가지게 된다. 일반적인 프랙티스는 반복 주기에 상관없이 최소한 한 주에 한 번 새 버전의 시스템을 제공하는 것이다. 이것은 특히 End Game에 더욱 더 다가갈 수록 좋은 전략이다.
조사식 테스트 팀의 목표는 "무엇이 잘못될 것 같은가?"라는 질문을 하는 것으로, 개발팀이나 비즈니스 이해관계자들이 고려하지 못한 잠재적인 시나리오들을 탐색하는 것이다. 그들은 "이 시스템이 좋은가?" 아닌가 그리고 "이 시스템이 문서화된 스펙을 충족하는가?" 하는 질문에 답변하려고 노력할 것이다. Confirmatory testing 활동은 시스템이 의도를 충족하는지 아닌지 확인한다. 따라서, 그다지 많은 가치를 부여하지 못하는 작업이 반복된다. Kaner는 훌륭한 테스터들은 프로그래머들이 놓친 결함을 찾고, 개별 개발자들의 협소한 시야를 찾아내는 것이라는 아이디어를 발전시켰다.
조사식 테스터들은 결함 스토리의 형태로 잠재적인 문제를 기술한다. 이것은 애자일 결함 리포트와 동일한 것이다. 결함 스토리는 요구사항의 형태로 취급된다. 이것은 추정되고 우선순위가 매겨져서 당신의 요구사항 꾸러미에 쌓여진다. 하나의 결함을 수정해야될 필요성 자체도 요구사항의 한 가지 유형이다. 따라서, 또 다른 요구사항들과 같이 처리되기에 적합하다. 당신이 기대하는 것처럼, End Game 동안에 당신이 작업해야 하는 유일한 요구사항 유형은 결함 스토리들이다.
당신의 조사식 테스팅은 부하/스트레스 테스팅, 통합 테스팅 그리고 보안 테스팅과 같은 일반적인 이슈를 다룰 것이다. 시스템 그 자체와 지원 문서 간의 일치를 확인하는 시나리오 테스팅 또한 일반적이다. 당신은 또 유저 인터페이스가 대부분의 최종 사용자에게 보여지는 시스템이기 때문에 어떤 형태의 사용성 테스팅을 수행할 것이다. 그러므로, 사용성은 성공을 위해 중요한 이슈이다. UI에는 사람들이 읽는 문서와, 상호작용하는 화면 모두가 포함되며, 그 두가지 모두 테스트할 필요성을 암시한다.
훌륭한 조사식 테스팅 활동은 그것이 처리되는데 너무나 비용이 많이 들기 전에 개발자가 오랜 기간 놓친 문제들을 발견해 낸다. 또한 그 팀이 정기적으로 고품질의 작동하는 소프트웨어를 성공적으로 만들어 내었다고 경영진에 피드백을 제공하기도 한다. Kaner는 조사식 테스팅을 수행하는데 한 가지 올바른 방법만 있는 것은 아니며, 적용할 수 있는 한 가지 기법 리스트만 존재하는 것은 아니라고 지적한다. 당신의 활동들은 당신이 지원하는 프로젝트 팀의 목표를 반영해야 한다. 예를 들어, 그 시스템이 출시될 수 있는지 아닌지 결정하기 위한 목표인가? 시스템이 기존 다른 시스템들과 호환되는지를 확인해야 하나? 개발자들이 놓친 결함의 근원들을 지적함으로써 개발자 자신의 테스팅 활동에 문제가 있는지 확인하도록 도움을 주어야 하나? 당신 조직이나 관리자들이 소송당할 가능성을 줄여야 하나? 당신이 테스팅을 하는 상황은 어떻게 그리고 무엇을 테스트해야 하는지를 결정할 것이다. 즉, 각 프로젝의 상황이 서로 다를 뿐만 아니라, 그 상황은 프로젝트 전체 라이프싸이클을 지나면서 변경된다.
애자일 팀에 의해 수행되는 confirmatory testing의 형태는 테스팅 전체에서 단지 일부분일 뿐이다. 이것은 전통적인 스모크 테스팅과 비슷한 애자일 테스팅이다. 이것은 좋은 출발이며, 자동화된 리그레션 테스팅을 가지는 것은 진화식의 개발 기법에서 요구되는 안전망을 제공한다. 조사식 테스팅은 당신이 치명적인 "큰 그림" 이슈 뿐만 아니라, 지금까지 아무도 관심두지 않았던 "작은 그림" 이슈를 탐색하게 해주며, 이것은 일반적으로 confirmatory testing가 하지 못하는 것이다.
품질은 가장 먼저 처리해야 할 업무이다.
내가 여기에 기술한 테스팅 접근법은 전통적인, 다량의 문서와 시스템이 잘될 것이라는 희망을 가지고 벽너머의 테스터들에게 던져놓는 문서 중심의 접근법과는 다르다. 나의 경험으로는 당신 시스템의 품질은 당신이 행한 테스팅 활동의 품질과 같다. 통찰력있는 피드백을 주신 Michael Bolton, Cem Kaner, Renu L. Rajani, 그리고 Steve Robinson에게 감사한다.
Agile Testing Resources
당신은 당신의 테스팅 활동들을 어떻게 향상시킬 것인지에 대한 도발적인 아이디어들을 다음의 리소스에서 발견할 수 있다:
. Agile Testing Mailing List (tech.groups.yahoo.com/group/agile-testing).
. Context-Driven Software Testing Mailing List (tech.groups.yahoo.com/group/software-testing).
. "High-Volume Test Automation," by C. Kaner, W.P. Bond, and P. McGee (www.kaner.com/pdfs/HVAT_STAR.pdf).
. James Bach's blog (www.satisfice.com/blog).
. "Lessons Learned in Software Testing," by C. Kaner, J. Bach, and B. Pettichord (www.testinglessons.com).
. Michael Bolton's testing articles (www.developsense.com/articles).
. "Roadmap for Agile Testing" and "The Testing Team's Motto," by Brian Marick (www.testing.com/writings).
. "What Is Exploratory Testing?" by James Bach (www.satisfice.com/articles/what_is_et.shtml).
12/12, 2006
Agile Testing Strategies
Scott Ambler
스코트가 여기서 보인 바와 같이, 당신 시스템의 품질은 당신이 행한 테스팅 활동의 품질 만큼만 좋아진다.
스코트는 DDJ 선임 기고 편집자이며 수많은 IT 서적의 저자이다. 그는 www.ambysoft.com/ scottAmbler.html에서 연락할 수 있다.
지난 몇개월 전부터 나는 애자일 프로젝트에서의 테스팅에 대해서 우리가 어떻게 해야 하는지 수많은 사람들로 부터 질문을 받아왔다. 애자일 개발자들은 명백하게 "테스트에 중독된" 사람들이다. 이번 기고에서 나는 애자일 소프트웨어 개발 프로젝트에서 사용되는 테스팅에 대한 몇가지 전략을 탐색할 것이다. 경고의 말: 비록 우리가 명백히 이전의 우리 전세대들로 부터 물려받은 일련의 테스팅 방법론을 따르지 않더라도, 나는 이전의 고전 방식에서 몇가지 트릭을 여전히 배울 수 있다고 생각한다.
철학적인 기초를 다지면서 시작해 보자.
* 첫째, 당신은 가능한 한 빨리 테스트를 하기 원할 것인데, 이것은 시간이 지나면서 결함 한 개의 잠재적인 영향력이 기하급수적으로 커지기 때문이다 (이것이 항상 사실은 아니다. 하지만, 신경써야 하는 문제이다.) 사실상, 많은 애자일 개발자들은 테스트 우선 접근법 (test-first approach)을 선호한다.
* 둘째, 당신은 가능한 한 자주, 더 중요한 것들을, 가능한 한 효과적으로 테스트하기 원할 것인데, 이것은 결함을 발견할 가능성을 높이기 위한 것이다. 비록 이러한 짧은 기간의 반복에서 비용이 증가하더라도, 이전의 연구들은 테스팅에 많은 투자를 할 수록 향상된 품질로 인해서 시스템의 TCO(total cost of ownership)가 감소된다는 것을 보여주고 있다.
* 셋째, 당신은 당신의 상황에서 충분한 테스팅을 하고 싶을 것이다. 즉, 상업적인 뱅킹 소프트웨어는 지역내 걸 스카우트의 회원 관리 소프트웨어 보다는 더 테스팅에 많은 투자를 해야한다.
* 네째, 페어 프로그래밍이나 다른 사람과 함께 모델링하는 것 같은 페어 테스팅(pair testing)은 대단히 훌륭한 아이디어이다. 나의 일반적인 철학은 소프트웨어 개발은 수영과 많이 닮아 있다는 것이다. 즉, 홀로 수행하면 극도로 위험하다.
라이프싸이클 전체를 통틀어 테스팅하기
그림 1은 테스팅의 의도를 위한 애자일 라이프싸이클의 고수준 레벨을 보여준다. (상세한 설명은 www.ddj.com/dept/architect/188700850의 "Initiating an Agile Project"에서 찾아보라). 애자일 프로젝트는 우리가 그 프로젝트의 기초를 세우는 단계인 짧은 초기화 단계 (반복 0)를 종종 겪는다. 이후, 진화적인 방식으로 (반복적이거나 점진적인) 그 시스템을 개발하는 제작 단계가 이어진다. 결국 시스템을 선보이는 End Game 단계를 거쳐, 그 시스템을 운영하고 유저를 지원하는 프로덕션 단계로 나아간다. 일련의 부기맨(boogeyman)을 두려워 말라. 초기화 단계는 요구사항 정의 단계가 아니며, End Game 단계는 테스팅 단계가 아니다.
그림 1: 애자일 라이프싸이클 동안의 테스트 활동들
테스팅 활동들은 라이프싸이클 동안에 각기 다르다. 통합 0 단계동안에 당신은 초기 셋업 작업들을 수행한다. 이것에는 외부 "조사" 테스팅 팀이 될 수 있는 사람들을 식별하고, 테스팅 툴을 식별하며 잠재적으로 설치하고, 필요한 경우 사용성 테스팅 랩 같은 희귀한 리소스들의 일정을 잡기 시작하는 것이 포함된다. 만일 당신의 프로젝트에 데드라인이 존재한다면, 그 프로젝트가 End Game에 진입해야 하는 프로젝트의 일정을 확인하기 원할 것이다. 좋은 소식은 제작 반복 기간 동안에 증가된 테스팅이 End Game 동안에 덜 테스팅하도록 만든다는 것을 발견할 것이라는 점이다.
상당한 양의 테스팅이 제작 반복 기간 동안에 발생한다. 기억하라. 애자일 주의자들은 자주 테스트하고, 일찍 테스트하며, 대개 테스트 우선의 개발 방식을 취한다. 이것은 이해관계자의 현재 관심사에 대해서 confirmatory testing을 하는 것으로, 대개는 유닛 레벨에서 마일스톤 단위로 수행된다. 이것은 훌륭한 출발점이다. 하지만, 테스팅 과정 전체를 의미하는 것은 아니다. (이것이 우리가 왜 다수의 통합 레벨에서 위험 기반의 조사식 테스팅을 필요로 하는지에 대한 이유이다.) 스타일에 상관없이, 당신의 진정한 목적은 테스트 하는 것이어야 한다. 테스트를 계획하는 것이 아니다. 그리고, 확실히 어떤 시점에서 희망적으로 테스트를 어떻게 할 것인지를 기술한 문서에 있지 않다. 애자일주의자들은 여전히 계획하고 있고 우리는 여전히 문서를 작성한다. 하지만, 우리의 초점은 실제 테스팅과 같은 높은 가치를 지닌 활동들에 있다.
End Game 동안에 당신은 아마도 그 릴리즈에 대해서 전체 시스템/인수 테스팅을 포함하여 최종 테스팅 활동을 수행하여야 할 것이다. 당신이 그렇게 하도록 미리 정했다면 (의료 소프트웨어 개발과 같은 생명 중시의 환경에서는 일반적이다) 또는 당신의 조직이 그것을 필요로 하는 고객과 서비스 레벨의 협약을 맺었다면 진실이된다. 운좋게도, 당신이 제작 반복 기간 동안에 효과적으로 테스트해왔었다면, 당신의 최종 테스팅 활동들은 직관적이며 빠른 것이 증명될 것이다. 만일 당신이 End Game 기간 동안에 "심각한 테스팅"의 유형을 일부라도 수행하고 있다면, 당신의 팀은 당신이 찾은 결함에 대해서 조치를 취할 시간이 충분치 않기 때문에 곤란을 겪을수도 있다.
제작 반복 기간 동안의 테스팅
애자일 프로젝트에서 대다수의 테스팅은 제작 반복 기간 동안에 발생한다. 당신의 테스팅 활동은 시스템과 마찬가지로 제작 과정을 거치면서 진화한다. 그림 2는 2개의 제작 반복 기간을 묘사하며, 팀에 의해 병렬적으로 수행되는 confirmatory testing과, 이상적으로는 독립적인 테스트 팀에 의해 수행되는 investigative testing 활동을 나타낸다. (나는 테스팅 커뮤니티 내에서 사상적 리더인 Michael Bolton으로 부터 "confirmatory"와 "investigative" 테스팅의 개념을 가져왔다.) 비록 작은 프로젝트의 경우 독립적인 테스트 팀이 항상 가용한 것은 아니지만, 적극적으로 추천된다. Confirmatory testing은 이해관계자들이 최근까지 정의한 대로 시스템이 충족하는지 확인하는데 집중한다. 반면에 investigative testing은 개발팀이 고려하지 못한 문제들을 발견하는데 집중한다.
그림 2: 애자일 개발 라이프싸이클 동안의 점진적인 테스팅
두가지 측면의 confirmatory testing이 있다. 애자일 인수 테스팅과 개발자 테스팅이 그것인데, 이 두개 모두 라이프싸이클 동안에 지속적인 리그레션 테스팅을 할 수 있도록 자동화된다. Confirmatory testing은 애자일에서 스펙에 대한 테스팅과 같은 것이다. 사실상, 우리는 요구사항 명세의 주요 부분이 작동하도록 인수테스트를 고려하고, 우리 개발자 테스트는 디자인 스펙의 주요 부분들이 작동하도록 고려한다. 이 두 가지 개념 모두는 가능할 때마다 하나의 근원적인 정보인 애자일 프랙티스에 적용된다. (?)
애자일 인수 테스팅은 전통적인 기능 테스팅과 전통적인 인수 테스팅을 혼합한 것인데, 개발팀과 그 이해관계자들이 집합적으로 작업 하기 때문이다. 개발자 테스팅은 전통적인 유닛 테스팅과 전통적인 클래스/컴포넌트/서비스 통합 테스팅의 혼합이다. 개발자 테스팅은 어플리케이션 코드와 데이터베이스 스키마 양쪽을 (자세한 정보는 www.ddj.com/architect에서 나의 기고 "Ensuring Database Quality"를 찾아보라) 확인하려고 노력한다. 당신의 목표는 코딩 에러를 찾고, 전체 패스(path) 테스팅이 불가한 경우 최소한의 커버리지를 수행하고, 시스템이 그 이해관계자들의 의도를 만족하는지 확인하는 것이다. 개발자 테스팅은 종종 하나의 테스트가 작성되고 충분한 제품 코드가 그 테스트를 충족하기 위해서 작성되는 테스트 우선적인 방식으로 수행된다 (상세 내용은 www.agiledata.org/essays/ tdd.html을 보라). 흥미롭게도, 이러한 테스트 우선 접근법은 상세 디자인 활동이 먼저이고 테스팅 활동은 그 다음인 것으로 고려된다.
자동화는 진화적인 프로젝트 상에서 리그레션 테스팅에 대한 필요가 계속 증가하기 때문에 제작 테스팅의 관점에서 중요하다. 맞춤 테스팅 프레임워크 (www.fitnesse.org) 는 아마도 요구사항 문서 툴일 텐데, 종종 애자일 인수 테스트를 자동화하는데 사용된다. 또한 유즈케이스와 시나리오 정의 또는 UML 액티비티 다이어그램이나 플로우 차트와 같은 프로세스 다이어그램으로 부터 인수 테스트 케이스를 생성할 수도 있으며, 툴은 정확하게 이것을 하기위한 시작점이 된다. Java를 위한 JUnit (www.junit.org)과 비주얼 베이직을 위한 VBUnit (www.vbunit.org) 같은, XUnit 프레임워크는 개발자 테스트를 자동화하는데 사용된다. HP의 Mercury's TestDirector (www.mercury.com/us/products/quality-center/testdirector) 또는 IBM의 Rational's TestManager (www-128.ibm.com/developerworks/rational/ products/testmanager)는 종종 오픈 소스의 대체물들보다 더 세련된 것으로 입증되었기에 고려하기 좋은 옵션들이다. FindBugs (findbugs.sourceforge.net) 같은 정적 코드 분석 툴은 가끔 소스 코드 내의 잠재적인 품질 문제를 확인하는데 도움을 주기 위해 실행되는 자동화 테스팅(툴)에 해당된다.
조사식 테스팅 (Investigative Testing)
내가 이 컬럼을 작성하고 있었을 때, 운좋게도 Dr. Cem Kaner가 발표하는 Toronto Association of Systems and Software Quality (TASSQ)에 참석할 수 있었다. Kaner는 Lessons Learned in Software Testing (Wiley, 2001)의 공저자로, 이 책은 소프트웨어 테스팅에서의 그의 사상과 경험이 기술되어 있다. 결과적으로, 내 자신의 아이디어를 개념화하는데 도움이 되었다. 특히, 나는 제작 반복 기간 동안의 조사식 테스팅 활동을 올바르게 기술하는데 어려움을 겪고 있었다. 하지만 Kaner의 발표는 내 경험과 합쳐져서 도움이 되었다.
별도의 테스트 팀이라고? 당신은 터무니 없는 소리를 하고 있군! 실제로, 독립적인 테스트 팀이 당신의 작업의 결과를 확인하기 위해 라이프싸이클 동안에 간격을 두어 시스템을 제출받는 것을 통해 상당한 가치를 제공한다. 애자일 팀은 각 제작 기간의 끝단에서 작동하는 소프트웨어를 만들어낸다. 그러므로, 당신은 그 시점에 테스트해야 할 새로운 것을 가지게 된다. 일반적인 프랙티스는 반복 주기에 상관없이 최소한 한 주에 한 번 새 버전의 시스템을 제공하는 것이다. 이것은 특히 End Game에 더욱 더 다가갈 수록 좋은 전략이다.
조사식 테스트 팀의 목표는 "무엇이 잘못될 것 같은가?"라는 질문을 하는 것으로, 개발팀이나 비즈니스 이해관계자들이 고려하지 못한 잠재적인 시나리오들을 탐색하는 것이다. 그들은 "이 시스템이 좋은가?" 아닌가 그리고 "이 시스템이 문서화된 스펙을 충족하는가?" 하는 질문에 답변하려고 노력할 것이다. Confirmatory testing 활동은 시스템이 의도를 충족하는지 아닌지 확인한다. 따라서, 그다지 많은 가치를 부여하지 못하는 작업이 반복된다. Kaner는 훌륭한 테스터들은 프로그래머들이 놓친 결함을 찾고, 개별 개발자들의 협소한 시야를 찾아내는 것이라는 아이디어를 발전시켰다.
조사식 테스터들은 결함 스토리의 형태로 잠재적인 문제를 기술한다. 이것은 애자일 결함 리포트와 동일한 것이다. 결함 스토리는 요구사항의 형태로 취급된다. 이것은 추정되고 우선순위가 매겨져서 당신의 요구사항 꾸러미에 쌓여진다. 하나의 결함을 수정해야될 필요성 자체도 요구사항의 한 가지 유형이다. 따라서, 또 다른 요구사항들과 같이 처리되기에 적합하다. 당신이 기대하는 것처럼, End Game 동안에 당신이 작업해야 하는 유일한 요구사항 유형은 결함 스토리들이다.
당신의 조사식 테스팅은 부하/스트레스 테스팅, 통합 테스팅 그리고 보안 테스팅과 같은 일반적인 이슈를 다룰 것이다. 시스템 그 자체와 지원 문서 간의 일치를 확인하는 시나리오 테스팅 또한 일반적이다. 당신은 또 유저 인터페이스가 대부분의 최종 사용자에게 보여지는 시스템이기 때문에 어떤 형태의 사용성 테스팅을 수행할 것이다. 그러므로, 사용성은 성공을 위해 중요한 이슈이다. UI에는 사람들이 읽는 문서와, 상호작용하는 화면 모두가 포함되며, 그 두가지 모두 테스트할 필요성을 암시한다.
훌륭한 조사식 테스팅 활동은 그것이 처리되는데 너무나 비용이 많이 들기 전에 개발자가 오랜 기간 놓친 문제들을 발견해 낸다. 또한 그 팀이 정기적으로 고품질의 작동하는 소프트웨어를 성공적으로 만들어 내었다고 경영진에 피드백을 제공하기도 한다. Kaner는 조사식 테스팅을 수행하는데 한 가지 올바른 방법만 있는 것은 아니며, 적용할 수 있는 한 가지 기법 리스트만 존재하는 것은 아니라고 지적한다. 당신의 활동들은 당신이 지원하는 프로젝트 팀의 목표를 반영해야 한다. 예를 들어, 그 시스템이 출시될 수 있는지 아닌지 결정하기 위한 목표인가? 시스템이 기존 다른 시스템들과 호환되는지를 확인해야 하나? 개발자들이 놓친 결함의 근원들을 지적함으로써 개발자 자신의 테스팅 활동에 문제가 있는지 확인하도록 도움을 주어야 하나? 당신 조직이나 관리자들이 소송당할 가능성을 줄여야 하나? 당신이 테스팅을 하는 상황은 어떻게 그리고 무엇을 테스트해야 하는지를 결정할 것이다. 즉, 각 프로젝의 상황이 서로 다를 뿐만 아니라, 그 상황은 프로젝트 전체 라이프싸이클을 지나면서 변경된다.
애자일 팀에 의해 수행되는 confirmatory testing의 형태는 테스팅 전체에서 단지 일부분일 뿐이다. 이것은 전통적인 스모크 테스팅과 비슷한 애자일 테스팅이다. 이것은 좋은 출발이며, 자동화된 리그레션 테스팅을 가지는 것은 진화식의 개발 기법에서 요구되는 안전망을 제공한다. 조사식 테스팅은 당신이 치명적인 "큰 그림" 이슈 뿐만 아니라, 지금까지 아무도 관심두지 않았던 "작은 그림" 이슈를 탐색하게 해주며, 이것은 일반적으로 confirmatory testing가 하지 못하는 것이다.
품질은 가장 먼저 처리해야 할 업무이다.
내가 여기에 기술한 테스팅 접근법은 전통적인, 다량의 문서와 시스템이 잘될 것이라는 희망을 가지고 벽너머의 테스터들에게 던져놓는 문서 중심의 접근법과는 다르다. 나의 경험으로는 당신 시스템의 품질은 당신이 행한 테스팅 활동의 품질과 같다. 통찰력있는 피드백을 주신 Michael Bolton, Cem Kaner, Renu L. Rajani, 그리고 Steve Robinson에게 감사한다.
Agile Testing Resources
당신은 당신의 테스팅 활동들을 어떻게 향상시킬 것인지에 대한 도발적인 아이디어들을 다음의 리소스에서 발견할 수 있다:
. Agile Testing Mailing List (tech.groups.yahoo.com/group/agile-testing).
. Context-Driven Software Testing Mailing List (tech.groups.yahoo.com/group/software-testing).
. "High-Volume Test Automation," by C. Kaner, W.P. Bond, and P. McGee (www.kaner.com/pdfs/HVAT_STAR.pdf).
. James Bach's blog (www.satisfice.com/blog).
. "Lessons Learned in Software Testing," by C. Kaner, J. Bach, and B. Pettichord (www.testinglessons.com).
. Michael Bolton's testing articles (www.developsense.com/articles).
. "Roadmap for Agile Testing" and "The Testing Team's Motto," by Brian Marick (www.testing.com/writings).
. "What Is Exploratory Testing?" by James Bach (www.satisfice.com/articles/what_is_et.shtml).
