アプリ納品時に泣かないための受け入れテストの基礎知識：Androidアプリ開発テスト入門（終）（2/3 ページ）

[生路茂太，日本Androidの会テスト部]

解決策【1】受け入れテスト項目のための要求獲得

　これまでテスト設計などを専業で行ってきた方にとっては、テスト設計とは機能仕様書やマニュアル／ヘルプなどから分析的に受け入れテストの作成をされた場合が多いのではないでしょうか。

　Androidアプリであっても、こうした大まかな流れに間違いはないのですが、問題はWebやクリエイティブのような制作業界においては仕様化やドキュメント作成に十分なリソースが割かれることが少なく、感覚的な受け入れ基準が前提となっていることです。

　これはどういうことかというと、これまでソフトウェア開発の分野においては、要求仕様と実装と受け入れテストのそれぞれは、「発注側サービス担当者」「受注側開発エンジニア」「発注側受け入れテスト担当者」といったように分担されることが前提となっていたかと思います。しかし、Androidアプリ開発においては、「受発注の二人三脚で要求仕様を獲得しながらテスト設計を並行して受け入れ基準の合意していく必要がある」ということです。

企画書と画面遷移図からユースケースを抽出

　さて、読者の皆さんは普段は、どのようなプロセスでAndroidアプリの開発を行っていますでしょうか。筆者自身の経験や他案件の観察から気付いた、よくあることは、「企画書と画面遷移図からデモ実装に入り、それがそのまま本流として扱われ、発注側の感覚的な受け入れテストや隠れたマーケット側のリスクを突破できずに撃沈する」パターンです。

　これは、既存のWeb制作やクリエイティブ制作では、むしろ実績のある正統的なプロセスだったことが、この悲劇に拍車を掛けているようです。将来は改善しているかもしれませんが、発注側にソフトウェアエンジニアリングのQCD（Quality：品質、Cost：予算、Delivery：納期）の感覚がなく、受注側にマーケティングやクリエイティブの感覚がない状態は今後しばらく続くと思います。

　こうした状態を前提に受け入れテストを実現するためには、相互理解の中間地点として「ユースケース」という概念を導入する必要があるように思います。具体的なアウトプットとしては企画書と「画面遷移図」からUMLの「ユースケース図」が書き出せれば理想的です。

ユースケース図 - ＠IT情報マネジメント用語事典 via kwout

　作業は受発注側どちらでもいいので、ユースケースを介して対象プロダクトに対する要求が共有する必要があります。最近はいきなり「ロバストネス図」を描く場合もあるようですが、受発注間で要求の共通認識を作るという意味ではユースケース図である必要性があります。

ユースケースの理由を書き出すことで発注側の暗黙知を共有

　次が重要なのですが、開発対象のプロダクトに各ユースケースが必要な理由を丁寧に説明していきます。

　現在の受発注間で起こっている“すれ違い”の多くは、「理由」というメタ情報の共有不足によって起こるケースが多いように思います。この「要求」と「理由」の関係を整理するために、「USDM（Universal Specification Description Manner）」記法が非常に有効的です。

　USDMは、もともと組み込みソフトウェアの上流工程で生まれ、その後も前述のJUASのUVCプロジェクトなどを通じてSIerの上流工程にも応用されました。書籍『要求を仕様化する技術・表現する技術』が原典ですが、組み込み出身の方はご存じの方も多いと思います。筆者も組み込み向けライブラリの開発からクラウドサービス開発の分野まで広くお世話になりました。

　このUSDMを制作系の方向けに簡単に説明しますと、以下にようになるかと思います。

• やりたいイメージ（企画書・画面遷移書）から文章でやりたいこと（ユースケース・要求）を抽出する
• やりたいこと（ユースケース・要求）とやり方（要件）をさらに分解する
• やりたいこと（ユースケース・要求）のシズル感などを伝えるためのメタ情報（理由）を補う

USDMとユースケースの関係

　これを行うことで、発注側は本当にやりたいことが明確になり、受注側も発注側の要求の理由を知ることで、絵や文章だけだと伝えきれないメタな情報を共有できます。

