버그 배시

버그 배시는 여러 사람이 같은 시간에 모여 한 제품을 함께 써 보며 버그를 찾는 행사입니다. 시간은 짧게 정해 두고 그동안만 집중합니다. 평소 테스트를 맡지 않는 사람도 함께합니다. 출시 전에 많은 눈으로 제품을 빠르게 훑어보려고 엽니다.

쉽고 빠른 이해

무슨 일을 하나 — 팀이 시간을 맞춰 모여서 다 같이 제품을 써 보고 버그를 찾습니다. 출시를 앞둔 결제 화면을 열두 명이 오후 한때 동시에 만져 보는 식입니다.

왜 하나 — 한 사람은 늘 비슷한 길로만 제품을 씁니다. 쓰는 습관이 다른 사람이 여럿 모이면 아무도 안 가 본 길이 짧은 시간에 많이 밟힙니다.

어떻게 도나

1. 무엇을 볼지, 어디서 써 볼지, 버그를 어떻게 적을지 미리 정합니다
2. 정한 시간 동안 다 같이 써 보며 찾은 버그를 한 목록에 올립니다
3. 끝나면 겹쳐 올라온 버그를 합치고 무엇부터 고칠지 정합니다

대가 — 많은 사람의 시간을 한꺼번에 씁니다. 같은 버그가 여러 번 올라옵니다. 적어 올린 글의 질도 사람마다 다릅니다. 찾기만 하고 고칠 시간이 없으면 목록만 길어집니다.

상세

이 절은 음식 주문 앱이 새 결제 화면을 내보내기 이틀 전에 연 버그 배시 하나를 따라갑니다. 준비하고, 진행하고, 정리하는 순서로 봅니다. 마지막에는 하는 일이 비슷한 다른 방식들과 견줍니다.

이사 들어가기 전날 온 가족이 새 집을 돌아봅니다. 아버지는 수도꼭지를 하나씩 틀어 봅니다. 아이는 방문을 전부 여닫아 봅니다. 고장 난 곳을 찾으면 쪽지를 붙여 둡니다. 혼자 돌 때보다 짧은 시간에 훨씬 많은 곳이 살펴집니다.

버그는 소프트웨어가 만든 사람의 의도와 다르게 움직이는 것입니다. 버그 배시는 이 버그를 여러 사람이 한꺼번에 찾는 행사입니다. 같은 시간에 같은 제품을 써 보고 찾은 것을 한 목록에 모읍니다.

이렇게 하는 까닭은 사람마다 제품을 쓰는 습관이 달라서입니다. 개발자는 자기가 만든 기능을 만든 순서대로 써 봅니다. 고객 문의를 받는 사람은 고객이 자주 막히는 길로 먼저 갑니다. 습관이 다른 사람이 여럿 모이면 한두 사람이 안 가 본 길이 짧은 시간에 많이 밟힙니다.

그래서 참가자를 일부러 넓게 부릅니다. 개발자와 QA(Quality Assurance, 품질 보증) 담당 말고도 기획자, 디자이너, 고객 지원 담당이 함께합니다. 결제 화면 배시에는 열두 명이 모였습니다.

시작 전에 정해 두는 셋

버그 배시는 한두 시간이면 끝납니다. 대신 그 전에 정해 둘 것이 셋 있습니다. 이게 빠지면 참가자가 시작하고 나서 한참을 헤맵니다.

첫째는 범위입니다. 범위를 좁히면 참가자가 한 기능을 깊게 봅니다. 넓히면 기능끼리 맞물리는 데서 나는 버그까지 닿습니다. 결제 화면 배시는 이번에 바뀐 화면에 범위를 맞췄습니다.

범위 안에서 사람마다 주제를 하나씩 따로 주기도 합니다. 「쿠폰과 포인트를 같이 쓴다」처럼 무엇을 살펴볼지 한 줄로 적은 것입니다. 이런 주제 문장이 테스트 차터입니다. 주제를 나눠 주면 열두 명이 모두 같은 버튼만 누르는 일을 막습니다.

둘째는 써 볼 서버입니다. 버그 배시는 고객이 쓰는 운영 서버에서 하지 않습니다. 열 명 넘는 사람이 이상한 값을 넣고 가짜 주문을 쏟아내기 때문입니다. 그래서 운영과 같은 모양으로 따로 꾸린 서버를 씁니다.

이런 시험용 서버를 통틀어 테스트 환경이라고 부릅니다. 테스트 환경은 쓰임새에 따라 여럿 둘 수 있습니다.

