하우스키핑 점검표로 읽는 소프트웨어 테스트 7원칙

국제소프트웨어테스팅자격위원회(ISTQB)는 수십 년간 쌓인 테스트 경험을 일곱 가지 원칙으로 정리했다. 자격시험에 자주 나오는 내용이지만, 그보다 실무에서 판단이 흔들릴 때 기댈 수 있는 기준이라는 점에서 의미가 크다.

호텔에서 일하다 IT 기업으로 옮긴 뒤 이 원칙들을 처음 공부했을 때, 낯설기보다는 반가웠다. 대부분이 호텔에서 이미 겪어 본 일이었기 때문이다. 졸저 『이제 QA, AI Agent랑 같이 합시다』에서도 이 원칙들을 호텔 이야기로 풀어 보았다. 여기서는 그 내용을 하우스키핑과 객실 관리의 관점에서 다시 정리해 본다.

원칙 1. 테스트는 결함이 있음을 보여 줄 뿐, 없음을 증명하지 못한다

하우스키핑 직원이 객실 열 곳을 점검해 문제가 없었다고 해서, 호텔의 모든 객실이 완벽하다고 말할 수는 없다. 테스트도 마찬가지다. 많은 테스트를 통과했다는 것은 찾은 결함이 적다는 뜻이지, 결함이 없다는 뜻이 아니다. 그래서 테스터는 "버그 없습니다"가 아니라 "이 범위에서는 문제를 찾지 못했습니다"라고 말해야 한다. 정직한 보고는 겸손한 표현에서 시작된다.

원칙 2. 모든 경우를 다 테스트할 수는 없다

숙박일 1~14박, 인원 1~4명, 객실 타입 세 가지, 회원 여부, 1년 365일을 모두 조합하면 14 × 4 × 3 × 2 × 365 = 122,640가지가 된다. 전부 해 보는 것은 불가능하다. 하우스키핑 매니저가 모든 객실의 모든 서랍을 매일 열어 보지 않는 것과 같다. 그래서 무엇을 먼저, 얼마나 점검할지 고르는 기술이 필요하다. 테스트 기법이 바로 그 고르는 기술이다.

원칙 3. 일찍 테스트할수록 시간과 비용을 아낀다

객실 리노베이션 도면 단계에서 콘센트 위치를 바로잡으면 선 하나를 고치면 된다. 공사가 끝난 뒤라면 벽을 다시 뜯어야 하고, 고객이 투숙한 뒤라면 사과와 보상까지 더해진다. 소프트웨어도 같다. 결함은 늦게 발견할수록 고치는 비용이 커진다. 기획서 단계의 리뷰가 중요한 이유다.

원칙 4. 결함은 몰려 있다

어느 호텔에나 유독 민원이 자주 나오는 객실이 있다. 배관이 오래되었거나, 엘리베이터 옆이라 소음이 있거나, 창이 잘 닫히지 않는 방이다. 소프트웨어의 결함도 일부 기능에 몰리는 경향이 있으며, 정산이나 할인 계산처럼 규칙이 복잡한 곳이 대표적이다. 과거에 결함이 많았던 곳, 고객 문의가 많은 곳을 더 꼼꼼히 보는 것이 효율적이다.

원칙 5. 같은 테스트는 점점 닳는다

매일 같은 순서로 객실을 점검하면 늘 보던 곳만 보게 된다. 침대와 욕실은 꼼꼼히 보지만 커튼 레일 위의 먼지는 몇 달째 아무도 보지 않는다. 테스트도 같은 테스트 케이스를 반복하면 새로운 결함을 잘 찾지 못한다. 그래서 테스트 케이스를 주기적으로 고치고 새로운 데이터와 관점을 더해야 한다. 이 원칙은 예전에 '살충제 패러독스'라는 이름으로도 불렸다. 같은 살충제를 계속 뿌리면 벌레가 내성이 생기는 것에 빗댄 표현이다.

원칙 6. 테스트는 상황에 따라 달라진다

5성급 호텔과 비즈니스 호텔의 객실 점검 기준이 같을 수 없다. 테스트도 마찬가지다. 결제가 오가는 정산 기능과 공지사항 게시판은 테스트의 깊이와 방법이 달라야 한다. 정답 하나를 외우기보다 "이 상황에서는 무엇이 중요한가"를 묻는 것이 출발점이다.

원칙 7. 결함이 없다고 성공한 것은 아니다

버그 하나 없이 완벽하게 동작하는 예약 시스템을 만들었는데, 프런트 직원이 예약 하나를 잡는 데 화면을 열 번 넘겨야 한다면 어떨까. 아무도 쓰고 싶어 하지 않을 것이다. 결함을 찾아 고치는 것만으로는 부족하며, 사용자가 실제로 원하는 것을 만들었는지도 함께 확인해야 한다. 객실이 규정대로 완벽하게 청소되어 있어도 고객이 원한 것이 조용한 방이었다면, 그 객실은 고객에게 좋은 객실이 아니다.

품질을 다루는 원리는 산업을 넘는다

일곱 가지 원칙을 호텔의 언어로 옮겨 보면, 소프트웨어 테스트가 결코 개발자만의 전문 영역이 아니라는 것을 알 수 있다. 품질을 점검하고, 한정된 자원으로 우선순위를 정하고, 같은 실수가 반복되지 않도록 과정을 고치는 일은 하우스키핑과 프런트, 정산의 현장에서 매일 일어나는 일이다.

서비스품질 연구가 고객이 지각하는 품질을 다룬다면, 소프트웨어 테스트는 그 품질을 지탱하는 시스템의 품질을 다룬다. 두 영역의 원리가 이렇게 닮아 있다는 사실은, 호텔 현장의 사람들이 시스템 품질을 이야기하는 데 필요한 것이 전혀 새로운 지식이 아니라 이미 가진 경험을 옮겨 담을 언어라는 점을 보여 준다.