기본 콘텐츠로 건너뛰기

탐색적 테스팅의 역사

이 글은 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의 책은 우리가 그동안 모았던 서로 다른 아이디어의 구조를 그려내는데 도움을 주었다.

  • 미디어와 도구에 대한 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), 단순하게 말해서 테스팅이다.

-----
번역 후기
탐색적 테스팅을 바크와 핸드릭스에게 배우고 나름 열심히 해왔다고 자부해온 지난 수년간이 부끄러울 지경입니다.
지난 십수년간 발전해온 탐색적 테스팅의 전체적인 개념을 소개하는 글인지라 그동안의 배경을 모르면 이해하기 어려울 듯 합니다.
사실 저도 중간 중간 어떤 개념들은 굉장히 낯설기도 합니다.
특히나 스크립트 테스팅 부분은 저도 처음 번역하면서 잠시 헤맸던 부분입니다. 이와 관련해서 원글에 달린 댓글을 쭉 읽어보시는 것도 도움이 되실 것이고..아니면 제 교육에.. 쿨럭 쿨럭...

번역을 하면서 관용어구를 몰라도 너무 몰라서 번역하기 정말 어려웠습니다. 확실하지 않은 부분은 영문을 병기했습니다. 영어로 읽을때는 의미를 이해해도 이것을 한국어로 대체하는 작업은 언제나 쉽지 않네요. 일부 용어는 김창준님의 도움을 받았습니다.
그래도 매우 많은 부분이 구글 번역기로 돌린 것처럼 생경합니다. 제 한국어 실력이 미천하여 그러니 양해해 주시기 바랍니다.
마지막에 힘들고 지쳐 무성의하게 번역한 부분도 있습니다.
부디 잘못 오역된 부분은 꼭 알려주시기 바랍니다.

후기를 쓰다보니.. 웬지 모르게 바크에게 미안해지네용.. ㅠㅠ

댓글

이 블로그의 인기 게시물

샤오미 손세정기 2세대와 TCO 쓰윽비누 고급형 거품비누디스펜서 비교하기

옛날 옛날 한 옛날 2018년 11월에 그 때 당시 유행했던 샤오미 손세정기 2세대를 2대를 샀었습니다. 그 때 샀던 손세정기 2대 중 1대는 1년도 채 되지 않아서 사망해버리고... 남은 1대로 2021년 7월까지 썼으니 얼추 2년 넘게 썼습니다. 7월에 고장나서 눈물을 머금고 버릴 때는 금방 고장나서 버린 것 같았는데.. 다시 구매 내역을 뒤져보니 정말 오래도 사용했네요. 안써본 사람은 있어도 한번 써본 사람은 이 디스펜서를 계속 쓰게 됩니다. 2년동안 써보 샤오미 손세정기는 우선 디자인이 너무 이쁩니다. 하지만 방수 기능이 시원치 않아서 늘 조마조마했습니다. 전용 세정액을 써야하는 것도 좀 불편했습니다. 리필 하는 방법이 있긴 하지만.. 솔직히 쉽지 않아서 늘 전용 세정액을 구매해서 사용했었습니다. 하지만 고장이 나고나서 리필을 쉽게 할 수 있고 방수 기능도 되는 디스펜서가 필요해서 이것 저것 검색하다가 TCO 쓰윽비누 고급형 거품비누디스펜서(이하 '쓰윽')을 구매하게 되었습니다. 그런데, 2달도 안되어서 모터가 나가버렸습니다. 참, 어이가 없네요.. 뭐.. 이런... 중국 제품보다 내구성이 떨어지네요.. 겨우 2달 써봤지만... 간단하게 리뷰를 남겨볼까 합니다. 우선 디자인으로 따지면 샤오미와 비교해서 못생겨도 너무 못생겼습니다. 대충 이렇게 생겼는데.. 큼.. 전원 버튼은 샤오미는 터치라면 이건 버튼으로 되어 있고 방수를 위해서인지 위에 실링이 붙어 있습니다. 보기에는 별로지만 그래도 없는 것보다 나은 거라고 생각했는데... 샤오미는 거품 양을 조절할 수 없지만, 쓰윽은 3단계로 조절할 수 있습니다. 그런데, 조절은 할 수 있는데.. 나오는 거품 양은 그야말로 랜덤입니다. 센서 정밀도가 좀 문제인지.. 제 생각에는 1번이 아니라 2번이나 3번으로 인식해서 거품이 많이 나오는 것 같았습니다. 샤오미는 AA 건전지를 4개 사용하고, 쓰윽은 AAA 건전지 4개를 사용합니다. 그런데, 샤오미는 건전지로 전원이 겨우 2주 정도 유지했는데.. 쓰윽