　こうして作られた要求と仕様の関係はUSDMによって、ワイヤーフレームも含めて要求仕様としてまとめることができます。こうして仕様が決まれば、次は仕様の客観性と定量性の確認も兼ねて受け入れテストの設計をできる状態になります。

ユースケースとワイヤーフレームの関係

解決策【2】受け入れ基準ガイドライン

　さて、要求仕様の作成によって、発注側は「自分が相手に何を作ってほしいか」を受注側に伝えることができました。また、要求仕様の対となる受け入れテストを作成することで仕様の妥当性も確認できました。

　後は、受注側がそれを満たすプロダクトを作ってくるの待つばかり…… と思いきや、そう簡単な話ではありません。発注者以外のステークホルダーの要求を考慮する必要があります。

　ご存じのとおり、Androidアプリは高性能な開発環境により簡単に多機能のアプリを作成できますが、アプリの商取引を取り巻く環境は複雑です。

　例えば、国ごとのプライバシーやワイセツの基準、著作権違反、TwitterやFacebookのAPI利用規約、ユーザーが無意識に最低限求めるユーザビリティ要件、などなど考えなければならないことが山ほどあります。発注側が、これらの要求を取りこぼしていると、当然受け入れ条件に反映されませんので、プロダクトのQCDに何らかの悪い影響を及ぼすことになります。

Androidアプリの非機能要件

　リサーチすれば分かるような法律や規約といった静的な要件以外にも、市場にリリースして初めて分かったキャリアごとの回線網による挙動の違いや、多端末試験の結果ノウハウ化された実装のアンチパターンやデザインパターンなどもあると思います。

　Androidアプリの受け入れテストには、自分のプロダクトに対する要求とともに、こうした技術的制約や法律的制約といった外部環境の知識が必須となります。

SIerの世界におけるガイドライン

　SIerの世界では、産官学が一丸となって業界全体のコストを削減するべく、前述のJUASの「UVC」プロジェクト以外にも、各種ガイドライン作成や非機能要件の体系化といった取り組みがされてきました。しかし、Androidアプリのような軽量開発の分野ではそうした活動が追い付いていません。

表　要求仕様やガイドラインに関する各団体の取り組み

独立行政法人 情報処理推進機構（IPA）	非機能要件グレード
経済産業省（METI）	クラウドサービスレベルのチェックリスト
一般社団法人 電子情報技術産業協会（JEITA）	民間向けITシステムのSLAガイドライン
一般社団法人 情報サービス産業協会（JISA）	要求工学知識体系（REBOK）

　こうしたガイドラインがないと、気軽に高性能なアプリが作れる環境になってもビジネスリスクが大き過ぎて市場が萎縮してしまいます。

　特に、非技術的要素の非機能要件に関わる受け入れ基準については、発注側から明示がない限り受注側では分かりようがなく、リリース後の思わぬトラブルを引き起こすことが多いかと思います。

iOSやWindows Phoneのアプリ審査基準を参考にする

　1つの方法論として、他プラットフォームのiOSやWindows Phoneのアプリ審査基準を参考に、事前に各項目をチェックリストの代わりとして検討することで、一定の基準ガイドライン効果になると考えています。

　例えば、iOSのアプリ審査ガイドラインを基に自分のアプリの要求仕様および受け入れ条件を決めるときのことを考えてみます。

App Review Guidelines - Apple Developer via kwout

　2.22に「地域やキャリアによる制限が掛からないこと」とありますが、この「要件」から「要求」を考えて見ましょう。おそらく、「どこでも使えることを前提としたい」「他社のサービスに囲い込まれたくない」といった要求を想定できます。

Androidテスト部のアプリ審査基準を使う

　さて、そこで自分のAndroidアプリにフォーカスを当てるといかがでしょうか。それまで想定外だった、「国外で使われたくない」「特定キャリアからの利用を前提としたい」などの要求が発見されることはないでしょうか。このような要求の発見があってこそ、後に続く要件化と受け入れテスト項目の作成が可能になるのです。

　Androidテスト部では、簡便な形ではありますが、このような用途でiOSやWindows Phoneの各アプリ審査基準を使っていただければと要件項目化をまとめていますので、お役に立てれば大変幸いです。

• スマートフォンプラットフォームレギュレーション分析