수동 테스트 면접 질문: 실전 답변 10가지

먼저 이 질문 10개를 살펴보고, 솔직하게 설명할 수 있는 업무 경험에 맞춰 예시 답변을 조정하세요. 소프트웨어 테스트 직무 면접 질문에는 요구사항, 입력값, 예상 결과, 선택 이유를 연결해 답하세요.

1. 수량 필드는 어떻게 테스트하시겠어요?

예시 답변: “허용되는 값과 제출 동작을 확인한 뒤, 허용되는 수량과 거부되는 수량, 경계값을 테스트하겠습니다. 정수 범위가 1~10이라면 0, 1, 10, 11을 포함하고 각 값의 예상 결과를 명확히 정하겠습니다.”

2. 동등 분할과 경계값 분석은 어떻게 다른가요?

“동등 분할은 비슷하게 처리될 것으로 예상되는 입력값을 그룹으로 나누는 방법이고, 경계값 분석은 순서가 있는 분할의 경계에 초점을 맞추는 방법입니다. 수량이라면 일반적인 유효값으로 5를 선택하고, 1과 10 주변에서 허용 여부가 바뀌는 지점을 확인하겠습니다.”

3. 테스트 사례에는 무엇이 들어가야 하나요?

“다른 테스터가 확인 절차를 반복할 수 있을 만큼 자세해야 합니다. 결제 절차를 테스트한다면 시작 시점의 장바구니와 계정 상태, 수량, 동작, 예상 주문 총액을 명시하고, 테스트한 빌드에서 관찰한 결과를 기록하겠습니다.”

4. 서로 영향을 주는 비즈니스 규칙은 어떻게 테스트하시겠어요?

“조합을 선택하기 전에 조건과 예상 동작을 나열하겠습니다. 결제하려면 재고가 있고 결제가 승인되어야 한다면 두 조건을 함께 다루고, 재고가 있는 상품의 결제가 거절되는 경우도 포함하겠습니다.”

5. 상태는 언제 중요해지나요?

“같은 동작을 시작 상태를 달리해 테스트하겠습니다. 준비된 장바구니에서 주문을 제출하는 것은 유효할 수 있지만, 결제가 처리 중일 때 다시 제출하면 합의된 중복 제출 규칙을 따라야 합니다.”

6. 결함을 수정한 뒤에는 무엇을 테스트하시겠어요?

“확인 테스트는 수정이 제대로 되었는지 확인하고, 회귀 테스트는 다른 곳에 부정적인 영향이 생겼는지 확인합니다. 수량 10이 거부되던 결함을 수정한 뒤에는 해당 실패를 다시 실행하고, 변경 내용에 따라 주변 수량과 결제 절차를 확인하겠습니다.”

7. 간헐적으로 발생하는 실패는 어떻게 보고하시겠어요?

“조건과 시도 횟수, 시각, 증거를 기록하겠습니다. 결제 절차가 10회 중 2회 실패했다면 그 관찰 결과를 보고하고, 성공한 순서와 실패한 순서를 보존하겠습니다. 추정한 원인을 확인된 사실처럼 제시하지 않겠습니다.”

8. 심각도와 우선순위는 어떻게 다른가요?

“심각도는 영향의 크기이고 우선순위는 언제 수정할지에 관한 것입니다. 영향을 받는 구매 흐름과 사용할 수 있는 우회 방법을 설명한 다음, 제 초기 평가를 최종 판단으로 간주하지 않고 팀과 일정을 논의하겠습니다.”

9. 요구사항이 불명확하면 어떻게 하시겠어요?

“구체적으로 질문하겠습니다. 수량에 2.0을 입력하면 정수 수량으로 인정되나요? 합의된 해석을 기록하고, 선호하는 동작을 조용히 선택하는 대신 그 해석을 테스트 기대 결과에 반영하겠습니다.”

10. 시간이 너무 부족하면 어떻게 하시겠어요?

“구매를 막거나 잘못된 청구를 발생시킬 수 있는 실패부터 확인하고, 테스트하지 못한 부분을 설명하겠습니다. 진행 상황을 공유할 때 테스트한 빌드와 결과, 미확인 항목, 권고 사항을 알려 릴리스 책임자가 판단할 수 있게 하겠습니다.”

기법을 언급하기 전에 범위를 관찰 가능한 동작으로 바꾸세요. 예시 요구사항: 필수 수량 필드에는 1부터 10까지의 정수가 포함될 수 있으며, 양 끝값도 허용됩니다. 유효한 값을 제출하면 해당 수량만큼 정확히 장바구니에 추가됩니다. 유효하지 않은 값을 제출하면 수량 검증 메시지가 표시되고 장바구니는 바뀌지 않습니다. 각 사례를 시작할 때 재고는 충분하고 장바구니는 비어 있다고 가정하세요.

