<div id="readability-page-1" class="page"><div><figure></figure><h2 id="6eaa"><strong>임시 테스팅(Ad-hoc Testing)?</strong></h2><blockquote><p id="3f9c">임시 테스팅이란 미리 정의된 테스트 계획이나 시나리오를 사용하지 않고 직관적이고 즉석으로 테스트를 수행하는 것을 말합니다. <br>이는 사전에 테스트 케이스를 필수적으로 작성하지 않아도 되며, 기능에 대한 이해도가 높지 않은 상태에서도 테스트를 할 수 있다는 것을 의미하기도 합니다.</p></blockquote><p id="1e79">이렇듯 별다른 준비 없이 빠르게 시작할 수 있는 임시 테스팅의 장점은 시간과 효율성이라고 생각합니다.</p><p id="3833">사전에 준비하는 시간없이 바로 테스트가 진행되기 때문에 준비시간 만큼의 시간이 절약되며 문서를 보며 기능을 익히는 것이 아니라 직접 사용해보며 바로 해당 기능에 대한 이해도를 높일 수 있기 때문에 투자 시간 대비 기능 이해도가 높기 때문입니다.</p><p id="47d9">시간에 대한 이점이 있기 때문에 테스트 시간이 충분하지 못한 상황에서 많은 도움을 받을 수 있습니다. 빠르게 전체 기능을 확인할 수 있어서 이슈공유와 수정도 빠른속도로 진행될 수 있습니다. 주요 기능만 빠르게 볼 수도 있고 비즈니스 임팩트가 큰 부분만 집중적으로 볼 수 도 있습니다. <br>내가 원하는 부분을 내가 확인하고 싶은 방식으로 즉흥적으로 수행할 수 있기 때문에 테스트 결과를 얻기 위한 지름길을 내는 방식이라고도 할 수 있겠습니다.</p><p id="dc9e">또다른 이점중에 하나인 효율성은 아래의 글로 간단히 설명할 수 있을 것 같습니다.</p><p id="2958">옛말에 “백번 듣는것 보다 한번 보는게 낫다.”라는 말이 있습니다.</p><p id="b0bf">임시 테스트에 이 말을 빗대어 보자면</p><p id="5807">“백번 명세서 보는것 보다 한번 테스트 하는게 낫다.”라고 할 수 있겠습니다.</p><p id="b70e">글과 이미지로 익힌 정보와 실제 내가 행동하며 얻는 정보의 양은 차이가 있습니다. 또한 복잡도가 높은 기능이라 문서만으로 이해가 쉽지 않다면 더욱더 그럴 것입니다.<br>지금까지의 경험을 토대로 본다면 내가 보고 읽어서 습득한 정보보다 경험을 함으로써 알게되는 정보가 많았으며 질적으로도 우수했습니다. <br>경험 기반 테스팅 이라는 테스트 기법이 있는것 처럼 QA직무에는 내가 가진 경험의 양과 범위가 매우 중요합니다. 그렇기 때문에 시간 투자 대비 정보의 양을 더 많이 습득 하기 위해 임시 테스트를 초기에 수행하는 것은 매우 좋은 전략이라고 할 수 있습니다. 복잡도가 높은 기능도 직접 사용하다보면 머리속에 어느정도 플로우차트가 그려지며 정리가 될 수도 있기 때문입니다.</p><p id="b622">저같은 경우 시간이 부족한 경우나, 일정이 확보되어 사전 준비를 모두 마무리 한 경우 모두 항상 테스트 시작시점에는 임시 테스팅을 진행하여 현재의 기능을 빠르게 파악하고 Critical, Blocker급 이슈들을 공유할 수 있도록 합니다. 이것은 빌드 안정성을 초기에 확보할 수 있고 확인된 이슈들의 정보를 가지고 현재 진행중인 QA기간을 어떻게 분배해서 가져갈지도 판단할 수 있기 때문입니다. 초기에 전반적인 기능 관련된 이슈 라이징(Issue Rising) 을 할 수 있다면 해당 이슈의 수정 시작 시간을 앞당기는데도 도움이 됩니다.</p></div><div><figure></figure><h2 id="27c3"><strong>탐색적 테스팅?(Exploratory testing)</strong></h2><blockquote><p id="33b0">탐색적 테스팅이란 테스트를 진행하며 실시간으로 테스트 결과를 분석하고 그 다음 테스트 방향을 정하여 진행되는 방식을 말합니다. 초기에는 테스트 계획 없이 시작하지만 진행하면서 계획을 수립하거나 조정할 수 있으며 수행과정과 결과를 기록합니다.</p></blockquote><p id="44ad">탐색적 테스팅은 속도보다는 집중적인 테스트에 유리한 방식입니다. 어느 한 부분을 테스트하고 그 과정에서 판단되는 리스크나 예외사항들이 나오면 그것을 확인하기 위해 계속해서 테스트 하고 또다시 확인되는 내용을 분석해서 다른 테스트 진행하는 꼬리에 꼬리를 무는 방식으로 진행됩니다.</p><p id="504a">이렇기 때문에 이전에 임시 테스팅을 진행하셨거나, 테스트 케이스를 통한 테스트를 진행 하셨더라도 예외사항 발견이나 추가 테스트를 진행하여 테스트 커버리지를 넓히는데 도움이 되는 테스트 기법입니다.</p><p id="f151">장점은 역시 뛰어난 문제 발견 능력입니다. <br>한 부분을 집요하게 분석하며 테스트 할 수 있기 때문에 사전에 고려하지 못한 부분을 추가로 확인할 수 있고 그 과정에서 다른 문제점을 발견할 수도 있습니다.</p><p id="9930">여기서 임시테스트와의 차이점이 드러납니다. <br>임시 테스트는 테스트 진행 시 해당 기능에 대한 지식이 충분하지 않아도 진행이 가능하지만 탐색적 테스팅의 경우 해당 기능에 대한 지식이 충분한 상태로 진행을 해야 합니다. <br>이럴경우 내가 가진 정보를 바탕으로 앞서 진행한 것과 다른 테스트방식을 진행 할 수 있게 되지만 정보의 양이 부족할 경우 화면내에 주어진 정보로만 테스트방식을 분석하게 되어 다양한 분기나 입력값을 예측하기 어렵게 됩니다. <br>또한 빠르게 전체 기능을 확인하는 임시 테스트와는 달리 특정 기능만을 집중적으로 테스트하는 방식을 사용합니다. 빠른 이슈 발견이 목적이 아니라 깊이 있는 분석과 테스트를 통한 탐색이 주목적인 것입니다.</p><p id="bdb0">진행자의 경험의 양에 따라서 더 깊고 다양한 분석도 가능하기 때문에 임시 테스팅과 같이 QA로써의 경험이 중요시됩니다. 물론 도메인 경험은 어느직군을 막론하고 중요한 부분이지만 QA는 특정 도메인 지식보다도 다양한 도메인의 지식이 업무를 하는데 더 많은 이점이 있는 것 같습니다. 예전부터 단일 서비스로 시작해서 점점 부가기능을 확대해 나가는 서비스들이 있기 때문에 여러가지 서비스를 경험해보시는 것도 많은 도움이 될 것입니다.</p><p id="27b6">저는 탐색적 테스팅을 계획한 테스트가 완료 되었을 때 추가로 진행하는 편입니다. 이 때 추가로 이슈가 발견되거나 이전에 고려하지 못했던 사용성 이슈가 체크되기도 합니다. <br>후반부에 진행되는 테스트인 만큼 이슈 발견시 수정에 충분한 시간이 확보되지 않을 수 있습니다. 이 때 발견되는 이슈 수정건은 유관부서내에 충분한 정보를 제공해서 배포시 리스크를 판단할 수 있도록 하는 것이 좋습니다.</p></div></div>

