「まもりあいJapan」の品質をまもるためにやったこと

はじめまして、モンスター・ラボ の山下と申します。

接触確認アプリ「まもりあいJapan」プロダクト開発チームでテストを担当しました。普段は、テスター・ラボのマネージャとしてテストサービス提供をさせていただいております。

「まもりあいJapan」は5/18にコードを公開しました。このプロジェクトの当初のミッションは、このアプリを安全な形で迅速にリリースすることでした。この中でのテストチームの取り組みについて共有させていただきます。「まもりあいJapan」の開発経緯に関しては、以下をご参照ください。
「接触確認アプリ「まもりあいJapan」開発の経緯と今後について」

まずやったこと ： テスト方針と計画

本当に短期間での開発・テストであったため、課題も多くテストスコープを確定することも難しいものでした。
まずは、ざっくりとしたテスト計画を作成しました。作成したテスト計画では、テストフェーズの定義を行い、フェーズ分類とそれぞれの目的とテスト実施環境（設備・サーバーなど）を明らかにし、テスト準備や実施にかかる開発チームの役割分担を示しました。テストフェーズごとに実施するテストの種類とテスト手法は下表のようにしました。

すべてのテストを通して言えることですが、短期間で必要なテストを効果的に実施するか、については大きな課題でありました。また、重要な要素となるBLE通信まわりについては、新規性の高い技術利用という点で懸念がありました。

つぎにやったこと ： 具体的なテスト内容検討

上記で示したそれぞれのテスト種類でどのようなテストをしたのかをご説明します。テスト内容を確定させていくには、開発者やPM、ステークホルダーとコミュニケーショをとりながら確定させていきます。なぜPMだけで確定しないのか。PMが確定することが最適ではないか、という意見の方もいると思います。しかし、ステークホルダー毎に重視する品質が異なるのです。それぞれの思う品質をヒアリングすることが大切です。ヒアリングした内容をすべて盛り込むことは、限られた時間で実施することは不可能です。ヒアリングした内容を踏まえて調和のとれた内容に落とし込み、ステークホルダーに納得してもらうこともテスト担当の重要な役割の1つです。単純に中間的な意見を採用するのではなく、当然ながら品質の観点で「このプロジェクトではどのような品質を担保しなければならないのか」をきちんと説明して納得してもらうことが前提となります。
機能テストでは、細かな組み合わせ・パターンを詳細に掘り下げたテストではなく、必要な最小限での実施としました。重要度の選定には、開発者へのヒアリングが重要であり、Q＆Aを頻繁に行いました。ときには、デザインチームのFigmaの情報が非常に有効でした。
シナリオテストでも代表的なユースケースに絞り込んで行いました。
負荷テストでは、リリース直後またリリースして数カ月後を想定し、200万人以上のユーザが利用する状況においてピーク時であってもシステムが正常に応答を返すことを目的に確認しました。なお負荷テストツールは「locust」を利用しました。
セキュリティテストでは、OWASPテストガイドのTOP10に基づいて、内部のペンテストを含む現在の業界のベストプラクティスと比較して、モバイル・API・管理画面のWeb Frontendのセキュリティテストをしました。
フィールドテストでは、実際に利用する環境（場所・規模・人数）でユースケースに基づいた確認を行う予定でした。環境は下表のようなものを想定しました。

結果として、フィールドテストは実施しない（我々がリリースすることがなくなったため）ことになりましたが、オレンジの枠で囲んだ要素として、シナリオテストに含める形で実施することができました。テスト結果は、「「まもりあいJapan」 開発試行錯誤の裏話 前編」にてご確認ください。

課題

◆ 課題① テスト設計の元となるべきテストベースが存在しない

テストベースが全くなかったわけではありませんが、通常のプロジェクトに比べるとドキュメント化されている情報が極めて少ない状況でありました。
テストベースとは、テストケースの基となるドキュメントや情報です。これはテストのスコープによりさまざです。また、必ずしもドキュメントとして明文化されたものだけではありません。会議の議事メモやメールでのやり取り、ホワイトボードでの開発メモなども含みます。

