이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
제가 졸업 프로젝트에서 앱을 만들며 테스트 케이스를 설계해본 경험이 있습니다.
저는 그때 "사용자가 실제로 하는 행동"을 기준으로 테스트를 짭니다. 처음엔 제가 제가 의도한 정상 흐름만 테스트한 적이 있었습니다. 그러자 막상 사용자가 예상 못 한 순서로 누르자 앱이 멈췄습니다.
그 실패 뒤 저는 "사용자가 정상 흐름을 벗어나는 경우"까지 테스트 케이스에 넣었습니다. 빈 값을 넣거나, 버튼을 빠르게 두 번 누르거나 하는 경우요. 테스트 케이스 설계에서 저는 "내가 의도한 대로"가 아니라 "사용자가 실제로 할 법한 모든 행동"을 기준으로 삼습니다. 사용자는 늘 내 예상을 벗어나기 때문입니다. 그게 진짜 품질을 지키는 길이라고 배웠습니다.
제가 졸업 프로젝트에서 테스트 케이스를 설계해본 경험이 있습니다.
저는 그때 "잘못되면 영향이 큰 곳"을 가장 중요한 기준으로 봅니다. 처음엔 제가 모든 기능을 똑같은 비중으로 테스트하려다, 시간이 모자라 정작 중요한 곳을 얕게 본 적이 있었습니다.
그 실패 뒤 저는 기능마다 "여기가 깨지면 사용자에게 얼마나 큰일인가"를 따져, 위험이 큰 곳을 먼저 촘촘히 테스트했습니다. 핵심 거래 기능은 깊게, 부가 기능은 가볍게요. 테스트 케이스 설계에서 저는 모든 곳을 똑같이 보는 게 아니라, 위험과 영향이 큰 곳에 더 많은 케이스를 배치하는 것을 기준으로 삼습니다. 한정된 시간으로 품질을 지키려면 어디에 집중할지 정해야 한다는 걸 배웠습니다.
제가 팀 프로젝트에서 테스트 케이스를 설계해본 경험이 있습니다.
저는 그때 "기능이 원래 무엇을 하기로 했는지"를 기준으로 테스트를 짭니다. 처음엔 제가 완성된 화면만 보고 테스트를 만든 적이 있었습니다. 그러자 "원래 되기로 한 기능인데 빠진 것"을 놓쳤습니다. 화면에 없으니 테스트도 안 한 것입니다.
그 실패 뒤 저는 처음 정한 요구사항 문서를 펼쳐놓고, 항목 하나하나가 제대로 동작하는지를 테스트로 확인했습니다. 테스트 케이스 설계에서 저는 "만들어진 것"이 아니라 "만들기로 한 것"을 기준으로 삼습니다. 그래야 빠진 기능까지 잡아낼 수 있기 때문입니다. 요구사항과 결과물을 맞대보는 게 품질 검증의 출발이라고 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 품질보증 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.