열린 공간, 누가바닷컴

Exploratory Testing is :
Simultaneously learning about system while designing and executing tests,
using feedback from the last test to inform the next. 

ET에 대해 잘 모르는 사람에게 ET의 개념을 설명할 때 위의 정의만큼 잘 정리된 것도 없다.

어떤 단계적인 형태를 갖는 단방향 프로세스가 아닌 '하나 또는 여러 세션' 속에서 혹은 '하나 또는 여러 테스트 사이클' 속에서 시시각각 바뀌는 Context를 고려하여 설계, 수행, 학습 등 여러 가지 행위들이 동시적으로 일어난다는 것을 겨우 이해시키고 나면 그 다음 또 의문을 갖는 것이 '학습'에 대한 의미가 무엇이냐, 하는 것이다. 

"요구사항보면 제품에 대해 나오는데 뭔 학습이 필요하지?"
"제품 기획자가 과제 설명회할 때 잘 들었어야지."
"정말 신입들에게 유용한 테스팅 기법이겠네."

ET에서 학습이라는 것은 제품에 대해 무지한 신입 테스터가 제품을 써보면서 어느 정도 제품에 대해 이해하기 위한 정도의 개념이 아니다. 정말 그 정도의 의미로 밖에 이해하지 않는다면 차라리 사용자 매뉴얼을 보고 그대로 따라 사용해봐라, 라고 하는 것이 ET를 수행하는 것보다 훨씬 효과적일 것이다. 제품에 대해 학습한다는 것의 의미는 제품이 동작하는 원리를 안다는 것이고, 제품이 어느 부분에서 취약점을 가지고 있는지를 안다는 것이고, 사용성 관점에서 무엇이 불편하며, 제품이 결함을 일으키는 원인을 알아간다는 것이다. 그 후에는 학습의 대상은 제품 뿐만 아니라 개발자, 사용자, 구매자, 이해관계자 그리고 마켓 등 제품을 둘러싼 모든 영향을 주고 받는 요소에 대한 범위로 까지 확장된다.

이렇게 까지 설명을 해도 '학습'의 의미를 좁은 범위로 한정하는 사람이 있다면, 그 사람은 분명 학습을 하는 방법 자체가 잘못된 것이다. 제대로 된 학습을 통해 의미있는 경험을 한 적이 없기 때문에 그 사람은 학습의 의미를 좁게 보는 것이다. 좋은 질문은 좋은 답을 이끌어낸다. 좋은 테스트 아이디어는 좋은 질문이고, 좋은 학습은 좋은 답이다. 좋은 테스트 아이디어는 유연한 사고체계와 경험, 지식, 스킬을 잘 활용할 줄 알 때 나온다. 실제로 아웃소싱 팀의 테스터들이 Adhoc Test(ET를 수행할 여건이 안되어)를 수행하는 것을 지켜본 일이 있다. 

테스터 A는 UI 상에 보여지는 버튼들을 이용하여 테스트 아이디어들을 도출했다. 버튼들을 한번씩 눌러보고 제대로 동작을 하는지 장애를 일으키지 않는지를 보겠다는 것이다.

테스터 B는 테스터 A의 사고방식의 역방향으로 접근했다. 자신의 과거에 경험했던 장애들을 떠올리며 그런 유형의 장애를 일으킬만한 시나리오들을 세우고는 시행착오를 겪으며 이것 저것 시도하고 있었다.

테스터 C는 좀 엉뚱했다. 내가 제공해준 테스트 파일은 2가지 워드 문서였는데, 굳이 그 워드 문서를 뒤죽박죽 편집해가며 테스트를 하고 있었다.

테스터 D는 한번은 해커의 옷을 입었다가 한번은 학생의 옷을 입었다가 한번은 여성의 옷을 입으며 여러 관점에서 각 User가 수행할 것으로 예상되는 시나리오를 세워 테스트를 하고 있었다.

자, 각각의 테스터는 어떤 학습을 하게 될까?