안녕하세요! QA여행 ( https://qajourney.tistory.com/ ) 입니다.
닷새째 챌린지를 꾸준히 함께해 주고 계신 여러분, 진심으로 환영하고 응원합니다.
어제 우리는 QA의 헌법과도 같은 '7가지 테스팅 원칙'에 대해 배웠습니다.
하지만 이론만으로는 마음에 와닿지 않을 수 있죠.
"그래서 저 원칙들이 실제 업무에서 어떻게 쓰인다는 거지?" 라는 궁금증을 가지셨을 텐데요.
오늘 바로 그 궁금증을 속 시원히 해결해 드리겠습니다.
어제 배운 원칙들이 실제 현업에서 어떤 모습으로 나타나는지, 생생한 사례를 통해 만나보시죠!
사례 1: "이거 다 테스트해주세요"가 불가능한 이유
- 관련된 원칙: #2 완벽한 테스팅은 불가능하다 / #6 테스팅은 정황에 의존적이다
새로운 쇼핑몰 프로젝트의 QA로 투입된 당신. PM(프로덕트 매니저)이 다가와 말합니다.
"이번에 오픈하는 쇼핑몰, 문제없게 꼼꼼히 다 테스트해주세요!"
이때 '네, 알겠습니다!'라고만 대답한다면 우리는 밤을 새워도 모든 테스트를 끝내지 못할 겁니다.
왜냐고요?
- 회원가입: 가능한 모든 ID 조합, 비밀번호 길이, 이메일 형식...
- 상품 검색: 수만 가지 검색어, 필터 조합(가격, 색상, 사이즈...), 정렬 순서...
- 결제: 모든 종류의 신용카드, 간편결제, 쿠폰, 포인트 사용 조합...
이 모든 경우의 수를 테스트하는 것은 현실적으로 불가능합니다.
이때 우리는 2번 원칙 '완벽한 테스팅은 불가능하다' 를 근거로 PM과 논의를 시작해야 합니다.
QA의 실전 대응: "네, 사용자들이 불편함 없이 서비스를 이용하도록 꼼꼼히 보겠습니다.
다만 모든 경우의 수를 테스트하기엔 시간과 자원이 한정적이니,
가장 위험도가 높고 사용자들이 많이 쓸 것으로 예상되는 핵심 기능에 집중하는 것이 좋겠습니다.
예를 들어, '가장 많이 팔리는 상품 카테고리'나 '메인에 노출된 상품의 결제 프로세스'처럼요.
리스크와 우선순위를 정해서 테스트 계획을 공유해 드리겠습니다."

사례 2: 기획서 한 줄이 막아준 야근 한 달
- 관련된 원칙: #3 조기 테스팅은 시간과 비용을 절약한다
새로운 '소셜 로그인' 기능 기획서 리뷰에 참여한 당신.
기획서를 읽어보니, 카카오 로그인 시 사용자의 이메일 정보를 필수로 받아오게 되어 있습니다.
하지만 당신은 경험상 카카오 정책상 사용자가 이메일 제공에 동의하지 않을 수도 있다는 사실을 알고 있습니다.
QA의 실전 대응: "기획자님, 카카오 로그인을 구현할 때 사용자가 이메일 정보 제공에 동의하지 않는 케이스가 있을 수 있습니다.
이 경우 우리 서비스에서는 어떻게 처리할지 정책을 정해야 합니다.
이메일 없이 가입시키거나, 아니면 이메일 제공 동의를 유도하는 화면을 추가해야 할 것 같습니다."
만약 이 논의 없이 개발이 다 끝난 후에 이 문제를 발견했다면 어땠을까요? 이미 만들어진 로직을 수정하고, 관련된 모든 부분을 다시 테스트해야 하는 엄청난 추가 비용(시간, 인력)이 발생했을 겁니다.
기획 단계에서 발견한 '결함' 덕분에 팀의 한 달치 야근을 막은 셈이죠.
이것이 바로 '조기 테스팅' 의 위력입니다.
사례 3: 또 그 기능이야? 유독 버그가 많은 곳
- 관련된 원칙: #4 결함은 특정 모듈에 집중된다
서비스를 운영하다 보면 유독 특정 기능에서만 버그가 계속 발견되는 경험을 하게 됩니다.
예를 들어, 여러 외부 시스템과 연동되는 '쿠폰 할인 금액 계산' 기능처럼요.
- 신규 쿠폰이 추가될 때마다 계산 오류 발생
- 포인트와 중복 사용 시 문제 발생
- 특정 상품 카테고리에서 할인율이 다르게 적용되는 문제
이런 현상을 마주했을 때 우리는 4번 원칙, '결함은 특정 모듈에 집중된다' 를 떠올릴 수 있습니다.
이 '결함 집중 구간(Defect Cluster)'을 파악하고 나면, 다음 배포 시 테스트 자원을 어디에 더 집중해야 할지 명확해집니다.
QA의 실전 대응: "다음 스프린트에서는 '쿠폰' 관련 기능이 안정화될 때까지 리그레션 테스트 범위를 더 넓히고,
다양한 예외 케이스를 추가해서 집중적으로 테스트해야겠습니다."
마무리하며
어떠신가요?
어제 막연하게만 느껴졌던 원칙들이 실제 업무와 연결되니 훨씬 가깝게 느껴지지 않으신가요?
이처럼 테스팅 원칙은 QA가 마주하는 수많은 선택의 순간에 "왜" 그렇게 결정해야 하는지 논리적인 근거를 제시해 주는 강력한 도구입니다.
오늘로 1주차의 모든 진도를 마쳤습니다.
닷새 동안 꾸준히 참여해주신 여러분 자신에게 큰 칭찬을 보내주세요! 정말 수고 많으셨습니다.
내일 6일차에는 <1주차 회고 및 Q&A> 시간을 갖겠습니다. 한 주간 배운 내용을 깔끔하게 정리하고,
여러분이 궁금해하셨던 점들을 짚어보는 시간을 가질 예정이니 편하게 참여해주세요!
그럼, 즐거운 금요일 저녁 보내시고 내일 뵙겠습니다!
'ISTQB 4주 실전' 카테고리의 다른 글
| (2주 1일차) 모든 길은 로마로? 모든 개발은 SDLC로! (97) | 2025.08.18 |
|---|---|
| (1주 6일차) 1주차 회고, 징검다리도 두들겨 보고 건너기 (84) | 2025.08.16 |
| (1주 4일차) QA의 헌법! 7가지 테스팅 원칙 (115) | 2025.08.14 |
| (1주 3일차) 커피, Jira, 그리고 소통 - 현업 QA의 하루 (53) | 2025.08.13 |
| (1주 2일차) 테스팅과 디버깅, 똑같은 거 아닌가요? (56) | 2025.08.12 |