페르소나 기반 탐색적 테스팅

TL;DR

테스트 케이스만으로는 실제 사용자 버그의 5%만 잡는다. 급한 교사, IT 초보 조교, 장난꾸러기 학생이 되어 시스템을 괴롭히면 나머지 95%를 찾을 수 있다.

테스트 케이스의 한계

우리는 완벽한 테스트 케이스를 작성했다고 생각했다:

TC-001: 학생 등록
1. "학생 추가" 클릭
2. 이름, 전화번호 입력
3. "저장" 클릭
4. 성공 메시지 확인
✅ PASS

그런데 실제 운영에서는 이런 일이 벌어진다:

  • 급한 교사가 저장 버튼을 10번 연타 → 학생 10명 중복 생성
  • IT 초보 조교가 브라우저 뒤로가기 누름 → 입력 데이터 전부 날아감
  • 장난꾸러기 학생이 이름에 이모지 1000개 입력 → 서버 다운

테스트 케이스는 “정상적인 사용자”만 가정한다. 하지만 실제 사용자는 정상적이지 않다.

페르소나 테스팅이란?

특정 사용자 유형을 연기하면서 시스템을 사용하는 방법이다.

기존 테스팅

"학생 등록 기능이 동작하는가?"

페르소나 테스팅

"급한 교사가 30초 안에 학생 5명을 등록하려고 발버둥칠 때
시스템이 견디는가?"

완전히 다른 질문이고, 완전히 다른 버그를 찾아낸다.

4가지 핵심 페르소나

페르소나 1: 급한 교사 선생님

특징

  • 로딩을 기다리지 않음
  • 모든 버튼을 연타
  • 에러 메시지를 읽지 않음
  • “빨리빨리” 마인드

이렇게 테스트한다

// 일반 테스트
await clickButton("저장");
await waitForLoading();
assert(saved);

// 급한 교사 테스트
for(let i=0; i<10; i++) {
  clickButton("저장");  // 로딩? 그런 거 없음
}
// 서버에 요청 10개가 동시에 날아감

실제 발견한 버그들

  • 저장 버튼 연타 → 중복 데이터 생성
  • 로딩 중 페이지 이동 → 데이터 손실
  • 동시 요청 → 서버 Race Condition
  • 세션 타임아웃 미처리 (5분 후 돌아와서 저장 실패)

페르소나 2: IT 초보 조교

특징

  • 브라우저 뒤로가기가 “취소”라고 생각함
  • 에러 메시지를 이해 못함
  • 실수로 새로고침 자주 누름
  • “어? 이게 뭐지?” 마인드

이렇게 테스트한다

시나리오:
1. 학생 정보 입력 중...
2. "어? 잘못 눌렀나?" → F5 새로고침
3. "어? 다 사라졌네?" → 뒤로가기
4. "어? 페이지가 이상해" → F5 연타

실제 발견한 버그들

  • 새로고침 시 입력 데이터 손실
  • 뒤로가기 시 상태 불일치
  • 불친절한 에러 메시지 (“Error 500” → “잠시 후 다시 시도해주세요”로 개선)
  • 모달 밖 클릭 시 데이터 손실 경고 없음

페르소나 3: 장난꾸러기 학생

특징

  • 시스템 한계를 테스트하고 싶음
  • 이상한 값 입력 시도
  • 다른 학생 데이터 접근 시도
  • “이거 되나?” 마인드

이렇게 테스트한다

-- 이름 입력란에 이런 거 넣어봄
'; DROP TABLE students; --
<script>alert('해킹당함')</script>
😀😀😀😀😀 (이모지 1000개)
ㅋㅋㅋㅋㅋ (한글 자음 1000개)

실제 발견한 버그들

  • SQL Injection 취약점
  • XSS 공격 가능
  • 입력 길이 제한 없음 → 서버 메모리 폭발
  • 권한 검증 누락 (URL 조작으로 다른 학생 데이터 접근)

페르소나 4: 멀티태스킹 학부모

특징

  • 여러 자녀 동시 관리
  • 모바일/PC 동시 접속
  • 여러 브라우저 탭 열어둠
  • “동시에 여러 개” 마인드

이렇게 테스트한다

탭1: 첫째 아이 숙제 확인 중
탭2: 둘째 아이 상담 일정 등록 중
모바일: 셋째 아이 출석 체크 중
→ 모든 탭에서 동시에 저장 버튼 클릭

실제 발견한 버그들

  • 동시 로그인 시 세션 충돌
  • 탭 전환 시 데이터 혼선 (첫째 데이터가 둘째 화면에)
  • 실시간 동기화 안 됨
  • 동시 수정 시 마지막 저장이 모든 걸 덮어씀

탐색적 테스팅 기법

