🧪 Software Testing · 1/8 · 약 7분

시리즈 전체 보기

처음 검증 플랫폼을 마주했을 때 화면에는 빌드, 정적 확인, 실행 기반 확인, 결과 수집, 리포트처럼 익숙하면서도 경계가 모호한 메뉴가 늘어서 있었다. 기능 이름부터 외우려니 각 메뉴가 왜 필요한지, 실패했을 때 어디부터 확인해야 하는지가 좀처럼 연결되지 않았다.

관점을 바꿔 가상의 요구사항 하나가 최종 리포트에 도착할 때까지 따라가 보기로 했다. 입력이 무엇이고, 단계마다 어떤 산출물이 생기며, 실패가 어디에 기록되는지를 연결하자 플랫폼은 ‘검사 도구의 모음’이 아니라 ‘판단 근거를 전달하는 파이프라인’으로 보이기 시작했다.

#SoftwareTesting · #Verification · #Build · #Report

이 글에서 다룰 것

1. 메뉴보다 먼저 입력과 산출물을 그렸다

메뉴 이름은 제품마다 달라질 수 있지만 검증의 큰 흐름은 비교적 안정적이다. 소스와 설정을 준비하고, 재현 가능한 상태로 빌드한 뒤, 구조와 실행을 서로 다른 방식으로 관찰하고, 결과를 모아 사람이 판단할 수 있는 리포트로 바꾼다.

가상 소스와 설정
      ↓
재현 가능한 빌드
   ↙          ↘
정적 확인    실행 기반 확인
   ↘          ↙
     결과 수집
         ↓
근거가 연결된 리포트

이렇게 그린 뒤에는 각 단계에 같은 세 질문을 붙였다. “무엇을 받는가?”, “무엇을 남기는가?”, “실패하면 어디에서 멈추는가?”다. 이 세 질문만으로도 화면에서 보이는 기능과 실제 책임을 분리할 수 있었다.

단계 주요 입력 남겨야 할 산출물 먼저 확인할 실패
빌드 가상 소스·설정 실행 가능한 결과와 로그 환경 차이, 설정 누락, 재현 실패
정적 확인 소스·구조 정보 위치가 포함된 확인 결과 분석 범위와 규칙 적용 여부
실행 기반 확인 빌드 결과·시험 입력 실행 이력과 관찰값 입력, 환경, 실행 중단 지점
결과 수집 여러 확인 결과 회차·상태·예외가 연결된 기록 누락, 중복, 서로 다른 기준
리포트 수집된 근거 판단과 근거를 함께 담은 설명 숫자와 원인의 단절

2. 정적 확인과 실행 기반 확인은 경쟁 관계가 아니다

처음에는 둘 중 하나가 더 강력한 검사라고 생각하기 쉬웠다. 하지만 두 방식은 관찰하는 대상이 다르다. 정적 확인은 실행하지 않고 구조와 규칙을 살피고, 실행 기반 확인은 실제 입력을 통과시키며 나타난 행동을 관찰한다.

관점 정적 확인 실행 기반 확인
핵심 질문 구조상 위험이나 규칙 위반이 있는가? 특정 입력에서 기대 행동이 관찰되는가?
강점 실행하기 어려운 경로도 넓게 살필 수 있음 실제 상태 변화와 결과를 확인할 수 있음
주의점 발견한 항목이 실제 장애로 이어지는지 별도 판단 필요 실행하지 않은 조건은 관찰되지 않음

따라서 결과를 합칠 때도 단순히 성공과 실패 두 칸으로 만들기보다, 어떤 방식으로 무엇을 관찰했는지 남겨야 한다. 서로 다른 질문의 답을 같은 점수로 뭉치면 다음 행동을 고르기 어려워진다.

3. REQ-001을 끝까지 추적해 보았다