스텁 시험을 하면 안 되나

개발을 멈추지 않으려면 스텁이 필요합니다. 금지는 스텁 합격률을 실연계 완료로 보고하는 일입니다.

상대 기관이 끝까지 창구를 안 열면

실연계 0건을 위험으로 올리고, 회신일 다음 영업일을 선행으로 고정합니다. 우리 개발 완료일을 연계 종료일로 쓰지 않습니다.

실전문 주에 전 건을 다시 돌려야 하나

스텁에 없던 타임아웃, 중복, 부분 실패, 재처리만 다시 돌립니다. 이미 확인한 필드 매핑까지 다시 돌리면 창이 겹칩니다.

고객 사인을 스텁 화면에서 받아도 되나

업무 결과가 가짜 데이터면 그 사인은 환경 확인입니다. 실잔액이 찍힌 뒤에 검수 사인을 다시 받습니다.

연계 스텁 시험 기준 잡기 - 실전문 전에 합격으로 보면 어디서 깨지나

외부 기관 전문이 아직 안 왔는데 통합시험 합격률이 95%라면, 그 상대가 실서버인지부터 물어야 합니다. 스텁은 우리가 기대한 응답만 돌려주고, 타임아웃과 중복 전문, 오류 코드는 일부러 넣지 않으면 안 나오기 때문이죠. 주간보고에 스텁 합격과 실연계 합격을 같은 칸에 적으면 발주사는 연계가 끝났다고 읽습니다. 끝난 줄 알고 인력 철수 일정을 2주 당기면, 실전문 주에 사람이 없죠. 스텁을 없애라는 뜻이 아닙니다. 어디가 환경 검사고 어디가 연계 합격인지 칸이 없어 생기는 착각이죠. 이번 포스팅에서는 스텁으로 닫아도 되는 항목과 실전문 전까지 열어 둘 항목을 자세히 다뤄보도록 하겠습니다. 연계가 임계경로에 있는 프로젝트라면 합격 칸을 나눠 보세요.

항목	스텁으로 볼 수 있나	닫는 시점
필드와 전문 항목 대응	가능	스텁 통과 때
정상 응답 1종 매핑	가능	스텁 통과 때
타임아웃	재현이 제한됨	실응답 로그 후
중복 수신	재현이 제한됨	실응답 로그 후
부분 실패와 재처리	재현이 제한됨	실연계 시나리오 후

스텁으로 닫는 항목과 실전문까지 열어 둘 항목

스텁 합격률은 무엇을 재는 숫자일까?

스텁 합격은 우리 송신 포맷이 기대 응답과 맞는지를 봅니다. 상대 기관의 실제 처리 시간은 포함되지 않습니다.

스텁은 상대가 없을 때 개발을 멈추지 않으려고 둡니다. 그 목적까지는 맞죠.

문제는 합격률 95%를 연계 완료로 보고하는 순간이죠. 스텁은 우리가 적어 둔 샘플 3종만 돌려주므로, 상대가 나중에 추가하는 오류 코드 2종은 시험에 없습니다.

없는 케이스를 0건 결함으로 적으면 품질이 아니라 시험 범위가 빈 것입니다. 검증(Validation)은 고객이 업무 결과를 확인하는 자리인데, 스텁 결과만 놓고 사인하면 고객은 가짜 잔액을 확인한 셈이죠.

가짜 잔액에 찍힌 사인은 실거래 주간에 무효가 됩니다. 무효가 된 사인을 완료 실적으로 남기면 진척만 앞서고 잔여 시험은 실전문 주에 몰립니다.

실전문 전에 닫으면 안 되는 항목은 무엇일까?

타임아웃, 중복 수신, 부분 실패, 재처리. 이 넷은 실응답이 오기 전에는 합격으로 닫지 않습니다.

화면 필드가 전문 항목과 대응되는지는 스텁으로도 볼 수 있습니다. 반대로 3초 타임아웃, 같은 전문의 중복 수신, 일부 계정만 실패하는 부분 실패, 실패 후 재처리는 상대 시스템의 행동이 있어야 재현됩니다.