対応：
まずは仕様に関する情報を集め、テスト観点の洗い出しをしました。標準的な観点に加えて、自身の経験や ”こうあるべき” という観点です。これを基にしてテスト設計を作成しました。テスト設計を進めていく中で仕様があいまいな点、いくつか矛盾点の指摘を挙げることができました。

◆ 課題② 仕様が日々頻繁に変更すること

特に開発終盤では、日次ベースで仕様の変更が起こりました。開発の成果物においてトレーサビリティ（追跡可能性）を確保しておかなければ、一貫性と整合性を保った製品開発はできないと言われています。これは、テストベースとテスト設計の結果であるテストケースにおいても同様です。トレーサビリティが確保できている状態であれば変更があってもテストケースのどこを変更すべきかは容易に把握することができます。逆にトレーサビリティが確保できていないこと自体が致命的な欠陥を内在する要因となることもあります。
本来であれば、トレーサビリティマトリクスを作成したり、要求管理ツールやALM(Application Lifecycle Management) ツールを導入したりします。

対応：
今回は、ツール導入などできませんので開発チームのdaily meetingが生命線となりました。そこではMiroというオンラインホワイトボードがとても重宝しました。このオンラインホワイトボードで仕様に関する共有が迅速に行われました。

今回の体験を通して学んだこと

上記で示したようなテストベースがない、仕様変更が頻繁に起こるプロジェクトでは、早い段階からテスト担当をアサインすることが重要だということです。これは整合性・一貫性の担保にも繋がります。
今回の場合、ある程度開発が進行したところでの参画でしたがもっと早い段階つまり仕様を詰めるところの参画には、
　・仕様に関するインストールが不要となる
　・仕様に関するQ＆Aの工数が削減できる
　・仕様の矛盾点をテスト工程よりも前に発見することができる
などの利点があります。
一般的なことですが、手戻りコストの観点から、可能な限り上流で欠陥の修正をすること（いかに品質を作り込むか）が品質管理はもとよりコストコントロールのポイントとも言えます。

「1：10：100の法則」と言われる、設計の段階でミスを修正するコストを1とすると、開発後のテストでバグを直すコストは10倍、さらに運用時に発生したバグを修正するには設計時の100倍以上かかる、という法則があります。

また、今回の活動を通して、改めてテスターとは？品質担保とは？ということについて深く考える機会となりました。それは基本となる「行動規範」からはじまります。
以下、JSTQBでの行動規範に記載されている内容です。
※ JSTQB　日本におけるソフトウェアテスト技術者資格認定の運営組織で、 各国のテスト技術者認定組織が参加しているISTQB（International Software Testing Qualifications Board）の加盟組織として認定されています。

ソフトウェアテストの技術やソフトウェア関連の技術は時代とともに変化し、増え続けています。ソフトウェアテストの専門家として、その技術を学び、自分たちの技術として身につけて実践していかなければなりません。技術はその活用のための倫理的な視点も重要になります。
倫理的な視点がないと、本来の目的と異なったことを効率化するためにも使えてしまうからです。テスト技術者とは、生涯をかけて学習し、倫理観を持って実践していく事が必要な職業ともいえるでしょう。

テストに関わる私たちは、品質という一見目に見えないものを扱っています。それは「倫理的なアプローチ」で推進される必要があり、公共の利益に寄与する形で専門職として地位向上に努めなければならない、とされています。

さいごに

Code for Japan が「まもりあいJapan」をリリースすることはなくなりましたが、この活動を通じてさまざまな方々と協力し、試行錯誤しながら日本での接触確認アプリの土台作りに参加できたことを光栄に思います。
関係者のみなさまに大きな感謝と尊敬の念を抱かずにはいられません。この場をお借りして御礼申し上げます。本当にありがとうございました。
日本における今後の取り組みは厚生労働省主幹で進められますので、最短でのリリースに向けてシビックテックの力で貢献させていただきたいと思います。