テスト要求分析を語る夕べ
２０１８年６月２６日（火）１８時４０分に開催しました「テスト要求分析を語る夕べ」の原稿をリライトしたものです。
【目次】
１．はじめに
１－１．語る夕べシリーズについて
１－２．本日の進め方
１－３．対象者
１－４．コンテキスト
２．テスト要求分析
２－１．分析について
２－２．テスト分析の種類
２－３．要求の定義について
２－４．プロセスの定義について
２－５．テストプロセスの定義について
２－６．テスト要求分析のタスクについて
３．確認・準備
３－１．プロジェクトのステークホルダー分析
３－２．テストベースの識別
４．獲得
４－１．ユーザーのテスト要求、組織のテスト要求の獲得
５．分析
５－１．システムのステークホルダーの分析
５－２．テスト対象の分析
５－３．過去の欠陥、類似製品の欠陥の分析
５－４．プロジェクトリスクの識別
５－５．前提条件、制約条件の識別
５－６．テストベースの分析
５－７．テスト観点の識別
５－８．テスト条件の識別
５－９．テストタイプの識別
６．記述
６－１．テスト条件、テスト観点の記述／モデル化
１．はじめに
１－１．語る夕べシリーズについて
喫茶店や居酒屋などで話されている事柄をオープンの場で話します。登壇している２人の私的な会話に、皆さんを巻き込む感じです。セミナー講師が受講生に向かって理解させるというスタイルではなく、登壇者が勝手に喋りますので、ぐたぐた過ぎて、参加者の方が消化不良になることもあります。
登壇者の話に割り込んできても構いません。どんどん話に入ってきてください。基本はツイッターで呟いていただいてかまいませんが、僕が呟かないで欲しいと言った内容については止めてください。ハッシュタグはこちらになります。
皆さんの判断でこれは「問題になりそうだな」というのがあれば、そちらも控えていただけると有り難いです。
１－２．本日の進め方
いつもの語る夕べでは、登壇者が２人で話をしますが、本日はひとり語りになります。ひとりで喋りますが、いつものようにセミナーのような講義形式にはしません。質問があれば随時受け付けます。いちいち手を挙げなくても構いません。
１－３．対象者
中級～上級者向けの内容になっています。初心者、初級者の人は、ソフトウェアテストにこんな世界もあるんだと思ってください。セミナーですと、初心者にもなんとか理解してもらおうと努力しますが、今日は配慮しません。僕が喋りたいことをしゃべります。
１－４．コンテキスト
初めてテスト要求分析を行うテストチーム（第三者検証会社に勤めている人でもよいですし、たまたまテストチームに配属になった開発者でも構いません）に所属する人に対して、テスト要求分析について一緒に考えるというコンテキストです。
顧客や開発側から提供された文書類は十分ではなく、テストチームで頑張らなくてはいけないという状況です。この状況を設定したのは、「この話は要件定義や設計の話ではないか」と疑問を持つ人がいるかもしれないからです。十分な情報が無いので、テストチームが頑張るというシチュエーションだと思ってください。
従来型の開発を行っている組織です。アジャイル開発ではありませんので、今回紹介する内容は、ヘビーウェイトなものかもしれません。あまりにも重過ぎて、胃もたれをするかもしれません。Web系QAの人でアジャイルなテストをやっている人は、参考になりそうなところだけ、摘み食いしてください。
２．テスト要求分析
２－１．分析について
テスト分析について語る前に、分析とは何かを確認します。大辞林の定義を確認します。
分析：
①ある事柄の内容・性質などを明らかにするため、細かな要素に分けていくこと
②知的活動の過程・方法の一。所与の対象・表象・概念などを、それを構成する部分・要素・条件などに分け入って解明すること
③物質に含まれている成分の種類や量を化学的・物理的に求めること
「大辞林」より引用
辞書では、分析とは「分けること」になるようです。しかし、分析とは「分ける」だけではないという感覚が僕の中に常にありました。「分析とは・・・」と自分の言葉で語ることができれば良いのですが、書籍から以下の文章を引用します。
観念を形成するためには、一つ一つ順番に観察しなくてはならない。
－ 中略 －
対象をあるがままに理解するには、対象を順番に経時的な秩序によって、対象間に同時的に存在している秩序を再構成しなくてはならない。
－ 中略 －
こうした分解と再構成こそ、人が「分析」と名付けるものである
「論理学 考える技術の初歩」より引用
分析とは対象を理解するために必要なことであり、分けるだけでなく、再構成も必要だと考えています。
２－２．テスト分析の種類
テスト分析という言葉を使うとき、私たちはいくつかの意味で使います。
・テスト設計の前に行う分析のこと
・テスト結果の分析のこと
・第三者検証会社が仕事を始める前に行う分析のこと
今回のテーマであるテスト要求分析は、１番目のテスト設計の前に行う分析のことです。他の意味との混同を避けるために、テスト要求分析という用語で話を進めます。
２－３．要求の定義について
テスト要求分析の「要求」についても定義を確認します。
要求：
①問題を解決したり，目標を達成するために，ステークホルダが必要とする条件，あるいは，能力。
A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
②契約，標準，仕様，あるいは，その他の正式に要請された文書を満たすために，システム，あるいは，システムコンポーネントが満たすべき条件，あるいは，持つべき能力。
A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
③上記の ①，②の条件や能力を記述した文書。
A documented representation of a condition or capability as in ① or ②.
「要求工学知識体系（REBOK）」より引用
要求といいますと、顧客やユーザーが「言ったこと」だと思う人もいます。テスト要求分析における「要求」は、REBOKで定義したものと似ています。顧客やユーザーが「言ったこと」だけではありません。
２－４．プロセスの定義について
テスト要求分析は、テストプロセスのアクティビティの一つです。最初にプロセスの定義について確認します。
プロセス（process）：
①物事を進める手順
②物事が変化するときの経過。物事が進む過程
③食品の保存のために行う加工処理
④「プロセス平版」の略。
「大辞林」より引用
次にJSTQB用語集の定義を確認します。
プロセス（process）：
相互関係のある活動のセット。
入力を出力に変換する。[ISO/IEC 12207]
「ソフトウェアテスト標準用語集（日本語版）Version 2.3.J02」より引用
プロセスという言葉は、変換や加工そのものを指したり、変換する過程や手順を示している用語です。僕が説明する場合には、「プロセスとは入力を出力に変換する諸活動の連鎖」と言うことが多いです。
｜ ｜で囲ったところがプロセスになります。＜入力＞から【出力】に変換される活動１から活動３までの連鎖になります。
＜入力＞⇒｜プロセス｜⇒【出力】
＜入力＞⇒｜〔活動１〕→〔活動２〕→〔活動３〕｜⇒【出力】
上記のイメージを活用して僕の解釈を説明しますと次のようになります。
Wikipediaのビジネスプロセスの定義を少し加工した次の定義の方が腑に落ちる人もいるかもしれません。
特定のアウトプットを創り出す、活動（アクティビティ）またはタスク の構造と関係の集合である。
それはしばしば、アクティビティのシーケンスとしてフローチャートで可視化される。
Wikipedia 「ビジネスプロセス」の項を参考に作成
２－５．テストプロセスの定義について
プロセスの定義を確認しましたので、次はテストプロセスについて確認します。
テストプロセス（test process）：
基本的なテストプロセスは、テストの計画とコントロール、テストの分析と設計、テストの実装と実行、終了基準の評価と報告、テスト終了作業によって構成される。
「ソフトウェアテスト標準用語集（日本語版）Version 2.3.J02」より引用
用語集の定義では、プロセスの構成要素であるアクティビティ（活動）を列挙することで定義とするスタイルをとっています。
僕が使っているテストプロセスの構成要素（アクティビティ）は以下のとおりです。
・テスト要求分析
・テストアーキテクチャ設計
・テスト詳細設計（テストケース作成）
・テスト実装（テスト手順作成）
・テスト実施
・テスト報告
・テスト評価
２－６．テスト要求分析のタスクについて
JSTQBの各シラバスではテスト分析として書かれていますが、テスト要求分析と読み替え、定義を確認します。
テスト分析は、「何を」テストするかをテスト条件の形式で定義する活動である。テスト条件は、テストベース、テスト目的、およびプロダクトリスクを分析することにより、識別可能である。
また、成功のための詳細な測定および対象（たとえば終了基準の一部）と見なすことも可能であり、成功のためのテスト目的、および他のプロジェクトまたはステークホルダの基準を含む、テストベースおよび定義された戦略目的にまで遡ることができる必要がある。
さらに、テスト条件は、テスト設計およびそれ以外のテスト成果物を作成した際には、これらの成果物を追跡できる必要もある。
「2012 年度版 Advanced Level シラバス 日本語版 - テストマネージャ」より引用
テスト計画作業では、テストプロジェクトのスコープを定義する。テストアナリストはこのスコープを使用して、次のことを行う。
テストベースを分析する。
テスト条件を識別する。
テストアナリストはテスト分析を効果的に進めるために、次の開始基準が満たされていることを確認する必要がある。
テストベースとして機能するテスト対象が記述されたドキュメントが存在する。
このドキュメントは、レビューに適切な評価で合格しており、レビュー後に必要に応じて更新されている。
テスト対象に対して、残りのテスト作業を完了するために適切な予算とスケジュールが確保されている。
テスト条件を識別するには、通常、テストベースとテスト目的を分析する。
「2012 年度版 Advanced Level シラバス日本語版 - テストアナリスト」より引用
整理しますと、JSTQBのシラバスによればテスト要求分析は、次のようなタスクがあります。
・テスト目的を分析する
・テストベースを分析する
・テスト条件を識別する
・「何を」テストするかをテスト条件の形式で定義する
念のために、用語の確認をしておきましょう。
テスト目的（test objective）：
テストを設計、実行する理由や目的
テストベース（test basis）：
コンポーネント要件やシステム要件を推測できる全てのドキュメント
テスト条件（test condition）：
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
「ソフトウェアテスト標準用語集（日本語版）Version 2.3.J02」より引用
さて、僕が使っているテスト要求分析はテスト要求の源泉を入力して、テスト条件、テスト観点などを出力します。
「テスト要求の源泉」という言葉は聞きなれないと思いますが、テスト目的、テストベース、ユーザーのテスト要求、組織のテスト要求、テスト対象、欠陥情報、ステークホルダー、プロダクトリスクなどテスト要求分析に活かせる情報のことを言います。
＜入力＞⇒｜テスト要求分析｜⇒【出力】
入力：
・テスト要求の源泉
・テスト目的
・テストベース
・ユーザーのテスト要求
・組織のテスト要求
・テスト対象
・欠陥情報
・ステークホルダー
・プロダクトリスク
出力：
・テスト条件、テスト観点
・テスト範囲
・前提条件、制約条件
・プロジェクトリスク
テスト要求分析の出力はいくつかありますが、この語る夕べで話をするのはテスト条件とテスト観点とします。
一般のエンタープライズ系の開発で行われている要件定義、要求プロセスには、様々なものが提唱されています。多くの組織で社内標準として整備されていたり、方法論として販売されているものもあります。
これらのタスクを抽象化して表現すると、次のようにまとめることができます。「確認・準備・獲得・分析・記述・検証・設定・引継」で、真ん中に管理があります。「確認・準備・獲得・分析・記述・検証・設定・引継」のように書いてしまいますと、一直線に要求を定義できると考えてしまうかもしれません。
しかし、要求はリニアなプロセスでは充分に獲得できません。要求を獲得し、分析をした後で足りないことに気づき、また獲得に向かいます。要求を記述している最中に要求が抜けていることに気づき、分析に戻ったり、獲得まで戻ったりします。このように何度も繰り返すことで、よい要求を作ることができます。
図１．要件定義の抽象的なタスク
一般的な要件定義のやり方を抽象化することによって、テスト要求分析に当てはめることができます。つまり、テスト要求分析の抽象的なタスクは「確認・準備・獲得・分析・記述・検証・設定・引継・管理」になります。
この抽象的なタスクのうち、主要な「確認・準備・獲得・分析・記述」を具体的なタスクに落として整理すると、次のようになります。
確認・準備
・プロジェクトのステークホルダー分析
・テストベースの識別
獲得
・ユーザーのテスト要求、組織のテスト要求の獲得
分析
・システムのステークホルダーの分析
・テスト対象の分析
・過去の欠陥、類似製品の欠陥の分析
・プロジェクトリスクの識別
・前提条件、制約条件の識別
・テストベースの分析
・テスト観点の識別
・テスト条件の識別
・テストタイプの識別
記述
・テスト条件、テスト観点の記述／モデル化
さて、次からはテスト要求分析の各タスクについて説明していきます。
３．確認・準備
３－１．プロジェクトのステークホルダー分析
アジャイルサムライに「ご近所さん」を探せという節があります。「プロジェクトのご近所さんと会って、あらかじめ知り合いになっておこう」という趣旨のことが書かれています。
図２．「ご近所さん」を探せ
－「アジャイルサムライ」p.69 より引用－
テスト要求分析を始めるにあたって、テストチームのステークホルダーを把握しておくことは大切です。「ご近所さん」を探せでは、コアチームとその他となっていますが、これはアジャイル開発を前提としたチーム編成だからです。
開発規模が大きな開発チームでは、コアメンバーとその他メンバーの間に周辺メンバーがいることがあります。
図３．プロジェクトの中核・周辺・外郭の人々
コアのメンバーである自分たちから、周辺のステークホルダー、さらにその外側のステークホルダーへと関係者を見つけていきます。コアメンバーがテストチームならば、開発側、ビジネス側とステークホルダーを探します。
ステークホルダーの大半はプロジェクトの体制図に書かれている人ですが、大切なのは体制図に「書かれない関係者」で「影響力を持つ人たち」を探すことです。これをアクセシビリティ分析で確認します。
図４．プロジェクトのアクセシビリティ分析
ステークホルダーを識別できたら、次にステークホルダーを分析します。影響度と重要度で分析するケースが多いようです。
影響度：意思決定に及ぼす相対的な力
重要度：テストが成功するための必要性
以下の図のようにマトリクス上にステークホルダーをプロットし、自分たちの（我々の）チームに対してポジティブかネガティブかを把握します。影響度が高いのにネガティブな発言をする人がいる場合、テスト要求分析を実施し、テストアーキテクチャ分析を実施し、と良いテストのために頑張っても、それ自体を否定されることがありますので、別途対応が必要になります。
このようなステークホルダー分析は、普通の開発でも行われますが、テストチームの場合、特にやったほうがよいと思います。「テストチーム」「テストの人」「ＱＡの人」というだけで、ネガティブな反応をする人は少なくありません。このような反応する人と上手く対応していかなければ、今日ここで話をしているテクニックを上手く使って、よいテストを実施しようとしても、それまでの苦労が全部水の泡になることもありますから。
図５．プロジェクトのステークホルダー分析
３－２．テストベースの識別
顧客や開発側から提供された仕様書や設計書で十分だと思ってしまいます。目の前に膨大な文書があるので、他のテストベースがあるとは考えもしないでしょう。受け取ったテストベースをこれからどのように料理をするか考えるかもしれません。
しかし、多くの現場では顧客や開発側から提供されたテストベースでは不十分であるというケースをよく見かけます。提供されたテストベース以外にもテストベースがあるかどうかを探ってください。
図６．テストベースの種類（視野）
仕様が書かれているものを探します。例えばメーリングリストに仕様は埋もれていませんか？ 目の前にある文書は実は更新されておらず、古い仕様のままであるということはよくあることです。最新の仕様はメールを見なければ分からないという現場はあちらこちらにあります。
最近の開発スタイルですと、チケットのコメントの中に仕様が埋もれているというケースがあります。チケットのタイトルとは直接関係ないコメントの中に、仕様が書かれているというものです。チャットで仕様を議論するというスタイルもあるそうです。そうなると、後から参加する人が仕様を追うのは大変です。
本日とは異なりテスト要求分析を簡易版で話すことがあります。そのとき「視座・視野・視点」というキーワードを使って話をします。プロジェクトのステークホルダー分析によって登場人物（視座）を特定し、その視座から必要なテストベースを探す（視野）と説明しています。
例えばシステム運用者の立場でテストすると決めたならば、システム運用に関係する文書がテストベースになります。手元に開発の文書だけしか無いのであれば、システム運用者の立場のテストを設計することは困難になります。そのため、システム運用に関する文書を入手するなり、有識者にヒアリングをすることになります。
４．獲得
４－１．ユーザーのテスト要求、組織のテスト要求の獲得
ユーザーのテスト要求や組織が持っているテストや品質に関する標準や決まりを獲得します。
ユーザーのテスト要求には様々なものがあります。
・品質方針や品質計画（テスト密度や欠陥密度などを含む）
・開発標準（工程名称、工程区分を含む）
・テスト標準（テストタイプを含む）
・テスト手法（使用するテスト技法やVSTeP、HAYST法、ゆもつよメソッドなどのテスト方法論の指定も含む）
・テスト環境
・機材利用可否（シミュレータや試作機など）
・テストツール利用可否（ツールの種類とライセンス、保有スキルなど）
・テスト期間、費用、要員数
・テストの作業場所
・テスト成果物の保守性
ステークホルダーが多数いて、ユーザーのテスト要求が様々あり、どのように捉えたらよいのか分からない場合は、下記のようなリッチピクチャーを書いて整理してもよいでしょう。
図７．リッチピクチャー
私が使っているリッチピクチャーとは、次のようなものです。
・漫画と吹き出しを用いて、どのような意見があるのかを俯瞰する絵です
・直感的な現状把握を行うことが目的です
・公式なテクニックや定まった形式はありません。
・ステークホルダの意見、世界観、問題意識を把握することに意義があります
・発言者の位置にも意味があり、描き手の意図が反映されます（近い、遠い、中央、周辺）
５．分析
５－１．システムのステークホルダーの分析
３章でプロジェクトに関係するステークホルダーを探し、分析しました。本節では、テスト対象であるシステムやソフトウェアに関係するステークホルダーを探します。企画、要求（機能、非機能）、開発、販売、利用・運用、廃棄の各フェーズに関与する人々を識別します。
図８．テスト対象のライフサイクル
プロジェクトに関係するステークホルダーと、テスト対象に関係するステークホルダーで重なる人が大半です。僕が気にしているのは、重ならない人々です。重ならない人は、プロジェクトメンバーと接点が無いので、その人たちの要望・ニーズ・要求は意識しないと汲み取れないからです。
私がプロダクトのステークホルダー分析を行う場合、次のようなオニオンモデルを使います。
図９．オニオンモデル
やっていることは、下表のように交差するセルの一つ一つに該当するステークホルダーを挙げるということですが、表をじっくり見てもステークホルダーを思いつかないことが多く、昔からオニオンモデルを使っています。
図１０．ステークホルダー識別表
５－２．テスト対象の分析
テスト対象とは、テストの対象であるシステムやソフトウェアのことです。僕はテスト対象を分析するとき、通時的な見方、共時的な見方をしています。
通時的：
関連がある複数の現象、あるいは体系を時間の流れに沿って記述しようとするさま。また、ある対象を歴史的な変化の相でとらえようとするさま。
共時的：
ある現象を、時間の流れの一断面における静止現象としてとらえ、その構造を体系的に記述しようとするさま。また、ある対象を歴史的な変化の相においてではなく、一時期の安定した体系としてとらえようとするさま。
「精選版 日本国語大辞典」より引用
企画側面、要求（機能）側面、要求（非機能）側面、開発側面、販売側面、利用側面、廃棄側面の時間的な流れを踏まえ、各側面から分析を行います。テスト対象のライフサイクルに応じた分析です。
【企画側面】
テスト対象をなぜ作ることになったのか、どのようなコンセプトのシステムまたはソフトウェアなのか、などを分析します。分析というよりは、ステークホルダーから「なぜ」やコンセプトを聞き出すというほうが適切かもしれません。
コンセプトが聞き出せない場合は、テスト対象に対して利用する人や利用シーン、関連するモノやコトを組み合わせて、文脈（コンテキスト）を見つけることで、コンセプトを引き出します。
テスト対象と同様のシステムやソフトウェアが市場にある場合には、類似商品との差別化要因を確認します。
この企画側面で得られた情報によって、どこを重点的にテストすべきかが明確になります。例えば、類似商品との差別化要因が「ユーザビリティ」「使い勝手の良さ」であれば、ユーザビリティテストに重きを置かなくてはいけません。
図１１．テスト対象のコンセプト
【要求（機能）側面】
テスト対象を機能の側面で分析します。テストベースに機能仕様書があっても、テストにそのまま使えるとは限らないため、テスト設計に必要な情報を得るために、様々な側面で分析します。
僕が分析で用いている見方は次のようなものです。
１．目的－手段の階層構造、目的－機能－手段の階層構造
２．システム全体を構成する個々の部分の相互作用
３．データの流れ、入力から出力の変換過程
４．刺激－反応モデル、リクエスト－レスポンスするもの
５．状態遷移、状態の変化
６．写像、関数、入力と出力の対応関係
７．論理の集合、ルールの集合
８．手順、手続き、システムをイベントの連鎖として認識する。
９．静的な構造、クラス（補集合なし）、セット（補集合あり）
これらの見方は重なっているところがあります。MECEになっていません。僕の場合は、テスト対象のシステムの特性に合わせて、または開発者の考え方や特性に合わせて、分析するときの見方を変えます。全ての見方で分析するのではなく、相手に合わせてこちらの見方を変えています。
【非機能側面】
テスト対象であるシステムやソフトウェアの非機能側面を分析します。ISO/IEC 25010の品質モデルを使うところが多いようです。
図１２．システム・ソフトウェア製品の品質モデル
（「つながる世界のソフトウェア品質ガイド」より引用）
ただし、この品質モデルを鵜呑みにしてはいけません。よく見かけるのは、ここに挙げられている品質特性以外の特性があるにも関わらず、この品質モデルをテンプレートのようにそのまま使っているケースです。テスト対象に必要な品質モデルは何かを考えることが大切です。
ここで非機能要求について整理してみましょう。非機能要求は次の３種類に分類することができます。
・複数のシステムを含めて全体で考慮すべきもの
セキュリティが代表的なもの
ポリシーやガイドラインのような形式のものが多い
・ある特定のシステムで考慮すべきもの
保守容易性、移植性、信頼性、回復性、機能拡張性といったもの
・ある特定のシステムの個別コンテキストで考慮すべきもの
性能効率性、性能拡張性、使用性、可用性といったもの
気を付けるべき非機能要求は、個別コンテキストで考慮すべきものです。要件定義書に個別コンテキストが書かれていればよいのですが、書かれていない場合は確認する必要があります。
個別コンテキストの非機能要求を考える場合、次のようなコンテキストを明らかにします。
図１３．非機能要求の個別コンテキスト
（「非機能要求記述ガイドライン」を参考に作成）
１．場面（Situation）の検討
刺激の発生源からの何らかの刺激による場面変化を考えます。
「クリスマス・シーズン」の様な「システムに影響を及ぼす外部の刺激（イベント）」を検討することで、場面を洗い出します。
「システムに影響を及ぼす」のヒントとして以下のようなものがあります。
・ビジネスやシステムの目標達成や KPI 向上につながること
・顧客満足度向上や市場シェア拡大に貢献すること
・収益の減少、資金繰りや利益の損失につながること
・顧客や市場シェアの喪失につながること
・ブランドイメージの低下につながること
別の切り口として災害時の状態を設定する場合もあります。通常期、警戒期などを業務モードと呼ぶことがあります。
図１４．災害時のモード
２．稼働状態(Operating Condition)の検討
usual（通常時）、surge（予想可能なピーク）、burst（予測不可能なピーク）を適用することから検討し、必要に応じて変更します。
システムの置かれている場面により、クリスマス・シーズンのsurgeと平日のsurgeとは異なります。
図１５．通常時、ピーク時
稼働状態について分かりにくい人もいるかもしれませんので、イメージでお伝えします。
同じ負荷量でも稼働状態が異なると意味が変わることを示しています。
図１６．稼働状態と負荷
負荷のかかり方も様々です。
図１７．負荷のかかり方
３．運転モード(Operation Mode)の検討
full （正常運転）、degraded （縮退運転）、limited （制限運転）、alternative （代替運転）の４つが主なモードです。
クラウドを利用している場合、縮退運転ではなく拡張（アップグレード）運転もあります。
図１８．運転モード
なお、一般には、この非機能要求記述ガイドに載っている方法ではなく、品質特性シナリオを用いることが多いかもしれません。
品質特性シナリオとは，システムが備えるべき品質特性をシナリオ形式で記述するというものです。次の６つの要素から構成されています。
図１９．品質特性シナリオ
（「SQuBOK V2設計開発領域について」を参考に作成）
・刺激源（Source）：
刺激の発生源
刺激を生み出す要素
システムの応答へとつながる刺激の元となっている発生源、もしくは発生源となる可能性があるもの
刺激の発生源となるエンティティ。ユーザー、組織、システムなどが、これに該当する。
発生源は一つあるいは複数個の場合がある
刺激（Stimulus）
システムに影響を与えるもの
システムを刺激し、応答を誘引する（方向づける）もの
現象、イベント、状況などが働きかけて、システムもしくはステークホルダが何らかの形で応答し、もしくはアクションを行う。
刺激は、ユーザのリクエスト、イベントもしくは割り込み、エラー、変更の要求など
環境（Environment）：
関係している環境的状況
刺激が発生した状況・環境
応答と応答測定に影響する環境的状況の説明、標準的オペレーション、ピーク負荷、悪化状態のオペレーション。開発時、運用時、割り込みなしのオペレーションなど
アーキテクチャが刺激を受けている間にシステムが運用されている環境で発生している条件を意味する
成果物（Artifact）：
アーキテクチャの要素
刺激によって直接的あるいは間接的に影響を受けるアーキテクチャの諸要素を意味する
応答（Response）：
刺激によって持たらされるべき動作
ステークホルダが期待する応答内容を描写する
応答測定（Response measure）：
評価可能なシステムの応答単位
応答測定には、さまざまなものがあり、人数、金額などのコスト人月、エラーの発見率、応答時間、復帰時間など
刺激のレパートリーによって、この応答の種類も増えていく
ここでいう測定というのは、単にインターフェイスに対する入力から結果的に得られた出力を機能的に把握することを意味する訳ではない
「アーキテクチャ中心設計手法」を参考に作成
ソフトウェアアーキテクチャを設計する道具としては、品質特性シナリオのほうが使い勝手がよいと思うのですが、テストの道具としては、非機能要求記述ガイドに載っている方法のほうが使いやすいと考えています。
このように説明していますと、「品質モデルはまったく使わないのですか？」という質問がありました。また、「品質モデルを使わないと初心者はどうしてよいのか分かりません」という質問もありました。
私は品質モデルをテンプレートのようにそのまま使わないと言っているだけで、非機能要求を導くためのガイドワードとして使うことはあります。
図２０．ユーティリティツリー
（「日経SYSTEMS 2012.11 p.104 ユーティリティーツリー」を参考に作成）
非機能側面について時間をかけて説明しました。それはテストに関わる人が入手できる情報に非機能に関して十分な内容が含まれていないことが多く、非機能側面の分析には時間がかかるためです。
【開発側面】
テスト対象の開発側面とは、開発工程におけるテスト対象の良いところ（自信のあるところ）、悪いところを分析します。
「悪いところ」は、プロダクトリスク、品質リスクとも言います。JSTQBの用語集とシラバスを引用して、どんなリスクなのかを確認します。
プロダクトリスク（product risk）：
テスト対象に直接関係するリスク。
「ソフトウェアテスト標準用語集（日本語版）Version 2.3.J02」より引用
ソフトウェアやシステムで失敗する可能性のある領域(次に起きる事象が意に沿わなかったり、危険を引き起こしたりす
る可能性)をプロダクトリスクと呼ぶ。これらは、プロダクトの品質に対するリスクであり、以下のものが含まれる。
・故障の起きやすいソフトウェアの出荷
・ソフトウェアやハードウェアが個人や会社に対し損害を与える可能性
・貧弱なソフトウェア品質特性(例えば、機能性、セキュリティ、信頼性、使用性、性能など)
・貧弱なデータの完全性と品質(例えば、データ移行問題、データ変換問題、データ伝送問題、データ標準への違反)
・予定の機能が動作しないソフトウェア
「2012 年度版 Foundation Level シラバス 日本語版」より引用
プロダクトリスクの一部は、不具合が混入している可能性が高く、その影響が高いと思われるものです。
例えば、
・構造上問題が起きそうな箇所
・前工程までの検証作業（レビューやテスト）が足りなかったり滞ったりした箇所
・前工程のテストで不具合が多発した箇所
・類似製品や母体系製品の過去バグ
・顧客クレームから分析した知識
・スキルの足りないエンジニアが担当した箇所
・設計中に不安が感じられた箇所
・進捗が滞ったりエンジニアが大きく入れ替わったりした箇所
・仕様変更の発生率が高い箇所
・複雑なビジネスロジックの箇所
・ユーザー部門の関与度合いが低い箇所
・テスト環境を用意できない箇所
・新しい技術を導入した箇所
・当初よりもスケジュールが短縮された箇所
・当初よりも費用が削減された箇所
・要員が不十分なまま開発された箇所
・他のプロジェクトでも使っている箇所
・本番データを活用できない箇所
・複数のチームが関与していた箇所
・担当している組織が異なる連結箇所
・担当者間が不仲なチームが関与していた箇所
・地理的に分散している開発拠点が作成した連結箇所
・多数のシステムとのインタフェース箇所
獲得したこれらの情報は、テストの優先順位を付けるのに使います。また、良し悪しには直接関係ありませんが、テストを開始する前までの仕様変更状況をおさえておくのは良いでしょう。
構造上の問題が起きるかどうかに気づけるかどうかは経験に依存します。しかし、富士通の七つの設計原理を使うことで怪しそうなところに目を配ることはできます。
単純原理
・自然であれという原理
・可能な限りシンプルにすること
同型原理
・形にこだわるという原理
・同じものは同じように実現すること
・例外を設けないこと
対称原理
・形の対称性にこだわるという原理、対になるものは対にすること
・上があれば下、右があれば左、アクティブがあればインアクティブという対称性にこだわること
・バランスを崩さないこと
階層原理
・形の階層的美しさにこだわるという原理
・主従関係、前後関係、本末関係などを崩さないこと
・ものごとの階層関係を常に意識し、あるべき姿を求めること
・層に穴を空けないこと
線形原理
・処理の流れは直線がよく、さらに矩形であるのがよいとする原理
・特異点や閾値、組み合わせによる特殊な振る舞いが無いこと
明証原理
・ロジックの明証性にこだわるという原理
・ロジックは直感的に分かりやすくすること
・分からないものやふるまいがないこと
・おかしなものを受け取らない、先に送らない、無視しない、勝手に処理しないこと
安全原理
・安全性を意識するという原理
・必然性のないところや曖昧なところは安全サイドに設計しておくこと
「ソフトウェア品質知識体系ガイド（第2版）－SQuBOK Guide V2－」と「ソフトウェア品質は“ユーザー主導”の時代へ」を参考に作成
【販売側面】
テスト対象が自社開発の場合、どのような販売をするのかを分析します。どのような販売経路で売るのか、いくらで売るのか、問い合わせ窓口はどうなっているのかなどです。特に販売価格は重要です。高価格であれば比例して高い品質を求められるし、低価格であれば、それなりの品質でも利用者に許容してもらえるかもしれません。
受託開発の場合はテスト期間やテスト費用などの形でユーザーのテスト要求の中に含まれるかもしれません。
販売側面はビジネスモデルの側面と捉えることもできます。ビジネスモデルとして見たとき、製造者と販売者との接点、販売者と購入者との接点を分析して、テストの優先度付けに活かすことができます。
【利用側面】
テスト対象をいつ（天）、どこで（地）、誰が（人）が使うのかを分析します。テスト対象であるシステムやソフトウェアの購入者（販売側面）と利用者（利用側面）が異なる場合は、その違いを明確にします。購入者と利用者が異なる場合の利用者を特に Customer's Customer （C’s C）と呼ぶことがあります。便宜的に〇〇側面と言っていますが、上記のように厳密に分けず行きつ戻りつしながら分析していきます。
B2Cのビジネスをやっている企業の顧客は、購入者であり利用者になります。そのため、わざわざ C’s C という概念を持ち出す必要がありません。この C’s C という概念が必要になるのは、B2Bビジネスをやっている場合です。B2Bビジネスの顧客は企業になります。そのため、顧客の顧客という概念が生まれます。なお、 Customer's Customer のイメージするには、次の記事がよいかもしれません。「Focus on Your Customer’s Customer」
利用側面では、システムの運用やシステムの管理に関しても、いつ（天）、どこで（地）、誰が（人）が使うのかを分析します。今回はシステム運用を利用側面に入れていますが、組織によっては運用側面と独立させた方がよいかもしれません。
システム対象が譲渡できるものである場合、他者への譲渡も利用側面で検討します。
【廃棄側面】
システムやソフトウェアの中には廃棄するときのことを考えたほうがよいものもあります。僕はこの廃棄側面の分析をしたことはありませんが、組込み系の人からこのような側面で分析をしていると伺ったことがあります。
ASTERのテスト設計コンテストでは、ここ数年カラオケシステムをテスト対象にしています。ある年の参加者が、カラオケシステムの廃棄を考慮に入れていました。環境に考慮したシステムづくりだったり、廃棄時に個人情報が入っていないかなどのセキュリティに考慮しているかどうかを分析していました。
５－３．過去の欠陥、類似製品の欠陥の分析
欠陥データベースが存在する場合や類似システムの品質状況が把握できる場合は、テスト対象に混入されている可能性のある欠陥を分析します。また、派生開発の場合は母体システムの品質状況を把握します。
僕の場合、SIerに勤めていたときは、「よくある不具合」としてまとめていましたが、勤めている会社を変えると、その情報にアクセスできなくなるので、最近はこの分析を行う機会が少なくなりました。
図２１．不具合推測リストの例
（「オフショア開発におけるテスト改善 JaSST’10 」より引用）
５－４．プロジェクトリスクの識別
ユーザーの要求や組織の要求からプロジェクトリスクの識別をします。
JSTQBの用語集とシラバスを引用して、どんなリスクなのかを確認します。
プロジェクトリスク（project risk）：
（テスト）プロジェクトのマネジメントとコントロールに関係するリスク。たとえば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。
「ソフトウェアテスト標準用語集（日本語版）Version 2.3.J02」より引用
プロジェクトリスクはプロジェクトを遂行する際に影響を与えるリスクである。例えば、以下のようなものがある。
組織問題の要素
－スタッフのスキル、およびトレーニング不足、人員不足
－人事の問題
－以下のような政治的な問題
・テスト担当者のニーズやテスト結果が上手く伝わらない。
・テストやレビューで見つかった事項がチームで上手くフォローアップできていない。
(例えば、開発やテストの実施方式が改善されていない)
－テストから期待できるものを正しく評価しようとしない。
(例えば、テストで見つかった欠陥の情報を真摯に受
け止めようとしない)
技術的な問題
－要件を正しく定義できない
－制約があるために、要件を拡張できない
－テスト環境が予定通りに用意できない
－データ変換の遅れ、移行計画の遅れ、データ変換／移行ツールの開発・テストの遅れ
－設計、コード、構成データ、テストデータ、テストの低い品質
供給者側の問題
－サードパーティ製品の故障
－契約上の問題
「2012 年度版 Foundation Level シラバス 日本語版」より引用
５－５．前提条件、制約条件の識別
ユーザーの要求や組織の要求、および、これまでの分析結果から前提条件と制約条件と識別します。
・前提条件（Assumption）
前提条件は、プロジェクトまたはチーム内部で設定したものです。
将来見直すこともあります。
前提が崩れたらリスクとなり、QCDに影響が及ぶ可能性が高まります。
前提条件を挙げることでリスクを許容しているともいえます。
・制約条件
制約条件は、プロジェクトまたはチーム外部から設定されているものです。
自分たちの制御が及ばない制限で、自分たちでは変更できない条件のことです。
時間的な制約・場所的な制約・資源的な制約、契約条項及び法律などで規定されていることが多いです。
この条件のもとプロジェクトを推進しなければなりません。
５－６．テストベースの分析
以下に、仕様書を読むための道具、テストベースを分析するのに使える道具を紹介します。
【三色ボールペン】
テストベースを識別したのち、仕様書を読んで疑問点を明らかにしていきます。
図２２．三色ボールペンによる仕様書の読み方
この三色ボールペンを用いた仕様書の読み方は、三色それぞれに意味を持たせます。その意味は『三色ボールペン情報活用術』に載っているやり方と同じです。書籍では、次のように定義しています。
赤 ── 客観的に見て、最も重要な箇所
青 ── 客観的に見て、まあ重要な箇所
緑 ── 主観的に見て、自分がおもしろいと感じたり、興味を抱いたりした箇所
「三色ボールペン情報活用術」p.38より引用
ただし、テスト要求分析で用いる場合には、緑色を少し拡張して
緑 ── 主観的に見て、おかしいと感じた箇所
として使っています。
緑は主観です。面白いと感じたり、おかしいと感じたりする感じ方を重視しています。感じたまま、思ったままを表現します。最近は、気がかりなことと言う人が増えてきています。
仕様書を読むとき、違和感を感じてもそのままにしておく人は多いかもしれません。頭の中に浮かんでくる言葉や感じを流れるままにして、わざわざメモは取りません。いちいちメモを取っていたら、読み終わるのに時間がかかってしまうからです。
三色ボールペンを使って仕様書を読んでみると、今まで無視してきた言葉がこんなにも多かったことに驚くかもしれません。いろいろな気づきがあり、さらなる疑問が生まれることもあります。どんどん仕様の理解が深くなり、今までの読み方がいかに表面的なものであったかが分かり恥ずかしくなったと、わざわざ僕に報告してくれた人もいました。
【テスト分析の三角形】
「仕様書を読む」目的は、テスト設計を行うためです。テスト対象を理解するという目的もありますが、理解するのはテスト設計のためです。そのため、テスト設計につながる読み方をした方が、遠回りなようで近道なことがあります。
この「テスト分析の三角形」はテスト設計につながる読み方をするときに使います。
図２３．テスト分析の三角形
一度効果を感じていただければ、この１１個の観点で仕様書を読み、三色ボールペンでメモしていっても構いません。
この「テスト分析の三角形」ですが、もともとは要求仕様のレビューのときに作った道具でした。そのときは「蓄積」が入っていませんでした。高信頼化ソフトウェアのための開発手法ガイドブックのときは真ん中は処理だけでした。
５－７．テスト観点の識別
テスト観点とテスト条件を比較すると、僕は主にテスト観点を識別します。テスト条件ではなくテスト観点という場合、厳密性には欠けますが、僕は「テストしたいと思うモノやコト」ぐらいのふんわりとした意味で使っています。テストで気になるところをマインドマップなどを用いてツリー構造でまとめますが、そのツリーの構成要素（ノード）をテスト観点と呼んでいます。
テスト観点に関しては、次のような道具を使って識別します。
【タートル図】
図２４．タートル図
多くのテストケースを収拾し、「どこをテストしているのか」でまとめたのがこの図になります。青色は濃い青と薄い青がありますが、これはテスト分析の三角形にでてきた構成要素です。ですから、タートル図はテスト分析の三角形の拡張版とも言えます。
ひとつの機能または処理を中央に置いて、その周辺に書かれているキーワードを参考にして、「テストしたいな」「確認したいな」「評価しておいた方がいいな」と思うものを挙げていきます。
ここに挙げているキーワードは抽象化していますが、誰かが一度はテストしている事柄ですので、今回の対象もテストする可能性はあります。
仕様書にはすべての情報が書かれているわけではありませんので、タートル図を見て気になった観点は開発側にヒアリングすることもあります。
【意地悪漢字】
意地悪漢字は「裏」と「表」があります。「裏」にはネガティブな漢字を集め、「表」には例外的な漢字を集めました。一種のガイドワードです。
どのような経緯で作られたかは、こちらの資料をご覧ください。
仕様書には、異常な処理や状態、例外的な処理や状態の記述が十分に書かれていないことがあります。そのため、そのような処理や状態への対応は、プログラムを書く人に委ねられています。
テストを設計するとき、そのようなあやふやな箇所を狙いに行きます。狙うのですが、そもそも仕様書に書かれていないため、テスト観点を挙げるときに、思いつくかどうかに依存してしまいます。
この意地悪漢字に含まれる漢字をガイドワードとして、狙うところを見つけます。
図２５．意地悪漢字
【対立漢字】
対立漢字は対立する漢字を集めています。「天」と「地」と「人」に分かれています。厳密な分け方ではありませんが、「天」は時間が関係するものを、「地」は空間が関係するものを、「人」は人の生活に関係するものを集めています。ただし、図形に割り付けているため、ちょっと違うものも入っています。
対立する漢字は、抽象的な因子（値）と言えます。この抽象的な因子（値）から、水準（パラメータ）を見つけ、この水準（パラメータ）が含まれるテスト条件・観点を探すというボトムアップアプローチで使います。
図２６．対立漢字
仕様書には対立漢字のどちらか一方しか書かれていないこともあります。この場合は、意地悪漢字と同様の使い方ができます。意地悪漢字と異なり、頻繁に使う道具ではありませんが、仕様書の記述がゆるゆるのところには効き目がある道具です。
５－８．テスト条件の識別
テスト条件は分かりづらい概念ですので、僕はテスト観点の識別を行うことが多いです。一応、テスト条件について記します。
JSTQBの用語集やシラバスでは、次のように書かれています。
テスト条件（test condition）：
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
「ソフトウェアテスト標準用語集（日本語版）Version 2.3.J02」より引用
テスト条件は、通常、テストされるアイテムに固有であるが、テストアナリストは次の標準的な考慮事項について検討する必要がある。
・一般的には、テスト条件をさまざまな詳細度合いで定義することが望ましい。
まず、高位レベルの条件を識別し、「画面 x の機能性」など、テストの全般的な対象を定義する。
次に、特定のテストケースの基準として、より詳細な条件（たとえば、「画面 x では、正しい長さよりも一桁足りないアカウント番号を拒否する」など）を識別する。
この種類の階層アプローチを使用してテスト条件を定義することにより、高位レベルのアイテムに対するカバレッジを十分なものにすることができる。
・プロダクトリスクが定義済みの場合、各プロダクトリスクに対処するために必要なテスト条件について、リスクアイテムにまで遡って識別する。
「2012 年度版 Advanced Level シラバス 日本語版 - テストアナリスト」より引用
僕はテスト条件とは「◇◇な場合、○○すると□□となる」と書けるものとしています。テスト条件という用語を定義していませんが、理解しやすさを優先しました。
・テスト対象が
・◇◇な場合（条件、状態、前提）
・〇〇すると（トリガー、イベント、操作）
・□□となる（期待結果）
シラバスでは「画面 x では、正しい長さよりも一桁足りないアカウント番号を拒否する」を例に挙げています。この例を先ほどの形式に当てはめますと次のようになります
・テスト対象が｜画面 x では
・◇◇な場合 ｜アカウント番号が正しい長さよりも一桁足りない場合
・〇〇すると ｜（番号を入力し、○○ボタンを押下すると）
・□□となる ｜
（画面は）拒否すること
このようなテスト条件を分析していきます。
５－９．テストタイプの識別
テスト観点をある程度識別できたら、次はテストタイプの識別を行います。テストタイプは複数のテスト観点から構成される場合があります。分析を分解と再構成であるとしたときの、再構成にあたります。
たとえば、長時間稼動させる性能・負荷のテストをしようと考え、次のようなテスト観点が導けたとします。
図２７．長時間稼動の性能・負荷のテストに関わるテスト観点の例
これらの組み合わせから、今回のテスト対象をテストするのに適したテストタイプが何かを検討します。いくつか例を挙げてみます。
◎低負荷＋一定量の長時間稼動テスト
◎低負荷＋一定量＋ときたまピークの長時間稼動テスト
◎低負荷／高負荷＋不定量の長時間稼動テスト
◎高負荷＋一定量の長時間稼動テスト
図２８．長時間稼動テストの種類
テストタイプの識別が重要だといいますと、組織で持っているテストタイプ一覧から選択することだと思う人がかなりいます。そうではなく、テスト観点の組み合わせから、適切なテストタイプを識別することが大切です。
６．記述
６－１．テスト条件、テスト観点の記述／モデル化
皆さんはテスト観点をモデル化する際に、マインドマップを使っているとのことなので、モデル化のツールはマインドマップになります。トリミング＆トリアージがポイントです。
【マインドマップ】
図２９．マインドマップ
マインドマップは分析しながら随時更新しながら書いていきます。テストタイプの識別も、マインドマップに書かれたテスト観点間のつながりをくっつけたり、はずしたりしながら、検討していきます。
以上、テスト要求分析について語ってきました。今までで一番長い語る夕べだったとおもいます。
さて、会場から何かご質問はありますか？
この記事が気に入ったらサポートをしてみませんか？