이 연습에서는 빈 입력, 1.5와 같은 소수, “two”와 같은 문자를 거부하기로 합의하세요. 2.0, 앞에 붙은 0, 앞뒤 공백 같은 표기를 허용할지는 별도의 형식 규칙이 필요합니다. 그런 선택을 정수 범위 요구사항에 포함된 것으로 조용히 간주하지 마세요.

숫자 입력을 세 가지 분할로 나누세요. 1보다 작은 정수, 1부터 10까지의 정수, 10보다 큰 정수입니다. 대표값을 선택한 다음 허용 경계에 초점을 맞추세요. 아래 표는 범위 내부 값, 경계 확인, 입력 형식 확인을 함께 보여 줍니다.

말로 답하는 예시: “장바구니를 초기화하고 10을 입력해 한 번 제출한 다음, 장바구니에 상품이 10개 있는지 확인하겠습니다. 다시 초기화한 뒤 11을 입력해 검증 메시지가 표시되고 장바구니가 바뀌지 않는지 확인하겠습니다. 이 방법은 화면에 값이 표시되는 것과 실제로 업데이트가 성공한 것을 혼동하지 않고 상한 허용 경계를 확인합니다.”

인터페이스에서 문자를 입력할 수 없다면 그 동작을 기록하고 지원되는 입력 경로를 테스트하세요. 입력할 수 없었던 값을 제출했다고 주장하지 마세요. 면접관이 재고를 8개로 바꾸면 잠시 멈추고 재고 규칙이 수량 한도와 어떻게 적용되는지 확인하세요.

용어는 ISTQB CTFL v4.0.1 실라버스, Foundation Level 실라버스 팀 작성을 따릅니다. 이 자료의 출처 및 저작권자는 ISTQB와 실라버스 저자들임을 여기에 밝힙니다. 이 가이드의 요구사항과 답변은 설명을 위한 면접 예시입니다.

결과를 결정하는 조건과 그 결과에 도달하는 순서를 구분하세요. 예시 가정: 장바구니에는 유효한 상품이 하나 있습니다. 결제 전에 재고를 확인합니다. 재고가 있을 때만 결제를 요청합니다. 결제가 승인된 뒤에만 주문을 확정합니다. 결제가 거절되면 다시 시도할 수 있도록 장바구니를 유지합니다.

간결한 결정 표에서 결제가 진행될 수 없을 때는 “요청하지 않음”이라고 표시하세요. 그러면 불가능한 조합에도 테스트 결과가 필요한 것처럼 보이지 않습니다.

다음으로 상태를 설명하세요. 준비됨, 결제 처리 중, 결제 실패, 확정됨입니다. 준비됨 → 결제 처리 중 → 결제 실패 → 결제 처리 중 → 확정됨의 순서를 따라가세요. 각 단계에서 화면에 표시되는 상태와 주문이 존재하는지 확인하세요.

결제 처리 중 두 번째로 클릭하는 경우에는 별도의 규칙이 필요합니다. 합의된 동작은 진행 상황을 표시하면서 중복 제출을 무시하는 것이라고 가정하세요. 예상 결과는 결제 시도 한 번과 최종 주문 한 건이지, 두 건이 아닙니다. 제공된 테스트 환경에서 그 결과를 확인하는 데 필요한 증거를 설명하세요. 버튼이 비활성화된 것만으로는 이후 시스템에서 실제로 무슨 일이 일어났는지 확인할 수 없습니다.

소프트웨어 테스트 면접 질문에 답할 때는 두 접근 방식의 관계를 명확히 하세요. 조건 표는 선택지를 정리하고, 상태 순서는 앞선 이벤트에 따라 달라지는 동작을 드러냅니다. 어떤 결과를 결함이라고 판단하기 전에 재시도와 중복 제출에 관한 기대 동작을 면접관에게 확인하세요.

먼저 원래 실패를 밝힌 다음 변경 사항이 영향을 미칠 수 있는 범위를 설명하세요. 예시: 요구사항에서 허용하는데도 빌드 Q-17은 수량 10을 거부합니다. 빌드 Q-18에는 수정 사항이 포함되어 있습니다. Q-18에서 시작 조건을 똑같이 맞춰 기록된 단계를 반복하고, 오류 메시지가 사라졌는지만 보지 말고 장바구니 결과를 확인하세요.

그다음 범위를 좁혀 회귀 테스트 항목을 선택하세요.

