QA · 테스트 엔지니어 기술면접, 내가 쓴 커밋으로 대비하기
QA·테스트 엔지니어 기술면접은 테스트를 많이 짰는지가 아니라, 무엇을 어느 층위에서 검증할지 고를 수 있는지를 봅니다. 느리고 깨지기 쉬운 테스트를 왜 그 층위에 뒀는지, 실패했을 때 원인을 좁힐 수 있는지가 질문거리입니다. 이 페이지는 QA 직군 면접의 조준점을 정리하고, 데브핏(DevFit)이 이용자 본인의 깃허브 커밋에서 그 질문을 어떻게 만들어 내는지 설명합니다.
QA · 테스트 면접에서 면접관이 파고드는 지점
층위를 고른 기준이 있는가
단위로 충분한 검증을 E2E로 올렸는지, 반대로 통합에서만 잡히는 걸 단위로 흉내 냈는지. 테스트 커밋은 «이걸 이 층위에서 검증한 이유»를 부릅니다.
깨지는 테스트를 다뤄 봤는가
고정 대기(sleep), 실행 순서 의존, 공유 상태. 재시도 설정이 붙은 커밋은 «왜 깨졌고 근본 원인은 무엇이었나요»로 이어집니다.
테스트 데이터를 어떻게 만들었는가
픽스처를 공유했는지, 테스트마다 격리했는지, 실 데이터를 썼는지. 격리 실패는 가장 흔한 flaky 원인입니다.
커버리지를 어떻게 해석하는가
숫자가 높은데 단언이 없는 테스트. 커버리지 설정 커밋은 «이 수치가 무엇을 보장하나요»를 묻기 좋은 자리입니다.
내 커밋에서 나올 수 있는 질문
아래는 QA · 테스트 코드에서 자주 만들어지는 형태의 질문입니다. 데브핏(DevFit)은 레포지토리 전체가 아니라 이용자 본인이 작성한 커밋과 diff만 조준해, 질문마다 근거가 되는 커밋·파일 경로를 함께 붙입니다.
- “이 케이스를 E2E로 올리신 이유가 뭔가요? 단위로는 왜 안 됐나요?”
- “이 테스트에 대기 시간이 들어가 있는데, 원래 무엇을 기다리는 건가요?”
- “테스트가 순서에 상관없이 통과하나요? 공유하는 상태가 있나요?”
- “커버리지가 이 수치인데, 빠져 있는 위험한 분기는 어디인가요?”
코드에 “없는 것”도 질문이 됩니다
면접에서는 짠 것만큼 안 짠 것도 물어봅니다. 데브핏은 아래 같은 부재 신호를 결정론적으로 찾아 질문으로 만듭니다.
- 실패 케이스 없이 성공 경로만 있는 테스트 → «예외 경로는 누가 검증하나요?»
- CI에서 돌지 않는 테스트 디렉터리 → «이 테스트는 언제 실행되나요?»
- 단언 없이 호출만 하는 테스트 → «이 테스트는 무엇을 보장하나요?»
자주 다루는 기술
- Playwright
- Cypress
- JUnit
- pytest
- Vitest
- k6
다만 질문은 기술 이름에서 나오지 않습니다. 같은 Playwright를 써도 커밋마다 고른 선택이 다르고, 면접관이 파고드는 건 그 선택입니다. 그래서 데브핏은 기술 스택별 표준 질문지가 아니라, 겨냥한 채용공고 1건과 내 깃허브(GitHub) 커밋을 함께 읽어서 질문을 만듭니다.
QA · 테스트 공고 하나로 시작해 보세요
채용공고 URL을 붙여 넣으면 포지션과 요구 사항을 정리하고, 연결한 레포지토리에서 내가 쓴 커밋을 찾아 예상 질문과 어필 포인트를 만듭니다. 공고 1개가 준비 1회분입니다. 하루 10회까지 무료입니다. 합불 판정이나 지원자 랭킹은 만들지 않고, 최종 판단은 사람이 합니다.
공고 넣고 시작하기QA · 테스트 면접에서 함께 나오는 CS 개념
커밋에서 나온 질문은 대부분 개념 질문으로 이어집니다. 아래 문서는 QA · 테스트 면접에서 그 다음 질문으로 자주 넘어가는 주제입니다.
- 테스트 주도 개발 (TDD, Test Driven Development)
- Spring Boot 테스트 코드 작성
- 클린 코드와 리팩토링 (Clean Code and Refactoring)
- 경쟁 상태 (Race Condition)
- HTTP 상태 코드 (HTTP Status Code)
- 애자일 (Agile)