기능 목록이 길면 문장도 길어져야 하나

목록마다 네 칸이면 된다. 문장을 늘리기보다 예외 한 줄이 비었는지를 본다. 예외가 0줄이면 목록이 길어도 목차다.

정성 항목은 어떻게 합격으로 적나

편한 화면처럼 적지 않는다. 클릭 수, 필수 안내 문구, 제한 시간과 같이 두 사람이 같이 볼 수 있는 조건으로 바꾼다.

검수 주에 문장을 고쳐도 되나

오타와 증적 파일명 정정은 된다. 기대 결과가 바뀌면 범위 변경이다. 변경은 조서 통과 칸이 아니라 변경 목록으로 보낸다.

수행사 자체 시험 통과를 검수로 써도 되나

자체 시험은 확인 절차다. 고객이 기대 결과에 사인하지 않았으면 인수 판정이 아니다. 사인 주체가 다르면 문서도 나눈다.

검수 문장 다시 쓰기 - 정상 동작 한 줄을 시나리오 합격 기준으로

검수 조항 1줄이 정상 동작이면, 그 문장은 합격 기준이 아니다. 현업은 화면이 뜨면 통과라 읽고, 수행사는 예외가 없으면 통과라 읽는다. 두 읽기가 한 조서에 남아 있으면 사인 직전에 시나리오를 다시 쓰게 된다. 기능 목록 40개 중 예외가 적힌 줄이 0이면, 그 목록은 검수 대본이 아니라 화면 목차다. 입력값, 기대 결과, 증적 파일명, 예외 한 줄이 빠진 칸은 검수 주간에 회의로 돌아온다. 목차로 사인하면 운영 첫 주에 예외가 결함으로 들어온다. 빠진 칸을 착수 때 문장으로 고치는 순서와, 조서에서 누가 고칠지를 적는다. 검수 문장이 한 줄인 제안서를 보고 있다면 시나리오 합격 조건부터 다시 보면 된다.

칸	적을 내용	빠지면 회의에서 나오는 말
입력값	계정, 금액, 상태처럼 재현 가능한 값	아무 데이터나 넣으면 되죠
기대 결과	화면에 남아야 하는 값과 거절 문구	뜨면 된 것 아닌가요
증적	파일명, 건수, 처리 시각	캡처는 있는데 비교가 안 됩니다
예외	거절되어야 하는 입력 한 줄	운영에서 처음 봅니다
확인자	실행자와 다른 이름	본인이 통과로 적었습니다

검수 문장에 남을 네 칸

정상 동작은 왜 합격 기준이 못 될까?

정상은 사람마다 다르다. 합격은 입력과 기대 결과가 적힌 문장에서만 갈린다.

검수 회의에서 정상 동작을 두고 40분이 가는 일이 있다. 화면이 열리면 현업은 정상이라 하고, 필수값이 비어 있는데 저장이 되면 수행사는 설계대로라고 한다.

둘 다 문장을 어기지 않았다. 문장에 금지 조건이 없기 때문이다.

검증(Validation)은 고객이 사인하는 확인이다. 사인할 문장이 형용사이면 확인은 취향이 된다.

취향으로 열린 회의는 결함 건수를 늘리지 않는다. 결함 대신 해석 차이가 쌓인다.

해석 차이는 결함 대장에 등급이 없어 주간 지표에서 빠진다. 지표에서 빠진 차이가 검수 마지막 주에 한꺼번에 조서로 들어온다.

마지막 주에 문장을 고치면 테스트는 이미 끝난 뒤다.

시나리오 합격 문장은 무엇을 담아야 할까?

입력값, 기대 결과, 증적 파일명, 예외 한 줄. 네 칸이 없으면 시나리오가 아니다.

합격 문장은 길 필요가 없다. 네 칸이면 된다.

어떤 값으로 시작하고, 화면에 무엇이 남아야 하며, 어떤 파일명으로 증적을 남기고, 거절되어야 하는 입력은 무엇인가. 예를 들면 금액 0원 저장은 거절이고, 거절 메시지의 문구까지 적는다.