스테이징 환경은 테스트 환경 가운데 출시 직전 모습을 운영과 똑같이 올려 둔 것입니다. 결제 화면 배시는 스테이징 환경에서 했습니다. 이틀 뒤 고객이 볼 화면을 그대로 미리 써 봐야 출시 뒤에 날 버그를 앞당겨 찾을 수 있습니다.

참가자는 모두 같은 빌드를 씁니다. 빌드는 소스 코드를 돌릴 수 있는 프로그램으로 만든 결과물입니다. 사람마다 다른 빌드를 쓰면 같은 버그를 두고도 서로 다른 화면을 보게 됩니다.

셋째는 버그를 적는 곳입니다. 버그 트래커는 버그를 하나씩 글로 올리고, 누가 맡아 언제 고쳤는지까지 따라가는 도구입니다. 여기 올린 버그 글 한 건 한 건이 신고입니다. 배시용 목록을 따로 만들어 두면 끝난 뒤 이번 배시에서 나온 것만 골라 볼 수 있습니다.

버그를 적는 양식

평소 버그를 안 적던 사람이 많이 오므로 적을 칸을 미리 정해 줍니다. 가장 중요한 칸은 버그를 다시 일으키는 순서입니다. 이 순서를 재현 단계라고 합니다. 고치는 사람이 그 버그를 자기 눈으로 다시 봐야 원인을 찾을 수 있습니다.

아래 표는 결제 화면 배시에서 쓴 양식과, 한 참가자가 채운 신고 하나입니다.

칸이 정해져 있으면 고치는 사람이 참가자를 찾아가 다시 묻지 않아도 됩니다. 기대한 결과와 일어난 결과를 나눠 적게 하는 것도 같은 까닭입니다. 무엇이 틀렸는지를 적은 사람과 읽는 사람이 같게 이해합니다.

정한 시간 동안 써 보기

시간은 미리 끊어 둡니다. 이렇게 일에 쓸 시간을 먼저 정해 두는 것이 타임박스입니다. 길게 잡으면 집중이 흐트러집니다. 참가자의 다른 일도 밀립니다. 결제 화면 배시는 오후 두 시부터 한 시간 반으로 잡았습니다.

참가자는 대개 정해진 절차 없이 써 봅니다. 먼저 하나를 해 봅니다. 그 결과를 보고 다음에 해 볼 것을 고릅니다. 이런 방식이 탐색적 테스트입니다. 버그 배시는 탐색적 테스트를 여러 사람이 한꺼번에 하는 셈입니다.

버그를 찾으면 올리기 전에 목록부터 훑습니다. 같은 버그가 벌써 올라와 있을 수 있기 때문입니다. 아래 그림은 참가자 한 사람이 시간 안에 되풀이하는 일입니다.

flowchart TD
    A["범위 안에서 써 본다"] --> B{"이상한 것을 찾았나"}
    B -->|"아니다"| A
    B -->|"찾았다"| C{"목록에 이미 있나"}
    C -->|"있다"| D["그 글에 본 것을 덧붙인다"]
    C -->|"없다"| E["양식대로 새로 올린다"]
    D --> F{"시간이 남았나"}
    E --> F
    F -->|"남았다"| A
    F -->|"다 됐다"| G["정리로 넘어간다"]

이미 있는 버그에 덧붙이는 것도 쓸모가 있습니다. 다른 기기에서도 난다는 정보가 붙으면 원인을 좁히기 쉬워집니다. 새로 올리면 같은 버그가 두 줄이 되어 정리할 일만 늘어납니다.

진행을 맡는 사람을 한 명 두기도 합니다. 진행자는 참가자의 질문을 받습니다. 시험용 서버가 멈추면 개발자를 부릅니다. 여러 사람이 같은 버그를 계속 올리면 「이미 알려진 문제」라고 모두에게 알립니다.

끝난 뒤의 정리

시간이 끝나면 목록을 정리합니다. 겹친 신고를 하나로 합칩니다. 버그가 아니라 원래 그렇게 만든 동작이면 설명을 달고 닫습니다. 결제 화면 배시에서는 마흔 건이 올라와 스물다섯 건이 남았습니다.

남은 버그마다 얼마나 급한지 매겨 고칠 순서를 정합니다. 이 일을 트리아지라고 합니다. 응급실에서 환자를 위급한 순서로 가르는 일을 부르던 말을 가져왔습니다.

