アプリ納品時に泣かないための受け入れテストの基礎知識：Androidアプリ開発テスト入門（終）（1/3 ページ）
日本Androidの会テスト部が、いままで培ってきたAndroidアプリ開発におけるテストのノウハウを、実際のテストコード例とともに紹介していきます。最終回の今回は、要求獲得と要件定義、受け入れ基準をめぐる受発注間の“深い溝”、コンシューマ向けAndroidアプリ開発における問題点の3つの解決策などを解説します
「受け入れテスト」と「システムテスト」
本連載「Androidアプリ開発テスト入門」では、これまで「Vモデル」に従って単体テスト、結合テスト、システムテストと順を追って見てきました。システムテストのさらに上層で、かつ最上層に位置するプロセスは「受け入れテスト」です。最後に、“Androidの受け入れテストのまとめ”で、この連載を締めくくりたいと思います。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
「システムテスト」は「総合テスト」とも呼ばれます。この「総合」という言葉は単体テストの「単体」という言葉の対義です。ところが、「受け入れテスト」は「ユーザーテスト」とも呼ばれ、「ベンダ」の対義としての「ユーザー」という、実行責任を表した定義になります。
このように、システムテストと受け入れテストは、仮に内容が同じだったとしても、実行責任に違いがあるため、これまで紹介したテスト技法とは異なる考え方が必要になります。
「受け入れテスト」と「受け入れ基準」
話を進める前に、まずは簡単ですが用語の整理をしておきたいと思います。テスト技術に関する国際的な組織である「ISTQB」（International Software Testing Qualifications Board）がまとめた「ソフトウェア標準用語集 Ver.2（JSTQB訳）」には、以下のように用語が定義されています。
- 「受け入れ基準」（acceptance criteria）：ユーザー、顧客、その他の認可団体が、コンポーネントやシステムを承認する場合、満たさねばならない終了基準
- 「受け入れテスト」（acceptance testing）：システムが、ユーザーのニーズ、要件、ビジネス・プロセスを満足するかをチェックするための公式のテスト。このテストにより、システムが承認基準を満たしているかを判断したり、ユーザー、顧客、その他の認可主体がシステムを承認するかしないかを判定できる
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
つまり、「受け入れテスト」の合格基準は「受け入れ基準」と定義しますが、良くも悪くも、この受け入れ基準自体が「担当者の独断と偏見による曖昧な基準であっても成立し得る」わけです。
受け入れ基準が曖昧なときの問題
さて、自分が発注側の検収責任者であったとして、受け入れ基準が曖昧な状態で受け入れテストを行うと、どのような問題が起こるでしょうか。
受注側は、自分たちの基準でシステムテストを行い、発注側の受け入れテストに向けたリリースを行うことになりますが、受注側のシステムテストと受け入れテストの観点に大きな差異があるとBtoBの場合は突き返しを受けることになりますし、BtoCの場合はマーケットからそっぽを向かれることになります。
特にコンシューマ市場には、「どうすれば売れるか」なんていう基準は、そもそも分からないので、完璧な受け入れ基準が存在しないことはやむを得ません。しかし、この基準が曖昧なせいで、「せっかく作ったプロダクトが売れない、動かない、そして儲からない」という失敗リスクを引き上げることになります。
ですから、せめて受発注間の受け入れ基準の認識をできるだけ合わせておくことで、プロダクトの失敗リスクをマネジメントするべきなのです。
受け入れ基準の前提となる「要求獲得」と「要件定義」
今回の記事は、受け入れテストがメインテーマですが、受け入れテストを論じるうえで避けて通れない話題に、「要求獲得」や「要件定義」などの「要求仕様」としてまとめられる「上流工程プロセス」があります。
受け入れテストは受け入れ基準に準じて作られ、受け入れ基準は要件から作成され、要件は要求から作られます。また、要求や要件の妥当性は、受け入れテストの妥当性によって判断されます。このため、「受け入れテストと要求仕様は双子の兄弟」といっても過言ではありません。
上流工程には「要望」「要求」「要件」「仕様」といった概念がありますが、これらの用語の定義には多少の揺らぎが存在しています。ここでは、豆蔵ソフト工学ラボの定義に準じて次のように定義したいと思います。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
- 「要望」：要求の担い手が思い考えていることで、まだ要求の担い手の「期待」や「価値」が他者へは伝わっていない状態
- 「要求」：利害関係者の「要望」、つまり「期待」「価値」が顕在化した状態であり、他者に認識された状態
- 「要件」：要求の担い手の「期待」「価値」の真の姿が描き出され、利害関係者もその状態を認識できた状態。
なお、「仕様」とは特定分野の要件の集合体として定義します。例えば、画面仕様といえば画面に関する要件の集合といった具合です。
受け入れテストは「要件を満たしていることを試験で確認することによって、要求が満たされていることを確認するもの」と定義できます。
受け入れ基準をめぐる受発注間の“深い溝”
これらの上流工程プロセスを含む受発注間のコミュニケーションは、お互いの立場や知識体系の違いにより理想通り進まないことが多く、過去ソフトウェアエンジニアリング業界において、いろいろな取り組みがなされていました。
日本情報システム・ユーザー協会のUVCプロジェクト
ユーザーとベンダのコラボレーションに関する問題については、日本情報システム・ユーザー協会（JUAS）が、その名の通りの「User Vendor Collaboration」（UVC）というプロジェクトを行っています。
こちらの報告書は、今回の記事でも何度か引用させていただいています。
Androidアプリ開発では、ブリッジのためのノウハウが未成熟
組み込業界出身の筆者があえて誤解を恐れずに言いますと、SIerの世界では、業務を行うユーザーと開発を行う現場技術者のブリッジとして、いわゆる「SE」の業務知識と技術知識の両方に長けた職種の方が受発注の認識の統一に大きな役割を果たしていました。
しかしAndroidアプリの世界では、Web制作やクリエイティブの領域と、システム開発や組み込み開発の世界が交差しつつある中で、まだSEのようなブリッジ人材育成やブリッジのためのノウハウが未成熟な現実があります。
このため、特にクリエイティブ的な要素を持つ発注者から成る受け入れテスト実施側から見ると、従来のようなハイコンテクストな阿吽のコミュニケーションが成立せずフラストレーションがたまるようなことも多いようです。
事実、システム開発の世界では「魅力性」のような非機能要件は、重要性は認識しつつも現場へのプロセス落とし込みにまでは至っていなかったと思います。
さらに悪いことに、発注側にWeb制作のコスト感や作業感の前提がある場合、制作と開発の“ものづくり”のプロセスの違いから、金額が折り合えずに案件化に至らなかったり、大幅なオーバーランになってしまう例もあります。
コンシューマ向けAndroidアプリ開発における問題点の3つの解決策
これらの問題も根本対策は見つかっていませんが、今回は特にコンシューマ向けアプリ開発の受け入れテストおよび、それに伴う要件定義などの問題に注目し、以下の3つを紹介します。
Copyright © ITmedia, Inc. All Rights Reserved.