수동 테스트

수동 테스트는 사람이 소프트웨어를 직접 써 보며 제대로 동작하는지 확인합니다. 화면을 누르고 값을 넣은 뒤 나온 결과를 눈으로 보고 판단합니다. 확인하는 일을 코드에 맡기지 않고 사람이 맡는다는 점이 자동 테스트와 갈립니다.

쉽고 빠른 이해

무슨 일을 하나 — 사람이 프로그램을 손으로 써 보며 맞게 도는지 봅니다. 회원 가입 화면에 이메일을 넣고 가입 버튼을 누른 뒤 환영 문구가 뜨는지 눈으로 보는 식입니다.

왜 하나 — 확인하는 코드를 짜기 전에도 바로 해 볼 수 있습니다. 버튼 글자가 잘린 것처럼 미리 적어 두지 않은 이상한 점도 사람은 보는 순간 알아챕니다.

어떻게 도나

무엇을 넣고 무엇을 누를지, 어떤 결과가 나와야 하는지 정합니다
사람이 정한 순서대로 조작하고 나온 결과를 봅니다
기대와 다르면 버그로 적습니다. 고친 뒤에 다시 확인합니다

대가 — 같은 확인을 되풀이할 때마다 사람의 시간이 똑같이 듭니다. 하는 사람과 그날 컨디션에 따라 결과가 조금씩 갈립니다. 코드를 고칠 때마다 전부 다시 해 보기에는 너무 느립니다.

상세

이 절은 쇼핑몰의 회원 가입 화면 하나를 가지고 수동 테스트를 봅니다. 사람이 이 화면을 어떻게 확인하는지 먼저 보고, 같은 확인을 코드에 맡기면 무엇이 달라지는지를 뒤에서 견줍니다.

새집에 들어가기 전에 집주인은 집을 한 바퀴 돌며 점검합니다. 문을 열고 닫아 봅니다. 수도꼭지도 틀어 봅니다. 벽지에 얼룩이 없는지 눈으로 훑습니다. 점검표에 없던 삐걱거리는 마루도 밟는 순간 알아챕니다.

수동 테스트는 사람이 소프트웨어를 직접 조작하는 시험입니다. 결과가 맞는지도 사람이 판단합니다. 회원 가입 화면이라면 사람이 이메일과 비밀번호를 넣고 가입 버튼을 누릅니다. 그리고 「가입을 환영합니다」가 뜨는지, 받은 편지함에 확인 메일이 왔는지를 직접 봅니다.

이 방식은 미리 준비할 것이 거의 없습니다. 기능이 막 만들어진 날에도 바로 해 볼 수 있습니다. 확인하는 코드를 짜고 돌릴 환경을 꾸리기 전에, 써 보는 것만으로 시작합니다.

사람이 맡는 세 가지 일

수동 테스트 한 번은 세 동작으로 나뉩니다. 조작과 관찰과 판정입니다.

조작은 값을 넣고 버튼을 누르는 일입니다. 관찰은 화면에 뜬 문구, 받은 메일, 바뀐 숫자처럼 나온 결과를 보는 일입니다. 판정은 본 결과가 맞는지 틀린지 정하는 일입니다.

판정에는 기준이 있어야 합니다. 결과가 맞는지 가려 주는 기준을 테스트 오라클이라고 부릅니다. 「가입하면 환영 문구가 뜬다」고 적어 둔 기대 결과가 오라클 노릇을 합니다. 수동 테스트에서는 사람의 눈과 상식도 오라클이 됩니다.

이 마지막 점이 수동 테스트의 가장 큰 쓸모입니다. 기대 결과에 「버튼 글자가 잘리면 안 된다」까지 적어 두는 사람은 드뭅니다. 그래도 사람은 글자가 잘린 버튼을 보는 순간 이상하다고 느낍니다. 적어 두지 않은 문제까지 판정에 들어옵니다.

테스트 케이스를 따라 하는 방식

수동 테스트를 진행하는 방식은 크게 둘로 나뉩니다. 먼저 미리 적은 절차를 따라 하는 쪽입니다.

