개념
테스트 레벨(레슨 3)이 "어느 범위에서" 테스트하는가라면, 테스트 유형은 "무엇을" 확인하는가다.
기능 테스트 vs 비기능 테스트
- 기능 테스트(Functional): 소프트웨어가 무엇을 하는가. "로그인 버튼을 누르면 로그인이 된다", "할인율이 정확히 계산된다" 같은, 요구사항에 적힌 동작 자체를 본다.
- 비기능 테스트(Non-functional): 소프트웨어가 그 일을 얼마나 잘 하는가. 응답 속도(성능), 동시 사용자를 얼마나 견디는가(부하), 뚫리지 않는가(보안), 쓰기 편한가(사용성), 장애 없이 오래 도는가(신뢰성) 등. 비기능 테스트는 스테이지 5에서 깊게 다룬다 — 지금은 "기능은 되는데 느려서, 혹은 뚫려서 문제"인 경우가 별도 범주라는 것만 가져간다.
두 유형은 독립적으로 실패할 수 있다. 로그인 기능이 정확히 동작해도(기능 테스트 통과) 로그인에 10초가 걸리면(비기능 테스트 실패) 사용자는 이탈한다.
회귀 테스트 vs 확인 테스트
결함을 수정한 뒤에는 두 가지를 따로 확인해야 한다. 이름이 비슷해서 자주 섞이지만 목적이 다르다.
| 확인 테스트 (Confirmation / Re-testing) | 회귀 테스트 (Regression) | |
|---|---|---|
| 질문 | 이 결함이 진짜 고쳐졌는가? | 이 수정이 다른 곳을 망가뜨리지 않았는가? |
| 대상 | 원래 실패했던 그 케이스 | 수정과 관련 있을 수 있는 주변 기능 전체 |
| 놓치면 생기는 일 | 안 고쳐진 버그를 고쳐졌다고 착각 | 새 버그(회귀 결함)를 릴리즈에 포함 |
예시: "할인 쿠폰이 결제 화면에서 적용 안 됨" 결함을 고쳤다고 하자.
- 확인 테스트: 그 쿠폰으로 다시 결제해서 실제로 할인이 적용되는지 확인.
- 회귀 테스트: 쿠폰 계산 로직을 고치면서 건드린 코드가, 쿠폰과 무관한 다른 계산(배송비, 포인트 적립 등)에 영향을 주진 않았는지 확인.
확인 테스트만 하고 회귀 테스트를 생략하면, "그 버그는 고쳤는데 다른 버그가 새로 생겼다"는 흔한 사고로 이어진다. 반대로 매번 전체를 다 회귀 테스트하면 시간이 너무 오래 걸린다 — 그래서 변경의 영향 범위를 판단하는 능력(무엇을 회귀 테스트 범위에 넣을지) 이 중요하다. 이 판단은 모듈 2의 "요구사항 변경 시 영향 범위 분석"과도 이어진다.
실무에서 왜 필요한가
실무에서 핫픽스(급하게 배포하는 수정)일수록 시간에 쫓겨 확인 테스트만 하고 회귀 테스트를 건너뛰기 쉽다. 이게 반복되면 "버그 하나 고칠 때마다 버그 하나가 새로 생긴다"는 평판으로 이어진다. 반대로 매번 전체 회귀 테스트를 고집하면 배포가 느려져 팀 전체의 속도를 떨어뜨린다. 실무 QA의 판단력은 "이 변경이 어디까지 영향을 줄 수 있는가"를 코드 변경 범위와 아키텍처 이해를 바탕으로 좁히는 데서 나온다 — 이건 모듈 9(QA를 위한 개발 지식)에서 코드를 읽는 능력과 직접 연결된다.
실습 과제
과제 1 — 유형 분류하기 (10분)
다음 각 활동이 기능/비기능/회귀/확인 중 무엇에 해당하는지 적는다.
- 로그인 API에 초당 500 요청을 보내 응답 시간을 측정한다.
- "장바구니 수량 변경" 버그를 고친 뒤, 그 케이스를 다시 실행해 고쳐졌는지 본다.
- 검색 필터 기능을 새로 추가한 뒤, 기존 검색 정렬 기능이 여전히 잘 되는지 다시 돌려본다.
- 회원가입 폼에 이메일 형식이 아닌 값을 넣었을 때 거부되는지 확인한다.
과제 2 — 회귀 범위 설계하기 (15분)
"장바구니에 담긴 상품 수량이 최대 재고를 넘으면 담기 실패" 로직을 수정했다고 하자. 이 변경이 영향을 줄 수 있는 주변 기능 3가지를 추측해 적고, 각각에 대해 회귀 테스트로 무엇을 확인할지 한 줄씩 적는다. (힌트: 재고, 결제, 알림 중 어디와 얽혀 있을지 생각해본다.)
자가 체크리스트
- 기능 테스트와 비기능 테스트를 "무엇을 하는가 vs 얼마나 잘 하는가"로 구분할 수 있다
- 확인 테스트와 회귀 테스트의 목적 차이를 설명할 수 있다
- 확인 테스트만 하고 회귀 테스트를 생략했을 때 생기는 문제를 설명할 수 있다
- 주어진 코드 변경에 대해 회귀 테스트 범위를 합리적으로 추측할 수 있다
흔한 실수
- 회귀 테스트를 "그냥 다시 테스트하는 것"으로 뭉뚱그려 이해한다. 회귀 테스트는 특정 변경으로 인한 영향을 좁혀서 보는 것이지, 무작정 전체를 재실행하는 게 아니다 (전체 재실행이 필요한 경우도 있지만, 그건 회귀 테스트의 한 형태일 뿐이다).
- 비기능 요구사항을 "나중에 여유 있으면"으로 미룬다. 성능·보안 문제는 기능이 다 완성된 뒤에 손대려면 구조를 바꿔야 할 수도 있어 훨씬 비싸진다.
- 확인 테스트만 하고 끝낸다. "그 버그, 고쳤어요?"에 "네, 확인했어요"라고 답할 때 회귀 테스트를 빼먹었다면, 정확히는 "그 버그는 고쳐졌는지 확인했지만 다른 곳은 안 봤다"는 뜻이다.
참고 자료
- ISTQB Glossary — Regression Testing / Re-testing — 두 용어의 공식 정의와 구분
- Atlassian — What is Regression Testing — 실무 사례 중심 설명