처리 중 오류 한 문장으로 통일하면 단순한가

화면 구현은 짧아진다. 조치가 다른 실패가 한 문장이면 상담과 재시도는 더 길어진다. 통일의 기준은 조치다.

오류 문구는 디자인 검수에 넣나

길이 확인은 디자인에서 해도 된다. 합격 기준은 코드와 문장, 다음 행동이 시험 케이스에 있는가다.

사용자 문장에 오류 코드를 보여 줘도 되나

코드만 보여주고 문장이 없으면 사용자는 여전히 모른다. 문장이 있고 코드를 옆에 두면 상담 연결이 된다.

오픈 후 어미만 바꾸면 재시험인가

조치와 재시도 여부가 그대로면 문구 수정이다. 다음 행동이 바뀌면 기대 결과를 고치고 다시 시험한다.

오류 문구 목록 만들기 - 사용자 메시지 없이 검수가 안 닫히는 이유

오류 코드가 없으면 사용자는 실패 이유 없이 빈 화면만 본다. 같은 저장 실패라도 권한 없음, 중복, 마감 초과, 연계 지연은 조치가 다르다. 그런데 메시지가 모두 처리 중 오류가 발생했습니다로 같으면 상담원은 원인을 물을 곳이 없다. 개발자는 로그를 보고 알고, 현업은 전화로 묻는다. 그 간격이 오픈 첫 주 콜 수를 늘린다. 오류 문구는 디자인 마감이 아니다. 코드, 사용자 문장, 상담 스크립트, 재시도 가능 여부가 한 목록에 있어야 검수가 닫힌다. 목록을 언제 확정하고 시험에 어떻게 넣는지, 오픈 뒤 문구 변경은 어디로 보내는지 적는다.

칸	비어 있으면	닫는 사람
코드 번호	같은 문장을 추적 못 함	개발
사용자 문장	빈 화면만 보임	업무 오너
상담 한 줄	전화가 추측이 됨	상담 운영
재시도 여부	중복 저장이 늘어남	업무 오너와 개발
로그에만 둘 상세	테이블 이름이 화면에 노출	개발

오류 문구 목록에서 비우면 안 되는 칸

같은 실패를 왜 한 문장으로 두나

처리 중 오류 한 문장은 개발에는 편하고 상담에는 빈칸이다. 조치가 다르면 문장도 달라야 한다.

저장 실패를 한 문장으로 묶으면 예외 처리 코드는 짧아진다. 짧아진 대가로 사용자는 다시 누르면 되는지, 관리자를 찾아야 하는지 모른다.

다시 눌러도 되는 중복과, 눌러도 안 되는 마감 초과가 같은 문장이면 사용자는 다섯 번 누른다. 다섯 번의 재시도는 로그를 더럽히고, 상담 전화는 같은 질문을 반복한다.

오픈 첫 주 콜이 느는 이유 가운데 이 문장이 있다. 목록을 만들 때 기준은 예외 클래스 이름이 아니라 사용자 조치다.

다시 입력, 나중에 재시도, 관리자 요청, 다른 화면으로 이동. 조치가 네 갈래면 문장도 네 갈래다.

QA vs QC가 결함의 기대 결과를 이 문장으로 적지 않으면, 시험은 에러가 안 나면 합격이 된다. 에러가 안 나는 시험은 실패 경로를 안 본 시험이다.

목록에는 어떤 칸이 있어야 하나

코드, 사용자 문장, 상담 한 줄, 재시도 여부, 로그에만 남길 상세다. 문장만 있으면 목록이 아니다.

코드가 없으면 같은 문장을 나중에 고쳐도 어디를 고쳤는지 추적되지 않는다. 사용자 문장에 스택 추적이나 테이블 이름을 넣지 않는다.

그 정보는 로그 칸으로 보낸다. 상담 스크립트는 사용자 문장 다음에 상담원이 물어볼 한 가지를 적는다.

어느 메뉴였는지, 몇 시에 눌렀는지. 물어볼 것이 세 개 이상이면 문장이 아직 거칠다.

재시도 가능 여부는 예 아니오로 적는다. 애매하면 사용자가 다시 누르고, 서버는 중복 저장을 만든다.