테스트 케이스는 무엇을 하면 무엇이 나와야 하는지 적은 확인 항목 하나입니다. 수동 테스트에서는 이것을 코드가 아니라 표 한 장으로 적습니다. 테스트하는 사람은 절차를 한 줄씩 따라 합니다. 그리고 본 것을 마지막 칸에 적습니다.

칸	예
사전 조건	가입한 적 없는 이메일 하나를 준비한다
절차	가입 화면을 열고 이메일과 비밀번호를 넣은 뒤 가입 버튼을 누른다
기대 결과	「가입을 환영합니다」가 뜨고 확인 메일이 온다
실제 결과	환영 문구는 떴지만 확인 메일이 오지 않았다

표의 마지막 줄이 기대 결과와 다릅니다. 이렇게 기대에서 어긋난 동작을 결함이라고 부릅니다. 흔히 버그라고 부르는 것이 이것입니다.

테스트하는 사람은 찾은 결함을 버그 리포트로 남깁니다. 버그 리포트는 무엇을 했고 무엇을 기대했으며 무엇이 나왔는지를 적는 기록입니다. 따라 한 순서도 함께 적습니다. 개발자가 그 순서대로 해서 같은 결함을 다시 일으켜 봐야 원인을 찾을 수 있기 때문입니다.

미리 적은 절차를 따라 하는 방식을 스크립트 테스트라고 합니다. 누가 해도 같은 것을 같은 순서로 봅니다. 그래서 무엇을 확인했고 무엇을 안 했는지가 기록으로 남습니다.

써 보며 다음 시도를 고르는 방식

다른 하나는 절차를 미리 다 적지 않는 방식입니다. 이 방식을 탐색적 테스트라고 부릅니다. 하나를 해 보고, 그 결과를 보며 다음에 해 볼 것을 정합니다.

가입 화면이라면 이렇게 이어집니다. 이메일을 대문자로 넣어 본 사람이 「같은 주소를 소문자로 넣으면 두 번 가입되나」를 떠올립니다. 이런 시도는 미리 적은 표에 잘 들어 있지 않습니다.

두 방식 모두 사람이 조작하고 판정하므로 수동 테스트에 듭니다. 다른 것은 무엇을 확인할지 정하는 때입니다. 스크립트 테스트는 시작하기 전에 정합니다. 탐색적 테스트는 하는 도중에 정합니다.

결함을 고친 뒤의 확인

수동 테스트는 결함을 한 번 찾고 끝나지 않습니다. 결함 하나가 고쳐지기까지 사람은 같은 확인을 여러 번 되풀이합니다.

flowchart TD
    A["사람이 절차대로 조작하고 결과를 본다"] --> C{"기대 결과와 같은가"}
    C -->|같다| D["통과로 적는다"]
    C -->|다르다| E["버그 리포트를 남긴다"]
    E --> F["개발자가 고친다"]
    F --> G["고친 기능과 멀쩡하던 기능을 다시 확인한다"]
    G --> C

그림 아래쪽의 고리가 사람의 시간을 먹습니다. 개발자가 고친 뒤에는 고친 기능만 보면 끝나지 않습니다. 고친 코드가 멀쩡하던 다른 기능을 망가뜨렸을 수도 있기 때문입니다.

이렇게 멀쩡하던 기능이 여전히 멀쩡한지 다시 확인하는 일을 회귀 테스트라고 합니다. 회귀 테스트를 손으로 하면 고칠 때마다 같은 표를 처음부터 다시 따라 해야 합니다. 기능이 백 개면 백 개를 다시 눌러 봅니다. 고리가 한 번 돌 때마다 같은 시간이 듭니다.

자동 테스트와 가르는 선

같은 확인이라도 사람이 하느냐 코드가 하느냐에 따라 비용이 드는 모양이 바뀝니다. 아래에서 두 쪽을 나란히 놓습니다.

자동 테스트는 조작과 판정을 코드로 적어 두고 기계가 돌리는 시험입니다. 가입 요청을 보내는 코드와, 응답에 환영 문구가 들어 있는지 검사하는 코드를 함께 적습니다. 한 번 적어 두면 몇 번이든 사람 손 없이 다시 돌립니다.

	수동 테스트	자동 테스트
