QA 엔지니어 면접 준비 예시

메아리소프트에서 1,180건의 리그레션을 모두 같은 순서로 실행하니 릴리즈 검증에 5일이 걸렸습니다. 저는 기능 영향도, 과거 반복 결함 빈도, 릴리즈 필수 여부를 기준으로 케이스를 3단계로 나눴습니다. 주문과 결제처럼 사용자 거래에 직접 영향을 주는 경로와 변경 기능의 연관 케이스는 최우선으로 두고, 반복 결함이 적고 영향 범위가 좁은 항목은 뒤 단계에 배치했습니다. 매 회차 변경 목록과 결함 이력을 대조해 범위를 조정했고, iOS와 안드로이드 14종 호환성은 계속 확인했습니다. 그 결과 검증은 3일로 줄고 릴리즈 후 결함은 회차 평균 11건에서 4건으로 감소했습니다. 우선순위는 고정표가 아니라 변경 위험에 따라 갱신해야 한다고 배웠습니다.

메아리소프트에서 주문과 결제의 반복 스모크 테스트가 회차마다 수작업으로 9시간씩 들었습니다. 저는 실행 빈도가 높고 결과를 명확히 판정할 수 있으며, 실패가 나면 사용자 흐름이 막히는 핵심 경로를 우선 골라 Appium 시나리오 156건으로 만들었습니다. 화면 구조나 판단이 자주 바뀌어 탐색이 필요한 항목은 자동화 대상에서 제외하고 수동으로 확인했습니다. CI 야간 실행은 한 번에 42분이 걸리도록 관리했고, 다음 날 결과를 원인 분류와 함께 검토해 실패를 기능 오류와 환경 문제로 나눴습니다. 그 결과 회차당 수동 반복 검증 시간을 9시간 줄였습니다. 자동화 건수보다 실패를 믿고 해석할 수 있는 운영이 중요하다는 점을 배웠습니다.

온바로페이에서 카드와 간편결제 등 9종을 연동할 때 결제 성공만 확인해서는 금액 오류를 놓칠 수 있다고 판단했습니다. 저는 주문 금액, 할인과 취소 조건, 결제 요청액과 결과 금액을 단계별로 대조하고, 승인 거절이나 응답 지연 같은 실패 조건도 포함해 420건의 케이스와 63종의 실패 시나리오를 설계했습니다. 결제사별 규격 차이는 담당자와 월 2회 확인해 기대값에 반영했고, 금액 불일치가 나면 주문 조건과 요청·응답 결과를 같은 순서로 재현하도록 절차를 문서화했습니다. 그 결과 오픈 전에 금액 불일치 결함 7건을 발견해 수정 확인까지 이어갔습니다. 결제 검증은 정상 경로뿐 아니라 예외 조건과 재현 정보가 함께 있어야 완결된다고 배웠습니다.

온바로페이에서 트래픽이 늘 때 결제 응답이 느려지는 구간을 찾기 위해 저는 요청 패턴과 결제 흐름을 나눠 JMeter 시나리오 12종을 구성했습니다. 요청량을 단계적으로 올리며 응답 시간을 조건별로 비교했고, 초당 800건 부하에서 지연이 커지는 구간과 관련 요청 유형을 결과표에 남겼습니다. 단일 최고 처리량만 기록하지 않고 같은 조건에서 반복 측정해 편차도 살폈으며, 지연 구간과 재현 조건을 개발팀에 전달해 커넥션 풀 설정 조정 후 비교할 기준으로 삼았습니다. 월 1회 결과를 누적해 조정 전후를 같은 조건으로 확인할 수 있게 했습니다. 부하 수치 자체보다 재현 가능한 조건과 비교 기준이 개선으로 이어지는 핵심이라고 배웠습니다.

라온커머스의 900여 건은 먼저 변경 기능과 연결된 주문·결제 경로, 과거 영향이 컸던 결함, 릴리즈 필수 흐름을 기준으로 필수 범위에 두겠습니다. 메아리소프트에서도 1,180건을 세 단계로 나눠 변경 위험이 큰 항목부터 실행했고, 반복 결함이 적고 영향 범위가 제한된 항목은 추가 범위로 운영했습니다. 단말 호환성처럼 범위를 줄여도 놓치면 안 되는 검증은 별도 유지 항목으로 두고, 매주 변경 목록과 결함 이력을 대조해 우선순위를 갱신하겠습니다. 누락 위험은 필수 범위의 결과와 직전 회차 결함을 함께 검토해 보완하겠습니다. 기존 방식으로 테스트 기간을 5일에서 3일로 줄인 경험을 바탕으로, 1주 주기에서도 속도와 안전성을 함께 관리하겠습니다.

API 자동화를 실제로 구축한 경험은 아직 없습니다. 다만 메아리소프트에서 Appium으로 주문·결제 사용자 흐름 156건을 자동화하면서 반복 검증과 최종 사용자 경로를 나누는 기준을 세웠습니다. 라온커머스에서는 금액 계산, 주문 상태 전이, 결제 승인·실패 응답처럼 반복성과 판정 기준이 명확한 검증을 API 층에 두고, 화면 표시와 앱 내 실제 이동은 UI 층에서 확인하겠습니다. 먼저 기존 케이스와 API 명세를 대조해 요청 조건, 응답 필드, 상태값, 오류 응답의 기대 결과를 정리하고 우선순위가 높은 경로부터 자동화하겠습니다. 입사 후 첫 3개월 안에 핵심 경로의 설계와 구현을 익혀 UI와 API의 중복 실행을 줄이겠습니다.