• 허용되는 양 끝값인 1과 10, 거부되어야 하는 이웃 값인 0과 11을 확인합니다.
• 끝값만 실수로 허용하는 수정인지 확인하기 위해 5도 테스트합니다.
• 기존 장바구니 항목의 수량을 9에서 10으로 바꾸고 수량과 총액을 확인합니다.
• 해당 항목을 삭제한 뒤 다시 추가해 관련 장바구니 경로를 확인합니다.
• 합의된 결제 절차를 수량 10으로 완료하고 주문 수량을 확인합니다.

개발자가 장바구니 수정에도 공유되는 검증기를 바꿨다면 그 경로를 주의 깊게 확인해야 합니다. 변경이 국한된 경우에는 실패의 영향을 고려하면서 더 적은 항목을 선택할지 논의하세요. 티켓 제목만 보고 추측하지 말고 변경된 구성 요소를 물어보세요.

각 확인 결과를 기록하고 수정 사항 및 빌드와 연결하세요. 수량 10은 이제 작동하지만 11도 허용된다면 새 실패를 보고하세요. 원래 증상이 사라졌다는 이유만으로 모든 테스트를 종료하기에는 충분하지 않습니다. 남아 있는 범위와 차단된 확인 항목을 답변에 덧붙이세요.

면접관에게 팀원에게 전달할 수 있는 보고서를 보여 주세요. 결함 보고서 예시: 수량 요구사항은 양 끝값을 포함해 1~10이지만, 테스트 환경에서 상한값을 거부합니다. 아래 식별자와 관찰 결과는 이 예시에 해당합니다.

ID: QTY-24
제목: 재고가 있는 상품을 추가할 때 수량 10이 거부됨
관찰 일자: 2026-11-05
보고자: Alex, 수동 테스터
상태: 열림
빌드: Q-17
환경: QA 스토어프런트, 데스크톱 브라우저; 정확한 버전 첨부
참조: 요구사항 QTY-01; 테스트 사례 QTY-BOUNDARY-10
사전 조건: 빈 장바구니; 로그인된 테스트 계정; 상품 재고 20개
데이터: 수량 10; 상품 TEST-MUG

단계:
1. TEST-MUG 상품 페이지를 엽니다.
2. 수량에 10을 입력합니다.
3. 장바구니에 추가를 한 번 선택합니다.
4. 검증 메시지와 장바구니를 확인합니다.

예상 결과: 수량 검증 오류가 없고 장바구니에 TEST-MUG 상품 10개가 있음.
실제 결과: 수량 검증 오류가 표시되고 장바구니는 비어 있음.
재현 결과: 장바구니를 매번 초기화했을 때 3회 시도 중 3회 실패.
영향: 고객이 한 번의 동작으로 허용된 최대 수량을 추가할 수 없음.
관찰된 우회 방법: 5개씩 두 번 추가하면 장바구니 수량이 10개가 됨.
제안 심각도: 이 팀의 영향도 척도 기준으로 보통.
제안 우선순위: 대량 주문 프로모션 전에 분류 회의에서 검토.
증거: 메시지 스크린샷, 세션 녹화, 타임스탬프 첨부.

실제 보고서에서는 환경의 자리표시자를 바꾸고 언급한 증거를 첨부하세요. 계정 정보와 녹화물은 팀의 취급 규칙에 맞게 관리하세요. 추정한 원인은 따로 밝히세요. “상한 비교 로직 문제일 가능성”은 조사 단서이지 관찰된 결과가 아닙니다.

영향과 일정은 맥락에 맞게 논의하세요. 우회 방법은 즉각적인 불편을 줄일 수 있지만, 예정된 프로모션으로 인해 수정이 더 시급해질 수도 있습니다. 다른 팀은 서로 다른 평가 명칭을 사용할 수 있습니다. 고객에게 미치는 영향과 시기를 먼저 설명한 다음 팀의 척도에 맞추세요. 개발자가 재현하지 못한다면 티켓 상태를 바꾸기 전에 빌드와 데이터, 계정, 수행 순서를 함께 비교하세요.

불확실한 점을 구체적인 판단 요청으로 바꾸세요. 예시: “티켓에는 고객이 결제를 다시 시도할 수 있다고 되어 있지만, 결제가 거절된 뒤에도 장바구니 예약이 유지되는지는 나와 있지 않습니다. 재시도할 때 재고를 다시 확인해야 하나요?” 답변을 요구사항 옆에 기록하고 예상 결과를 업데이트하세요. 그때까지는 해당 확인을 통과로 처리하지 말고 기대 동작이 미해결 상태라고 표시하세요.

기한이 촉박하면 예상되는 피해와 영향을 받는 기능을 기준으로 순서를 제안하세요. 결제 사례에서는 주문 생성, 결제 실패, 중복 제출, 수량 합계를 먼저 확인합니다. 시간이 남으면 영향이 더 적은 화면 표시 세부 사항을 확인하세요. 설정 의존성 때문에 위험도가 높은 확인이 차단되면, 유용한 독립 테스트를 진행하면서 막힌 부분을 알리세요.

