탐색적 테스트

탐색적 테스트는 사람이 소프트웨어를 직접 써 보면서 문제를 찾습니다. 무엇을 해 볼지 미리 다 적어 두지 않습니다. 하나를 해 보고 그 결과를 보며 다음에 해 볼 것을 정합니다. 미리 적어 둔 절차로는 떠올리지 못한 문제를 찾으려는 것입니다.

쉽고 빠른 이해

무슨 일을 하나 — 사람이 소프트웨어를 직접 만지며 문제를 찾습니다. 쿠폰 입력 칸에 쿠폰을 넣어 본 사람이 「같은 쿠폰을 또 넣으면 어떻게 되지」를 이어서 해 보는 식입니다. 앞의 결과가 다음 시도를 정합니다.

왜 하나 — 미리 적어 둔 테스트는 적은 사람이 떠올린 경우만 확인합니다. 아무도 떠올리지 못한 경우는 그 목록에 없습니다. 써 보며 알게 된 것을 바로 다음 시도에 쓰면 그런 경우에 닿을 수 있습니다.

어떻게 도나

이번에 살펴볼 범위를 한두 줄로 정합니다
정해 둔 짧은 시간 동안 써 보며 결과를 보고 다음 시도를 고릅니다
해 본 것과 찾은 문제를 적어 둡니다. 끝나면 팀에 알립니다

대가 — 결과가 하는 사람의 경험에 크게 기댑니다. 무엇을 안 해 봤는지가 남지 않아서 얼마나 확인했는지 재기 어렵습니다. 같은 확인을 매번 똑같이 되풀이하는 일에는 맞지 않습니다. 기능이 막 나와 동작이 아직 굳지 않았을 때, 자동 테스트는 다 통과하는데 미덥지 않을 때 잘 맞습니다.

상세

이 절은 쇼핑몰 주문 화면의 할인 쿠폰 입력 칸 하나를 가지고 탐색적 테스트를 봅니다. 쿠폰 번호를 넣고 적용 버튼을 누르면 서버가 쿠폰을 확인합니다. 맞는 쿠폰이면 주문 금액에서 할인을 뺍니다.

진료실의 의사는 미리 뽑아 둔 질문 목록만 차례로 읽지 않습니다. 환자가 배가 아프다고 하면 어디가 언제부터 아픈지를 이어서 묻습니다. 대답 하나가 다음 질문을 정합니다. 탐색적 테스트도 이렇게 돌아갑니다 — 앞의 시도 결과가 다음 시도를 정합니다.

소프트웨어를 시험하는 데에는 이와 반대인 방식도 있습니다. 테스트 케이스는 무엇을 넣으면 무엇이 나와야 하는지를 적은 확인 항목 하나입니다. 「쿠폰 WELCOME 을 넣으면 주문 금액에서 천 원이 빠진다」가 테스트 케이스 하나입니다.

스크립트 테스트는 이런 항목을 미리 써 두고 하나씩 따라 하는 방식입니다. 무엇을 확인할지를 테스트하기 전에 다 정합니다. 그래서 누가 해도 같은 순서로 같은 것을 봅니다. 대신 목록을 쓴 사람이 떠올리지 못한 경우는 끝까지 아무도 안 봅니다.

탐색적 테스트는 무엇을 확인할지 정하는 때를 테스트하는 도중으로 옮깁니다. 써 보면서 배웁니다. 배운 것으로 다음 시도를 짜고, 짠 것을 바로 해 봅니다. 배우기와 짜기와 해 보기가 따로 나뉜 단계가 아닙니다. 한 사람 안에서 같이 돌아갑니다.

쿠폰 입력 칸에서 건진 버그

아래 표는 테스터 한 사람이 쿠폰 입력 칸을 탐색한 과정입니다. 한 줄이 시도 하나입니다. 마지막 칸은 그 결과를 보고 떠올린 다음 시도입니다.

해 본 것	본 것	그래서 다음에 해 볼 것
맞는 쿠폰을 넣는다	주문 금액에서 할인이 빠진다	같은 쿠폰을 한 번 더 넣어 본다
같은 쿠폰을 또 넣는다	「이미 적용된 쿠폰」이 뜬다	화면이 막는 것 말고 서버도 막는지 본다
적용 버튼을 아주 빠르게 두 번 누른다	할인이 두 번 빠진다	버그로 적고 다시 일으키는 순서를 남긴다
쿠폰 번호 뒤에 빈칸을 붙인다	「없는 쿠폰」이 뜬다	소문자로도 넣어 본다
쿠폰 번호를 소문자로 넣는다	적용된다	물어볼 거리로 적어 두고 넘어간다