문구를 적지 않으면 메시지 코드만 바뀐 빌드가 통과한다. 요구사항 식별 단계에서 예외를 말로만 듣고 명세에 안 남기면, 검수 문장은 본 경로만 담게 된다.

본 경로 20건이 모두 통과해도 운영의 첫 민원은 거절 경로에서 난다. 거절 경로를 시나리오 번호로 빼 두면, 빠졌는지가 목록 길이로 보인다.

목록 길이가 본 경로와 같으면 예외가 빠졌다고 의심하는 편이 맞다.

증적이 스크린샷뿐이면 검수에서 무엇이 빠질까?

스크린샷은 화면의 한 순간이다. 데이터 건수와 처리 시각이 없으면 재현이 안 된다.

조서에 캡처 40장이 첨부되어 있어도 합격의 근거가 약한 경우가 있다. 캡처에는 조회 조건과 총 건수가 잘려 있다.

잘린 캡처는 다음 날 같은 화면을 열어도 비교가 안 된다. 증적 최소 세트는 세 가지다.

조건이 보이게 찍은 화면, 결과 건수나 합계가 적힌 파일, 처리 시각이 남는 로그 한 줄. 로그를 남기지 못하는 화면은 그 이유를 시나리오에 적는다.

이유를 적지 않으면 없는 증적이 통과로 처리된다. QA vs QC를 한 팀이 겸하면 증적 체크가 테스트 실행과 같은 손으로 끝난다.

같은 손은 자기 캡처를 빠짐으로 보기 어렵다. 증적 칸의 확인란은 실행자와 다른 이름이 적혀야 한다.

이름이 같으면 그 칸은 아직 비어 있는 것과 같다.

예외 경로를 빼면 어느 주에 터질까?

예외는 설계 주간이 아니라 검수 주간이나 운영 첫 주에 터진다. 빠를수록 고치는 손이 적다.

예외를 나중에 보자고 미루면 나중은 대개 두 자리다. 검수 3일 차, 아니면 오픈 다음 월요일.

검수 3일 차에는 이미 시나리오 일정이 짜여 있어 문장을 추가하면 일정이 늘어난다. 오픈 다음 월요일에는 그 예외가 결함이 아니라 장애 티켓이 된다.

장애 티켓으로 들어온 규칙은 원래 요구였는지 변경인지를 다시 싸운다. 싸움을 줄이려면 예외 문장을 설계 확정 주에 넣는다.

그 주에 현업이 예외를 모르면, 모른다는 사실 자체를 미확정 목록에 남긴다. 미확정은 합격이 아니다.

미확정을 공란으로 두면 공란은 해당 없음으로 읽힌다. 해당 없음과 아직 모름은 조서에서 다른 표시를 써야 한다.

표시를 나누지 않으면 검수율은 빨리 오르고, 운영 이슈는 그 속도로 따라온다.

조서의 문장은 누가 고쳐야 할까?

수행사가 초안을 쓰고, 발주사 현업이 기대 결과를 고친다. 고친 사람 이름이 버전이다.

문장 수정을 수행사에게만 맡기면 기대 결과가 구현 가능한 쪽으로 기울다. 현업에게만 맡기면 화면 제약 없는 문장이 된다.

순서는 고정하는 편이 낫다. 수행사가 입력값과 증적 칸을 채운 초안을 내고, 현업이 기대 결과와 예외만 고친다.

고친 뒤에 양쪽 이름이 적힌 버전을 기준선으로 둔다. 이름이 없는 수정은 회의 중 구두 합의로 남는다.

구두 합의는 다음 빌드에서 사라진다. 기준선 이후의 문장 추가는 검수 범위의 증가이므로 변경 목록에 올린다.

변경 목록에 없는 추가는 당일 시나리오로 끼어들어 증적이 빈다. 빈 증적으로 사인하면 그 줄은 통과가 아니라 미실시다.

미실시를 통과로 세지 못하게 집계 식을 조서 하단에 적는다.