메아리소프트에서 Jira 결함의 등록 기준과 심각도 4단계를 정리해 재현 불가 처리 비율을 18%에서 6%로 낮췄습니다. 라온커머스에 적용할 때는 먼저 주문·결제 결함의 재현 불가 분모와 처리 시점을 같은 기준으로 정하고, 누락되는 재현 정보를 확인하겠습니다. 결함마다 앱과 단말 환경, 주문 조건, 결제 수단, 재현 절차, 기대 결과와 실제 결과, 관련 요청 식별 정보를 기록하도록 기준을 두겠습니다. 금액 불일치와 승인 실패는 주문 상태와 결제 결과를 함께 확인해 심각도를 판단하고, 반복 유형은 주기적으로 모아 팀이 개선 항목으로 검토할 수 있게 하겠습니다. 재현 정보의 품질을 지표와 연결해야 결함 관리가 실제 예방으로 이어진다는 점을 배웠습니다.

메아리소프트에서 Appium 야간 실행 실패를 다섯 가지 원인 규칙으로 나누고 분류 결과를 리포트에 자동 첨부했습니다. 라온커머스에서는 먼저 실패를 기능 오류, 환경·기기 문제, 테스트 데이터 문제, 동기화·화면 인식 문제, 실행 기반의 일시 오류로 구분하겠습니다. 로그와 화면 증거를 함께 남기고, 환경 문제는 원인을 기록한 뒤 제한적으로 재실행하며 같은 기능 오류가 다시 나오거나 핵심 경로에서 재현되면 결함으로 등록하겠습니다. 단순히 재실행 후 통과한 결과만으로 종료하지 않고 최초 실패와 재실행 결과를 함께 보겠습니다. 분류 누락 건도 주간 리포트에서 확인해 규칙을 보완하겠습니다. 이런 운영으로 자동화 결과를 판정 가능한 근거로 바꾸겠습니다.

Postman 등을 이용해 API 자동화 테스트를 구축한 경험은 아직 없습니다. 가장 가까운 경험은 온바로페이에서 결제 수단 9종의 연동 케이스 420건을 설계하고, 결제 단계별 금액과 실패 조건을 검증한 일입니다. 저는 각 수단의 요청 조건과 기대 결과를 맞추고, 금액 불일치 결함 7건의 재현 절차를 정리했습니다. 이 경험을 바탕으로 입사 후 첫 달에는 주문·결제 API 명세와 기존 회귀 케이스를 연결해 요청·응답, 상태 전이, 오류 응답의 검증 조건을 정리하겠습니다. 이후 3개월 안에 핵심 결제 경로부터 자동화하고, 실패 결과를 기존 원인 분류 흐름에 연결하겠습니다.

피처 플래그를 이용한 단계 출시나 카나리 배포 중 중단 여부를 판단한 경험은 아직 없습니다. 가까운 경험으로 메아리소프트에서 릴리즈마다 변경 범위와 결함 이력을 확인해 리그레션 우선순위를 조정했고, 회차 평균 640건을 실행하며 출시 전 위험을 관리했습니다. 라온커머스에서는 입사 후 첫 달에 단계 출시 대상 기능과 기존 핵심 경로의 기준 지표를 익히고, 결함과 주문·결제 오류를 관찰할 조건을 정리하겠습니다. 첫 3개월 동안 스쿼드의 단계 출시 절차에 맞춰 지표 변화와 테스트 결과를 기록하고, 사전에 합의된 중단 기준을 적용하는 검증 역량을 갖추겠습니다. 정규 릴리즈 검증과 단계 출시 운영은 구분해 배우겠습니다.

메아리소프트에서 리그레션 범위를 줄일 때 저는 단순히 케이스 수를 덜 실행하기보다 위험도가 낮은 반복 검증을 뒤로 보내고, 거래 흐름과 단말 호환성은 유지하는 방향으로 정리했습니다. 기능 영향도와 반복 결함 빈도, 릴리즈 필수 여부를 기준으로 1,180건을 세 단계로 나누고, iOS와 안드로이드 14종 점검은 별도 필수 항목으로 남겼습니다. 회차마다 변경 기능과 과거 결함을 대조해 우선 실행 범위를 조정하고, 결과를 테스트 계획에 반영했습니다. 그 결과 정규 검증 기간을 5일에서 3일로 줄이면서 호환성 점검은 계속 유지했고, 릴리즈 후 결함은 평균 11건에서 4건으로 감소했습니다. 일정과 품질은 같은 위험 기준으로 논의해야 한다고 배웠습니다.

메아리소프트에서 가이드 23편이 여러 곳에 흩어져 신규 QA가 필요한 절차를 찾기 어려웠습니다. 저는 문서별 내용을 대조해 중복 설명은 합치고, 도메인마다 달라지는 준비·검증 절차는 남겨 6편으로 재구성했습니다. 실무자가 실제로 쓰는 흐름을 기준으로 체크리스트 4종을 만들고, 온보딩 순서에 맞춰 기본 절차부터 배치했습니다. 신규 QA 2명에게 자료를 적용해 이해가 필요한 지점을 보완했고, 분기별 갱신 담당을 정해 변경 사항이 다시 흩어지지 않게 했습니다. 그 결과 독립 테스트 투입 기간은 평균 6주에서 3주로 줄었습니다. 문서는 줄이는 것보다 현장에서 갱신하고 활용할 기준까지 설계해야 효과가 지속된다고 배웠습니다.