新しい機能を公開するたびに、既存の再生・ダウンロード・購入のフローも見直す必要がありました。キッズオーディオプラットフォーム K社で、繰り返されるリリース日程に合わせてQAを専任で担い、次の検証に活用するテスト資産を残した事例です。
オーディオサービスのアップデートを確認するとき、新しく追加した画面だけを見るのでは十分ではありません。利用者は、アップデート前に購入したコンテンツを再生し直すこともあれば、ダウンロードしておいたコンテンツを利用することもあります。
キッズオーディオプラットフォーム K社も、機能改善が続くなかで既存の体験を併せて点検する必要がありました。QAの専任人員がいない状況で、開発日程に合わせて検証を続ける仕組みが求められていました。
2019年から2020年にかけて進めたこのプロジェクトでは、オーディオサービスの重要フローを繰り返し検証し、リリースごとに結果を開発チームと共有しました。新機能の確認と既存機能の再確認を、同じリリース過程のなかに入れることが中心でした。
検証の基準は画面の数ではなく、コンテンツを利用するフローでした
コンテンツ一覧が表示され、再生ボタンを押せるという事実は出発点です。実際の利用過程には、コンテンツの購入と利用権、ダウンロードしたファイルの使用もつながっています。
プロジェクトでは、再生、ダウンロード、購入、利用権に応じたアクセスを主な検証対象としました。利用者がコンテンツを手に入れて利用するフローを中心にテストを構成したのです。
これらのフローは切り離して見ることが困難です。購入した結果がコンテンツ利用に反映されるかと、オーディオが再生されるかは、別の確認項目です。どちらか一方が正常だからといって、もう一方まで確認したことにはなりません。
サービスを長く検証するほど、こうした関係を記録しておくことが重要になります。新しい担当者が画面を初めて押しながら範囲を推測し直すのではなく、何と何をつなげて確認すべきかを引き継げなければなりません。
新しいリリースが出るたびに、以前の体験も確認し直しました
アップデートは、新機能を加えるだけの作業とは限りません。共通コードや連携部分が変われば、既存のフローも影響を受けることがあります。
K社のプロジェクトでは、続いていくリリースに合わせてQAを行い、回帰テストを継続しました。以前は正しく動いていた機能が変更後も維持されているかを、繰り返し確認する作業です。
回帰テストの意味は、同じ画面をとにかく何度も押すことにあるのではありません。利用者が頼り続けている重要フローを、次の変更でも見落とさないよう基準として保つことにあります。
新機能の完了だけを見る日程と、既存の体験まで併せて確認する日程は違います。プロジェクトでは、繰り返す検証をリリースの一部として扱うことで、この差を埋めました。
古い端末とOSも検証条件として扱いました
開発環境で使う端末と、実際の利用者が持っている端末は異なることがあります。特定の端末で確認した再生結果だけで、すべての利用環境を説明することはできません。
検証範囲には、古い端末とOSの組み合わせも含めました。合意したサポート環境で、重要フローがどのように動作するかを見たのです。
重要なのは、端末を多く揃えているという事実よりも、どの環境で何を確認したかをつなげることです。問題が起きた環境を説明できてはじめて、開発チームも同じ条件で確認し直せます。
サポート環境は、製品の変化とともに見直す必要があります。当時のリリースで確認した組み合わせが記録として残っていれば、以後のバージョンで維持する範囲と新たに加える範囲を比較できます。
見つけた問題は、修正に使える情報として伝えました
「音が出ない」という説明だけでは、原因を絞り込むことが困難です。再現条件と手順、確認した結果が揃っていてはじめて、修正作業につながります。
プロジェクトでは、欠陥を重要度と再現情報で整理して共有しました。検証の日程と実行、結果報告を、繰り返されるリリース過程に合わせて運用しました。
検証の役割は、問題を見つけるところで終わりません。開発チームが確認し直して対応できるように、情報を伝えなければなりません。特に複数のリリースが続くときは、どの問題がどの時点で確認されたかを追跡できてこそ、議論が混ざりません。
欠陥の数を成果として前面に出すよりも、見つけた問題が実際に扱われる記録として残ったかが重要でした。同じ問題を毎回最初から説明しなくて済むようにすることも、継続的なQAの役割です。
繰り返した検証は、次の人が引き継げる資産として残しました
遂行の過程で、テスト戦略と主要シナリオ、繰り返す検証に使う記録を整理しました。終了後も重要フローを確認し直せるように、テスト資産を引き継ぎました。
専任の人員が働いているあいだ検証量を確保することと、その人が去ったあとも基準が残ることは、別の結果です。K社のプロジェクトでは、目の前のリリース対応とともに、後続の検証に活用できる基盤を残しました。
テスト資産は、次のリリースの準備を助けます。どのフローを繰り返し確認したか、どの条件で問題が現れたかを引き継げば、検証の出発点を毎回新たに作る必要がなくなります。
新しい機能を出し続けるサービスには、既存の体験を確認し続ける過程も必要です。 K社の事例は、一度きりの点検を越えて、リリースが続く期間を通じて検証の基準を保った経験です。
