執筆者と承認者、読者がそれぞれ異なる画面を使うニュースルーム。P社の公開を控え、執筆・承認・公開・修正・予約公開を検証し、権限とブラウザ表示も併せて確認して、5営業日で結果をまとめました。
ニュースルームでは、記事が一本読者に届くまでにいくつもの状態を経ます。執筆中の原稿と承認済みの記事、予約された記事とすでに公開された記事は、同じ文書であっても異なる扱いが必要です。
公開ページのデザインだけを確認しても、この過程はわかりません。記事を書く人、承認する人、読む人は、それぞれ異なる立場からサービスを使うからです。
CMSで構築されたニュースルームP社のリリース前検証は、この公開の過程を中心に進めました。IXCは制作と切り離された検証の役割で、外部公開の前に確認する範囲を定めて実行しました。
見栄えのよい記事ページより先に、公開までの流れを見ました
ニュースルームの成果物は読者が見るページです。しかし、そのページがいつ、どの状態で公開されるかは編集の過程で決まります。
予約された記事が定めた条件どおりに公開されるか、修正が意図したページに反映されるか、役割の異なるユーザーが必要な作業を行えるかを見なければなりません。単にページが開くという事実とは別の問いです。
今回の検証では、執筆・承認・公開・修正・予約公開を重要フローと定めました。公開されたページの表示とアカウント権限も併せて確認しました。
このように範囲を定めると、機能一覧ではなく編集業務を中心に結果を読めます。問題が起きたとき、どの段階の作業に影響するのかをつなげて見られるからです。
5営業日の検証は、範囲を定めるところから始まりました
短い日程のQAでは、何を確認するかを先に合意する必要があります。範囲が定まっていなければ、テストを多く行っても、何を根拠に公開可否を判断するのかが曖昧になりかねません。
P社では、着手前に検証範囲を書面で確定し、5営業日で実行しました。公開前に必要な確認を日程の中で行えるよう準備したのです。
この期間は、すべてのCMSプロジェクトに同じように当てはまる日程ではありません。機能の数と環境、提供される資料、修正と再検証の範囲によって、必要な時間は変わり得ます。
この事例で注目すべき点は、早く終えたという事実だけではありません。定めた日程と合意した範囲を一緒に説明できるように、検証を構成しました。
役割別のアクセスと読者が見る結果を併せて確認しました
編集業務には権限の差があります。執筆できる人、承認できる人、公開された記事を読むだけの人を、同じ条件で確認することはできません。
検証では、権限のないアカウントのアクセス範囲を調べ、公開されたページがブラウザごとに意図どおり表示されるかも確認しました。
二つの検証は見る位置が異なります。役割別のアクセスはどの作業を許可するかという問いであり、ブラウザ表示は公開された結果がどう届くかという問いです。
ニュースルームが編集ツールであると同時に公開ウェブサイトである以上、この二つが併せて必要です。内部の公開過程と外部の閲覧体験を続けて見る方法です。
「エラーがあります」を修正できる記録に変えました
確認した欠陥には重要度と再現条件を添えました。検証結果には、確認できなかった領域と範囲外に置いた部分も併せて記しました。
すべての問題を同じ大きさで並べると、開発チームはあらためて優先順位を判断しなければなりません。再現に必要な情報が足りなければ、原因を探す前に状況から説明し直すことにもなりかねません。
したがって検証結果は、エラーを見つけた記録であると同時に、修正する作業を整理する資料でなければなりません。どの条件で問題が起きたのかと、公開にどんな影響を及ぼし得るのかを、一緒に読めるようにする必要があります。
今回の成果物も、公開可否と修正の順序を判断する根拠として残しました。検証が完了したという事実だけをもって、すべての欠陥の修正や最終リリースまで完了したと広げることはしません。
公開可否を議論できる資料をつくりました
P社には、合意した範囲の検証結果と欠陥リスト、未確認領域が残りました。日程の中で何を確認したかだけでなく、どこまでは言えないのかも併せて整理しました。
リリース前QAの価値は、漠然とした安心を与えることにはありません。確認した動作と残った問題をもとに、公開前に何を対処し、どの条件を受け入れるかを議論できるようにすることにあります。
ニュースルームの品質は、記事ページの見た目だけでなく、原稿が公開される過程にもあります。今回の検証は、その過程を独立した立場で確認し、判断資料として残したプロジェクトです。