코디에서 TV 시리즈에 극장판 결합하기

이 방법은 코디 스킨에 따라 될 수도 있고 안될 수도 있습니다. 하지만 대체로 가능하다고 봅니다.  일본 애니메이션 중에는 극장판이 중간 중간 있는 애니메이션이 꽤 있습니다. 그런데 코디에서서는 영화 라이브러리와 TV 시리즈 라이브러리가 구분되어 있기 때문에 한 화면에서 보면서 몰아보기가 쉽지 않습니다. 그런데, 주말에 코디 메뉴를 뒤적거리다가 처음 보는 기능을 발견했습니다. 예전부터 있던거지만 몰랐을 수도 있죠. 어쨌든 특정 영화를 특정 TV 시리즈에 연결해서 한 화면에서 볼 수 있습니다. 시작해 볼까요.. 먼저 영화 라이브러리에서 TV 시리즈와 연결하기 원하는 영화를 선택하고 팝업 메뉴를 호출합니다.(리모컨에서 확인 키 길게 눌러서..) 그리고 관리를 선택합니다. 그러면 아래같은 메뉴가 나옵니다. 여기서 TV 쇼 연결을 선택하시면 현재 코디에 등록된 TV 시리즈가 주르륵 출력되고 거기서 원하는 TV 쇼를 선택하시면 됩니다. 그 다음에 해당 TV 시리즈 화면으로 가보시면 아래처럼 에피소드와 영화가 한 화면에 출력됩니다. 그리고 팁 하나를 더 추가하자면 코디에서 스크래퍼로 영화나 TV 시리즈를 추가하려고 해도 정보가 없다며 추가가 되지 않는 경우가 있습니다. 그렇다면 아래 옵션을 꺼주시면 정상적으로 스크래퍼에서 정보를 불러와 등록을 할 수 있습니다. 등록하려고 하는 영상 파일에 메타 정보가 올바르지 않으면 스크래퍼에서 정보를 불러오지 못하더라구요. 우리 모두 코디와 함께 즐거운 미디어 라이프를...

스위치봇 & 스위치봇 허브 미니 간단 사용기

제 블로그에 예전부터 오셨던 분들은 제가 사브작 사브작 홈 오토메이션을 어설프게 해온 것을 아실겁니다. 작년부터 너무 하고 싶었던 도어락 자동화에 도전해봤습니다. 우리 나라에 자체 서비스로 앱을 통해 도어락을 제어하는 제품은 꽤 있습니다. 게이트맨도 있고, 키위도 있고, 삼성도 있죠.. 그런데.. 전 그것보다 구글 어시스턴트를 지원하는 도어락이 필요했는데... 그런건 안만들더라구요.. 꼭 필요한건 아니지만 웬지 해보고 싶은데... 언제 제품이 출시될지도 몰라서.. 가능한 방법을 찾아보다가.. 스위치봇이라는 제품으로 도어락을 버튼을 꾹 누르는 방법을 찾아서 스위치봇이 직구가 아닌 국내에 출시되었길래 낼름 구매해서 도전해봤습니다. 스위치봇 제품에 대한 내용이나 구매는  https://www.wakers.shop/  에서 하시면 됩니다. 저는 스위치봇에 스위치봇을 구글 홈에 연결시키기 위해 스위치봇 허브 미니까지 구매했습니다. 스위치봇 허브 미니가 없으면 스위치봇을 외부에서 제어하거나 구글 홈에 연결할 수 없습니다. 그리고 제가 스위치봇 허브 미니를 구매한 이유 중 다른 하나는 이 제품이 RF 리모컨 기능이 지원됩니다. 집에 있는 모니터를 제어할 필요가 있어서 이참 저참으로 같이 구매했습니다. 제품 등록은 어렵지 않습니다. 여기서는 스위치봇 허브 미니에 RF 리모컨을 등록해서 구글 어시스턴트로 제어하는 방법을 소개해드릴까 합니다. 제가 스위치봇 허브 미니로 모니터를 제어하고 싶었던 부분은 컴퓨터에서 크롬캐스트로 외부 입력을 때에 따라 바꿔야 하는데.. 그때마다 리모컨을 찾는게 너무 불편해서였습니다.  어차피 리모컨은 외부 입력 바꿀 때 빼고는 쓸 일도 없는지라.. 매번 어디로 사라지면 정말 불편해서 이걸 자동화 하고 싶었습니다. 그런데, 처음에 스위치봇 허브 미니를 등록하고 여기에 리모컨을 등록하니.. 구글 홈에 등록된 리모컨이 자동으로 등록이 됩니다. 그런데, 등록된걸 확인해보니 전원 On/Off만 제어되는 것이고, 나머지 버튼은 구글 홈으로 제어가 안되어서..