ゆもつよメソッドを勝手に語る夕べ
２０１９年１月１６日（水）１９時に開催しました「ゆもつよメソッドを勝手に語る夕べ」の原稿をリライトしたものです。
目次
１．はじめに
２．ゆもつよメソッドの特徴
３．ゆもつよメソッドのプロセス
３－１．ゆもつよメソッドのプロセスとアクティビティ
３－２．テスト分析とテスト設計の違い
３－３．テスト分析のアウトプット
３－４．テスト設計のアウトプット
４．ゆもつよメソッドのテスト分析
４－１．テストタイプの特定
４－２．フィーチャ
４－３．論理的機能構造
４－４．テストカテゴリ
４－５．テスト条件
４－６．テスト分析マトリクス
１．はじめに
語る夕べシリーズについて
喫茶店や居酒屋などで話されている事柄をオープンの場で話します。登壇している２人の私的な会話に、皆さんを巻き込む感じです。セミナー講師が受講生に向かって理解させるというスタイルではなく、登壇者が勝手に喋りますので、ぐたぐた過ぎて、参加者の方が消化不良になることもあります。
登壇者の話に割り込んできても構いません。どんどん話に入ってきてください。
基本はツイッターで呟いていただいてかまいませんが、僕が呟かないで欲しいと言った内容については止めてください。ハッシュタグはこちらです。
皆さんの判断でこれは「問題になりそうだな」というのがあれば、そちらも控えていただけると有り難いです。
本日の進め方
今回はあさこ姐さんに語りますので、あさこ姐さんの理解に応じて内容が変わります。あさこ姐さんとの会話がかみ合わなかったときのために、資料は用意してきています。
大まかな理解をしてもらってから、徐々に詳しい話に移っていきます。ですので、同じ箇所を何度もなぞっていきます。
対象者
ゆもつよメソッドを何となく知っている人を対象にしています。ゆもつよメソッドって何？という人は、分からないところを質問してください。
２．ゆもつよメソッドの特徴
一般の人が感じている特徴
ゆもつよメソッドをご存知の方、ゆもつよメソッドの特徴って何でしょうか。ゆもつよメソッドを知っている人は手を挙げてください。答えていただきましょう。
僕が感じている特徴
僕はテストカテゴリだと思っているのですが、テスト分析マトリクス、通称ゆもつよマトリクスが特徴だという人もいるかもしれません。
ゆもつよメソッドのプロセスが素直なことが特徴だと思う人もいるかもしれません。ゆもつよメソッドは、飛び道具的なものが無いオーソドックスな方法です。
飛び道具と言いますか必殺技ですかね。普通のソフトウェア開発では現れないものです。例えば、僕が使っているのは「マインドマップ」ですが、お客様からお金をもらう仕事の成果物にマインドマップがあると拒絶する人もいます。
ゆもつよメソッドのプロセスは、このまま組織に導入しても違和感がありません。「マインドマップを作成する」というのが入っていたら、組織のプロセスに入れるのは結構難しいんです。特に大きな組織では。
湯本さんが言っている特徴
では、湯本さんご自身では、どんな特徴があると言っているでしょうか。湯本さんはゆもつよメソッドには５つの特徴があると言っています。
・ドキュメントフォーマット
・論理的機能構造
・テストカテゴリ
・仕様項目特定パターン
・テスト分析マトリクス
ドキュメントフォーマット
ドキュメントフォーマット以外は、この後に説明をしていますので、ここでは省き、ドキュメントフォーマットについて説明します。
ドキュメントフォーマットというのは、テスト分析とテスト設計を一つのシートにまとめて書けるというものです。言われてみると当たり前のような気がしますが、このようなフォーマットを使っている組織は少ないんです。
実際、このドキュメントフォーマットの人気は凄いです。特に組織の標準を策定する部署の人たちに人気があります。
僕なんかは「好きに書けばいいじゃん」って思っているので、何か特定のフォーマットに書かせるということはしないのですが、このようなスタイルはお客様からは好まれません。決められたフォーマットに書くというスタイルを望まれる場合が多いからです。
どのような経緯でこのような一つのシートにしているか疑問に思ったことがあります。僕も組織の標準を作る部署にいたことがあるので分かるのですが、組織で文書フォーマットを標準化しようとしますと、構造化した文書体系を作りたがるものです。しかし、ゆもつよメソッドではしていません。
ここからは僕の推測になりますが、ゆもつよメソッドが作られた目的からそうせざるを得なかったのではないかと思っています。
ゆもつよメソッドの目的
ゆもつよメソッドは、「テストチームのレベルを合わせること」という目的から生まれたと聞いています。テストケースを作成するまでのやり方だったり、テストケースのレベルだったり、それらがバラバラの状態を解決したい。これが発端です。
チームのレベルを合わせるには、様々なテクニックがあり、今日はそれをお伝えしますが、チームのレベルを合わせるという意味でコアになるのが、このドキュメントフォーマットになります。
だから、「ゆもつよメソッドをやっています」というときは、指定のドキュメントフォーマットを使う必要があります。まあ、ある程度のカスタマイズは許容範囲だと思いますけど。
３．ゆもつよメソッドのプロセス
第３章では、ゆもつよメソッドのプロセスを通じて、大まかにゆもつよメソッドの流れをおさえておきます。細かいテクニックの話は第４章からになります。
３－１．プロセスとアクティビティ
ゆもつよメソッドのプロセスとアクティビティは、このようになっています。ゆもつよメソッドは計画、分析、設計、詳細設計というプロセスで構成されています。各アクティビティは２～４のタスクで構成されています。
なお、ゆもつよメソッドと言いますと、縦軸にフィーチャーを並べ、横軸にテストタイプを並べる「ゆもつよマトリクス」が有名ですが、このマトリクスを作成するというタスクはありません。注意が必要です。
３－２．テスト分析とテスト設計の違い
テスト分析とテスト設計の違いを大まかに言います。
テスト分析はテスト条件を導くまで。
テスト設計はテストケースの一歩手前まで。
テストケースを書くのはテスト詳細設計ですので、テスト設計はその一歩手前までになります。
３－３．テスト分析のアウトプット
上図の下にある表が、ゆもつよメソッドで使っているドキュメントフォーマットです。
テスト分析アクティビティのアウトプットを以下に示します。
・仕様項目と期待結果の特定と列挙
・テストパラメータの列挙
ゆもつよメソッドではテスト条件という言葉をあまり使いません。仕様項目と期待結果といいます。仕様項目は、テスト条件の「◇◇な場合、○○すると□□となる」の「◇◇な場合」「○○すると」になります。
３－４．テスト設計のアウトプット
テスト設計のアウトプットを以下に示します。
・テストケースの構成要素であるテストパラメータの特定
ゆもつよメソッドは、テストケースをパラメータ・バリュー（ＰＶ）で構成しているとしているため、テストパラメータの特定がテスト設計のアウトプットになります。
ゆもつよメソッドのテストケースは、一般によく用いられている大項目、中項目、小項目のスタイルではありません。パラメータ・バリュー形式です。テストに詳しい方ならば、因子と水準という直交表を用いた組み合わせテストの用語を使う方がよく分かるかもしれません。
いきなりテストパラメータを導出できない場合には、テスト設計方針を挙げます。
４．ゆもつよメソッドのテスト分析
ゆもつよメソッドでは、テスト計画とテスト分析は並行作業になりまし、各アクティビティも並行作業なので、このようにリニアに並べるのは正しくありませんが、理解を容易にするために、あえてこのような書き方をしています。
正しいプロセスを知りたい場合には、「ゆもつよメソッドにおけるテスト分析とテスト設計」を参照してください。
以下に、左側にアクティビティを直列に並べて整理し、右側にアクティビティを理解するために必要な概念または手法を書いています。
ゆもつよメソッドには独特の概念があります。このような方法論を説明するとき、アクティビティに合わせて説明するのが楽です。テストタイプを特定するにはどうしたらよいか、機能を分類するにはどうしたらよいか、というふうに説明する方法です。
しかし、ゆもつよメソッドの場合はアクティビティの説明よりも、概念や手法から入った方が理解がしやすいと思います。そのため、今回の説明では概念の説明を中心に行います。
４－１．テストタイプの特定
テストタイプ
JSTQBの用語集ではテストタイプは次のような説明がされています。
テストタイプ：
コンポーネント又はシステムをテストするためのテスト活動をまとめたものであり、たとえば機能テスト、使用性テスト、回帰テストなどのように特定のテスト目的に焦点を当てている。
テストタイプは一つ又は複数のテストレベル又はテストフェーズで行なわれる
「ソフトウェアテスト標準用語集（日本語版） Version 2.3.J01」より
テストタイプについて、湯本さんは次のような図を使って説明しています。
「技術評論社 ソフトウェア・テストPRESS Vol.1」より引用
ソフトウェア・テストPRESSの創刊号から持ってきました。ずいぶん古いものですが、先月、湯本さんに確認したところ変わっていないということなので、このまま使います。
ある組織では品質特性のことをテストタイプと言っているようですが、この図を見ればわかるように、湯本さんは品質特性とテストタイプは異なるものだと思っています。
なお、僕は品質特性とテストタイプは多対多の関係にあると思っています。このようなツリー構造にはならないこともあるだろうと思っていますが、その話を深堀りするのはやめましょう。今日はゆもつよメソッドの話ですからね。
テストタイプがあるということは、ソフトウェアの品質を確認するとき、一つの側面からの確認では不十分だということです。機能テストを実施したからと言って、それは機能という側面からのテストでしかないということです。
テストタイプの特定
ゆもつよメソッドの場合、テストタイプはプロジェクトのたびに、一から作るものではありません。組織として、または個人としてあらかじめ用意してあるものです。
テストタイプの特定は、テスト計画時に定めたテスト目的に照らして、あからじめ用意してあるテストタイプを選びだす行為を言います。「特定」というのは、プロジェクト開始前に存在しているテストタイプの一覧から選ぶ行為です。
テストタイプが持っていない組織が用意するにはどうすればよいかというと、今の時代はインターネットを検索すると見つかったりしますので、それを使いつつ改善していくのがよいかもしれません。
最近、TISが公開した「テスト種別＆テスト観点カタログ」を参照してもよいかもしれません。物足りないところはあると感じる人もいるかもしれませんが、普通のSIの仕事なら十分でしょう。
ただし、テストタイプは使いにくいところもありますので、注意が必要です。にしさんが講演でよく取り上げる例が、性能テストと負荷テストです。何を性能テストと呼び、何を負荷テストと呼ぶかは、組織によって異なることがあります。深堀したい方は、にしさんの資料を読んでください。
また、テスト実施に引っ張られて、性能テストと負荷テストを区別していない組織もあります。
同時アクセス数を少しずつ増やしていって、性能限界まで達するようなテストをするとします。このとき、同時アクセス数が少ない状態では性能テストのようなものであり、同時アクセス数がピーク時の性能要件のときには負荷テストと呼ばれ、ピーク時を超えて限界まで同時アクセス数を増やすとき、限界テストとする場合があります。
このようにテストタイプを固定に持ってしまうと、ソフトウェアによっては適切なテストができない可能性があります。そのため、にしさんのVSTePでは、その都度テスト観点を挙げるようにしています。
※「VSTePは、その都度テスト観点を挙げる」という僕の発言に対して、にしさんがツイートしています。認識が間違っていたようです。
では、ゆもつよメソッドのようにテストタイプを予め用意するのは、よくない方法かというというと、そんなことはありません。
例えば、エンタープライズ系システムの開発がメインであるとするならば、ゆもつよメソッドのように予め決めておき、その中から選ぶというのは効率的な方法だと思っています。
テストタイプとテストカテゴリ
ゆもつよメソッドと言えば、テストカテゴリと言う人もいるくらい、テストカテゴリは重要な概念なのですが、なかなか分かりづらい概念でもあります。組織によっては、テストタイプとテストカテゴリを同義語、シノニムであるとみなしているところもあるので、混乱する人もいるようです。
湯本さんはテストタイプとテストカテゴリを次のように定義しています。
テストタイプ：
実施するテストの種類
テスト分析時にテストの目的から見て適切なものを選択する
どのドメインでも適用できる汎用的なものをテストタイプと言う
（湯本さんのテキストを参考に作成）
テストカテゴリ：
テストタイプを具体化したもの
ドメイン特有のものとしてプロジェクトで考えたテストタイプ
テストすべき事項（仕様項目）を着目する結果やテストの方法で分類する箱
テストタイプとテスト条件の中間に位置するもの
（湯本さんのテキストを参考に作成）
テストカテゴリについては、後ほどまた取り上げます。
４－２．フィーチャ
フィーチャとは
ゆもつよメソッドにおけるフィーチャ一覧とは、テスト対象を理解し、テスト対象の網羅性を確保するために使用する一覧表のことです。
第三者検証会社では、自分たちの仕事の範囲を決めるために、よく機能一覧表を用います。そのため、第三者検証会社に所属している人は、「はいはい、よく使うものやつね」と早合点していまい、ちゃんと理解しようとしないことがあります。
第三者検証会社が使う機能一覧表は、仕様書や設計書などのテストベースからコピー＆ペーストで作成するものです。機能仕様書の目次構成とほとんど変えません。
ゆもつよメソッドのフィーチャ一覧は、テストベースを右から左にコピーするのではなく、該当するテストレベルの粒度で機能を整理します。
そのシステムはどういう機能で構成されているのか、その機能はどんなことをしているのかを整理することにより、不明点が明確になっていきます。
フィーチャの作り方
左側にある一覧は、機能仕様書の目次を抜き出し一覧表にしたものです。呼び名が違う機能であっても、同じ種類の機能とみなせば一か所にまとめます（ex. 一覧再生、サムネイル設定）。
画質設定、撮影設定と、撮影モード設定、ホワイトバランス、オートフォーカスなどの撮影の設定は、撮影設定に属する仕様としてまとめています。
湯本さんが取り上げる例は、どちらかというと機能仕様書をしっかり書いている組込み系の事例を使って説明されるので、エンタープライズ系を主に仕事にしている人の中には、ピンとこない人もいるようです。
エンタープライズ系の場合、たくさんの文書を作成します。そのため、システムの機能が複数文書に点在して書かれていることがあります。テーブル仕様書の備考欄に機能が書いてあったりすることがあります。
この点在している機能をひとまとめにすることが、ゆもつよメソッドのフィーチャ一覧です。
４－３．論理的機能構造
論理的機能構造は、外部からテスト対象の構造を推測するために用いるものです。そして、ここが重要な点ですが、論理的機能構造はテストカテゴリを導くときのベースとなるモデルになっています。
論理的機能構造は、入力調整、変換、出力調整、貯蔵、サポート、相互作用になります。この論理的構造の各要素にテストカテゴリをプロットしていきます。
論理的機能構造は、フィーチャ一つひとつに存在します。
ゆもつよメソッドではありませんが、ソフトウェアアーキテクチャの参照モデルにテスト観点をプロットするという方法があります。
ゆもつよメソッドの論理的機能構造に馴染めなかったり、フィットしなかったりする場合には、テスト対象が前提としているソフトウェアアーキテクチャの参照モデルを使うこととお勧めしますが、ゆもつよメソッドではなくなってしまいます。
次にいくつかの参照モデルを示します。
（「Java ES ソリューションアーキテクチャー」より引用）
（「階層アーキテクチャの利点は、複雑さの減少」より引用）
（「階層アーキテクチャの利点は、複雑さの減少」より引用）
４－４．テストカテゴリ
テストカテゴリとは、テストすべきフィーチャを抜けもれなく多面的にみるための分類です。テストカテゴリとは、テスト条件（仕様項目）を見つける際に、一貫性のある解釈をするために、論理的機能構造の各要素にテスト対象から見てふさわしい名前付けをしたものになります。
ゆもつよメソッドの目的は、テストチームが作成するテストケースの記述レベルをそろえることです。このテストカテゴリはテスト条件を抽出するための取っ掛かりになるところです。
そのため、テストカテゴリの意味をチーム内で理解しあうため、このテストカテゴリはどんな意味なのか、このテストカテゴリで見つける可能性のある不具合は何かについてチーム内で議論します。
決定したテストカテゴリに対して、チーム内で合意を取ります。
テストカテゴリはテスト対象の知識と過去の不具合や本番障害の知識から導出されます。
テスト対象の知識からテストカテゴリを導出することから始めます。機能仕様書から該当するキーワードを洗い出し、リストに入れていきます。
キーワードを見て、名前を変えた方がいい場合には、テスト条件を洗い出しやすい名前を付けます。そして、名前付けしたテストカテゴリの意味をメンバーで共有します。
テストカテゴリが抽出されたのちに、どんな不具合が見つけられるか議論します。ゆもつよメソッドでは、テストカテゴリに不具合の知識が紐づきます。
私がやる場合には、「機能」（ゆもつよメソッドではフィーチャ）に不具合の知識を紐づけますが、ゆもつよメソッドではテストカテゴリを作成しますので、テストカテゴリに紐づけています。
論理的機能構造の説明で、参照モデルにテスト観点をプロットする話をしましたが、ゆもつよメソッドの場合は、機能仕様書を読んで、論理的機能構造にプロットしていきます。ミュージックビデオレコーダーのフィーチャ「録音」の場合を例にしています。
機能仕様書から該当するキーワードを洗い出し、下記のようなリストに入れます。
「サポート」と「相互作用」は、テスト対象のフィーチャのテストによって内部的に呼び出される別処理の結果確認のことを指します。自処理の操作で完結するテストを「サポート」と呼び、他処理との連携操作が必要なテストを「相互作用」と呼びます。
相互作用は、他の処理を動かさなければ確認できない項目です。サポート、相互作用はあくまでもメインの処理ではなく、別処理の結果を確認する項目になります。
サポート、相互作用に該当するキーワードは、「反映」「割り込み」「リソース共有」「連動処理」「同期処理」になります。
非機能テストのテストカテゴリの作り方
非機能テストのテストカテゴリは、論理的機能構造を手がかりに、着目すべきパラメータを識別します。
４－５．テスト条件
テスト条件とは
ゆもつよメソッドでは、テスト条件とはテスト分析の結果と言えます。テストの視点から見たテスト対象の仕様項目であるとも言っています。
ゆもつよメソッドについて書かれた文書に載っているフォーマットには、テスト条件とは書かれておらず、仕様項目と書いてあるものがほとんどです。
テスト条件はテストベースに含まれるフィーチャから抽出します。次に取り上げる内容は「テスト要求分析を語る夕べ」で話をしたので、お聞きになった方もいると思いますが、参加していない方もいると思いますので取り上げます。
僕と湯本さんが認識しているテスト条件は次のようなものです。テスト条件とは「◇◇な場合、○○すると□□となる」と書けるものとしています。
テスト対象が
◇◇な場合（条件、状態、前提）
○○すると（トリガー、イベント、操作）
□□となる（期待結果）
と言い換えてもよいかもしれません。
JSTQBのシラバス載っている例を取り上げてみましょう。「画面 x の機能性」のように、テスト条件を挙げる対象を決めます。次に、特定のテストケースの基準として、より詳細な条件を識別します。これがテスト条件です。
シラバスではテスト条件として次の例を挙げています。
画面 x では、正しい長さよりも一桁足りないアカウント番号を拒否する
この例を先ほどの形式に当てはめますと次のようになります。
テスト対象が ｜画面 x
◇◇な場合 ｜アカウント番号が正しい長さよりも一桁足りない場合
○○すると ｜（番号を入力し、○○ボタンを押下すると）
□□となる ｜（画面は）拒否すること
テスト条件の別の例として、湯本さんのツイートを引用します。
先ほどの型に合わせてみると、次のようになります。
テスト対象が｜飛行機の予約機能（アプリ）
◇◇な場合 ｜その飛行機が予約可能であれば
〇〇すると ｜行きと帰りの飛行機を選択して、クラスと搭乗者を入力した時に
□□となる ｜予約できること
■ゆもつよメソッドのテスト条件
ゆもつよメソッドでは、テスト条件を仕様項目と期待結果の組み合わせで表現できるとしています。
フィーチャー ｜フライト予約
仕様項目 ｜購入金額の計算
期待結果 ｜クラス×人数に消費税をかけた金額になること
仕様項目にはいくつかの構成要素があり、次の要素が挙げられています。
・機能を使ってもらうためのインタフェース
・機能のために他へ要求するインタフェース
・事前状態
・外部イベント
・機能に影響を与える内部動作
・出力
・事後状態
ゆもつよメソッドでは、この仕様項目を見つける際にテストカテゴリを用います。テストカテゴリとは、論理的機能構造の各要素にテスト対象からみて相応しい名前を付けたものです。
ゆもつよ流テスト条件の構造
テスト条件の構造は次のとおりです。
ゆもつよ流テスト条件の構造とワークシート
論理的機能構造と仕様項目の識別
テストベースを整理し不明点を明らかにします。テストベースに書かれている内容をピックアップし、論理的機能構造に割り付けます。仕様を読んで、データの入出力をシミュレーションします。その際、データ入出力パターンを明らかにします。
論理的機能構造のどこの箱の結果をテストで確認するのかを明らかにします。整理したら表にします。テストベースに書かれていることが表に抜けや漏れがないかを確認します。今までの経験から仕様項目に不足がないかを見直します。過去のバグを抽象化したキーワードを利用します。
データ入出力パターン
流れるデータの種類（テストパラメータ）にどういうものがあるのか、データの種類を見つけたら、そこから流れそのものを見つけていきます。
というのが最近のゆもつよメソッドなんですけど、このデータ入出力パターンをどう使ったらよいのか、僕はまだ分かっていません。データの流れを追いかけるのは当たり前過ぎて、どう使ったらよいのかよく分からないのです。
この違和感というか使い勝手が分からないというのは、おそらく僕がどのようにテスト対象を捉えるかに関わっているのだと思います。以前、Maniaxという同人誌にも書いているので読んだことのある方もいるかもしれませんね。
僕はテスト対象となるシステムを次のように複数の見方で認識しています。
・目的－手段の階層構造、または目的－機能－手段の階層構造で認識する
機能階層でシステムを表現する
要求工学のゴール指向アプローチでよく用いられる
・システム全体の能力をそれを構成する個々の部分の相互作用で認識する
上位システムを下位システムの相互作用に分解し、
その個々の下位システムをさらにその下位に分解していく。
機能は複数のサブ機能で構成されていると認識する
機能一覧表、機能階層図としてシステムを表現する
・データの流れ、データの変換過程として認識する
システムを入力から出力への変換変換と認識する
複数ステップを踏んで変換する場合、データの流れとして認識する
通称「バケツリレー」と言う場合には、この見方をしている
データフロー図でシステムを表現する
・刺激－反応のモデルとして認識する
リクエスト－レスポンスするものとして認識する
トリガーによって、どのような反応をするのかに興味がある
状態遷移でもイベントが関係するが、この刺激－反応モデルは、
状態に関心を持っていない
ユースケース仕様書などでシステムを表現する
僕が探索的テストを行うときは、この意識が強い
・状態の変化として認識する
状態が変化するもの、遷移するものとして認識する
状態遷移図、状態遷移表としてシステムを表現する
・写像、関数として認識する
入力と出力の対応関係とみなす。
マトリクスを用いた表現が多い
テスト技法の同値分割を使用する場合は、この見方をしている
・論理の集合として認識する
ルールが集まったものとして認識する
ビジネスルールの集合としてシステムを認識する
デシジョンテーブルとしてシステムを表現する
・手順、手続き、イベントの連鎖として認識する
データの流れとは異なり、イベントの連鎖や実行順序に関心がある
ユースケース仕様書や、システムシナリオなどでシステムを表現する
・静的な構造として認識する
クラス（補集合なし）、セット（補集合あり）としてシステムを
表現する
このように、システムをいくつかの見方で分析することが可能です。
僕の場合、テスト対象のシステムの特性に合わせて、または開発者の特性に合わせて、テスト分析するときの見方を変えます。そのため、ゆもつよメソッドのように決まった手順でテスト分析することができません。相手に合わせてこちらも変えるので。
ゆもつよメソッドは僕の解釈になりますが、「機能の集合としてシステムを認識する」力が強いと思っています。テスト条件のところで、デシジョンテーブルのような表現をしますけれども、機能に含まれるロジックを表現しているだけで、ルールの網羅性は見ていません。
テスト分析をするとき、一つの見方で突き進む場合と複数の見方で進む場合とを比較すると、複数で見た方がテストケースの抜け漏れが少ないように感じると思います。エビデンスはありませんが、直感的にはそう感じられます。
このデータの入出力パターンがゆもつよメソッドに入り込む時期は、湯本さんが博士課程にいたころです。機能集合的な見方だけでは漏れてしまう何かを補うために入れたのではないかというふうに感じます。
言いたいことは何かというと、湯本さん自身もまだ咀嚼できていないのではないか、だから僕がすっきりできないのではないかと思っているってことです。
４－６．テスト分析マトリクス
テスト分析マトリクスは、機能（テスト対象）とテストタイプ（目的をベースとした視点）の両面で、テストケースへと詳細化するためのツールです。
機能一覧はテスト対象を該当するテストレベルの粒度で整理し、機能をリストアップしたものです。
テストタイプ一覧、テストカテゴリ一覧は、機能（テスト対象）に対して、どのような意図でテストをすべきかをリストアップしたものです。
テスト分析マトリクスの利用方法には、次のようなものがあります。
・テスト分析対象を鳥瞰する
・テスト分析対象の把握
・テスト設計工数の見積もり
・テスト設計の予実比較
よく第三者検証会社で、テスト分析マトリクスと似たような表を使ってテスト観点、テスト条件を抽出する方法を採用しているところがありますが、ゆもつよメソッドはこの方法とは異なります。
ゆもつよメソッドにおけるテスト分析マトリクスは、テスト観点やテスト条件を導き出すものではありません。
さて、これでゆもつよメソッドのテスト分析について語ってきました。
質問はありますか？
━━━━━━━━━━━━━━━━━━━━━━━━━━━