개념
같은 기능, 다른 질문
"회원 가입" 기능 하나를 두 사람이 맡았다고 하자.
소프트웨어 테스터는 이렇게 일한다. 기획서의 화면과 실제 화면을 비교한다. 이메일 형식이 틀리면 오류 메시지가 뜨는지 본다. 비밀번호 규칙을 어기면 막히는지 본다. 중복 이메일로 가입하면 어떻게 되는지 본다. 이상한 것을 발견하면 재현 절차·실제 결과·기대 결과·환경을 적어 결함을 등록한다. 수정되면 다시 확인한다.
테스트 엔지니어는 먼저 다른 질문을 한다. 이 기능의 위험은 어디에 있는가? 가입 API는 화면 검증을 우회해 직접 호출될 수 있는가? 이메일 중복 판정은 대소문자를 구분하는가? 동시에 같은 이메일로 두 요청이 들어오면? 비밀번호 규칙의 경계값은? 가입 후 DB에 비밀번호가 평문으로 남지는 않는가? 이 질문들을 동등 분할·경계값·결정표·상태 전이로 정리해 테스트 조건과 케이스 로 만들고, 화면·API·DB·로그를 모두 확인 대상에 넣는다.
두 사람 다 테스트를 한다. 차이는 질문의 출발점이다.
| 소프트웨어 테스터 | 테스트 엔지니어 | |
|---|---|---|
| 출발점 | 주어진 요구사항과 화면 | 요구사항 + 시스템 구조 + 위험 |
| 핵심 동사 | 확인한다, 기록한다, 재확인한다 | 분석한다, 설계한다, 설명한다 |
| 확인 범위 | 주로 화면 | 화면 + API + 데이터베이스 + 로그 |
| 결과물 | 실행 기록, 결함 보고서, 회귀 결과 | 테스트 조건·케이스 설계서, 테스트 수트, 품질 상태 설명 |
| 잘했다는 기준 | 빠짐없이, 재현 가능하게 | 적은 케이스로 위험을 많이 줄였는가 |
소프트웨어 테스터 — 품질 정보의 출발점
테스터 단계를 "단순 반복 업무"로 낮춰 보는 시각이 있지만, 이 단계에서 만드는 것은 조직의 모든 품질 판단의 원료다. 재현되지 않는 결함 보고서는 개발 시간을 태우고, 빠진 환경 정보는 엉뚱한 수정을 부른다.
이 단계의 핵심 업무는 네 가지다.
- 요구사항과 화면 비교 — 기능이 의도대로 동작하는지 확인한다
- 결함 보고 — 재현 조건, 실제 결과, 기대 결과, 환경, 증거를 기록한다
- 실행 환경 준비 — 테스트 데이터, 계정, 기기, 브라우저를 준비한다
- 재시험과 회귀 — 수정된 결함과 영향받을 수 있는 기존 기능을 다시 확인한다
필요한 기술은 테스팅 기본 원리(모듈 1), 테스트 케이스 작성과 실행, 명확한 결함 보고서(모듈 6), Jira 같은 이슈·테스트 관리 도구(모듈 22), 웹·모바일 서비스의 기본 구조 이해다.
테스트 엔지니어 — 요구사항을 시험 가능한 구조로
테스트 엔지니어 단계의 핵심 업무도 네 가지다.
- 분석 — 요구사항과 시스템 구조를 분석해 검증할 조건을 찾는다
- 설계 — 경계값, 결정표, 상태 전이 같은 설계 기법으로 케이스와 수트를 만든다(모듈 3)
- 화면 밖 확인 — API, 데이터베이스, 로그를 함께 확인한다(모듈 9, 12)
- 설명 — 테스트 결과와 결함을 분석해 제품 위험과 품질 상태를 설명한다
추가로 필요한 기술은 테스트 분석·설계 기법, API 테스트와 HTTP 기초, SQL과 데이터 검증, 시스템·서비스 구조 이해, 테스트 수트와 회귀 범위 관리다.
경계선은 "설계와 설명"에 있다
두 단계의 경계는 경력 연수가 아니다. 3년 차 테스터도 있고 1년 차 테스트 엔지니어도 있다. 경계를 넘었는지는 다음 세 질문으로 판단한다.
| 질문 | 테스터의 답 | 테스트 엔지니어의 답 |
|---|---|---|
| 이 기능에 케이스가 왜 23개인가? | "기획서 항목마다 하나씩 만들었다" | "입력 3개를 동등 분할해 경계값을 붙였고, 조합은 결정표로 7개로 줄였다" |
| 화면에서 정상인데 정말 정상인가? | "화면에 성공이라고 떴다" | "API 응답 코드와 DB 레코드, 감사 로그까지 확인했다" |
| 이번 릴리스 품질은 어떤가? | "결함 12건 중 10건 해결됐다" | "남은 2건 중 1건이 결제 경로에 있어 이 조건에서만 위험하다" |
세 질문에 오른쪽처럼 답할 수 있으면 테스트 엔지니어 단계에 들어선 것이다.
입문부터 3년 차까지 — 단계별로 쌓을 것
| 시기 | 목표 | 쌓아야 할 결과물 |
|---|---|---|
| 입문(0~6개월) | 기능 확인과 결함 보고를 혼자 할 수 있다 | 재현 가능한 결함 보고서 30건 이상, 회귀 체크리스트 1개 |
| 1년 차 | 한 기능 범위를 독립적으로 맡는다 | 한 기능의 테스트 케이스 세트, 회귀 범위 판단 기록 |
| 2년 차 | 설계 기법으로 케이스를 줄이고 근거를 댄다 | 기법을 명시한 설계서, API·DB 확인이 포함된 케이스 |
| 3년 차 | 품질 상태를 위험의 언어로 설명한다 | 릴리스 품질 요약, 결함 분석 보고서 |
3년 차 무렵에는 공통 기반을 넘어 어느 경로로 넓힐지 고민이 시작된다. 이때 기반이 탄탄할수록 선택지가 많다.
학습 순서 — 이 커리큘럼 안에서
공통 기반은 이 커리큘럼의 스테이지 1~3이 그대로 대응한다.
- 테스팅 기초: 모듈 1(본질·레벨·유형), 모듈 6(결함 생명주기와 보고)
- 문서화 실습: 모듈 2(요구사항 읽기), 모듈 3(설계 기법), 모듈 7(테스트 문서·관리)
- 도구 실습: 모듈 22(Jira·TestRail 등 관리 도구)
- 화면 밖으로: 모듈 9(개발 지식), 모듈 12(API 테스트)
실무에서 왜 필요한가
두 단계를 구분하지 못하면 성장이 정체된다. 3년 동안 테스터 단계의 일만 반복한 사람은 "경력 3년"이지만 테스트 엔지니어 공고에서 설계 질문에 답하지 못한다. 반대로 결함 보고를 대충 넘기고 설계만 하려는 엔지니어는 개발팀의 신뢰를 잃는다 — 재현 안 되는 보고서 한 장이 설계서 열 장의 신뢰를 깎는다.
팀 입장에서도 이 구분은 업무 배분의 기준이 된다. 새로 온 사람에게 처음부터 설계를 맡기지 않고, 테스터 단계의 결과물 품질을 먼저 확인한 뒤 설계로 넘기는 것이 안전하다.
채용시장에서의 위치
국내 공고에서 "QA 엔지니어"는 대부분 테스트 엔지니어 단계 이상을 기대한다. "API 테스트", "SQL 활용", "테스트 설계 기법"이 우대사항이 아니라 자격요건에 들어가 있다면 확실하다. 반대로 "QA 테스터", "검증 인력", "테스트 수행"이라는 표현은 테스터 단계 자리다.
신입이 테스트 엔지니어 공고에 지원할 때 가장 효과적인 증거는 설계 근거가 적힌 테스트 케이스 세트 하나와 화면 밖까지 확인한 결함 보고서 하나다.