순서를 정할 때 보는 축은 대개 둘입니다. 심각도는 버그가 사용자에게 얼마나 큰 해를 주는지입니다. 고칠 일정과 상관없이 버그가 낳는 결과만 봅니다.

우선순위는 그 버그를 얼마나 먼저 고칠지입니다. 심각도에 더해 출시 일정과 그 화면을 고객이 얼마나 자주 지나가는지까지 보고 정합니다. 그래서 둘은 보통 같이 가지만 늘 같지는 않습니다.

아래 표는 결제 화면 배시에서 남은 버그 셋을 이렇게 가른 것입니다.

둘째 줄은 심각도가 중간인데도 우선순위를 높여 출시 전에 고치기로 했습니다. 결제 버튼이라 고객이 반드시 지나가는 화면이기 때문입니다. 셋째 줄은 심각도가 낮고 고객이 주문을 마치는 데 지장이 없어서 우선순위를 뒤로 밀었습니다.

출시 전에 고친 버그는 고친 뒤 다시 확인합니다. 고친 내용은 테스트 코드로도 남겨 둡니다. 코드를 바꿀 때마다 옛 확인을 다시 돌려 고친 버그가 돌아오지 않았는지 보는 것을 회귀 테스트라고 합니다.

비슷한 방식과 가르는 선

사람이 직접 제품을 써 보며 문제를 찾는 방식은 버그 배시 말고도 여럿 있습니다. 아래 표는 그중 다섯을 누가, 얼마 동안, 무엇을 주로 찾느냐로 가릅니다.

도그푸딩은 자기 회사 제품을 직원이 날마다 쓰는 일입니다. 버그 배시와 달리 행사가 아니라 일상입니다. 그래서 짧게 훑어서는 안 보이는 불편까지 쌓여 드러납니다.

베타 테스트는 출시 전에 일부 고객에게 먼저 써 보게 하는 일입니다. 회사 안 사람은 회사 안의 기기와 습관으로만 씁니다. 바깥 고객에게 맡기면 그 밖의 환경에서 나는 문제가 나옵니다.

버그 바운티는 바깥 사람이 보안 구멍을 찾아 알려 주면 상금을 주는 제도입니다. 이름이 비슷해 버그 배시와 자주 섞입니다. 버그 배시는 팀 안의 짧은 행사입니다. 상금도 보안도 본론이 아닙니다.

잘 맞는 때와 대가

버그 배시가 값을 하는 때는 사람 눈으로 볼 것이 한꺼번에 많이 생겼을 때입니다. 그런 때를 셋 모았습니다.

여는 시점도 중요합니다. 출시 바로 전날 열면 큰 버그가 나와도 고칠 시간이 없습니다. 그래서 고칠 여유를 며칠 남기고 엽니다. 결제 화면 배시를 출시 이틀 전으로 잡은 것도 이 때문입니다.

버그 배시에도 대가가 있습니다. 흔히 드는 것은 넷입니다.

마지막 줄 때문에 버그 배시는 테스트 자동화를 대신하지 않습니다. 자동 테스트는 이미 확인한 것이 계속 맞는지를 코드를 바꿀 때마다 지킵니다. 버그 배시는 사람이 직접 써 봐야 보이는 것을 짧은 시간에 넓게 훑습니다.

참가자에게 상을 거는 팀도 있습니다. 가장 심각한 버그를 찾은 사람에게 주는 식입니다. 찾은 개수만으로 상을 주면 사소한 신고가 늘어나서 정리할 일만 많아집니다. 그래서 개수보다 심각도를 봅니다.

관련 항목

버그 배시가 속하는 상위 분류

QA와 테스트 · 수동 테스트 · 소프트웨어 테스트 · 테스트 전략

버그 배시를 진행하는 방식

탐색적 테스트 · 세션 기반 테스트 · 테스트 차터 · 타임박스 · 테스트 휴리스틱

버그 배시와 견주는 테스트 방식

도그푸딩 · 베타 테스트 · 버그 바운티 · 사용성 테스트 · 인수 테스트 · 애드혹 테스트

버그 배시를 준비하는 환경과 도구

테스트 환경 · 스테이징 환경 · 빌드 · 버그 트래커 · 이슈 트래커

버그 배시가 남기는 기록

버그 리포트 · 재현 단계 · 중복 버그 · 알려진 문제

찾은 버그의 고칠 순서를 정하는 기준

트리아지 · 심각도 · 우선순위 · 버그 수명 주기

찾은 버그가 돌아오지 못하게 막는 테스트

회귀 테스트 · 테스트 자동화 · 스모크 테스트 · 단위 테스트