QA 엔지니어

테스트 기본기

신입에게 실제로 보는 영역입니다. 자동화 툴보다 이쪽이 먼저입니다.

• 테스트 케이스 설계필수

  기능 하나를 두고 정상 경우, 예외 경우, 경계값을 나눠 확인 항목을 뽑을 수 있어야 합니다. 공고에서 가장 자주 요구하는 항목입니다.

• 결함 관리 · 버그 리포팅필수

  개발자가 그대로 따라 해서 문제를 재현할 수 있는 수준으로 써야 합니다. 재현 절차, 기대 결과, 실제 결과, 환경 정보가 기본 형식입니다.

• 테스트 프로세스 이해필수

  단위·통합·시스템·인수 테스트가 각각 무엇을 보는지, 회귀 테스트와 스모크 테스트를 언제 돌리는지 설명할 수 있으면 됩니다.

• 꼼꼼함 · 집요함필수

  역량이라기보다 자질에 가깝지만 공고와 면접에서 가장 반복적으로 확인하는 부분입니다. 반복 업무를 끝까지 놓치지 않고 이상한 지점을 그냥 넘기지 않는 성향을, 겪은 사례로 말할 수 있어야 합니다.

협업 · 도구

QA는 개발·기획·디자인 사이에 서는 자리라 소통 능력이 곧 실력으로 평가됩니다.

• 커뮤니케이션필수

  "안 됩니다"가 아니라 어떤 조건에서 무엇이 어떻게 다른지를 전달해야 합니다. 유관 부서와의 원활한 소통은 거의 모든 공고에 명시됩니다.

• JIRA 등 이슈 트래킹 툴필수

  이슈 등록·상태 변경·필터링 정도면 신입 기준으로 충분합니다. 협업 툴 사용 경험을 묻는 공고가 많습니다.

• 테스트 문서 작성권장

  테스트 계획서, 케이스 목록, 결과 리포트를 남기는 일이 업무의 상당 부분입니다. 스프레드시트로 정리해본 경험이면 시작으로 충분합니다.

• 로그 분석우대

  앱·서버 로그에서 오류 지점을 찾아 개발자에게 넘길 수 있으면 리포트의 질이 달라집니다. 우대사항으로 자주 등장합니다.

테스트 자동화

우대에서 필수로 넘어가는 중인 영역입니다. 신입 지원자 사이에서 가장 크게 벌어지는 지점이기도 합니다.

• Python 또는 JavaScript 기초권장

  자동화 스크립트를 읽고 고칠 수 있는 수준이면 됩니다. 개발 직무만큼의 깊이는 요구하지 않습니다.

• Selenium권장

  웹 자동화의 기본입니다. 브라우저를 열어 로그인하고 값을 입력해 결과를 확인하는 시나리오 하나를 직접 돌려본 경험이면 이야기할 거리가 됩니다.

• Appium우대

  모바일 앱 QA를 노린다면 함께 봅니다. 웹 자동화를 먼저 익힌 뒤 옮기는 순서가 수월합니다.

• SQL우대

  테스트 데이터를 직접 조회하거나 결과를 확인할 때 씁니다. 조회와 조인 정도면 신입 기준으로 충분합니다.

• API 테스트 (Postman 등)우대

  화면 뒤에서 오가는 요청·응답을 확인할 수 있으면 결함의 원인을 훨씬 정확히 좁힙니다.

도메인 이해

무엇을 테스트하느냐에 따라 필요한 배경 지식이 완전히 달라집니다. 지원할 분야를 먼저 정하는 편이 효율적입니다.

• 웹 · 모바일 앱권장

  공고 수가 가장 많은 영역입니다. 브라우저·OS·기기별로 다르게 동작하는 문제를 확인하는 일이 많습니다.

• 게임우대

  플레이 시나리오와 밸런스, 빌드 단위 테스트가 중심이라 다른 도메인과 업무 성격이 꽤 다릅니다.

• 금융 · 핀테크우대

  금융·핀테크 서비스 QA 경험을 우대하는 공고가 따로 있습니다. 정확성 요구가 높은 만큼 처우도 상대적으로 좋은 편입니다.

개발 직무처럼 만들어 보여주는 결과물이 없는 대신, 문서가 포트폴리오 역할을 합니다. 이미 나와 있는 서비스나 본인·팀의 프로젝트를 하나 골라 주요 기능의 테스트 케이스를 설계하고, 실제로 돌려 찾은 결함을 정해진 형식으로 정리하면 됩니다. 결함을 몇 개 찾았는지보다 어떤 기준으로 확인 항목을 뽑았는지가 평가 대상입니다.

• ✓대상 서비스와 테스트 범위를 정한 이유
• ✓정상·예외·경계값을 구분한 테스트 케이스 목록
• ✓재현 절차·기대 결과·실제 결과·환경이 들어간 버그 리포트
• ✓심각도와 우선순위를 나눈 기준
• ✓스프레드시트 또는 노션으로 정리해 링크로 열람 가능하게

위 문서에서 반복되는 확인 항목 몇 개를 골라 자동화합니다. 규모는 작아도 됩니다. 로그인·검색·글쓰기처럼 매번 확인해야 하는 흐름을 Selenium이나 Playwright로 돌리고, 실행 결과를 리포트로 남기는 데까지 가면 충분합니다. 자동화 경험이 우대에서 필수로 넘어가는 중이라 이 항목의 가치가 계속 올라가고 있습니다.

• ✓GitHub 저장소 공개 + README에 실행 방법
• ✓자동화 대상으로 이 시나리오를 고른 이유
• ✓실행 결과 리포트 또는 실행 화면 녹화
• ✓수동으로 하면 몇 분, 자동화하면 몇 초인지 비교

지원할 분야가 정해졌다면 그 도메인의 서비스를 대상으로 범위를 넓혀봅니다. 모바일 앱이면 기기·OS 버전별 차이를, 금융 서비스면 금액 계산과 예외 처리를 집중적으로 봅니다. API 테스트나 로그 분석까지 붙이면 수동 테스터가 아니라 원인을 좁힐 줄 아는 지원자로 읽힙니다.

• ✓도메인 특성상 반드시 확인해야 하는 항목 정리
• ✓기기·브라우저·OS 조합을 나눈 테스트 매트릭스
• ✓API 요청·응답 확인 또는 로그로 원인을 좁힌 사례
• ✓테스트 결과를 요약한 최종 리포트