간단한 릴리스 진행 상황 공유에는 네 가지를 담으세요. 무엇을 테스트했는지, 어떤 결과가 나왔는지, 무엇을 알 수 없는지, 어떤 판단이 필요한지입니다.

예시: “Q-18에서 허용 및 거부 수량 확인은 통과했고, 결제가 승인된 결제 절차에서는 예상한 주문이 생성됐습니다. 테스트 결제 설정을 사용할 수 없어 결제 거절 후 재시도는 차단된 상태입니다. 릴리스 전에 설정을 복구하고 재시도 확인을 완료할 것을 권고합니다. 지금 릴리스하면 재시도 경로는 릴리스 책임자가 수용해야 할 명시적인 위험으로 남습니다.”

“실행한 확인에서 실패가 없었다”를 “시스템에 결함이 없다”로 바꾸지 마세요. 통과, 실패, 차단, 미실행 상태를 구분하세요. 의견이 다른 상황에 관한 테스트 직무 면접 질문에는 개발자와 증거를 비교하고, 해결되지 않은 비즈니스 동작을 담당 의사 결정자에게 전달하는 방법을 설명하세요. 누락된 설정을 마련하거나 재시도 규칙을 확인하는 등 실질적인 다음 조치로 마무리하세요.

SayNow AI를 사용해 테스트 판단을 명확하게 말하는 연습을 해 보세요. AI 모의 면접에서는 질문과 후속 질문을 주고받는 음성 대화를 할 수 있으며, 대화 후에는 유창성, 내용 구성, 상황 적합성, 목표 달성도에 관한 점수와 제안을 확인할 수 있습니다.

취업 면접 시나리오를 열기 전에 이 가이드에서 기술적으로 확인한 예시 하나를 준비하세요. 말로 답할 때는 먼저 판단을 말하고, 관련 요구사항을 설명한 다음 예상 결과를 제시하세요. 논란이 된 결함을 조사한 경험처럼 과거 경험을 말할 때는 STAR를 활용하세요. 대화 중 모호한 부분에 관한 질문을 받으면 전체 이야기를 처음부터 다시 시작하지 말고 바로 답하세요.

대화 후에는 피드백에서 바꿀 점 하나를 고르세요. 예상 결과를 앞에서 말하기, 배경 설명 줄이기, 본인이 한 일을 더 분명히 설명하기 등이 있습니다. 그 변화를 염두에 두고 다시 연습하세요. SayNow AI는 기술적 정확성을 확인하지 않습니다. 요구사항을 기준으로, 지식이 있는 테스터와 함께 테스트 판단을 별도로 검토하세요. 말하기 점수는 연습에 관한 피드백으로 활용하세요.

취업 면접 시나리오에서 면접 답변을 연습하세요.

모든 문장을 외우는 대신 조건을 바꿔 마지막으로 한 번 연습하세요. 연습 상대에게 수량 한도를 바꾸거나 우회 방법을 없애 달라고 하거나, 보고된 실패를 뒷받침하는 증거가 무엇인지 물어봐 달라고 하세요. 여러분은 테스트 기대 결과를 조정하고 그에 따른 영향을 설명해야 합니다.

다음 체크리스트로 답변을 검토하세요.

• 듣는 사람이 요구사항과 가정을 파악할 수 있나요?
• 구체적인 테스트 데이터와 관찰 가능한 예상 결과를 제시했나요?
• 명시된 시작 조건을 바탕으로 다른 사람이 결함 보고서를 재현할 수 있나요?
• 변경 후 선택한 테스트가 중요한 이유를 설명했나요?
• 관찰된 결과와 추정 원인, 해결되지 않은 질문을 구분했나요?
• 다음 조치와 정보를 전달받아야 할 사람이 누구인지 밝혔나요?

소프트웨어 테스트 직무 면접 질문을 준비할 때는 기술 예시와 함께 프로젝트 경험 하나도 준비하세요. 본인이 기여한 일과 실제로 관찰한 결과를 설명하세요. 관련 행동 면접 가이드와 STAR 가이드를 활용해 이야기를 핵심에 집중하세요.

수동 테스트 직무 면접 질문에 대한 좋은 답변은 명확한 요구사항을 계획된 입력값, 예상 결과, 근거가 있는 다음 판단과 연결합니다. 수량 사례를 연습하고, 솔직하게 이야기할 수 있는 경험에 맞춰 결함 보고서를 조정한 다음, 선택한 확인 절차 후에도 남는 위험을 설명하세요.