URS의 목적과 책임 - Part 4
실무자 판단력의 진짜 시작은 여기서 갈린다
현장에서 문서를 검토하다 보면
어떤 문장에서는 손이 멈춘다.
반면, 어떤 문장은 아무 생각 없이 넘긴다.
그리고 몇 달 뒤 실사 때, 그 '넘겼던 문장'이 문제를 일으킨다.
이게 바로 URS의 무서운 점이다.
처음엔 기능 나열처럼 보여도,
그 문장이 이후 FDS, DQ, IQ, OQ, 실사까지 전부를 따라가기 때문이다.
처음에 놓친 문장은, 끝까지 흔들린다.
실무자는 알 것이다.
“기능이 있어야 한다”로만 쓰인 문장은
도대체 어떤 설정을 말하는 건지,
그 기능이 데이터 무결성과 어떻게 연결되는지,
시험은 어떤 방식으로 할 수 있을지를
도무지 떠올릴 수 없다는 걸.
하지만 그런 문장에 '검토 완료' 사인 한 번 잘못하면
실사 때 그 페이지가 감사관의 질문지로 바뀐다.
검토자의 손을 멈추게 만드는 문장은 다르다.
그 문장은
‘기능’이 아니라
‘구조’를 보여준다.
‘개발자 언어’가 아니라
‘규제 대응 언어’로 쓰여 있다.
예를 들어, 단순히
“알람 발생 시 기록이 되어야 한다”가 아니라
“알람 발생 시 알람 ID, 발생 시각, 원인코드, 사용자가 입력한 해소 사유가 변경 불가한 로그에 저장되어야 하며, 해당 로그는 시스템 관리자만 조회 가능해야 한다.”
이 정도면
검토자는 이 문장이
OQ 테스트로 직행할 수 있는 구조임을 직감한다.
결국 실무자는 문장을 ‘읽는’ 것이 아니라
검증 가능성과 규제 타당성을 함께 판단해야 한다.
좋은 문장은 검토자에게
이 기능이 어떤 정책 설정을 요구하고,
이 설정이 어떤 방식으로 통제되고,
무엇이 기록되며,
어떤 항목으로 시험될 수 있는지를 상상하게 만든다.
그래서 이 문장은 넘기지 못하고,
멈추게 되는 것이다.
그게 문서의 ‘검토력’이고,
실무자의 ‘판단력’이다.
문서마다 검토자는 질문을 던진다.
“이건 시험 가능할까?”
“기록으로 남을 수 있을까?”
“이게 실제 사용 환경에서 통제 가능할까?”
이 질문에 명확히 ‘예’라고 답하게 만드는 문장이,
신뢰받는 문장이다.
반대로
질문이 하나라도 뜨면,
그건 아직 미완의 문장이다.
그리고 그 문장을 넘기는 순간,
실사 질문은 QA에게로 돌아온다.
이 지점이 바로
‘검토자의 직관’이 ‘검증 전략’으로 연결되는 순간이다.
많은 사람들이 이 부분을 ‘감각’이라고 말하지만,
사실 이건 훈련이고, 논리다.
어떤 문장이 시험 가능하고, 어떤 문장이 리스크를 품고 있는가
이걸 아는 사람이
진짜 QA다.
검토자는 그냥 체크리스트를 따라가는 사람이 아니다.
문서의 미래를 예측하는 사람이다.
기능의 끝을 보고,
그 기능이 남길 기록과,
그 기록이 남길 책임을 본다.
그래서 결국 문서 검토란,
문장을 넘길 것인가, 멈출 것인가를
수백 번 선택하는 일이다.
그 선택의 질이,
곧 시스템 신뢰도의 차이를 만든다.
그리고 그것이 바로
QA 실무자 한 명이 남기는 가장 결정적인 흔적이 된다.
