개념
품질이란 무엇인가
"품질이 좋다"는 말은 애매하다. 소프트웨어에서 품질은 보통 두 가지 축으로 나눠 본다.
- 명세 충족(conformance to requirements): 요구사항에 적힌 대로 동작하는가
- 쓰임에 적합함(fitness for use): 실제 사용자가 목적을 달성할 수 있는가
두 축은 자주 어긋난다. 요구사항대로 정확히 만들었는데도 사용자가 못 쓰는 소프트웨어가 있고, 요구사항엔 없지만 사용자가 당연히 기대하는 동작(예: 뒤로가기 버튼이 데이터를 날리지 않는 것)이 빠져서 "버그"로 취급되는 경우도 있다. 테스트는 이 두 축을 모두 확인하는 활동이다 — 명세와 맞는지(이후 배울 "검증"), 그리고 실제로 쓸모 있는지(이후 배울 "확인")를 함께 본다.
결함이란 무엇인가
결함(Defect/Bug)은 소프트웨어가 기대한 대로 동작하지 않는 상태를 가리킨다. 다만 "기대"의 기준이 항상 명확한 건 아니다.
- 명세에 명시적으로 어긋나는 경우 (요구사항: "이메일 형식만 허용" → 실제: 아무 문자열이나 통과)
- 명세엔 없지만 상식적으로 기대되는 동작을 어기는 경우 (합계 금액이 음수로 표시됨)
- 이해관계자마다 기대가 다른 경우 (기획자는 버그라 하고 개발자는 의도된 동작이라 함)
세 번째 유형이 실무에서 가장 많은 갈등을 만든다. 이 갈등을 줄이는 방법(수용 기준을 명확히 하는 법)은 모듈 2에서 다룬다. 지금은 "결함은 합의된 기대와의 차이"라는 정의만 가져간다.
왜 일찍 찾을수록 싼가
같은 결함이라도 발견 시점에 따라 수정 비용이 크게 달라진다. 이유는 단순하다 — 늦게 발견될수록 그 결함 위에 다른 코드와 결정이 쌓여 있기 때문이다.
| 발견 시점 | 무엇이 드는가 |
|---|---|
| 요구사항 리뷰 단계 | 문서 한 줄 수정 |
| 개발 중 (코드 리뷰) | 커밋 하나 수정 |
| 테스트 단계 | 결함 리포트 작성 → 재작업 → 재테스트 |
| 릴리즈 후 (운영) | 핫픽스 배포, 고객 대응, 신뢰 손상, 경우에 따라 데이터 복구 |
이 비대칭이 왜 QA가 "테스트 단계에서 버그를 잡는 사람"에 머물지 않고, 요구사항 리뷰 같은 상류 활동에도 참여해야 하는가의 근거다. 테스트를 뒤로 미룰수록 같은 결함을 잡는 비용이 커진다.
실무에서 왜 필요한가
"품질은 QA 담당"이라는 생각이 실무에서 가장 흔한 착각이다. 결제 시스템에서 이중 결제가 발생하는 결함을 예로 들어본다. 이 결함이 요구사항 리뷰 단계에서 "동시 요청 처리" 조건이 빠진 걸 발견했다면 문서 한 줄을 고치면 끝난다. 하지만 실제 운영 중에 발견된다면 이미 여러 고객이 이중 결제를 겪었고, 환불 처리와 고객 대응, 그리고 "이 서비스는 결제가 불안하다"는 신뢰 손상까지 함께 온다. 같은 결함, 완전히 다른 비용이다.
그래서 실무에서 QA는 "다 만들어진 뒤 검사하는 사람"이 아니라 기획·설계 단계부터 "이 조건, 확인했나요?"를 묻는 사람에 가깝다. 이 질문을 언제, 어떻게 던지는지는 모듈 2(요구사항과 테스트의 연결)에서 구체적으로 다룬다. 지금 이 레슨에서 가져갈 것은 "결함을 어디서 잡느냐가 조직의 실제 비용에 직접 영향을 준다"는 감각이다.
실습 과제
과제 1 — 비용 곡선 체감하기 (10분)
최근에 써본 앱이나 웹사이트에서 겪었던 불편함(버그처럼 느껴졌던 것) 하나를 떠올린다. 아래 표를 채워본다.
| 질문 | 답 |
|---|---|
| 무엇이 기대와 달랐나? | |
| 요구사항 리뷰 단계에서 발견됐다면 무엇을 고쳐야 했을까? | |
| 실제로는 언제(어느 단계) 발견됐을 것 같은가? | |
| 그 시점에 고치는 데 필요했을 작업은? |
과제 2 — 결함의 세 가지 유형 분류하기 (10분)
아래 세 사례를 "명세 위반 / 상식적 기대 위반 / 이해관계자 간 기대 불일치" 중 하나로 분류하고, 왜 그렇게 분류했는지 한 줄로 적는다.
- 회원가입 시 비밀번호 확인란과 비밀번호가 달라도 가입이 완료된다.
- 장바구니에서 상품을 삭제했는데 결제 화면에는 여전히 남아있다.
- 기획자는 "삭제 버튼을 누르면 바로 삭제"를 기대했지만, 개발자는 "삭제 확인 팝업을 먼저 띄우는 게 당연하다"고 생각해 그렇게 구현했다.
자가 체크리스트
- 품질의 두 축(명세 충족, 쓰임에 적합함)을 예시로 설명할 수 있다
- 결함이 발생하는 세 가지 유형(명세 위반, 상식적 기대 위반, 이해관계자 불일치)을 구분할 수 있다
- 결함을 늦게 발견할수록 비용이 커지는 이유를 "쌓인 코드와 결정" 관점에서 설명할 수 있다
- 이 비대칭이 QA가 상류 활동(요구사항 리뷰 등)에 참여해야 하는 근거임을 설명할 수 있다
흔한 실수
- "품질이 좋다 = 버그가 없다"로 단순화한다. 버그가 없어도 쓰기 불편하면 품질이 낮다고 느껴진다. 품질은 명세 충족과 쓰임에 적합함 둘 다를 본다.
- 모든 결함을 같은 무게로 취급한다. 결함의 종류(명세 위반 vs 이해관계자 불일치)에 따라 대응 방식이 다르다 — 후자는 코드를 고치기 전에 합의부터 필요하다.
- "버그 비용이 늦을수록 커진다"를 무조건 모든 상황에 적용한다. 실제로는 시스템 규모, 배포 빈도(예: 하루에도 여러 번 배포하는 조직)에 따라 격차가 줄어들기도 한다. 핵심은 "늦게 발견될수록 대체로 더 많은 것이 얽혀 있다"는 경향이지, 절대 법칙이 아니다.
참고 자료
- ISTQB Foundation Level Syllabus — "결함 비용 증가" 개념의 표준 출처
- Software Testing Help — What is Software Quality — 품질의 두 축에 대한 쉬운 설명