스테이징을 운영과 완전히 같게 만들어야 하나

완전히 같게 만들 수는 없다. 다른 칸을 조서에 적고, 그 칸이 시나리오 결과에 영향을 주면 재시험 일정을 붙인다.

샘플 데이터로 1차 검수를 해도 되나

1차는 가능하다. 다만 1차 합격을 최종 사인으로 쓰지 않는다. 건수와 예외가 들어간 2차 일정을 같은 주에 박아 둔다.

외부 연계가 아직 안 열리면

스텁 시험을 합격으로 기록하되 실연계 재시험이 남아 있다고 조서에 쓴다. 스텁 합격을 실연계 합격으로 읽히게 두면 오픈 주에 싸운다.

환경 차이를 누가 확인하나

수행사 QA가 목록을 만들고 발주사 PM이 조서에 서명한다. 목록 없이 구두로만 같다고 하면 다음 주에 기억이 갈린다.

검수 환경 맞추기 - 개발과 운영이 다른 데이터가 합격하는 이유

검수 주간에 시나리오 40개가 초록이어도, 운영 첫 주 장애의 상당수는 환경 차이에서 난다. 개발 DB에는 정제한 샘플이 있고 운영에는 10년치 예외 코드가 산다. 같은 화면이 다른 데이터가 되면 그 합격은 샘플 합격이다. 스테이징 스키마가 운영보다 한 달 뒤처져 있으면 그 한 달이 사각이다. 점심을 고를 때 오늘뭐먹지는 카카오 평점과 리뷰 건수를 같이 본다. 점수만 높고 건수가 열 건이면 숫자는 아직 얇다. 검수도 합격 건수와 데이터 건수를 같이 적어야 한다. 이번 포스팅에서는 환경을 맞춰 검수하는 순서를 자세히 다뤄보도록 하겠습니다. 오픈 주 장애를 검수 주간에 보고 싶은 분들께 맞춰 적습니다.

다른 칸	샘플 합격에서 보이는 것	조서에 남길 문장
데이터 건수	화면이 빨리 열린다	기준일, 건수, 예외 코드 포함 여부
스키마 버전	컬럼이 맞다	운영 대비 미반영 변경 목록
배치 시각	낮에 초록	실제 마감 시각으로 재시험 여부
권한 세트	관리자 계정 통과	역할별 계정으로 재시나리오
외부 연계	스텁 응답	실호출 일정과 실패 시 처리

검수 환경이 운영과 다를 때 조서에 적을 칸

시나리오가 초록인데 운영에서 깨지는 이유는?

합격이 측정한 대상이 운영 데이터가 아니다. 샘플에서 초록이면 운영 예외는 아직 안 본 것이다.

검수 조서의 초록은 그 환경에서 그 데이터가 통과했다는 뜻이다. 개발에 고객 100명, 주문 500건을 넣어 두고 월말 정산을 돌리면 숫자는 깔끔하다.

운영에는 휴면, 병합, 마이너스 잔액, 중복 사업자번호가 같이 산다. 그 예외가 시나리오 문장에 없으면 검증(Validation)은 샘플만 본 셈이다.

오픈 다음날 현업이 들고 오는 화면은 검수 때 본 화면과 이름이 같다. 데이터가 다르다.

이름이 같다고 같은 시험이 아니다. 조서 첫 줄에 환경 이름과 데이터 기준일을 안 적으면, 나중에 그 초록을 재현할 방법이 없다.

재현이 안 되는 합격은 분쟁에서 증거로 쓰기 어렵다.

검수 환경에 무엇을 맞춰야 할까?

스키마, 코드 버전, 배치 시각, 권한 세트, 연계 스텁 여부. 다섯이 운영과 다르면 합격 범위를 조서에 적는다.

환경을 운영과 1밀리미터까지 같게 만들 수는 없다. 같게 만들 수 없는 칸을 숨기는 것이 문제다.

