시험은 ‘누르는 것’이 아니라 ‘입증하는 것’이다.
시험은 ‘누르는 것’이 아니라 ‘입증하는 것’이다
실제 실무에서는 이런 상황, 자주 마주칩니다.
“기능 확인했어요. 버튼 눌러봤습니다.”
“잘 작동하던데요?”
“사진도 찍어뒀어요.”
정말요?
그게 시험(Test)인가요, 그냥 확인(Verification)인가요?
시험(Test)은 기능을 ‘보는 것’이 아니라 ‘입증하는 것’
많은 실무자들이 ‘시험’을 그냥 동작 확인 수준으로 이해합니다.
예를 들어, 알람이 울리는지 확인하고, 화면에 값이 뜨는 걸 보면 그걸로 끝.
그런데 CSV의 세계에서 시험은 훨씬 복잡합니다.
“이 기능은 요구사항에 따라 설계됐고, 그 설계대로 구현되었으며, 지금 제대로 작동하는 중이다.”
이 전체 과정을 문서로, 사진으로, 서명으로, 근거로 증명하는 것.
그게 진짜 시험입니다.
그럼 어떤 실수가 반복될까?
다음은 현장에서 자주 발생하는 시험 관련 오류입니다:
시험 목적이 없음: 그냥 “확인한다”고만 쓰고, 이 시험이 무엇을 입증하려는지 안 써놓음
기준값이 없음: 알람 발생 조건, 정상 범위, 통과 기준이 문서에 없음
기대결과가 애매함: “정상 동작해야 함” → 뭐가 어떻게 되는 게 정상?
반복 시험 없음: 1번 눌러보고 됐다고 통과. 재현성? 없음. 조건 바꾸고 재시험? 없음.
실패 시 시나리오 없음: 일부러 실패를 유도하는 시험이 없음 → 이게 진짜 위험함
시험 항목은 이 질문을 통과해야 합니다
이 시험은 어떤 요구사항에서 나왔는가? → URS 참조 또는 기능 번호 연결되어야 함
무엇을 입증하고자 하는가? → 시험 목적 필요. 단순 확인이 아님
시험 조건은 명확한가? → 환경, 상태, 시나리오까지 포함
예상 결과는 구체적인가? → “알람 발생” X → “X 조건에서 Y 알람이 A 방식으로 발생”
누가, 언제, 어떻게 수행했는가? → 서명, 사진, 기록 등 ‘검증 근거’ 확보 필수
검증 실무에서 꼭 필요한 마음가짐
시험은 “내가 확인했다”는 주장이 아니라
“누가 봐도 입증된 사실”이 되어야 합니다.
그래서 사진도 찍고, 화면 캡처도 하고, 시험 조건도 남기고,
“실패 시도도 일부러 해보고” → 그것도 기록해두는 이유입니다.
대표님도 잘 아시다시피,
시험의 진짜 목표는 “이 시스템을 믿을 수 있다”는 걸 문서로 말하는 것입니다.
말로 하지 말고, 문서로 말하자. 그게 CSV입니다.
현장에 바로 적용할 수 있는 팁
시험 항목을 작성할 때 ’왜?’를 먼저 묻자 → 이 시험, 왜 필요하지? 이걸로 뭘 증명하려는 거지?
‘정상 시나리오’와 ‘비정상 시나리오’를 모두 포함하자 → 정상 입력값 + 잘못된 입력값 → 둘 다 시험!
시험 결과는 수치로, 캡처로, 근거로 남기자 → “OK”만 쓰지 말고, 어떤 결과였는지 보여줘야 함
시험자의 관찰이 아니라 시스템의 반응을 기록하자 → 사람이 아니라 시스템이 증명하도록 설계하자
그리고 마지막 조언
시험을 대충 하면 시스템이 아니라 나 자신이 불안해집니다.
“이거 진짜 됐던 거 맞지?”
“나중에 누가 물어보면 뭐라 하지…”
시험은 나중에 감사를 위한 게 아닙니다.
‘지금의 나’를 위한 신뢰 확보입니다.
그리고 이것만은 꼭 기억하세요.
CSV의 핵심은 신뢰성이고, 시험은 그 신뢰를 문서로 만드는 작업입니다.