1. 미운 4살 방법 (Opposite Action)

테스트 케이스의 정반대로 행동한다:

정상 동작: 입력 → 확인 → 저장 미운 4살: 저장 → 입력 → 저장 → 취소 → 저장 → 삭제 → 저장

실제로 이렇게 하니 “저장 후 즉시 삭제” 시 DB 트랜잭션 꼬임 발견.

2. 15분 랜덤 QA

타이머 맞춰놓고 15분간 막 써본다:

0-3분: 모든 버튼 클릭
3-6분: 모든 입력란에 이상한 값
6-9분: 브라우저 크기 조절, 뒤로가기
9-12분: 네트워크 끊고 켜기
12-15분: 개발자 도구로 HTML 조작

실제 성과: 15분 만에 평균 3개 버그 발견

3. 트롤링 테스팅

의도적으로 시스템을 괴롭힌다:

  • 모든 API에 동시 요청 100개
  • 파일 업로드에 10GB 동영상
  • 모든 입력란 동시 수정
  • 브라우저 10개 탭에서 같은 작업

발견한 치명적 버그: 파일 업로드 크기 제한 없음 → 서버 디스크 꽉 참

탐색적 테스팅의 효과: 연구 결과

버그 발견율 개선

여러 연구에서 탐색적 테스팅의 효과가 입증되었다:

  • 11% 더 많은 이슈 발견: 탐색적 테스팅이 스크립트 테스팅 대비 평균 11% 더 많은 소프트웨어 오류를 발견한다는 연구 결과가 있다
  • 복잡한 버그 33% 더 발견: 여러 사용자 상호작용이 필요한 복잡한 버그를 33% 더 많이 발견
  • 최대 50% 효과 개선: 일부 연구에서는 기존 방법 대비 50%까지 더 효과적으로 결함을 발견한다고 보고

페르소나 기반 테스팅 효과

실제 사례 연구들:

  • 여행 앱: “Globetrotter Gina”, “Family Planner Frank” 같은 페르소나 적용 후 출시 후 버그 45% 감소
  • 헬스케어 앱: “Caregiver Claire” 페르소나로 약물 추적 혼란 문제 조기 발견, $250K 비용 절감
  • Capgemini 연구: 위험 기반 탐색적 테스팅으로 결함 발견 효율 35% 개선

버그 유형별 효과

IEEE 저널에 발표된 Juha Itkonen 연구팀의 분석:

버그 복잡도 스크립트 테스팅 강점 탐색적 테스팅 강점
Mode 0 (즉시 보이는 결함) ✅ 우수 -
Mode 1 (1회 상호작용) ✅ 우수 -
Mode 2 (2회 상호작용) - ✅ 우수
Mode 3+ (3회 이상) - ✅ 우수

핵심: 복잡한 시나리오일수록 페르소나 기반 탐색적 테스팅이 효과적

페르소나 테스팅 시작하기

1단계: 실제 사용자 관찰

우리 시스템 사용자는 누구인가?

  • 연령대는?
  • IT 숙련도는?
  • 사용 패턴은?
  • 급한 상황이 많은가?

2단계: 페르소나 정의

페르소나: 급한 학원장
특징:
  - 나이: 50대
  - IT 숙련도: 낮음
  - 상황: 학부모 면담 5분 전
  - 목표: 빨리 정보 확인하고 나가야 함
행동 패턴:
  - 로딩 안 기다림
  - 버튼 여러 번 클릭
  - 에러 메시지 안 읽음

3단계: 시나리오 작성

급한 학원장이 학부모 면담 5분 전:
1. 로그인 (비밀번호 3번 틀림)
2. 학생 검색 (이름 틀림, 다시 검색)
3. 출석 현황 확인하려다가 실수로 수정
4. 취소하려고 브라우저 뒤로가기
5. 다시 들어가서 확인
→ 이 과정을 3분 안에

4단계: 실행과 기록

중요한 건 “이상하다”고 느낀 모든 것을 기록하는 것:

  • 버튼이 느리게 반응함
  • 에러 메시지가 이해 안 됨
  • 데이터가 사라짐
  • 페이지가 깨짐

마치며

완벽한 테스트 케이스는 없다. 사용자는 우리가 상상하지 못한 방식으로 시스템을 사용한다.

페르소나 테스팅의 핵심은 “정상적인 사용”이라는 가정을 버리는 것이다.

급한 교사가 되어보고, IT 초보 조교가 되어보고, 장난꾸러기 학생이 되어보자. 그들의 눈으로 시스템을 보면, 숨어있던 버그들이 튀어나온다.

다음에 QA할 때는 테스트 케이스 대신 이렇게 물어보자:

“우리 시스템은 급한 교사의 저장 버튼 10연타를 견딜 수 있는가?”

참고 자료