요구사항 변경과 추적성(Traceability)

개념

요구사항은 바뀌는 게 정상이다

요구사항이 바뀌는 것 자체는 실패가 아니다. 시장 상황이 바뀌고, 사용자 피드백이 들어오고, 처음엔 몰랐던 제약이 나중에 발견된다. 문제는 변경 자체가 아니라, 변경이 어디까지 영향을 주는지 아무도 모르는 상태다.

추적성이란

**추적성(Traceability)**은 요구사항 하나가 어떤 설계, 어떤 코드, 어떤 테스트 케이스와 연결되어 있는지 계속 알 수 있는 상태를 말한다. 이 연결이 있으면, 요구사항이 바뀌었을 때 "이 변경 때문에 무엇을 다시 봐야 하는가"를 추측이 아니라 조회로 알 수 있다.

가장 단순한 형태는 추적성 매트릭스다 — 요구사항 ID와 테스트 케이스 ID를 표로 연결해둔다.

이제 REQ-101("무료배송 기준")이 3만원에서 5만원으로 바뀐다면, 이 표를 조회해서 TC-201, TC-202, TC-203을 다시 확인해야 한다는 걸 즉시 알 수 있다. 표가 없다면 "어떤 테스트가 이거랑 관련 있었더라?"를 기억에 의존해서 떠올려야 하고, 빠뜨릴 위험이 크다. 이건 모듈 1(레슨 4)에서 배운 회귀 테스트 범위를 정하는 문제와 정확히 같은 문제다 — 추적성 매트릭스는 회귀 범위를 근거 있게 정하는 도구다.

양방향으로 본다

• 정방향 추적(요구사항 → 테스트): "이 요구사항, 테스트로 커버되고 있나?"를 확인한다. 커버되지 않은 요구사항이 있다면 테스트 공백이다.
• 역방향 추적(테스트 → 요구사항): "이 테스트 케이스, 지금도 유효한 요구사항과 연결되어 있나?"를 확인한다. 연결이 끊긴("고아") 테스트 케이스는 이미 없어진 요구사항을 검증하고 있을 수 있다 — 정리 대상이다.

실무에서는 표 하나로 끝나지 않는다

간단한 기능은 스프레드시트 표로 충분하지만, 큰 프로젝트에서는 테스트 관리 도구(모듈 7에서 다룰 TestRail, Zephyr 등)가 이 연결을 자동으로 관리해준다. 지금은 도구 없이도 "요구사항과 테스트가 연결되어 있어야 한다"는 개념 자체를 익힌다 — 도구는 이 개념을 자동화한 것일 뿐이다.

실무에서 왜 필요한가

추적성이 없는 팀에서 요구사항이 바뀌면, "이거 바뀌었으니 관련된 거 다시 테스트해주세요"라는 말만 전달되고 실제로 "관련된 것"이 무엇인지는 각자의 기억에 맡겨진다. 사람마다 기억이 다르고, 빠뜨리는 부분이 생긴다. 특히 오래전에 만들어져 잘 안 건드리는 기능일수록 "설마 이것까지 영향 있겠어"라며 누락되기 쉽다. 추적성 매트릭스는 이 판단을 기억이 아니라 기록에 맡긴다. 규제 산업(의료기기, 금융 등)에서는 이 추적성이 감사(audit) 요건으로 명시되어 있는 경우도 많다 — 모듈 8(ISO/IEC/IEEE 29119)과 부록의 의료기기 표준에서 다시 다룬다.

실습 과제

과제 1 — 미니 추적성 매트릭스 만들기 (12분)

아래 두 요구사항에 대해, 각각 검증이 필요한 테스트 케이스를 2~3개씩 상상해서 추적성 매트릭스 표를 만든다 (요구사항 ID는 자유롭게 붙인다).

1. "로그인 5회 실패 시 계정이 10분간 잠긴다."
2. "장바구니는 로그아웃해도 24시간 동안 유지된다."

과제 2 — 변경 영향 찾기 (10분)

과제 1에서 만든 매트릭스를 보고, "계정 잠금 시간을 10분에서 30분으로 변경한다"는 요청이 왔다고 하자. 이 매트릭스를 근거로 어떤 테스트 케이스를 다시 봐야 하는지 답한다.

자가 체크리스트

• 추적성을 "요구사항-설계-코드-테스트의 연결 상태"로 설명할 수 있다
• 추적성 매트릭스를 간단한 표로 직접 만들 수 있다
• 정방향 추적과 역방향 추적의 차이와 각각의 용도를 설명할 수 있다
• 추적성이 회귀 테스트 범위 결정과 어떻게 연결되는지 설명할 수 있다

흔한 실수

• 추적성 매트릭스를 한 번 만들고 갱신하지 않는다. 새 테스트 케이스가 추가될 때마다 매트릭스도 함께 갱신하지 않으면, 시간이 지날수록 매트릭스를 못 믿게 된다.
• 모든 요구사항-테스트 관계를 다 기록하려다 포기한다. 처음부터 완벽한 매트릭스를 만들려 하지 말고, 리스크가 높은 기능부터 연결해나가는 게 현실적이다.
• "이 정도는 기억할 수 있다"고 매트릭스 자체를 생략한다. 기능이 몇 개 안 될 땐 괜찮아 보이지만, 프로젝트가 커지면 반드시 기억에 의존한 누락이 생긴다.

참고 자료

• ISTQB Glossary — Traceability — 추적성의 공식 정의
• ISO/IEC/IEEE 29119-3 — 테스트 문서 표준에서 추적성 매트릭스를 다루는 부분 (모듈 8에서 자세히)