셋째 줄이 이 탐색에서 건진 버그입니다. 화면은 같은 쿠폰을 두 번 넣는 것을 막았습니다. 그런데 버튼을 빠르게 두 번 누르자 적용 요청 두 개가 거의 같이 서버에 닿았습니다. 서버는 둘 다 통과시켰습니다.

이 시도는 둘째 줄의 결과에서 나왔습니다. 화면이 중복을 막는 것을 본 뒤에야 「서버도 막나」라는 물음이 생겼습니다. 미리 적어 둔 목록에는 「버튼을 빠르게 두 번 누른다」가 없었습니다. 앞의 결과가 다음 시도를 정한다는 것이 이런 뜻입니다.

넷째·다섯째 줄은 버그라고 단정하지 못한 경우입니다. 소문자는 받아 주면서 뒤에 붙은 빈칸은 지우지 않았습니다. 버그인지 일부러 정한 동작인지는 테스터 혼자 정할 수 없습니다. 그래서 팀에 물어볼 거리로 적어 둡니다.

다음 시도를 고르는 요령

다음에 무엇을 해 볼지를 테스터의 감에만 맡기지는 않습니다. 버그가 자주 숨는 곳을 알려 주는 어림 규칙이 있습니다. 경험에서 나온 이런 규칙을 테스트 휴리스틱이라고 부릅니다. 늘 맞지는 않습니다. 그래도 어디부터 건드릴지 빨리 고르게 해 줍니다.

아래 표는 흔히 쓰는 요령 다섯을 쿠폰 칸에 대 본 것입니다.

요령	쿠폰 칸에서 해 본다면
경계를 건드린다	최소 주문 금액 바로 아래와 바로 위에서 쿠폰을 써 본다
비우거나 넘치게 넣는다	빈 값을 넣는다 · 아주 긴 문자열을 넣는다
같은 일을 겹쳐 한다	버튼을 빠르게 두 번 누른다 · 창 두 개에서 같은 쿠폰을 쓴다
중간에 끊는다	적용 도중 뒤로 가기를 누른다 · 네트워크를 끊는다
순서를 바꾼다	쿠폰을 먼저 넣고 나서 장바구니 상품을 뺀다

첫 줄은 경계값 분석이라는 이름으로 따로 정리된 기법입니다. 값이 바뀌는 경계 바로 옆에서 버그가 잘 난다는 경험에서 나왔습니다. 셋째 줄은 앞 표에서 버그를 건진 바로 그 시도입니다.

목표와 시간을 정하고 시작하기

써 보며 정한다고 해서 아무 데나 누르는 것은 아닙니다. 탐색적 테스트는 대개 시작하기 전에 무엇을 살펴볼지를 한두 줄로 정합니다. 이 목표를 테스트 차터라고 부릅니다. 차터는 범위만 정할 뿐 무엇을 어떤 순서로 할지는 정하지 않습니다.

쿠폰 칸이라면 차터는 「쿠폰 적용을 살펴본다. 금액 경계와 중복 사용을 중심으로」쯤이 됩니다. 테스트 케이스처럼 나와야 할 값까지 적지는 않습니다. 어디를 볼지만 정해서 시간이 엉뚱한 데로 새지 않게 합니다.

시간도 미리 끊습니다. 보통 한두 시간 안팎으로 정해 둡니다. 그동안 차터 하나만 붙들고 탐색합니다. 시간이 다 되면 멈춥니다.

세션은 차터 하나와 정해 둔 시간을 묶은 한 덩이입니다. 세션 기반 테스트는 탐색적 테스트를 이런 세션 단위로 나눠 굴리는 방식입니다.

탐색하는 동안에는 해 본 것과 본 것을 짧게 적어 둡니다. 버그를 찾으면 다시 일으키는 순서를 함께 적습니다. 세션이 끝나면 찾은 것과 아직 못 본 곳을 팀에 알립니다. 못 본 곳은 다음 세션의 차터가 됩니다.

아래 그림은 세션 하나가 도는 모양입니다. 결과를 보고 다음 시도를 고르는 고리가 시간이 다 될 때까지 되풀이됩니다.

flowchart TD
    A["차터를 정한다"] --> B["해 본다"]
    B --> C["결과를 본다"]
    C --> D{"이상한가"}
    D -->|"그렇다"| E["다시 일으키는 순서를 적어 둔다"]
    D -->|"아니다"| F["다음에 해 볼 것을 고른다"]
    E --> F
    F -->|"시간이 남았다"| B
    F -->|"시간이 다 됐다"| G["찾은 것과 못 본 곳을 팀에 알린다"]

애드혹 테스트·스크립트 테스트와 가르는 선

탐색적 테스트는 미리 적은 절차가 없다는 점 때문에 애드혹 테스트와 자주 섞입니다. 애드혹 테스트는 목표도 기록도 없이 떠오르는 대로 눌러 보는 방식입니다. 아래 표는 세 방식을 무엇을 언제 정하느냐로 가릅니다.

	스크립트 테스트	탐색적 테스트	애드혹 테스트