29CM 기술블로그 - Medium

테스트를 진행하기 전 우리는 테스트 전략이나 계획을 수립하고 그것을 기반으로 테스트를 진행하게 됩니다. 이러한 상황에서 빛을 발하는 테스트 전략들이 있는데요 그 중 임시 테스팅 (Ad-hoc Testing)과 탐색적 테스팅(Exploratory testing)에 대해서 이야기 해보려고 합니다.
임시 테스팅(Ad-hoc Testing)?
임시 테스팅이란 미리 정의된 테스트 계획이나 시나리오를 사용하지 않고 직관적이고 즉석으로 테스트를 수행하는 것을 말합니다. 
이는 사전에 테스트 케이스를 필수적으로 작성하지 않아도 되며, 기능에 대한 이해도가 높지 않은 상태에서도 테스트를 할 수 있다는 것을 의미하기도 합니다.
이렇듯 별다른 준비 없이 빠르게 시작할 수 있는 임시 테스팅의 장점은 시간과 효율성이라고 생각합니다.
사전에 준비하는 시간없이 바로 테스트가 진행되기 때문에 준비시간 만큼의 시간이 절약되며 문서를 보며 기능을 익히는 것이 아니라 직접 사용해보며 바로 해당 기능에 대한 이해도를 높일 수 있기 때문에 투자 시간 대비 기능 이해도가 높기 때문입니다.
시간에 대한 이점이 있기 때문에 테스트 시간이 충분하지 못한 상황에서 많은 도움을 받을 수 있습니다. 빠르게 전체 기능을 확인할 수 있어서 이슈공유와 수정도 빠른속도로 진행될 수 있습니다. 주요 기능만 빠르게 볼 수도 있고 비즈니스 임팩트가 큰 부분만 집중적으로 볼 수 도 있습니다. 
내가 원하는 부분을 내가 확인하고 싶은 방식으로 즉흥적으로 수행할 수 있기 때문에 테스트 결과를 얻기 위한 지름길을 내는 방식이라고도 할 수 있겠습니다.
또다른 이점중에 하나인 효율성은 아래의 글로 간단히 설명할 수 있을 것 같습니다.
옛말에 “백번 듣는것 보다 한번 보는게 낫다.”라는 말이 있습니다.
임시 테스트에 이 말을 빗대어 보자면
“백번 명세서 보는것 보다 한번 테스트 하는게 낫다.”라고 할 수 있겠습니다.
글과 이미지로 익힌 정보와 실제 내가 행동하며 얻는 정보의 양은 차이가 있습니다. 또한 복잡도가 높은 기능이라 문서만으로 이해가 쉽지 않다면 더욱더 그럴 것입니다.
지금까지의 경험을 토대로 본다면 내가 보고 읽어서 습득한 정보보다 경험을 함으로써 알게되는 정보가 많았으며 질적으로도 우수했습니다. 
경험 기반 테스팅 이라는 테스트 기법이 있는것 처럼 QA직무에는 내가 가진 경험의 양과 범위가 매우 중요합니다. 그렇기 때문에 시간 투자 대비 정보의 양을 더 많이 습득 하기 위해 임시 테스트를 초기에 수행하는 것은 매우 좋은 전략이라고 할 수 있습니다. 복잡도가 높은 기능도 직접 사용하다보면 머리속에 어느정도 플로우차트가 그려지며 정리가 될 수도 있기 때문입니다.
저같은 경우 시간이 부족한 경우나, 일정이 확보되어 사전 준비를 모두 마무리 한 경우 모두 항상 테스트 시작시점에는 임시 테스팅을 진행하여 현재의 기능을 빠르게 파악하고 Critical, Blocker급 이슈들을 공유할 수 있도록 합니다. 이것은 빌드 안정성을 초기에 확보할 수 있고 확인된 이슈들의 정보를 가지고 현재 진행중인 QA기간을 어떻게 분배해서 가져갈지도 판단할 수 있기 때문입니다. 초기에 전반적인 기능 관련된 이슈 라이징(Issue Rising) 을 할 수 있다면 해당 이슈의 수정 시작 시간을 앞당기는데도 도움이 됩니다.
탐색적 테스팅?(Exploratory testing)
탐색적 테스팅이란 테스트를 진행하며 실시간으로 테스트 결과를 분석하고 그 다음 테스트 방향을 정하여 진행되는 방식을 말합니다. 초기에는 테스트 계획 없이 시작하지만 진행하면서 계획을 수립하거나 조정할 수 있으며 수행과정과 결과를 기록합니다.
탐색적 테스팅은 속도보다는 집중적인 테스트에 유리한 방식입니다. 어느 한 부분을 테스트하고 그 과정에서 판단되는 리스크나 예외사항들이 나오면 그것을 확인하기 위해 계속해서 테스트 하고 또다시 확인되는 내용을 분석해서 다른 테스트 진행하는 꼬리에 꼬리를 무는 방식으로 진행됩니다.
이렇기 때문에 이전에 임시 테스팅을 진행하셨거나, 테스트 케이스를 통한 테스트를 진행 하셨더라도 예외사항 발견이나 추가 테스트를 진행하여 테스트 커버리지를 넓히는데 도움이 되는 테스트 기법입니다.
장점은 역시 뛰어난 문제 발견 능력입니다. 
한 부분을 집요하게 분석하며 테스트 할 수 있기 때문에 사전에 고려하지 못한 부분을 추가로 확인할 수 있고 그 과정에서 다른 문제점을 발견할 수도 있습니다.
여기서 임시테스트와의 차이점이 드러납니다. 
임시 테스트는 테스트 진행 시 해당 기능에 대한 지식이 충분하지 않아도 진행이 가능하지만 탐색적 테스팅의 경우 해당 기능에 대한 지식이 충분한 상태로 진행을 해야 합니다. 
이럴경우 내가 가진 정보를 바탕으로 앞서 진행한 것과 다른 테스트방식을 진행 할 수 있게 되지만 정보의 양이 부족할 경우 화면내에 주어진 정보로만 테스트방식을 분석하게 되어 다양한 분기나 입력값을 예측하기 어렵게 됩니다. 
또한 빠르게 전체 기능을 확인하는 임시 테스트와는 달리 특정 기능만을 집중적으로 테스트하는 방식을 사용합니다. 빠른 이슈 발견이 목적이 아니라 깊이 있는 분석과 테스트를 통한 탐색이 주목적인 것입니다.
진행자의 경험의 양에 따라서 더 깊고 다양한 분석도 가능하기 때문에 임시 테스팅과 같이 QA로써의 경험이 중요시됩니다. 물론 도메인 경험은 어느직군을 막론하고 중요한 부분이지만 QA는 특정 도메인 지식보다도 다양한 도메인의 지식이 업무를 하는데 더 많은 이점이 있는 것 같습니다. 예전부터 단일 서비스로 시작해서 점점 부가기능을 확대해 나가는 서비스들이 있기 때문에 여러가지 서비스를 경험해보시는 것도 많은 도움이 될 것입니다.
저는 탐색적 테스팅을 계획한 테스트가 완료 되었을 때 추가로 진행하는 편입니다. 이 때 추가로 이슈가 발견되거나 이전에 고려하지 못했던 사용성 이슈가 체크되기도 합니다. 
후반부에 진행되는 테스트인 만큼 이슈 발견시 수정에 충분한 시간이 확보되지 않을 수 있습니다. 이 때 발견되는 이슈 수정건은 유관부서내에 충분한 정보를 제공해서 배포시 리스크를 판단할 수 있도록 하는 것이 좋습니다.
이렇게 전체 테스트 일정 중 전반부에 실행하는 임시테스트와, 후반부에 실행하는 탐색적 테스팅에 대해 이야기 해봤습니다. 모두 명확한 장점을 가지고 있어서 수행할 경우 많은 이점이 있는 테스트 입니다. 두 테스트 모두 QA의 경험에 영향을 많이 받는다거나, 초기 테스트 계획없이 수행한다 라는 공통점이 있지만 테스트를 진행할 수록 그 형태가 많이 달라지게 되어 사용하게 되는 시점이 갈리게 됩니다.
필요한 시점과 지점에 명확히 사용하여 해당 테스트의 효과를 직접 경험해보실 수 있다면 좋을 것 같습니다 :)
[함께 성장할 동료를 찾습니다]
29CM (무신사)는 3년 연속 거래액 2배의 성장을 이루었습니다. 이러한 배경을 바탕으로 높은 사용자 경험을 제공하면서 비즈니스 성장을 함께 할 동료를 찾습니다. 많은 지원 부탁드립니다!
29CM 채용 페이지 : https://www.29cmcareers.co.kr/
임시 테스팅(Ad-hoc Testing)과 탐색적 테스팅(Exploratory testing)을 활용한 테스트 전략 was originally published in 29CM TEAM on Medium, where people are continuing the conversation by highlighting and responding to this story.

임시 테스팅(Ad-hoc Testing)과 탐색적 테스팅(Exploratory testing)을 활용한 테스트 전략

댓글