목록의 행 수는 화면 수와 같지 않아도 된다. 저장, 결재, 연계, 권한, 마감처럼 공통 실패를 먼저 20행으로 닫고, 화면 전용 문장은 그 다음에 붙인다.

20행이 없는 상태에서 화면 200개의 문구를 쓰면 표현만 달라지고 조치는 같다.

시험에는 어떻게 넣나

정상 시나리오 옆에 실패 한 줄을 붙인다. 기대 결과는 코드와 사용자 문장이 같이 보여야 합격이다.

정상 흐름 40개만 있는 검수는 실패를 운에 맡긴다. 각 업무에 실패 한 줄이면 충분하다.

권한 없는 계정으로 저장, 마감 이후 저장, 연계 중단 중 저장. 기대 결과에 코드 번호와 화면에 보인 문장을 같이 적는다.

코드만 맞고 문장이 임시 문장이면 불합격이다. 검증(Validation)에서 현업이 그 문장을 읽고 다음에 무엇을 할지 말하면 합격에 가깝다.

읽어도 다음 행동을 모르면 문장을 다시 쓴다. 다시 쓰는 시점이 오픈 주면 번역과 화면 길이, 상담 스크립트가 같이 밀린다.

그래서 문구 확정은 시험 설계와 같은 주다. 설계가 끝난 뒤에 문구를 바꾸면 케이스의 기대 결과가 전부 옛 문장으로 남는다.

옛 문장으로 남은 케이스는 자동 비교에서 전부 실패로 보인다. 그 실패는 결함이 아니라 기준 변경이다.

상담 스크립트와 화면 문장이 다르면

사용자가 보는 문장과 상담원이 읽는 문장의 코드가 같아야 한다. 코드가 다르면 전화 응대가 추측이 된다.

화면에는 잠시 후 다시 시도해 주세요가 나오고, 상담 매뉴얼에는 연계 기관 장애라고 적혀 있으면 상담원은 화면을 믿을지 매뉴얼을 믿을지 고른다. 고르는 동안 사용자는 기다린다.

코드 E-204가 화면과 매뉴얼에 같이 있으면 상담원은 매뉴얼의 그 행만 읽으면 된다. 행에는 사용자에게 말할 문장과, 내부적으로 볼 로그만 있으면 된다.

내부 로그 위치를 사용자 문장에 적지 않는다. 운영 첫 주에는 이 목록을 상담 좌석에 한 장 둔다.

좌석에 없는 목록은 개발자 메신저로 다시 묻게 된다. 메신저로 묻는 오류는 통계에 안 남는다.

안 남은 오류는 다음 릴리스의 문구 개선으로도 안 들어온다. 주간에 코드별 발생 건수를 10건만 뽑아 봐도, 한 문장으로 뭉친 실패는 그때 갈라진다.

오픈 뒤 문구를 고치면 변경인가

오탈자와 길이 조정은 문구 수정이다. 조치가 바뀌거나 재시도 여부가 바뀌면 변경으로 다시 시험한다.

오픈 후 문장이 딱딱하다는 의견은 곧 온다. 어미를 다듬는 일은 코드와 조치가 그대로일 때 문구 수정으로 받는다.

다시 시도해 주세요를 관리자에게 문의하세요로 바꾸면 조치가 바뀐 것이다. 조치가 바뀌면 상담 스크립트와 시험 기대 결과가 같이 바뀐다.

그 변경을 장애 채널에 넣으면 30분 안에 문장만 배포하고 스크립트는 옛 것으로 남는다. 변경관리 항목에 코드 번호, 옛 조치, 새 조치, 재시험 케이스 번호를 적는다.

네 칸이 없으면 문구 커밋은 조용히 나간다. 조용히 나간 문장은 다음 날 상담 품질에서 불일치로 돌아온다.

공통 문장 한 줄의 수정은 그 문장을 쓰는 화면 수를 먼저 센다. 40개 화면이 같은 코드를 쓰면 수정은 40곳의 확인이다.

한 곳만 보고 배포하면 나머지 39곳은 옛 문장과 새 문장이 같이 운영된다. 옛 문장이 남은 화면은 상담 스크립트가 어느 화면 기준인지부터 다시 묻게 된다.

기준이 두 개면 응대도 두 개가 된다.