기사가 외부에 공개되기 전까지: CMS 뉴스룸의 출시 전 QA

예쁜 기사 페이지보다 먼저, 공개까지의 흐름을 봤습니다

뉴스룸의 결과물은 독자가 보는 페이지입니다. 그러나 그 페이지가 언제 어떤 상태로 공개되는지는 편집 과정에서 결정됩니다.

예약된 글이 정해진 조건에 맞게 발행되는지, 수정이 의도한 페이지에 반영되는지, 역할이 다른 사용자가 필요한 작업을 수행할 수 있는지 봐야 합니다. 단순히 페이지가 열린다는 사실과는 다른 질문입니다.

이번 검수에서는 작성·승인·발행·수정·예약 발행을 핵심 흐름으로 정했습니다. 발행된 페이지의 표시와 계정 권한도 함께 확인했습니다.

이렇게 범위를 정하면 기능 목록보다 편집 업무를 중심으로 결과를 읽을 수 있습니다. 문제가 발생했을 때 어느 단계의 작업에 영향을 주는지 연결해서 볼 수 있기 때문입니다.

5영업일의 검수는 범위를 정하는 데서 시작했습니다

짧은 일정의 QA에서는 무엇을 확인할지 먼저 합의해야 합니다. 범위가 정해지지 않으면 테스트를 많이 했더라도 무엇을 근거로 공개 여부를 판단할지 모호해질 수 있습니다.

P사에서는 착수 전 검수 범위를 서면으로 확정하고 5영업일 안에 실행했습니다. 공개 전에 필요한 확인을 일정 안에서 수행하도록 준비한 것입니다.

이 기간은 모든 CMS 프로젝트에 동일하게 적용되는 일정이 아닙니다. 기능 수와 환경, 제공되는 자료, 수정과 재검증의 범위에 따라 필요한 시간은 달라질 수 있습니다.

이 사례는 빠르게 끝냈다는 사실만 남은 프로젝트가 아닙니다. 정해진 일정과 합의한 범위를 함께 설명할 수 있도록 검수를 구성했습니다.

역할별 접근과 독자가 보는 결과를 함께 확인했습니다

편집 업무에는 권한의 차이가 있습니다. 작성할 수 있는 사람과 승인할 수 있는 사람, 공개된 기사를 읽기만 하는 사람을 같은 조건으로 확인할 수는 없습니다.

검수에서는 권한이 없는 계정의 접근 범위를 살피고 발행된 페이지가 브라우저별로 의도대로 표시되는지도 확인했습니다.

두 검증은 보는 위치가 다릅니다. 역할별 접근은 어떤 작업을 허용하는지에 관한 질문이고 브라우저 표시는 공개된 결과가 어떻게 전달되는지에 관한 질문입니다.

뉴스룸이 편집 도구이면서 공개 웹사이트라는 점에서 두 가지가 함께 필요합니다. 내부의 발행 과정과 외부의 읽기 경험을 이어서 보는 방식입니다.

‘오류가 있습니다’를 수정 가능한 기록으로 바꿨습니다

확인한 결함에는 심각도와 재현 조건을 붙였습니다. 검수 결과에는 확인하지 못한 영역과 범위 밖에 둔 부분도 함께 담았습니다.

모든 문제를 같은 크기로 나열하면 개발팀은 다시 우선순위를 판단해야 합니다. 재현에 필요한 정보가 부족하면 원인을 찾기 전에 상황부터 다시 설명해야 할 수도 있습니다.

따라서 검수 결과는 오류를 발견한 기록이면서 수정할 작업을 정리하는 자료가 돼야 합니다. 어떤 조건에서 문제가 발생했는지와 공개에 어떤 영향을 줄 수 있는지를 함께 읽을 수 있어야 합니다.

이번 결과물도 공개 여부와 수정 순서를 판단하는 근거로 남겼습니다. 검수가 완료됐다는 사실만으로 모든 결함의 수정이나 최종 출시까지 완료됐다고 확대하지는 않습니다.

공개 여부를 논의할 수 있는 자료를 만들었습니다

P사에는 합의한 범위의 검수 결과와 결함 목록, 미확인 영역이 남았습니다. 일정 안에서 무엇을 확인했는지뿐 아니라 무엇까지는 말할 수 없는지도 함께 정리했습니다.

출시 전 QA는 막연한 안심을 주는 일이 아닙니다. 확인한 동작과 남은 문제를 바탕으로 공개 전에 무엇을 조치하고 어떤 조건을 받아들일지 논의할 수 있게 합니다.

뉴스룸의 품질은 기사 페이지의 모양뿐 아니라, 원고가 공개되는 과정에도 있습니다. 이번 검수는 그 과정을 독립적으로 확인하고 판단 자료로 남긴 프로젝트입니다.