조작과 판정	사람이 한다	코드가 한다
처음 한 번	싸다. 바로 써 보면 된다	비싸다. 확인하는 코드를 짜야 한다
되풀이할 때	매번 같은 시간이 든다	사람 시간이 거의 안 든다
판정이 늘 같은가	사람과 그날 컨디션에 따라 갈린다	같은 코드는 같은 판정을 낸다
잘 잡는 문제	적어 두지 않은 이상한 점	적어 둔 기대에서 벗어난 결과

갈림의 핵심은 둘째 줄과 셋째 줄입니다. 수동 테스트는 시작이 싸고 되풀이가 비쌉니다. 자동 테스트는 시작이 비싸고 되풀이가 쌉니다. 그래서 같은 확인을 몇 번 돌릴지에 따라 어느 쪽이 싼지가 뒤집힙니다.

코드를 합칠 때마다 빌드와 시험을 자동으로 돌리는 방식을 지속적 통합이라고 합니다. 영어로 CI(Continuous Integration, 지속적 통합)라고 줄여 부릅니다. 하루에 수십 번 코드가 합쳐지면 그때마다 사람이 손으로 확인할 수는 없습니다. CI 안에서 매번 도는 시험은 자동 테스트가 맡습니다.

백엔드에서 하는 수동 테스트

수동 테스트는 화면이 있는 프로그램에서만 하는 일이 아닙니다. 화면이 없는 서버 쪽에서는 모습이 조금 다릅니다.

다른 프로그램이 서버 기능을 부를 수 있게 열어 둔 창구를 API(Application Programming Interface, 애플리케이션 프로그래밍 인터페이스)라고 합니다. 백엔드 개발자는 새 API 를 만들면 curl 이나 Postman 같은 요청 도구로 직접 한 번 불러 봅니다. 앞의 가입 화면이라면 가입 API 에 이메일과 비밀번호를 담아 요청을 보냅니다. 그리고 돌아온 상태 코드가 201(새로 만들어졌다는 뜻)인지, 응답 본문에 새 회원 번호가 들어 있는지를 눈으로 읽어 판단합니다.

이것도 사람이 조작하고 사람이 판정하므로 수동 테스트입니다. 같은 요청을 매번 손으로 보내고 있다면, 그 확인은 자동 테스트로 옮길 때가 된 것입니다.

쓰는 때와 드는 비용

수동 테스트가 값을 하는 일은 대개 세 종류입니다. 아래 표가 그 셋을 예와 함께 놓습니다.

맞는 일	예
처음 한 번 해 보는 확인	막 만든 기능이 대충이라도 도는지
사람 눈으로만 판정하는 확인	글자가 잘리지 않았나 · 문구가 자연스러운가 · 쓰기 편한가
자주 바뀌는 화면의 확인	디자인이 매주 바뀌는 시안 단계의 화면

둘째 줄의 「쓰기 편한가」는 코드로 적기 어려운 판정입니다. 실제 사용자에게 써 보게 하고 어디서 헤매는지 보는 시험을 따로 사용성 테스트라고 부릅니다.

반대로 맞지 않는 일도 분명합니다. 자주 되풀이해야 하는 확인과 결과가 숫자처럼 딱 떨어지는 확인입니다. 회귀 테스트가 대표적입니다. 사람이 같은 표를 수십 번 따라 하면 지루해집니다. 지루해지면 놓칩니다.

그래서 많은 팀이 둘을 섞어 씁니다. 자주 돌리고 판정이 분명한 확인은 자동 테스트로 옮깁니다. 사람의 눈이 필요한 확인과 처음 해 보는 확인은 수동 테스트로 남깁니다. 손으로 하던 확인을 코드로 옮기는 일을 테스트 자동화라고 합니다.

수동 테스트

상세

사람이 맡는 세 가지 일

테스트 케이스를 따라 하는 방식

써 보며 다음 시도를 고르는 방식

결함을 고친 뒤의 확인

자동 테스트와 가르는 선

백엔드에서 하는 수동 테스트

쓰는 때와 드는 비용

관련 항목

수동 테스트를 진행하는 방식

수동 테스트를 대신하는 자동화 수단

수동 테스트가 쓰고 남기는 기록

수동 테스트로 자주 하는 시험 종류

수동으로 API 를 불러 볼 때 쓰는 도구

수동과 자동의 몫을 나누는 기준

수동 테스트가 속하는 상위 분류