LIFECYCLE · 05 / 06
테스트
결함을 발라내고 품질을 보증한다. 누가·어떤 기법·어느 커버리지로 검증할지 지침을 주는 게 PM의 일.
QA vs QC
QA는 과정과 산출물을 보증하고, QC는 완성된 결과물을 검사한다.
QA는 만들면서 보증하고(과정과 결과), QC는 완성품을 받아 검사한다. PM의 역할은 직접 테스트가 아니라 누가·어떤 기법·어느 커버리지로 검증할지 지침을 세우는 것이다.
테스트 · 품질테스트 커버리지
테스트가 대상의 얼마를 덮었는지의 지표. RFP에 명시되기 시작했다.
커버리지가 높다는 것은 빈틈이 적다는 신호일 뿐, 품질이 보증된다는 뜻이 아니다. 100% 자체를 목표로 삼으면 의미 없는 시험만 늘어나므로, 수치는 미검증 영역을 찾는 진단 도구로 쓰고 측정 대상과 방법의 합의를 먼저 확보하는 것이 핵심이다.
테스트 · 품질테스트 설계 기법
구조 기반·명세 기반·경험 기반의 세 갈래 기법.
테스트 설계 기법은 전수 시험이 불가능하다는 전제에서 출발해, 한정된 자원으로 결함을 가장 잘 찾을 케이스를 고르는 기술이다. 명세 기반·구조 기반·경험 기반은 서로의 사각지대를 메우므로 한 갈래에 의존하지 말고 위험 영역에 맞춰 조합하고, 도출한 케이스는 커버리지로 빈틈을 점검하는 것이 실무의 정석이다.
테스트 · 품질Mock 테스트
실제 의존 대신 가짜(mock)로 대체해 인터페이스를 검증하는 테스트.
Mock 테스트의 가치는 가짜 응답이 실제 규격과 일치한다는 전제 위에서만 성립한다. 그래서 가짜로 넓게 검출하되 핵심 흐름은 실제 의존으로 한 번 더 확정하고, 명세가 바뀌면 Mock도 같은 변경 단위로 갱신하는 규율이 초록불의 신뢰를 지킨다.
테스트 · 품질단위 테스트
함수·모듈 단위로 검증하는 가장 작은 테스트. QA의 출발점.
단위 테스트의 가치는 커버리지 숫자가 아니라 실패했을 때 원인을 즉시 짚어 주는 정밀함에서 나온다. 단언 없이 호출만 채워 수치를 올린 테스트는 통과해도 아무것도 보증하지 못하므로, 경계값과 예외 경로에 검증을 집중하는 편이 현장에서 훨씬 오래 버틴다.
테스트 · 품질통합 테스트
모듈 간 인터페이스 결합을 검증하는 테스트.
통합 테스트에서 터지는 결함의 상당수는 코드 자체가 아니라 모듈 간 인터페이스 명세의 모호함에서 비롯된다. 데이터 형식·오류 코드·호출 전제를 양쪽이 문서로 합의해 두지 않으면, 빅뱅으로 한꺼번에 붙였을 때 원인 구간을 좁히지 못해 일정이 무너지므로 결합은 추적 가능한 작은 단위로 진행하는 편이 안전하다.
테스트 · 품질시스템 테스트
전체 시스템을 요구사항 기준으로 검증. 비기능 검증 포함.
시스템 테스트에서 발목을 잡는 결함의 다수는 기능이 아니라 명세에 흐릿하게 적혔던 비기능 요구사항, 즉 성능·부하·보안에서 나온다. 더불어 개발 환경과 운영 환경의 데이터 규모·동시성 차이를 좁히지 못하면 시스템 테스트를 통과하고도 운영 직후 문제가 재발하므로, 운영에 준하는 환경을 확보하는 것이 검증 신뢰도의 전제가 된다.
테스트 · 품질인수 테스트
고객 기준으로 합격 여부를 판정하는 최종 테스트. 검수의 근거.
인수 테스트의 승부는 수행 단계가 아니라 합격 기준을 글로 못 박는 요구사항 단계에서 갈린다. 기준이 모호하면 검수 회의는 결함 판정이 아니라 범위 논쟁으로 변질되며, 초과 요건은 잔여 결함과 분리해 운영 단계 개선 개발로 이관하는 것이 정석이다.
테스트 · 품질회귀 테스트
변경 후 기존 기능의 무결성을 재검증하는 테스트.
한 번 통과한 시험이라도 코드가 바뀌면 그 통과는 무효가 되며, 표면상 무관한 기능이 공통 모듈을 공유해 함께 깨지는 일이 잦다. 회귀 세트를 자동화해 CI/CD에 연결하면 부작용이 운영까지 가기 전에 빌드 단계에서 차단되므로 수정 비용이 가장 낮은 지점에서 멈춘다.
테스트 · 품질성능 테스트
부하·응답시간·처리량을 측정하는 비기능 테스트. JMeter·LoadRunner.
성능 테스트는 측정 목표를 비기능 요구사항으로 먼저 확정해야 합격·불합격을 가를 수 있으며, 평균 부하만 가정한 시나리오는 트래픽이 몰리는 첨두 상황을 놓친다. 도구의 선택보다 운영 환경에 근접한 데이터 규모와 시나리오 설계가 결과의 신뢰도를 좌우한다.
테스트 · 품질화이트박스 테스트
내부 구조·로직을 보고 경로를 검증하는 구조 기반 테스트.
커버리지 수치는 검증이 닿지 않은 빈 곳을 가리키는 지표일 뿐, 결함이 없다는 증명이 아니다. 도달은 했으나 단언이 부실하면 통과만 하고 결함은 그대로 남으므로, 숫자를 채우기보다 위험이 큰 핵심 경로의 실질 검증을 우선하는 편이 옳다.
테스트 · 품질블랙박스 테스트
내부를 모른 채 입출력으로 검증하는 명세 기반 테스트.
블랙박스 테스트의 품질은 결국 요구사항과 명세의 품질을 넘지 못한다. 명세가 모호하면 통과한 테스트도 잘못된 동작을 정상으로 굳힐 수 있으므로, 테스트 케이스를 요구 항목과 추적 가능하게 연결해 검증의 빈틈과 변경 영향을 함께 드러내는 것이 실무의 정석이다.
테스트 · 품질코드 인스펙션
정적 분석 도구로 소스 품질·결함을 점검. SonarQube 등.
정적 분석 도구를 처음 켜면 수천 건의 지적이 한꺼번에 나와 팀을 압도하기 쉽다. 전부를 동시에 잡으려 하면 도구가 외면받으므로, 변경분에 품질 게이트를 걸어 새 결함 유입부터 막고 보안·신뢰성 범주를 우선해 점진적으로 부채를 줄이는 운영이 현실적이다.