무엇을 볼지	미리 다 적는다	범위만 정하고 하면서 고른다	정하지 않는다
다음 시도	목록이 정한다	앞의 결과가 정한다	떠오르는 대로 한다
기록	목록이 곧 기록이다	해 본 것과 찾은 것을 적는다	대개 남기지 않는다
잘 찾는 문제	목록에 적은 경우가 깨진 것	아무도 떠올리지 못한 경우	우연히 닿은 것

탐색적 테스트와 애드혹 테스트를 가르는 것은 배운 것을 다음 시도에 쓰느냐입니다. 쿠폰 표에서 셋째 시도는 둘째 결과를 보고 골랐습니다. 떠오르는 대로 누르기만 하면 이런 이어짐이 생기지 않습니다.

자동 테스트와 나누는 일

테스트 자동화는 확인을 코드로 짜 두고 기계가 되풀이해 돌리게 하는 일입니다. 탐색적 테스트는 이것을 대신하지 않습니다. 자동 테스트는 이미 확인한 것이 계속 맞는지를 지킵니다. 탐색적 테스트는 아직 아무도 확인하지 않은 것을 찾습니다.

둘은 서로 이어집니다. 탐색에서 찾은 버그는 고친 뒤 자동 테스트로 남깁니다. 앞의 이중 할인이라면 「같은 쿠폰 적용 요청 두 개를 동시에 보내도 할인은 한 번만 빠진다」를 확인하는 테스트가 됩니다.

그 테스트는 코드를 바꿀 때마다 다시 돌아갑니다. 이렇게 변경 뒤에 옛 확인을 다시 돌려 되던 것이 깨지지 않았는지 보는 것을 회귀 테스트라고 합니다. 탐색은 새 버그를 찾습니다. 회귀 테스트는 찾은 버그가 돌아오지 못하게 막습니다.

되풀이할 확인을 기계에 넘기면 사람은 기계가 못 하는 일에 시간을 쓸 수 있습니다. 결과를 보고 이상하다고 느끼는 일입니다. 그 느낌으로 다음 시도를 고르는 일도 사람이 합니다.

잘 맞는 때와 안 맞는 때

탐색적 테스트가 값을 하는 때는 미리 적기 어려운 경우가 많을 때입니다. 아래 표가 그런 때를 모았습니다.

잘 맞는 때	까닭
기능이 막 나와 동작이 아직 굳지 않았다	나와야 할 값을 미리 적기 어렵다
테스트할 시간이 짧다	목록을 쓰는 시간 없이 바로 써 본다
자동 테스트는 다 통과하는데 미덥지 않다	목록 밖의 경우를 본다
여러 기능이 맞물리는 흐름을 본다	조합이 너무 많아 다 적을 수 없다

반대로 같은 확인을 정해진 대로 되풀이해야 하는 일에는 맞지 않습니다. 아래 표가 그런 때입니다.

안 맞는 때	까닭
같은 확인을 변경마다 똑같이 해야 한다	사람이 매번 하면 느리고 빠뜨린다. 자동 테스트가 맡을 일이다
무엇을 확인할지 미리 적은 계획을 내야 한다	계획이 하면서 정해져서 미리 낼 수 없다
하는 사람이 그 소프트웨어를 거의 모른다	다음 시도를 고를 실마리가 적다

탐색적 테스트의 결과는 하는 사람에 따라 크게 갈립니다. 같은 차터를 받아도 그 분야를 오래 다룬 테스터가 더 많은 문제를 찾습니다. 하는 사람의 경험이 곧 다음 시도를 고르는 힘이기 때문입니다.

얼마나 확인했는지 재기도 어렵습니다. 해 본 것은 적어 두지만 안 해 본 것은 어디에도 남지 않습니다. 세션이 끝날 때 못 본 곳을 따로 알리는 것이 이 빈틈을 메우려는 방법입니다.

탐색적 테스트

상세

쿠폰 입력 칸에서 건진 버그

다음 시도를 고르는 요령

목표와 시간을 정하고 시작하기

애드혹 테스트·스크립트 테스트와 가르는 선

자동 테스트와 나누는 일

잘 맞는 때와 안 맞는 때

관련 항목

탐색적 테스트와 견주는 테스트 방식

탐색적 테스트의 하위 종류

탐색적 테스트를 굴리는 단위와 기록

다음 시도를 고르는 데 쓰는 기법

탐색에서 찾은 버그를 지키는 테스트

사람이 손으로 진행하는 다른 검사

탐색적 테스트가 자주 건지는 결함

쿠폰 예의 이중 할인을 막는 설계

탐색적 테스트가 속하는 상위 분류