S1 · 설계

기획서 원문을 읽어 분석 문서와 설계 문서 두 장을 만든다. 앞의 것은 원문을 정리하고 테스트 후보를 뽑는 문서고, 뒤의 것은 그 후보를 분류 트리와 케이스로 전개한 문서다.

이 파이프라인에서 판단이 가장 많이 들어가는 자리고, 그래서 여기만 상위 모델을 쓴다.

분류는 정리가 아니라 셋업 계층이다

이게 이 단계에서 제일 중요한 규칙이다.

분류는 단순 기능 그룹핑이 아니라, 자동화 테스트의 사전조건 계층이다. 각 분류는 재현 스텝 실행 직전까지의 셋업 단계를 표현한다.

사람이 읽기 좋게 묶는 게 아니라, 자동화 코드가 그 계층에 그대로 매핑된다. 대분류는 어떤 화면·모드에 들어가 있어야 하는지, 중분류는 그 안에서 무엇이 준비돼 있어야 하는지를 뜻한다.

그래서 분류를 기능 이름으로 나누면 자동화가 매 케이스마다 처음부터 셋업한다. 같은 준비 상태를 공유하는 것들이 다른 분류에 흩어져 있으면, 묶어서 한 번만 만들 수가 없기 때문이다.

분류 이름에 동작·조건·결과를 쓰지 않는 것도 같은 이유다. 소분류 이름은 거기 도달한 상태를 가리켜야 하고, 무슨 동작을 하는지는 케이스가 말한다.

없는 데이터로는 케이스를 만들지 않는다

재현 스텝에 아이템이 실명으로 나와야 하는데, 그 이름은 게임 데이터 테이블에 있다. 그래서 설계 직전에 테이블을 훑어 실명 사전을 뽑아 설계기에 먹인다.

하필 여기인 이유는 문장이 여기서 태어나기 때문이다. 설계 문서에서 만들어진 표현이 문장화·리뷰·시트까지 그대로 흘러간다. 하류에서 고치면 이미 세 군데에 퍼진 뒤다.

규칙 세 개가 붙어 있다.

• 예시는 사전에서만 고른다. 기억이나 추측으로 아이템 이름을 쓰지 않는다. 그럴듯한 가짜 이름이 케이스에 박히면 실행하는 사람이 그걸 찾다가 시간을 버린다.
• 이름만으로 특정이 안 되면 식별자를 병기한다. 같은 이름이 여럿이면 이름은 정보가 아니다.
• 데이터에 없는 조합을 전제한 케이스는 지우지 않고 질의로 돌린다. 없는 게 기획 누락일 수도 있어서다. 지우면 그 질문이 사라진다.

값이 비어 있는 데이터의 동작도 후보에서 뺀다. 아직 안 채운 것과 비우기로 한 것은 다르고, 전자를 케이스로 만들면 데이터를 채우는 순간 그 케이스가 통째로 무의미해진다.

누락과 압축은 다른 실패다

설계가 끝나면 검수를 붙이는데, 게이트를 둘로 나눠 뒀다. 한동안 하나만 두다가 데었다.

게이트	무엇을 대조하나	잡는 실패
상류	기획서 → 분석 후보	누락 — 애초에 후보로 안 잡힘
하류	분석 후보 → 설계 케이스	압축 — 후보는 있는데 케이스로 안 펴짐

하나만 두면 어떻게 되냐면, 하류만 보면 상류 누락이 통과한다. 분석이 놓친 항목은 설계에도 없으니 “설계가 분석을 잘 전개했다”로 PASS가 나온다. 100% 전개율이 100% 커버리지가 아닌 것이다.

그리고 하류 게이트는 비율만 적고 끝내면 안 된다. 후보 하나하나에 대해 어디로 갔는지 표로 적는다 — 전개됨 / 침묵 누락 / 정당한 제외. 제외는 사유를 안 쓰면 누락으로 친다.

경계값은 예외 없이 100%다. 최소-1, 최소, 최대, 최대+1 중 하나라도 개별 케이스로 안 갈라져 있으면 그 자리에서 실패다. N 이하 / N 초과 같은 통합 표기를 발견하면 즉시 되돌린다.

되돌아오는 비용이 0이어야 한다

설계 해시가 같으면 이 단계를 통째로 건너뛴다. 뒤에서 막혀 되돌아왔을 때 설계를 다시 시키지 않기 위해서다.

이게 없으면 다음 게이트에 한 번 걸릴 때마다 제일 비싼 단계를 다시 돌게 된다. 되돌아오는 걸 전제로 만든 파이프라인이면 되돌아오는 값이 싸야 한다.