명세가 흔들릴 때 테스트가 무너지지 않는 법, 실습으로 되찾는 설계 기본기

테스트 케이스가 명세와 어긋나거나 결과가 들쭉날쭉할 때, ISO 표준을 기반으로 한 설계와 비결정형 테스트까지 실습으로 잡는 방법을 알고 싶으신가요.

 

현장에서 테스트 케이스를 만들다 보면 명세가 불완전하거나 변경이 잦아 케이스가 금방 쓸모없어지는 경험을 하게 됩니다.

 

특히 입력에 따라 결과가 달라지는 비결정형 요소가 포함되면, 같은 케이스를 반복해도 통과와 실패가 번갈아 나타나는 상황이 생깁니다.

 

이때 단순한 경험에 의존하기보다 명세 기반 설계로 돌아가 체계를 잡는 것이 중요합니다.

 

지금부터는 실제 요구사항 하나를 가지고 직접 따라가며 설계해 보는 과정을 안내합니다.

 

먼저 ISO/IEC/IEEE 29119 표준이 제시하는 테스트 케이스 설계 접근을 적용하기 위해, 간단한 로그인 기능을 예로 들어 봅니다.

 

가정하는 명세는 다음과 같습니다.

 

“사용자는 이메일과 비밀번호를 입력한 뒤 로그인 버튼을 누르면, 등록된 계정일 경우 메인 화면으로 이동하고, 그렇지 않으면 오류 메시지를 표시한다.

 

이메일은 형식 검사를 하며, 비밀번호는 8자 이상이어야 한다.”

 

이 명세를 노트에 그대로 적어 두고, 동등 분할을 시작합니다.

 

이메일을 ‘유효한 형식’과 ‘유효하지 않은 형식’으로 나누고, 비밀번호를 ‘8자 이상’과 ‘8자 미만’으로 나눕니다.

 

그다음 경계값 분석을 추가해 비밀번호 길이를 7자, 8자, 9자로 구체적으로 정해 봅니다.

 

이렇게 도출한 조건들을 조합하면, “유효한 이메일 + 8자 비밀번호 → 로그인 성공”, “유효한 이메일 + 7자 비밀번호 → 오류 메시지”, “잘못된 이메일 형식 + 8자 비밀번호 → 오류 메시지” 같은 테스트 케이스가 자연스럽게 만들어집니다.

 

각 케이스마다 입력 값과 예상 결과를 한 줄로 명확히 적어 두면, 명세와 일대일로 대응하는 구조가 완성됩니다.

 

이 과정에서 명세의 모호한 부분이 드러납니다.

 

예를 들어 “오류 메시지”가 정확히 어떤 문장을 말하는지, 로그인 성공 시 메인 화면의 어떤 요소가 보여야 하는지가 빠져 있을 수 있습니다.

 

이럴 때는 명세를 보완하는 질문을 스스로 던지고, “로그인 실패 시 ‘이메일 또는 비밀번호를 확인해 주세요’라는 문구가 표시된다”처럼 테스트 가능한 문장으로 구체화합니다.

 

이렇게 수정된 명세를 기준으로 케이스를 다시 정리하면, 나중에 요구사항이 바뀌어도 어떤 케이스를 수정해야 할지 바로 알 수 있어 유지보수 비용이 크게 줄어듭니다.

 

이어서 비결정형 테스트를 다루는 단계로 넘어갑니다.

 

이번에는 “검색어를 입력하면 관련 상품 목록이 나타나며, 목록의 순서는 추천 알고리즘에 따라 달라질 수 있다”는 기능을 예로 삼아 봅니다.

 

단순한 고정 값 검증만으로는 부족하기 때문에, 동일한 검색어를 여러 번 실행했을 때 나올 수 있는 결과 집합을 미리 정의합니다.

 

예를 들어 “검색어 ‘노트북’을 입력했을 때, 상위 5개 상품 중 최소 3개는 ‘노트북’이라는 키워드를 포함해야 한다”처럼 허용 범위를 설정합니다.

 

또는 응답 시간이 2초에서 5초 사이라면 통과로 간주하는 식으로, 시간 의존성도 범위로 표현합니다.

 

실제로 테스트할 때는 같은 입력을 5회 반복 실행하고, 그 결과가 미리 정한 집합 안에 들어가는지 확인합니다.

 

이렇게 하면 테스트가 한 번 실패했다고 해서 무조건 결함으로 단정하지 않고, 허용 가능한 변동 폭을 미리 설정할 수 있게 됩니다.

 

특히 실무에서 자주 마주치는 비동기 처리나 캐시 영향이 있는 기능에서 이 접근이 안정성을 높여 줍니다.

 

캐시가 적용된 검색 결과를 테스트할 때는 “첫 번째 실행과 두 번째 실행의 결과가 완전히 동일하지 않아도, 핵심 상품 ID가 포함되어 있으면 통과”라고 기준을 잡습니다.

 

노트에 이 기준을 적어 두고 실제로 몇 번 실행해 보면, 결과가 들쭉날쭉해도 테스트가 흔들리지 않는 경험을 하게 됩니다.

 

명세 기반 설계와 비결정형 처리를 함께 연습할 때 테스트 품질이 한층 올라갑니다.

 

표준에 맞춰 구조를 잡으면서도 현실의 불확실성을 반영하는 균형이 잡히기 때문입니다.

 

오늘 소개한 로그인과 검색 예시를 그대로 따라가며 자신만의 케이스를 작성해 보세요.

 

기존에 감으로 작성하던 케이스가 어떻게 체계적으로 바뀌는지 바로 체감할 수 있습니다.

 

테스트 설계의 기본으로 돌아가는 이 과정은 결국 전체 품질 검증의 신뢰도를 높이는 출발점이 됩니다.