검수 계획서에 다섯 줄을 적는다. 스키마 버전, 배포 태그, 배치가 도는 시각, 시험 계정의 권한, 외부 연계가 실호출인지 스텁인지.

스텁으로 돌린 시나리오는 실연계 시나리오가 아니다. 그 사실을 조서에 안 쓰면 발주사는 실연계를 본 줄 안다.

QA vs QC로 말하면, QC는 그 환경에서 케이스를 닫고 QA는 그 환경이 운영을 대표하는지 본다. 대표하지 못하면 합격 옆에 제한 범위를 붙인다.

제한이 없는 초록은 운영을 보증하는 문장으로 읽힌다.

샘플 데이터로 합격하면 왜 위험한가?

샘플은 예외를 지운 데이터다. 예외를 지운 채로 돌린 배치는 운영 마감일에 다른 경로로 간다.

시험 데이터를 만들기 쉬운 방법은 운영에서 일부만 복사한 뒤 개인정보를 지우고 깨진 코드를 고치는 것이다. 고치는 순간 그 데이터는 운영이 아니다.

깨진 코드가 운영의 실제다. 깨진 코드를 살린 채 마스킹만 하는 복사본이 검수에 필요하다.

건수가 수백이면 배치 잠금, 타임아웃, 중복 키가 안 보인다. 건수가 수십만이어야 보이는 결함이 있다.

그 결함을 오픈 주에 처음 보면 안정화 기간이 잠식된다. WBS에 데이터 복제와 건수 검증을 한 칸으로 넣어 두지 않으면, 검수 직전 이틀에 복제를 시작한다.

이틀로는 깨진 코드의 분포를 못 본다. 분포를 못 본 합격은 운이다.

배치 시각과 권한 세트를 어디에 적나?

시나리오 옆에 실행 시각과 계정 역할을 붙인다. 낮 시간에 돌린 마감 배치는 마감 배치가 아니다.

월말 정산을 수요일 오후 3시에 돌리면 온라인 트랜잭션과 안 겹친다. 실제 마감은 밤 11시 이후, 온라인과 배치가 같은 락을 두고 기다린다.

낮에 초록인 배치가 밤에 멈추는 현장이 반복된다. 시나리오 문장 옆에 실행 시각을 적는다.

권한도 같다. 관리자 계정으로 합격한 화면을 지점 직원이 열면 버튼이 없다.

버튼이 없는 것은 결함일 수도, 설계일 수도 있다. 검수 계정 표를 역할별로 나누고 현업이 자기 역할로 사인하게 한다.

관리자 한 계정으로 40개 시나리오를 통과시키는 검수는 권한 시험을 생략한 검수다. 생략한 칸은 운영 첫 주에 헬프데스크로 돌아온다.

환경 차이를 주간보고에 어떻게 남기나?

이번 주 검수 환경이 운영과 다른 칸을 세 줄로 적는다. 다른 칸을 숨기면 다음 주 회의는 같은 초록을 다시 본다.

주간보고에 진척률만 있으면 환경 이슈는 이슈 목록 맨 아래로 내려간다. 검수가 시작된 주부터 보고 첫 칸을 바꾼다.

운영 대비 스키마 차이, 데이터 기준일, 실연계 여부. 세 줄이 비어 있으면 그 주의 초록은 참고 숫자다.

발주사가 이 세 줄을 요구하지 않으면 수행사는 안 적는다. 안 적은 차이가 오픈 날 장애 원인이 되면, 회의는 그때 환경을 기억으로 복원한다.

기억으로 복원하는 장애 분석은 길어지고, 그 사이 현업은 수작업으로 마감을 돌린다. 수작업이 사흘을 넘기면 시스템은 보조가 된다.

보조가 된 시스템의 사인은 이미 늦다. 차이를 매주 한 문장으로 남기는 편이 싸다.

숨긴 초록을 운영 첫 주에 재현하려면 그때의 데이터 기준일과 배포 태그가 남아 있어야 한다.