이 넷을 스텁 합격으로 닫으면 오픈 리허설에서 처음 만납니다. 리허설에서 처음 만나는 결함은 수정 시간이 하루로 안 끝납니다.

상대 기관의 담당이 당일에 응답하지 않으면 우리 수정은 다음 창구까지 대기합니다. WBS에서 이 넷은 개발 완료가 아니라 실연계 마일스톤의 하위 작업으로 둡니다.

개발 완료 열에 넣어 100%로 칠하면, 진척률은 오르고 종료일은 그대로 밀립니다. 하위 작업을 4줄로 쪼개야 어느 줄이 비었는지가 보입니다.

주간보고 칸을 어떻게 나눌까?

환경 검사, 스텁 통과, 실연계 통과를 세 칸으로 나눕니다. 합계 합격률 한 칸은 철수 일정을 당깁니다.

보고 양식에 합격률 칸이 하나면 사람들은 가장 큰 숫자를 올립니다. 스텁 40건 중 38건은 95%가 되고, 실연계 0건은 분모에서 사라지죠.

분모에서 사라진 0은 위험이 아니라 침묵이 됩니다. 칸을 셋으로 나누면 실연계 0이 그대로 보이죠.

보이는 0은 Risk(위험)로 올리기 쉽습니다. 위험 한 줄에는 상대 기관의 다음 회신 예정일과, 회신이 없으면 우리 오픈을 며칠 미룰지를 같이 남겨야 하죠.

미룰 일수를 안 적으면 위험 목록은 감상문이 됩니다. 감상문은 운영위원회에서 결정으로 이어지지 않습니다.

결정이 안 된 위험은 다음 주 보고에서 같은 문장으로 다시 나옵니다.

상대 기관 일정이 밀리면 우리 일정은 어디에 붙일까?

실연계 시작일을 상대 회신일 다음 영업일로 고정합니다. 우리 개발 완료일에 붙여 두면 대기만 늘어납니다.

상대 기관이 전문 확정을 2주 미루면, 우리 개발자가 그 2주를 다른 화면에 쓰는 선택이 나옵니다. 선택은 맞을 수 있습니다.

다만 실연계 주를 개발 완료 바로 다음 날로 남겨 두면, 사람이 다른 화면에 가 있는 동안 전문이 도착합니다. 도착한 전문을 받을 담당이 없으면 그 주는 공백이죠.

공백 주는 곧 임계경로입니다. 착수 때 실연계 버퍼를 5영업일로 잡아 두고, 버퍼를 다른 과업에 빌려 쓸 때는 반납일을 같이 적어야 하죠.

반납일이 없는 빌려 쓰기는 증원처럼 보여도 연계 주에는 자리가 빕니다. 발주사가 상대 기관과 직접 회신일을 받으면, 그 날짜를 우리 WBS의 선행으로 넣습니다.

수행사 추정일로 선행을 채우면 매주 하루씩 어긋납니다.

스텁을 거두고 실연계로 바꿀 때 무엇을 다시 돌릴까?

필드 대응은 유지하고, 타임아웃과 오류 코드, 재처리 시나리오만 다시 돌립니다. 전 건 재시험은 일정을 두 배로 봅니다.

실전문이 열리는 날에 시나리오 40건을 처음부터 다시 돌리자는 제안이 나옵니다. 40건 안에는 이미 확인된 필드 매핑이 많습니다.

매핑을 다시 돌리는 시간은 새 오류 코드를 볼 시간을 잠식하죠. 다시 돌릴 목록은 스텁에 없던 항목으로 한정합니다.

타임아웃 2건, 중복 1건, 부분 실패 2건, 재처리 1건처럼 수를 적으면 반나절 창으로 계획할 수 있습니다. 수를 안 적으면 창은 이틀로 부풀고, 그 이틀이 오픈 리허설과 겹칩니다.

겹치면 리허설은 연계 디버깅이 됩니다. 디버깅이 된 리허설은 오픈 판단 자료가 되지 못합니다.

판단 자료가 되려면 실응답이 찍힌 로그 번호가 시나리오 옆에 붙어야 합니다.