이 글은 James Bach 의 'Exploratory Testing 3.0'을 번역한 글입니다.
이번 글은 의미를 전달하는데 무리가 없는 선에서 대부분 의역으로 번역되었습니다. 때문에 잘못 번역된 부분은 댓글로 남겨주시면 수정하도록 하겠습니다.(읽어보시면 시제나 문체가 시시각각으로 변합니다. 감안해서 읽어주시면 고맙겠습니다.)
이 글은 James Bach의 허락을 얻은 후 번역한 글로 다른 곳에 퍼가실때는 반드시 원 출처와 본 블로그를 같이 언급해주시기 바랍니다.
-----
[저자 주: 다른 글에서 이미 탐색적 테스팅을 이제는 테스팅으로 불러야 한다는 것을 얘기했다. 사실 Michael은 2009년에 테스트에 대해 얘기했었고, James는 테스터에 대해 얘기했던 것을 2010년에 블로그에 작성했다. Aaron Hodder는 2011년에 직접적으로 언급했고 Paul Gerrard 역시 그러했다.우리는 모든 테스팅은 탐색적이라는 것을 깊이 이해하고 가르쳤지만(여기에 James가 작년에 한 학생과 대화를 나눈 예가 있다.), "탐색적 테스팅"이라는 용어를 더이상 사용하지 않을 준비가 되어 있지 않다. 지금도 우리는 탐색적 테스팅이라는 용어를 사용하지 말아야 한다고 주장하지는 않는다. 다만 테스팅이 탐색을 어느 정도 포함한 스크립트 테스팅을 의미하는 것이 아니라 테스팅이 곧 탐색적 테스팅이라는 것이다.]
By James Bach and Michael Bolton
태초에 테스팅이 있었다. 아무도 탐색과 스크립트 테스팅을 구별하지 못했다. Jerry Weinberg는 1961년 Computer Programming Fundamentals에서 테스팅의 형식화(formalizing)에 주의를 표명하고 테스팅은 본질적으로 탐색이라고 설명했다. 그는 책에서 "프로그래머의 의도에 대한 많은 정보 없이 프로그램과 프로그래머의 의도가 얼마나 일치하는지 기계적으로 검사하는 것은 어렵다. 만약 검사를 위해 컴퓨터에 간단하게 몇가지 정보만 제시해도 된다면 사람 뿐만 아니라 컴퓨터도 코딩을 할 수 있을 것이다. 복잡한 논리 연산은 간단한 명령의 조합을 컴퓨터가 실행함으로써 구현될 뿐 컴퓨터가 논리적으로 추론을 하거나 원하는 것을 추론하는 것은 아니라는 것을 잊지 말아야 한다."
Jerry는 사람이 수행할 작업과 기계가 수행할 작업의 차이를 이해하고 있었다. 그러나 그 후 형식주의자(formalizers)들이 왔고 모두가 혼란에 빠졌다. 형식주의자들은 - 공식적으로 첫번째 테스팅 책인 Program Test Methods 출판으로 시작되었다. - 본질보다는 테스팅의 형식에 집중했다. 형식이란 단어, 사진, 비트 스트링, 데이터 파일, 테이블, 플로우 차트 및 명시적으로 모델링의 다른 형태를 의미한다. 이러한 것들은 우리가 보고, 읽고, 참조하고, 배치하고, 계산하고, 저장하고, 검색할 수 있다. 형식주의자들은 우리가 이러한 것들을 바라보도록 유혹했고 "오! 이것이 테스팅이다!"라고 말했다. 그러나 테스팅은 이러한 것이 아니다. 테스팅은 인간의 사고 과정과 활동을 연결하기 위해 이러한 것들을 사용하는 것이다. 사람이 고려되지 않는 테스팅이란 의사나 간호사가 없는 위험한 병원과 같다.: 의사나 간호사의 노력을 무위로 돌리고 환자를 위험에 처하게 하는 절대적으로 쓸모없는 최악의 병원말이다.
우리는 혁신을 비난하지는 않는다. 그 당시 그것들은 새롭게 떠오르는 개념이었다. 하늘은 그들의 편이었다. 그러나 공식화 및 기계화는 곧 실험실을 탈출했다. 분별없는 사람들이 "테스트 공정"과 잘못 설계된 IEEE 표준을 따르기를 요구했다. 짧은 시간에 "대부분의 테스트"는 스크립트 기반의 테스트가 되었다. 비공식 테스팅은 전문성이 없는 테스팅과 동일한 의미가 되었다. 생각, 감정, 사람간의 의사소통의 역할은 외면받게 되었다.
James는 1987년에 합류했고 이 모든 것을 이해하려고 노력했다. 그는 단지 진행중인 테스트를 보면서 "ad hoc" 테스팅이 결함을 잘 발견하는지 높은 수준의 스크립트 테스팅이 적용되는지 탐색했다.(Note: 탐색이 쉬었다는 의미가 아니다. 그 반대였다. 테스팅에서 매일 사람들이 어떻게 일을 하는지 주의 깊게 살펴 보고 민간 요법을 제거했을 때 우리 주변의 모든 증거들은 명백하지 않은 진리였다.) 그는 자신의 경험에 대해 글을 쓰고 얘기하기 시작했다. 컴파일러와 다른 개발자 도구를 테스팅하는 테스트 관리자로서 일한 몇년 동안 그는 Cem Kaner가 제안한 스크립트 테스팅의 반대 개념인 "탐색적 테스팅"을 탐구했다. Cem조차 몇 페이지에 걸쳐서 어렵게 설명하고도 정의하지 못한 용어였지만 그는 테스팅을 실행하면서 설계하는 것에 대하여 처음으로 직접적으로 이야기하였다.
그렇게 우리가 탐색적 테스팅 1.0이라 부르는 용어가 탄생했다.
(탐색적 테스팅 용어의 연대기는 The History of Definitions of ET(탐색적 테스팅 정의 변천사)를 참조하라.)
탐색적 테스팅 1.0: 반란(Rebellion)
스크립트가 있는 테스팅과 없는 테스팅은 다른 경험이었다. 먼저, 우리는 대부분 즉흥적 테스트로부터 드러난 아이디어의 품질을 확장시켰다. 탐색적 테스팅을 했을 때, 우리는 더 많은 결함과 더 나은 결함을 발견했다. 그것은 단지 더 나은 테스트를 수행한 것 같은 느낌이었다. 우리는 왜 그러한지 이유를 아직도 발견하지 못했다. 그러나 설명과 이론적으로 탐색적 테스팅의 첫번째 반복은 "더 좋은 테스팅"을 위한 공간을 만들고 스크립의 구속에서 탈출하도록 했다. 우리는 "Ad hoc 테스팅은 통제되지 않고 관리되지 않는다: 당신은 아무것도 하지 않고 있다."라는 태도에 직면했다. 우리는 이러한 생각에 저항했고, 그런 맥락에서 탐색적 테스팅은 특별한 활동이었다. 그래서 탐색적 테스팅에 대한 십자군으로서 기법을 제안하고 그 기법 사용을 주장했다. "스크립트를 실행하고 제품을 관찰해라! 제품과 상호작용해라! 결함을 찾아라!"
많은 사람들이 탐색적 테스팅에 대해 여전히 이렇게 생각한다. : 기술 그리고 별개의 활동으로. 그러나 이것은 잘못된 생각이다. 우리가 깨달았을 때, 탐색적 테스팅은 소외되고 허위정보가 유포되고 있었다. 그것은 시작으로는 괜찮았지만 그런식으로 생각하면 곧 막다른 골목에 이르게 될 것이다. 최근에 탐색적 테스팅에 관한 책을 쓴 사람들을 포함한 많은 사람들이 이러한 관점에 만족하고 있다.
탐색적 테스팅 1.0의 시대가 1995년부터 퇴색하기 시작했다. 그 당시 모든 테스터들이 무의식적으로 또는 비공식적으로 그것을 추구함에도 불구하고 적극적으로 탐색적 테스팅에 대한 훈련을 개발하는 사람은 업계에서 단지 소수였고 언제나 그러했다. 이 몇몇 사람들 때문에 탐색적 테스팅이 사라지지 않았다.
탐색적 테스팅 1.5: 설명(Explication)
90년대 후반 북미 지역에서 시작한 테스터들의 작은 커뮤니티(애자일 테스팅 커뮤니티에 참여했던 사람들을 포함해 훗날 전 세계 정황 주도 커뮤니티로 성장한)는 여전히 일반적인 테스팅을 구성하는 사고 절차와 기술을 이해하기 위해 노력하고 있었다. 이를 위해 그들은 연구의 두가지 주요 맥락을 추구했다. 하나는 가족 심리학과 시스템 사고를 결합한 Jerry Weinberg의 소프트웨어 공학에 대한 인본주의 접근이었다. 다른 하나는 Cem Kaner의 인지 과학과 Popper의 비판적 합리주의였다.이 작업은 곧 스크립트와 탐색적 테스팅에 대한 우리의 개념을 재구성하는 요인이 되었다. 왜? 왜냐하면 테스팅에 대한 우리의 깊은 이해가 매우 빠르게 발전했기 때문이다.
James가 ST Labs에 1995년 합류했을 때 그는 소프트웨어 테스팅을 위한 비전과 방법론을 개발하는데 모든 시간을 투자하는 것은 처음이었다. 이때는 그와 Cem이 15년 간의 공동 작업을 시작했을 때였고 Rapid Software Testing 방법론이 처음으로 형성될 때였다. 이 여정에서 큰 혁신들 중 하나는 테스팅 프로세스의 포괄적인 기초 모델에 테스터의 즉흥적인 생각을 접합한 guideword heuristics이라는 실용적인 방법의 도입이었다. 일반적으로 숙력된 소프트웨어 테스팅에 대한 인지 모델과 어휘로 개발된 테스트 기법 또는 문서 템플릿의 목록은 오랜 시간 동안 주변에 있었지만 우리는 탐색적 테스팅을 새로운 시각으로 바라보기 시작했다. 우리는 단지 다르다는 느낌 대씬에 스크립트와 탐색적 테스팅의 중요한 구조와 그들 사이의 관계를 비교하고 대조하기 시작했다.
1996년 James는 "탐색적 테스팅"이라고 불리는 첫번째 테스트 교육을 만들었다. 그는 설계 패턴 사고(design patterns thinking)를 설명하고 교육에 통합을 시도했다. 그는 테스팅 역량을 정의했다.
참고: 이 기간 동안 James는 우리가 더 이상 구분하지 않는 탐색적과 Ad hoc을 구분했었다. 탐색적 테스팅은 사전적인 의미로 ad hoc 절차이다.: ad hoce은 "목적에 따라 수행하라.(to this; to the purpose)"는 의미이다. 그는 정말로 숙련과 비숙련 테스트를 구분하려고 노력했고 오늘날 우리는 그것을 할 수 있는 더 나은 방법을 알고 있다. 현재 우리는 비숙련자도 요리를 하고 춤을 출 수 있는 것처럼 탐색적 테스팅과 같은 비숙련 ad hoc 테스팅을 인식하고 있다. "탐색적 테스팅"이라는 용어의 가치는 다른 것들 사이에서 ad hoc 활동의 더 나은 설명일 뿐이다.
1999년 James는 마이크로소프트로부터 탐색적 테스팅의 정형화된 프로세스 구축을 의뢰받았다. "공식적인 ad hoc 절차"의 개념은 역설적이었고 이것은 James와 Cem 사이에 격렬한 토론을 야기시켰다. 이 논쟁이 탐색적 테스팅 2.0이라는 개념을 이끌어 냈다.
또한 탐색적 테스팅이 프로젝트 관리에 좀 더 쓸모있도록 만드는 진전이 있었다. 2000년 James와 John은 마이크로소프트의 작업에 영향을 받아 휴렛 팩커드에서 그룹에 대한 "세션 기반 테스트 관리"를 개발했다. 이 개념은 비정형 탐사 작업에 대해 높은 수준의 책임성을 부여하는 것을 목표로 하는 마이크로소프트의 일반화된 프로세스 형태였다. SBTM은 테스트 케이스에 관하여 모델링 테스팅 적용에 강박 관념을 가진 형식 주의자들로부터 탐색적 작업을 보호 할 수 있도록 구성되었다. 어떤 의미에서 SBTM은 탐색적 작업을 완전히 관리할 수 있다고 인식하는 사람들을 돕는 데 매우 성공적이었다. SBTM은 "그렇게 하지 마시오." 에서 "좋아, 탐색적 테스팅 시간 블록은 테스트 케이스의 그것과 같은 것이군." 라는 식으로 태도를 변화시키는데 도움이 되었다.
2000년까지 테스팅 업계의 대부분은 탐색적 테스팅에 관하여 어느 정도는 알게 되었다. 우리는 더 나은 테스팅을 위해 안전한 체계를 만들기 시작했다.
탐색적 테스팅 2.0: 통합(Integration)
탐색적 테스팅 2.0의 시대는 the exploratory-scripted continuum 이라는 핵심 개념을 기반으로 한다. 이것은 완전한 탐색적 테스팅에서 완전한 스크립트 테스팅까지 테스팅 범위에 대한 슬라이딩 바이다. 모든 테스팅 작업은 이 슬라이딩 바 위에 있다. 이 문제를 인식하고, 우리는 탐색적 테스팅을 기술 적용 방법론(또는 Cem이 얘기하는 테스팅의 "형식"으로)으로 얘기할 수도 있지만 기술로 얘기하는 것을 멈추었다.
십년전과 달리 우리는 이제 테스팅의 요소와 기술에 대한 풍부한 생각을 가지고 있기 때문에 그런 식으로 테스트를 생각할 수 있었다. 그것은 특정한 사람들이 마치 타고난 것처럼 "직관적으로" 수행하는 방법이 더 이상 "창의적이고 신비한" 행동이 아니라는 것이다. 우리는 테스팅을 탐색 이외의 특정 구조, 모델, 그리고 인지 과정을 포함해 바라보게 되었고, 그래서 우리는 유용한 방법으로 테스팅으로부터 탐색을 분리할수 있다고 생각하게 되었다. 90년대 초 탐색적 테스팅이라고 불리던 많은 부분을 이제는 "자유형 탐색적 테스팅(freestyle exploratory testing)"이라고 부르게 되었다.
2006년 우리는 탐색적 테스팅을 동시 학습, 테스트 설계, 테스트 실행으로 간단하게 정의하였다. 이 개념을 발전시키기 위해 James와 Cem은 2006년 1월 Exploratory Testing Research Summit 이라는 회의를 소집했다.(참가자들은 James Bach, Jonathan Bach, Scott Barber, Michael Bolton, Elisabeth Hendrickson, Cem Kaner, Mike Kelly, Jonathan Kohl, James Lyndsay, and Rob Sabourin 였다.) 회의의 모든 참가자들은 탐색적 테스팅의 정의에 동의했지만 실제적인 의미에 동의한 사람은 소수였다. 당시에는 이 용어에 대한 정의가 없었지만 CDT(Context Driven Testing) 커뮤니티에서 지금은 피상적 동의(shallow agreement)라고 부르고 있다. 피상적 동의를 방지하고 탐색적 테스팅에 대한 이해를 증진시키기 위해서 우리는 Cem이 처음 제안하고 이후 좀 더 연상하기 쉽고 설명하기 쉽게 다른 몇몇이 수정한 정의를 채택하기로 결정했다.: "프로젝트 전반에 걸쳐 테스트 설계, 테스트 실행, 테스트 결과 분석과 같은 작업의 품질을 최적화하기 위해 테스터 개인의 자유와 책임감을 강조하고 이러한 활동을 상호 지원하기 위해 지속적으로 학습이 발생하는 테스팅의 유형" John Bach와 Michael도 각자 "자유와 책임"을 제안했었다.
그래서 우리는 특성과 미묘한 탐사의 아이디어와 테스트에서의 역할을 정의했다. 탐사는 많은 것을 의미할 수 있다.: 대상 찾아보기, 창조적으로 일하기, 가이드 없이 작업하기, 이전에 아무도 하지 않은 것 하기, 복잡성 제어하기, 자발적 행동 등. 연속성 개념의 출현과(James의 동생 John은 실제로 "테스터 자유 척도"라고 함) ExTRS peer conference에서의 논의로 우리는 탐험의 서로 다른 개념의 대부분은 일반적으로 테스트에 이미 포함되어 있다는 것을 깨달았다. "탐색적"이라는 형용사가 추가된 무엇, 그리고 "스크립트"와 대조하는 방법은 주체성의 문제였다.(the dimension of agency) 다시 말해서 자기 지향성(self-directedness)이었다.
새로운 정의의 전체적인 의미는 이후 몇 년동안 분명해졌고 James 와 Michael은 Rapid Software Testing methodology를 가르치고 컨설팅했다. 우리는 이제 "탐색적 테스팅"을 통해 자기 주도적으로 충분하고 완성도 높은 테스팅에 도달하려고 노력했다는 것을 인정한다.즉, 주체성 이외의 모든 면에서, 숙련된 스크립트 테스트와 숙련된 탐색적 테스팅을 구별하지 않는다. 이것은 문서나 사고, 경과 시간, 도구, 의도성이 아닌 단지 주체성의 문제이다. 당신은 종이 조각도 없이 스크립트 테스팅을 할 수 있다.(스크립트 테스팅은 당신이 문자 그대로의 스크립트를 따르도록 요구하지 않는다.) 당신은 어떤 사전 계획 없이도 스크립트 테스팅을 수행할 수 있다.(다른 누군가는 생각나는 아이디어에 따라 즉석에서 해야 할 일을 얘기할 수 있다.) 당신은 언제 어디서나 스크립트 테스팅을 수행할 수 있다.( 누군가가 당신에 스크립트를 건네 줄 수도 있고, 당신 스스로 작성할 수도 있다.) 당신은 도구에 관계없이 스크립트 테스트를 수행할 수 있다.(도구는 테스팅을 다른 방식으로 실행하도록 하지만, 스크립트가 반드시 필요한 것은 아니다.) 심지어 당신은 무의식적으로 스크립트 테스팅을 수행할 수도 있다.(아마도 당신은 스스로 자유롭게 선택을 했다고 여기겠지만 당신의 모델과 습관은 당신에게 보이지 않는 감옥(선입견)을 만들 것이다.) 스크립트 테스팅의 본질은 테스터가 테스트를 제어 하지 않고 다른 인자 또는 프로세스가 제어하고 있다는 점이다. 이 단순하고 중요한 아이디어를 깨닫는데 우리는 몇년이 걸렸다!
그동안 우리는 탐색적 테스팅의 특별한 기술에 우리의 생각을 추가했다. James와 Jon Bach는 "탐색적 테스팅에서 탐색이란 무엇인가?"라는 질문에 대답하기 위해 특성과 세부사항이 포함된 탐색적 기술과 전술 참조 시트를 만들었다.
2007년 또 다른 큰 도약이 천천히 일어나고 있었다. 시작은 미약했다.: The Shape of Actions 이라는 책의 일부에서 영감을 얻어 James는 인간의 판단과 지혜를 요구하는 프로세스와 그렇지 않은 프로세스를 구분하기 시작했다. 그는 "현명한(sapient)"과 "현명하지 않은(non-sapient)"라고 불렀다. 이것은 체계적인 연구와 암묵적 지식의 개발이라는 새로운 지평을 열어줬다.
2009년 Michel은 테스팅과 체킹을 구분하기 시작했다. 테스팅은 자동화 할 수 없지만 체킹은 완전히 자동화 할 수 있다. 체킹은 테스팅에 포함된다. 먼저 James는 현명한 테스팅의 개념이 이미 있기 때문에 이어라한 구분이 필요하지 않다고 하였다. 그에게 체킹은 단순히 현명하지 않은 테스팅이었다. 그러다 몇 년동안 이러한 아이디어를 컨설팅과 교육에 적용하면서 우리는 현명한과 현명하지 않은 보다 체킹과 테스팅이 더 나은 구분이라는 것을 (누가 먼저라고 할 것 없이) 깨달았다. 이것은 "현명하지 않은"이 "무식함"으로 인식되기 때문이었고 체킹을 비난하는 것처럼 인식되었다.
단어의 좋은 의미는 어떻게 만들어지고 그것이 전파되는데는 몇년이 걸리는 걸까? 이러한 생각은 우리가 실제적인 의사 결정을 정리하는데 필요한 도구이다. 시장의 수많은 새로운 의약품 처럼 우리의 생각과 용어의 잠재적 부작용과 장점을 알아 내기 위해 수많은 경험이 필요하다. 이것이 우리가 왜 어깨를 으쓱거리며 "그저 그럴 뿐이다."라고 말하는 인내심 없는 동료 또는 고객이 아닌 장인처럼 오래 시간 일해야 하는 이유이다. 이것이 동기가 부여된 행동과 훈련간의 명확한 의사소통 그리고 관리의 유행을 붙잡기 위해 새로 생기는 전문용어로 대체되는 깨지기 쉬운 민간 요법(folklore) 간의 차이를 의미한다는 것이 우리의 경험이다.
탐색적 테스팅 3.0: 표준화(Normalization)
2011년 사회학자 Harry Collins는 우리를 위해 모든 것을 변화시키기 시작했다. 이것은 Michael이 Tacit and Explicit Knowledge을 읽으면서 시작되었다. 우리는 Harry의 명확한 내용 전개와 화려한 통찰력에 빠르게 매혹되었다. 그는 많은 시간을 행동 과학자로 보냈고 그의 생각은 테스팅에서 우리가 인식하는 것들을 과학적으로 완벽하게 설명했다.
Harry와 그의 동료들의 성과를 연구함으로써, 우리는 스크립트 또는 다른 산출물로 인코딩 할 수 있는 것과 없는 것을 깨달았고 명시적인 지식과 암묵적인 지식 사이의 차이에 관하여 어떻게 이야기할 수 있는지 배우게 되었다. 그는행동(behaviour)(활동(activity)의 관찰, 기술된 측면)과 행위(actions)(의도를 가진 행동)를 구별했다. (James의 현명한과 현명하지 않은 테스팅의 차이도 여기에서 영감을 받았다.) 그는 mimeomorphic actions(우리가 매 순간마다 동일한 방식으로 행동하고 모방하기 원하는 행위) 과 polimorphic actions(사회적 조건에 대처하기 위해 변화해야 하는 행위)의 차이를 설명함으로써 자동화의 한계와 범위 식별에 도움을 주었다. 그는 (Trevor Pinch와) 과학적 지식이 어떻게 구성되는지; (Rob Evans와) 다른 전문 지식에 관하여; 과학자들이 특정 실험 결과를 어떻게 평가하는지에 대하여 각각 책을 썼다.
Harry의 책은 우리가 그동안 모았던 서로 다른 아이디어의 구조를 그려내는데 도움을 주었다.
마지막으로
탐색적 테스팅 3.0은 우리가 Rapid Software testing 방법론에서 "탐색적 테스팅"이라는 용어를 더 이상 사용하지 않기 때문에 약간 역설적이다.
그렇다. 22년동안 사용되어 온 용어를 없애버렸다. 왜?
이제 우리가 탐색적으로 모든 테스팅을 정의했기 때문이다. 우리의 테스팅에 대한 정의는 이것이다.:
"테스팅은 질문, 연구, 모델링, 관찰과 추론, 출력 검사와 같은 탐색과 실험(experimentation)에 의한 학습을 통해 제품을 평가하는 과정이다."
그렇다면 스크립트 테스팅과는 어떻게 연결되는가? "스크립트"란 당신의 선택 영역 바깥에 존재하는(일시적이라 하더라도) 테스팅에 영향을 미치는 모든 제어 시스템 또는 요소를 말한다. 이것은 당신에게 주어진 특정 지침을 단지 참조하는 것이 아니라 따라야 한다는 것이다. 당신의 편견이 스크립트다. 당신의 무지가 스크립트다. 당신의 조직 문화가 스크립트다. 선택은 당신이 하는 것이고 스크립트가 당신을 제어하지 못하도록 하라.
탐색으로 테스팅을 정의함으로, 스크립트는 우리의 테스팅에 잠재적으로 유용한 외부 요인, 특정 상황에서 전술적으로 적용하거나 관심을 가지고 이야기할 수 있는 손님처럼 될 수 있다. 우수한 테스터는 나무꾼이 무거운 장비에 대해 만족(complacent) 또는 무시(dismissive)하지 않는 것처럼 스크립트에 대하여 만족 또는 무시하지 않는다. 스크립트는 당신을 돕거나 파멸시킬 수 있으므로 전문가는 그것을 무시하지 않는다.
당신은 테스팅을 하고 있습니까? 그렇다면 당신은 이미 탐색적 테스팅을 하고 있는 것입니다. 당신은 스크립트 테스팅을 하고 있습니까? 만약 당신이 책임감을 가지고 있다면 당신은 스크립트(와 아마도 체킹)와 함께 탐색적 테스팅을 하고 있는 것입니다. 만약 당신이 단순히 "스크립트 테스팅"만 하고 있다면 당신은 영혼 없는 체킹만 하고 있는 것이고 우리는 그것이 진정한 테스팅이 아니라고 말할 것입니다. 당신은 기계가 아닌 책임감 있는 테스처처럼 행동하려고 노력해야 합니다.
탐색적 테스팅 3.0은 기술적으로 스크립트의 퇴보(demotion), 탐색적 테스팅의 증진(promotion), 단순하게 말해서 테스팅이다.
-----
번역 후기
탐색적 테스팅을 바크와 핸드릭스에게 배우고 나름 열심히 해왔다고 자부해온 지난 수년간이 부끄러울 지경입니다.
지난 십수년간 발전해온 탐색적 테스팅의 전체적인 개념을 소개하는 글인지라 그동안의 배경을 모르면 이해하기 어려울 듯 합니다.
사실 저도 중간 중간 어떤 개념들은 굉장히 낯설기도 합니다.
특히나 스크립트 테스팅 부분은 저도 처음 번역하면서 잠시 헤맸던 부분입니다. 이와 관련해서 원글에 달린 댓글을 쭉 읽어보시는 것도 도움이 되실 것이고..아니면 제 교육에.. 쿨럭 쿨럭...
번역을 하면서 관용어구를 몰라도 너무 몰라서 번역하기 정말 어려웠습니다. 확실하지 않은 부분은 영문을 병기했습니다. 영어로 읽을때는 의미를 이해해도 이것을 한국어로 대체하는 작업은 언제나 쉽지 않네요. 일부 용어는 김창준님의 도움을 받았습니다.
그래도 매우 많은 부분이 구글 번역기로 돌린 것처럼 생경합니다. 제 한국어 실력이 미천하여 그러니 양해해 주시기 바랍니다.
마지막에 힘들고 지쳐 무성의하게 번역한 부분도 있습니다.
부디 잘못 오역된 부분은 꼭 알려주시기 바랍니다.
후기를 쓰다보니.. 웬지 모르게 바크에게 미안해지네용.. ㅠㅠ
이번 글은 의미를 전달하는데 무리가 없는 선에서 대부분 의역으로 번역되었습니다. 때문에 잘못 번역된 부분은 댓글로 남겨주시면 수정하도록 하겠습니다.(읽어보시면 시제나 문체가 시시각각으로 변합니다. 감안해서 읽어주시면 고맙겠습니다.)
이 글은 James Bach의 허락을 얻은 후 번역한 글로 다른 곳에 퍼가실때는 반드시 원 출처와 본 블로그를 같이 언급해주시기 바랍니다.
-----
[저자 주: 다른 글에서 이미 탐색적 테스팅을 이제는 테스팅으로 불러야 한다는 것을 얘기했다. 사실 Michael은 2009년에 테스트에 대해 얘기했었고, James는 테스터에 대해 얘기했던 것을 2010년에 블로그에 작성했다. Aaron Hodder는 2011년에 직접적으로 언급했고 Paul Gerrard 역시 그러했다.우리는 모든 테스팅은 탐색적이라는 것을 깊이 이해하고 가르쳤지만(여기에 James가 작년에 한 학생과 대화를 나눈 예가 있다.), "탐색적 테스팅"이라는 용어를 더이상 사용하지 않을 준비가 되어 있지 않다. 지금도 우리는 탐색적 테스팅이라는 용어를 사용하지 말아야 한다고 주장하지는 않는다. 다만 테스팅이 탐색을 어느 정도 포함한 스크립트 테스팅을 의미하는 것이 아니라 테스팅이 곧 탐색적 테스팅이라는 것이다.]
By James Bach and Michael Bolton
태초에 테스팅이 있었다. 아무도 탐색과 스크립트 테스팅을 구별하지 못했다. Jerry Weinberg는 1961년 Computer Programming Fundamentals에서 테스팅의 형식화(formalizing)에 주의를 표명하고 테스팅은 본질적으로 탐색이라고 설명했다. 그는 책에서 "프로그래머의 의도에 대한 많은 정보 없이 프로그램과 프로그래머의 의도가 얼마나 일치하는지 기계적으로 검사하는 것은 어렵다. 만약 검사를 위해 컴퓨터에 간단하게 몇가지 정보만 제시해도 된다면 사람 뿐만 아니라 컴퓨터도 코딩을 할 수 있을 것이다. 복잡한 논리 연산은 간단한 명령의 조합을 컴퓨터가 실행함으로써 구현될 뿐 컴퓨터가 논리적으로 추론을 하거나 원하는 것을 추론하는 것은 아니라는 것을 잊지 말아야 한다."
Jerry는 사람이 수행할 작업과 기계가 수행할 작업의 차이를 이해하고 있었다. 그러나 그 후 형식주의자(formalizers)들이 왔고 모두가 혼란에 빠졌다. 형식주의자들은 - 공식적으로 첫번째 테스팅 책인 Program Test Methods 출판으로 시작되었다. - 본질보다는 테스팅의 형식에 집중했다. 형식이란 단어, 사진, 비트 스트링, 데이터 파일, 테이블, 플로우 차트 및 명시적으로 모델링의 다른 형태를 의미한다. 이러한 것들은 우리가 보고, 읽고, 참조하고, 배치하고, 계산하고, 저장하고, 검색할 수 있다. 형식주의자들은 우리가 이러한 것들을 바라보도록 유혹했고 "오! 이것이 테스팅이다!"라고 말했다. 그러나 테스팅은 이러한 것이 아니다. 테스팅은 인간의 사고 과정과 활동을 연결하기 위해 이러한 것들을 사용하는 것이다. 사람이 고려되지 않는 테스팅이란 의사나 간호사가 없는 위험한 병원과 같다.: 의사나 간호사의 노력을 무위로 돌리고 환자를 위험에 처하게 하는 절대적으로 쓸모없는 최악의 병원말이다.
우리는 혁신을 비난하지는 않는다. 그 당시 그것들은 새롭게 떠오르는 개념이었다. 하늘은 그들의 편이었다. 그러나 공식화 및 기계화는 곧 실험실을 탈출했다. 분별없는 사람들이 "테스트 공정"과 잘못 설계된 IEEE 표준을 따르기를 요구했다. 짧은 시간에 "대부분의 테스트"는 스크립트 기반의 테스트가 되었다. 비공식 테스팅은 전문성이 없는 테스팅과 동일한 의미가 되었다. 생각, 감정, 사람간의 의사소통의 역할은 외면받게 되었다.
James는 1987년에 합류했고 이 모든 것을 이해하려고 노력했다. 그는 단지 진행중인 테스트를 보면서 "ad hoc" 테스팅이 결함을 잘 발견하는지 높은 수준의 스크립트 테스팅이 적용되는지 탐색했다.(Note: 탐색이 쉬었다는 의미가 아니다. 그 반대였다. 테스팅에서 매일 사람들이 어떻게 일을 하는지 주의 깊게 살펴 보고 민간 요법을 제거했을 때 우리 주변의 모든 증거들은 명백하지 않은 진리였다.) 그는 자신의 경험에 대해 글을 쓰고 얘기하기 시작했다. 컴파일러와 다른 개발자 도구를 테스팅하는 테스트 관리자로서 일한 몇년 동안 그는 Cem Kaner가 제안한 스크립트 테스팅의 반대 개념인 "탐색적 테스팅"을 탐구했다. Cem조차 몇 페이지에 걸쳐서 어렵게 설명하고도 정의하지 못한 용어였지만 그는 테스팅을 실행하면서 설계하는 것에 대하여 처음으로 직접적으로 이야기하였다.
그렇게 우리가 탐색적 테스팅 1.0이라 부르는 용어가 탄생했다.
(탐색적 테스팅 용어의 연대기는 The History of Definitions of ET(탐색적 테스팅 정의 변천사)를 참조하라.)
탐색적 테스팅 1.0: 반란(Rebellion)
스크립트가 있는 테스팅과 없는 테스팅은 다른 경험이었다. 먼저, 우리는 대부분 즉흥적 테스트로부터 드러난 아이디어의 품질을 확장시켰다. 탐색적 테스팅을 했을 때, 우리는 더 많은 결함과 더 나은 결함을 발견했다. 그것은 단지 더 나은 테스트를 수행한 것 같은 느낌이었다. 우리는 왜 그러한지 이유를 아직도 발견하지 못했다. 그러나 설명과 이론적으로 탐색적 테스팅의 첫번째 반복은 "더 좋은 테스팅"을 위한 공간을 만들고 스크립의 구속에서 탈출하도록 했다. 우리는 "Ad hoc 테스팅은 통제되지 않고 관리되지 않는다: 당신은 아무것도 하지 않고 있다."라는 태도에 직면했다. 우리는 이러한 생각에 저항했고, 그런 맥락에서 탐색적 테스팅은 특별한 활동이었다. 그래서 탐색적 테스팅에 대한 십자군으로서 기법을 제안하고 그 기법 사용을 주장했다. "스크립트를 실행하고 제품을 관찰해라! 제품과 상호작용해라! 결함을 찾아라!"
많은 사람들이 탐색적 테스팅에 대해 여전히 이렇게 생각한다. : 기술 그리고 별개의 활동으로. 그러나 이것은 잘못된 생각이다. 우리가 깨달았을 때, 탐색적 테스팅은 소외되고 허위정보가 유포되고 있었다. 그것은 시작으로는 괜찮았지만 그런식으로 생각하면 곧 막다른 골목에 이르게 될 것이다. 최근에 탐색적 테스팅에 관한 책을 쓴 사람들을 포함한 많은 사람들이 이러한 관점에 만족하고 있다.
탐색적 테스팅 1.0의 시대가 1995년부터 퇴색하기 시작했다. 그 당시 모든 테스터들이 무의식적으로 또는 비공식적으로 그것을 추구함에도 불구하고 적극적으로 탐색적 테스팅에 대한 훈련을 개발하는 사람은 업계에서 단지 소수였고 언제나 그러했다. 이 몇몇 사람들 때문에 탐색적 테스팅이 사라지지 않았다.
탐색적 테스팅 1.5: 설명(Explication)
90년대 후반 북미 지역에서 시작한 테스터들의 작은 커뮤니티(애자일 테스팅 커뮤니티에 참여했던 사람들을 포함해 훗날 전 세계 정황 주도 커뮤니티로 성장한)는 여전히 일반적인 테스팅을 구성하는 사고 절차와 기술을 이해하기 위해 노력하고 있었다. 이를 위해 그들은 연구의 두가지 주요 맥락을 추구했다. 하나는 가족 심리학과 시스템 사고를 결합한 Jerry Weinberg의 소프트웨어 공학에 대한 인본주의 접근이었다. 다른 하나는 Cem Kaner의 인지 과학과 Popper의 비판적 합리주의였다.이 작업은 곧 스크립트와 탐색적 테스팅에 대한 우리의 개념을 재구성하는 요인이 되었다. 왜? 왜냐하면 테스팅에 대한 우리의 깊은 이해가 매우 빠르게 발전했기 때문이다.
James가 ST Labs에 1995년 합류했을 때 그는 소프트웨어 테스팅을 위한 비전과 방법론을 개발하는데 모든 시간을 투자하는 것은 처음이었다. 이때는 그와 Cem이 15년 간의 공동 작업을 시작했을 때였고 Rapid Software Testing 방법론이 처음으로 형성될 때였다. 이 여정에서 큰 혁신들 중 하나는 테스팅 프로세스의 포괄적인 기초 모델에 테스터의 즉흥적인 생각을 접합한 guideword heuristics이라는 실용적인 방법의 도입이었다. 일반적으로 숙력된 소프트웨어 테스팅에 대한 인지 모델과 어휘로 개발된 테스트 기법 또는 문서 템플릿의 목록은 오랜 시간 동안 주변에 있었지만 우리는 탐색적 테스팅을 새로운 시각으로 바라보기 시작했다. 우리는 단지 다르다는 느낌 대씬에 스크립트와 탐색적 테스팅의 중요한 구조와 그들 사이의 관계를 비교하고 대조하기 시작했다.
1996년 James는 "탐색적 테스팅"이라고 불리는 첫번째 테스트 교육을 만들었다. 그는 설계 패턴 사고(design patterns thinking)를 설명하고 교육에 통합을 시도했다. 그는 테스팅 역량을 정의했다.
참고: 이 기간 동안 James는 우리가 더 이상 구분하지 않는 탐색적과 Ad hoc을 구분했었다. 탐색적 테스팅은 사전적인 의미로 ad hoc 절차이다.: ad hoce은 "목적에 따라 수행하라.(to this; to the purpose)"는 의미이다. 그는 정말로 숙련과 비숙련 테스트를 구분하려고 노력했고 오늘날 우리는 그것을 할 수 있는 더 나은 방법을 알고 있다. 현재 우리는 비숙련자도 요리를 하고 춤을 출 수 있는 것처럼 탐색적 테스팅과 같은 비숙련 ad hoc 테스팅을 인식하고 있다. "탐색적 테스팅"이라는 용어의 가치는 다른 것들 사이에서 ad hoc 활동의 더 나은 설명일 뿐이다.
1999년 James는 마이크로소프트로부터 탐색적 테스팅의 정형화된 프로세스 구축을 의뢰받았다. "공식적인 ad hoc 절차"의 개념은 역설적이었고 이것은 James와 Cem 사이에 격렬한 토론을 야기시켰다. 이 논쟁이 탐색적 테스팅 2.0이라는 개념을 이끌어 냈다.
또한 탐색적 테스팅이 프로젝트 관리에 좀 더 쓸모있도록 만드는 진전이 있었다. 2000년 James와 John은 마이크로소프트의 작업에 영향을 받아 휴렛 팩커드에서 그룹에 대한 "세션 기반 테스트 관리"를 개발했다. 이 개념은 비정형 탐사 작업에 대해 높은 수준의 책임성을 부여하는 것을 목표로 하는 마이크로소프트의 일반화된 프로세스 형태였다. SBTM은 테스트 케이스에 관하여 모델링 테스팅 적용에 강박 관념을 가진 형식 주의자들로부터 탐색적 작업을 보호 할 수 있도록 구성되었다. 어떤 의미에서 SBTM은 탐색적 작업을 완전히 관리할 수 있다고 인식하는 사람들을 돕는 데 매우 성공적이었다. SBTM은 "그렇게 하지 마시오." 에서 "좋아, 탐색적 테스팅 시간 블록은 테스트 케이스의 그것과 같은 것이군." 라는 식으로 태도를 변화시키는데 도움이 되었다.
2000년까지 테스팅 업계의 대부분은 탐색적 테스팅에 관하여 어느 정도는 알게 되었다. 우리는 더 나은 테스팅을 위해 안전한 체계를 만들기 시작했다.
탐색적 테스팅 2.0: 통합(Integration)
탐색적 테스팅 2.0의 시대는 the exploratory-scripted continuum 이라는 핵심 개념을 기반으로 한다. 이것은 완전한 탐색적 테스팅에서 완전한 스크립트 테스팅까지 테스팅 범위에 대한 슬라이딩 바이다. 모든 테스팅 작업은 이 슬라이딩 바 위에 있다. 이 문제를 인식하고, 우리는 탐색적 테스팅을 기술 적용 방법론(또는 Cem이 얘기하는 테스팅의 "형식"으로)으로 얘기할 수도 있지만 기술로 얘기하는 것을 멈추었다.
십년전과 달리 우리는 이제 테스팅의 요소와 기술에 대한 풍부한 생각을 가지고 있기 때문에 그런 식으로 테스트를 생각할 수 있었다. 그것은 특정한 사람들이 마치 타고난 것처럼 "직관적으로" 수행하는 방법이 더 이상 "창의적이고 신비한" 행동이 아니라는 것이다. 우리는 테스팅을 탐색 이외의 특정 구조, 모델, 그리고 인지 과정을 포함해 바라보게 되었고, 그래서 우리는 유용한 방법으로 테스팅으로부터 탐색을 분리할수 있다고 생각하게 되었다. 90년대 초 탐색적 테스팅이라고 불리던 많은 부분을 이제는 "자유형 탐색적 테스팅(freestyle exploratory testing)"이라고 부르게 되었다.
2006년 우리는 탐색적 테스팅을 동시 학습, 테스트 설계, 테스트 실행으로 간단하게 정의하였다. 이 개념을 발전시키기 위해 James와 Cem은 2006년 1월 Exploratory Testing Research Summit 이라는 회의를 소집했다.(참가자들은 James Bach, Jonathan Bach, Scott Barber, Michael Bolton, Elisabeth Hendrickson, Cem Kaner, Mike Kelly, Jonathan Kohl, James Lyndsay, and Rob Sabourin 였다.) 회의의 모든 참가자들은 탐색적 테스팅의 정의에 동의했지만 실제적인 의미에 동의한 사람은 소수였다. 당시에는 이 용어에 대한 정의가 없었지만 CDT(Context Driven Testing) 커뮤니티에서 지금은 피상적 동의(shallow agreement)라고 부르고 있다. 피상적 동의를 방지하고 탐색적 테스팅에 대한 이해를 증진시키기 위해서 우리는 Cem이 처음 제안하고 이후 좀 더 연상하기 쉽고 설명하기 쉽게 다른 몇몇이 수정한 정의를 채택하기로 결정했다.: "프로젝트 전반에 걸쳐 테스트 설계, 테스트 실행, 테스트 결과 분석과 같은 작업의 품질을 최적화하기 위해 테스터 개인의 자유와 책임감을 강조하고 이러한 활동을 상호 지원하기 위해 지속적으로 학습이 발생하는 테스팅의 유형" John Bach와 Michael도 각자 "자유와 책임"을 제안했었다.
그래서 우리는 특성과 미묘한 탐사의 아이디어와 테스트에서의 역할을 정의했다. 탐사는 많은 것을 의미할 수 있다.: 대상 찾아보기, 창조적으로 일하기, 가이드 없이 작업하기, 이전에 아무도 하지 않은 것 하기, 복잡성 제어하기, 자발적 행동 등. 연속성 개념의 출현과(James의 동생 John은 실제로 "테스터 자유 척도"라고 함) ExTRS peer conference에서의 논의로 우리는 탐험의 서로 다른 개념의 대부분은 일반적으로 테스트에 이미 포함되어 있다는 것을 깨달았다. "탐색적"이라는 형용사가 추가된 무엇, 그리고 "스크립트"와 대조하는 방법은 주체성의 문제였다.(the dimension of agency) 다시 말해서 자기 지향성(self-directedness)이었다.
새로운 정의의 전체적인 의미는 이후 몇 년동안 분명해졌고 James 와 Michael은 Rapid Software Testing methodology를 가르치고 컨설팅했다. 우리는 이제 "탐색적 테스팅"을 통해 자기 주도적으로 충분하고 완성도 높은 테스팅에 도달하려고 노력했다는 것을 인정한다.즉, 주체성 이외의 모든 면에서, 숙련된 스크립트 테스트와 숙련된 탐색적 테스팅을 구별하지 않는다. 이것은 문서나 사고, 경과 시간, 도구, 의도성이 아닌 단지 주체성의 문제이다. 당신은 종이 조각도 없이 스크립트 테스팅을 할 수 있다.(스크립트 테스팅은 당신이 문자 그대로의 스크립트를 따르도록 요구하지 않는다.) 당신은 어떤 사전 계획 없이도 스크립트 테스팅을 수행할 수 있다.(다른 누군가는 생각나는 아이디어에 따라 즉석에서 해야 할 일을 얘기할 수 있다.) 당신은 언제 어디서나 스크립트 테스팅을 수행할 수 있다.( 누군가가 당신에 스크립트를 건네 줄 수도 있고, 당신 스스로 작성할 수도 있다.) 당신은 도구에 관계없이 스크립트 테스트를 수행할 수 있다.(도구는 테스팅을 다른 방식으로 실행하도록 하지만, 스크립트가 반드시 필요한 것은 아니다.) 심지어 당신은 무의식적으로 스크립트 테스팅을 수행할 수도 있다.(아마도 당신은 스스로 자유롭게 선택을 했다고 여기겠지만 당신의 모델과 습관은 당신에게 보이지 않는 감옥(선입견)을 만들 것이다.) 스크립트 테스팅의 본질은 테스터가 테스트를 제어 하지 않고 다른 인자 또는 프로세스가 제어하고 있다는 점이다. 이 단순하고 중요한 아이디어를 깨닫는데 우리는 몇년이 걸렸다!
그동안 우리는 탐색적 테스팅의 특별한 기술에 우리의 생각을 추가했다. James와 Jon Bach는 "탐색적 테스팅에서 탐색이란 무엇인가?"라는 질문에 대답하기 위해 특성과 세부사항이 포함된 탐색적 기술과 전술 참조 시트를 만들었다.
2007년 또 다른 큰 도약이 천천히 일어나고 있었다. 시작은 미약했다.: The Shape of Actions 이라는 책의 일부에서 영감을 얻어 James는 인간의 판단과 지혜를 요구하는 프로세스와 그렇지 않은 프로세스를 구분하기 시작했다. 그는 "현명한(sapient)"과 "현명하지 않은(non-sapient)"라고 불렀다. 이것은 체계적인 연구와 암묵적 지식의 개발이라는 새로운 지평을 열어줬다.
2009년 Michel은 테스팅과 체킹을 구분하기 시작했다. 테스팅은 자동화 할 수 없지만 체킹은 완전히 자동화 할 수 있다. 체킹은 테스팅에 포함된다. 먼저 James는 현명한 테스팅의 개념이 이미 있기 때문에 이어라한 구분이 필요하지 않다고 하였다. 그에게 체킹은 단순히 현명하지 않은 테스팅이었다. 그러다 몇 년동안 이러한 아이디어를 컨설팅과 교육에 적용하면서 우리는 현명한과 현명하지 않은 보다 체킹과 테스팅이 더 나은 구분이라는 것을 (누가 먼저라고 할 것 없이) 깨달았다. 이것은 "현명하지 않은"이 "무식함"으로 인식되기 때문이었고 체킹을 비난하는 것처럼 인식되었다.
단어의 좋은 의미는 어떻게 만들어지고 그것이 전파되는데는 몇년이 걸리는 걸까? 이러한 생각은 우리가 실제적인 의사 결정을 정리하는데 필요한 도구이다. 시장의 수많은 새로운 의약품 처럼 우리의 생각과 용어의 잠재적 부작용과 장점을 알아 내기 위해 수많은 경험이 필요하다. 이것이 우리가 왜 어깨를 으쓱거리며 "그저 그럴 뿐이다."라고 말하는 인내심 없는 동료 또는 고객이 아닌 장인처럼 오래 시간 일해야 하는 이유이다. 이것이 동기가 부여된 행동과 훈련간의 명확한 의사소통 그리고 관리의 유행을 붙잡기 위해 새로 생기는 전문용어로 대체되는 깨지기 쉬운 민간 요법(folklore) 간의 차이를 의미한다는 것이 우리의 경험이다.
탐색적 테스팅 3.0: 표준화(Normalization)
2011년 사회학자 Harry Collins는 우리를 위해 모든 것을 변화시키기 시작했다. 이것은 Michael이 Tacit and Explicit Knowledge을 읽으면서 시작되었다. 우리는 Harry의 명확한 내용 전개와 화려한 통찰력에 빠르게 매혹되었다. 그는 많은 시간을 행동 과학자로 보냈고 그의 생각은 테스팅에서 우리가 인식하는 것들을 과학적으로 완벽하게 설명했다.
Harry와 그의 동료들의 성과를 연구함으로써, 우리는 스크립트 또는 다른 산출물로 인코딩 할 수 있는 것과 없는 것을 깨달았고 명시적인 지식과 암묵적인 지식 사이의 차이에 관하여 어떻게 이야기할 수 있는지 배우게 되었다. 그는행동(behaviour)(활동(activity)의 관찰, 기술된 측면)과 행위(actions)(의도를 가진 행동)를 구별했다. (James의 현명한과 현명하지 않은 테스팅의 차이도 여기에서 영감을 받았다.) 그는 mimeomorphic actions(우리가 매 순간마다 동일한 방식으로 행동하고 모방하기 원하는 행위) 과 polimorphic actions(사회적 조건에 대처하기 위해 변화해야 하는 행위)의 차이를 설명함으로써 자동화의 한계와 범위 식별에 도움을 주었다. 그는 (Trevor Pinch와) 과학적 지식이 어떻게 구성되는지; (Rob Evans와) 다른 전문 지식에 관하여; 과학자들이 특정 실험 결과를 어떻게 평가하는지에 대하여 각각 책을 썼다.
Harry의 책은 우리가 그동안 모았던 서로 다른 아이디어의 구조를 그려내는데 도움을 주었다.
- 미디어와 도구에 대한 McLuhan의 생각
- Karl Weick 의 sensemaking
- James C. Scott의 가독성의 개념(notion of legibility) 에 관심을 갖도록 한 Venkatesh Rao의 템포의 개념(notions of tempo) (Venkatesh Rao’s notions of tempo which in turn pointed us towards James C. Scott’s notion of legibility)
- “exploratory-scripted continuum” 의 실제 구현은(realization) (Barclays Bank에서 일하는 테스터의 순진한 질문에 의해 우리가 관심을 가지게 된) 사실상 the “formality continuum.” 이다. 즉, 공식화라는 활동은 스크립트를 조금 더 만든다는 것을 의미한다.
- 테스터의 실행 강도에 따른 즉흥적인(spontaneous) 테스트와 신중한(deliberative) 테스팅 사이의 중요한 차이점에 대한 구체화(이것은 주체성의 정도에 관한 탐색적과 스크립트 테스팅과는 다른 것이다.)
- "책임감을 가진 테스터"의 개념 (수행한 테스트 전체와 테스트 품질에 대하여 개인적으로 책임감을 가지는 테스터)
- 우리가 얘기하는 테스팅에서 "현명함(sapience)"에 관한 설명을 대체하는 체킹과 테스팅의 중요한 차이점의 출현
- Rapid Software Testing namespace 에서 "테스팅"을 재정의하여 이러한 것들을 더욱 명확하게 하였다.(아래 참조)
마지막으로
탐색적 테스팅 3.0은 우리가 Rapid Software testing 방법론에서 "탐색적 테스팅"이라는 용어를 더 이상 사용하지 않기 때문에 약간 역설적이다.
그렇다. 22년동안 사용되어 온 용어를 없애버렸다. 왜?
이제 우리가 탐색적으로 모든 테스팅을 정의했기 때문이다. 우리의 테스팅에 대한 정의는 이것이다.:
"테스팅은 질문, 연구, 모델링, 관찰과 추론, 출력 검사와 같은 탐색과 실험(experimentation)에 의한 학습을 통해 제품을 평가하는 과정이다."
그렇다면 스크립트 테스팅과는 어떻게 연결되는가? "스크립트"란 당신의 선택 영역 바깥에 존재하는(일시적이라 하더라도) 테스팅에 영향을 미치는 모든 제어 시스템 또는 요소를 말한다. 이것은 당신에게 주어진 특정 지침을 단지 참조하는 것이 아니라 따라야 한다는 것이다. 당신의 편견이 스크립트다. 당신의 무지가 스크립트다. 당신의 조직 문화가 스크립트다. 선택은 당신이 하는 것이고 스크립트가 당신을 제어하지 못하도록 하라.
탐색으로 테스팅을 정의함으로, 스크립트는 우리의 테스팅에 잠재적으로 유용한 외부 요인, 특정 상황에서 전술적으로 적용하거나 관심을 가지고 이야기할 수 있는 손님처럼 될 수 있다. 우수한 테스터는 나무꾼이 무거운 장비에 대해 만족(complacent) 또는 무시(dismissive)하지 않는 것처럼 스크립트에 대하여 만족 또는 무시하지 않는다. 스크립트는 당신을 돕거나 파멸시킬 수 있으므로 전문가는 그것을 무시하지 않는다.
당신은 테스팅을 하고 있습니까? 그렇다면 당신은 이미 탐색적 테스팅을 하고 있는 것입니다. 당신은 스크립트 테스팅을 하고 있습니까? 만약 당신이 책임감을 가지고 있다면 당신은 스크립트(와 아마도 체킹)와 함께 탐색적 테스팅을 하고 있는 것입니다. 만약 당신이 단순히 "스크립트 테스팅"만 하고 있다면 당신은 영혼 없는 체킹만 하고 있는 것이고 우리는 그것이 진정한 테스팅이 아니라고 말할 것입니다. 당신은 기계가 아닌 책임감 있는 테스처처럼 행동하려고 노력해야 합니다.
탐색적 테스팅 3.0은 기술적으로 스크립트의 퇴보(demotion), 탐색적 테스팅의 증진(promotion), 단순하게 말해서 테스팅이다.
-----
번역 후기
탐색적 테스팅을 바크와 핸드릭스에게 배우고 나름 열심히 해왔다고 자부해온 지난 수년간이 부끄러울 지경입니다.
지난 십수년간 발전해온 탐색적 테스팅의 전체적인 개념을 소개하는 글인지라 그동안의 배경을 모르면 이해하기 어려울 듯 합니다.
사실 저도 중간 중간 어떤 개념들은 굉장히 낯설기도 합니다.
특히나 스크립트 테스팅 부분은 저도 처음 번역하면서 잠시 헤맸던 부분입니다. 이와 관련해서 원글에 달린 댓글을 쭉 읽어보시는 것도 도움이 되실 것이고..아니면 제 교육에.. 쿨럭 쿨럭...
번역을 하면서 관용어구를 몰라도 너무 몰라서 번역하기 정말 어려웠습니다. 확실하지 않은 부분은 영문을 병기했습니다. 영어로 읽을때는 의미를 이해해도 이것을 한국어로 대체하는 작업은 언제나 쉽지 않네요. 일부 용어는 김창준님의 도움을 받았습니다.
그래도 매우 많은 부분이 구글 번역기로 돌린 것처럼 생경합니다. 제 한국어 실력이 미천하여 그러니 양해해 주시기 바랍니다.
마지막에 힘들고 지쳐 무성의하게 번역한 부분도 있습니다.
부디 잘못 오역된 부분은 꼭 알려주시기 바랍니다.
후기를 쓰다보니.. 웬지 모르게 바크에게 미안해지네용.. ㅠㅠ
댓글
댓글 쓰기