◆「ゆもつよメソッドを語る夕べ」というイベントとこのページについて
connpassに「語る夕べ」というグループがあります。主にテストについて（※）、主催者であるみっきーさんが参加者に語るというイベントを開催するグループです。テスト界隈の方が多く参加し、毎回テストについて深い話をしています。普段SIerとして働いている私にとっては初めて聞くテスト手法の話が多く、参加する度に新しい発見があってかなり勉強になるイベントです。
※過去、RDRAについて語る回も開催されているので必ずしもテストだけがテーマと言うわけではありません。
そんな語る夕べで、過去何回か、ゆもつよメソッドというテスト手法について語る会が開催されました。
私が把握している範囲で、ゆもつよメソッドについて語られたのは2回です（実際にはもっと過去にもゆもつよメソッドについて語る会が開催されていた可能性はあります）。
①カルバートにゆもつよメソッドを語る夕べ
https://kataruyube.connpass.com/event/111126/
2018/12/12 19:00 〜 21:00
②あさこ姐さんにゆもつよメソッドを語る夕べ
https://kataruyube.connpass.com/event/111901/
2019/1/16 19:00 〜 21:00
①の日は、ゆもつよメソッドの提唱者である湯本さんもその場にいました。
（因みに、VSTePの提唱者であるにしさんもいました）
②の日は私は不参加でした。
この記事は、①に私が参加した際のメモと、別の参加者がtwitterで呟いたこと、②に参加した方がtwitterで呟いたことをまとめたものです。
ある程度ゆもつよメソッドを知っている人に対して語る会なので、いきなりこの記事を読んでもよくわからないと思います。
「◆参考資料」に記載した資料がゆもつよメソッドをちゃんと整理して説明しているので、整理された情報が欲しい人はその資料を見て下さい。
この記事は、その資料を見た後で見ると、為になるところが少しはあるかもしれない。。。という記事です。
◆参考資料
・イベント主催者であるみっきーさんがゆもつよメソッドを説明した資料
ゆもつよメソッドを勝手に語る夕べ
https://note.mu/kataruyube/n/na3195a510efe
・ゆもつよメソッドの提唱者である湯本さん本人の資料
（全体ではなく、テスト分析とテスト設計のみ）
ゆもつよメソッドにおけるテスト分析とテスト設計
https://www.slideshare.net/yumotsuyo/ss-71502350
・twitter のハッシュタグにもなってる（#ゆもつよメソッド）
https://twitter.com/hashtag/ゆもつよメソッド
・ソフトウェア・テスト PRESSの Vol 1とVol 10に、ゆもつよメソッドの話が載っているらしい
（テスト分析設計手法というテーマで）。
きっとこれに乗ってると思う
https://www.amazon.co.jp/dp/4774147338
・テスト分析入門 -「ゆもつよメソッド」を例に- #wacate
https://www.slideshare.net/kjstylepp/ss-36095291
◆イベント内容
２．ゆもつよメソッドの特徴
※章の番号はこの資料の番号に合わせています。
ゆもつよメソッドと言えばゆもつよマトリクスという人が多い。
湯本さん自身が言っているゆもつよメソッドの特徴
・ドキュメントフォーマット
⇒ドキュメントフォーマットはテスト分析とテスト設計をまとめて書ける。
なので、ソフト会社には人気が高い。
・論理的機能構造
・テストカテゴリ
・仕様項目特定パターン（※）
・テスト分析マトリクス
※ゆもつよメソッドで言う「仕様項目」は、JSTQBでいう「テスト条件」
３．ゆもつよメソッドのプロセス
３－１．プロセスとアクティビティ
ゆもつよメソッドにおけるテスト分析とテスト設計の4枚目のスライド
テスト分析、テスト設計でのトレーサビリティが大事。ゆもつよメソッドなら、1シートで一目瞭然。
なぜこういうスタイルにしたかというと、テストチームのレベルをそろえたい、すなわちテストケースを作るまでの粒度を揃えたい。
ゆもつよメソッドは「テストチームのレベルを合わせたい」という目的で生まれた。
チームのレベルを合わせる＝成果物のレベルを合わせる。
スキルレベルを合わせるためではない。
⇒ゆもつよメソッドのように、「そろえる」ことにフォーカスしていくと、チームで作るのに則していると思う。
みっきーさん的には、自分が吸収するからバラバラでもいいでしょと思うが、組織長のレベルが違うので、統一した方が違いは分かる。
テスト対象は何ですか
テスト条件は何ですか
これがわかるまでがテスト設計
テスト設計のアウトプットは、テストケースの構成要素であるテストパラメータを特定するところです。
明示されていないが、ゆもつよメソッドでテストケースというのは、テストパラメータと値の組み合わせ、つまりアクションと期待結果でできている
ISO29119では、組織で適用できるように作る。ゆもつよもそれに近い。
現場に適用するときには、テーラーリングする。
HAYST法とは目的が違う。
HAYST法はプロセスがちゃんとできている前提で、バグフォーカス。
ゆもつよメソッドは、プロセスフォーカス。
４．ゆもつよメソッドのテスト分析
テストタイプ：ソフトウェアテスト標準用語集参照
http://jstqb.jp/dl/JSTQB-glossary.V2.3.J02.pdf
http://jstqb.jp/syllabus.html
ソフトウェアテスト標準用語集より抜粋。
テストタイプ（test type）：
コンポーネント又はシステムをテストするためのテスト活動をまとめたものであり、たとえば機能テスト、使用性テスト、回帰テストなどのように特定のテスト目的に焦点を当てている。
テストタイプは一つ又は複数のテストレベル又はテストフェーズで行なわれる。
ゆもつよメソッドでは、現場で適用しやすいように、品質特性とテストタイプが1:Nにしようとしている。
ある組織では品質特性のことをテストタイプと言っているようですが、湯本さんは品質特性とテストタイプは異なるものだと思っています。
テストタイプについて、湯本さんは次のような図を使って説明しています。
テストタイプがあるということは、ソフトウェアの品質を確認するとき、一つの側面からの確認では不十分だということです。
機能テストを実施したからと言って、それは機能という側面からのテストでしかないということです。
テストタイプごとにテスト計画を作る。 ←イベント主催者の方から指摘を受けたのでこの記載は消します。
ゆもつよメソッドの場合、テストタイプはプロジェクトのたびに、一から作るものではありません。
組織として、または個人としてあらかじめ用意してあるものです。
しかし、組織標準のテストタイプは使いづらい。
例えば、何を性能テストと呼び、何を負荷テストと呼ぶのかは組織によって違う。使い分けない組織もある。
そもそも、テストタイプを持っていない組織もある。
テストタイプを持っていない組織が用意するにはどうすればよいかというと、今の時代はインターネットを検索すると見つかったりしますので、それを使いつつ改善していくのがよいかもしれません。
参考として、TISが公開した「テスト種別＆テスト観点カタログ」を提示している。
テスト種別＆テスト観点カタログ
組み込みだから組み込みの標準で！とはならない時代が来た。
IoTでがんがんつながる。
エンプラと変わらない世界だったりもする
同時アクセス数を少しずつ増やしていくテストがあるとする。
負荷が少ない時の測定値（性能テスト）と多い時の測定値（負荷テスト）でテストの切り口を変える。
⇒性能テストと負荷テストでテストタイプは分かれる
しかし、やることは一つ。つまり見たいことが違う。
徐々に増やしていく場合と、スパイクな感じでいっぺんにアクセスする場合でも見たいことは違うはず。
性能テスト→性能要件における上限におけるテスト→限界を超えた状態でのテスト
性能テスト、負荷テスト、限界テスト
それぞれ目的が違う
テストタイプとテストカテゴリ
テストタイプの下位に、テストカテゴリというものがある。
ゆもつよメソッドでは、テストカテゴリよりテストタイプの方が抽象度が高い。
ゆもつよメソッドのテストタイプは汎用的。
ゆもつよメソッドのテストカテゴリはドメイン特有のもの。プロジェクトで決める。
テストタイプ：
実施するテストの種類
テスト分析時にテストの目的から見て適切なものを選択する。
どのドメインでも適用できる汎用的なものをテストタイプと言う。
テストカテゴリ：
テストタイプを具体化したもの。
ドメイン特有のものとしてプロジェクトで考えたテストタイプ。
テストすべき事項（仕様項目）を着目する結果やテストの方法で分類する箱。
テストタイプとテスト条件の中間に位置するもの。
⇒テストタイプとテストケースの距離を埋めるための道具
※テストタイプとテストカテゴリが同義の組織もある
機能テストというテストタイプの中には
・計算
・入力
・保存
・モード
・表示
・エラー処理
などのテストカテゴリがある。
４－２．フィーチャ
ゆもつよメソッドにおけるフィーチャ一覧とは、テスト対象を理解し、テスト対象の網羅性を確保するために使用する一覧表のことです。
ゆもつよメソッドでは、フィーチャ一覧を作るにあたって、該当するテストレベルの粒度で機能を整理する。
テストレベル（test level）：
系統的にまとめ、管理していくテストの活動のグループ。
各テストレベルはプロジェクトの特定の責務と対応付けができる。
テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。
http://jstqb.jp/dl/JSTQB-glossary.V2.3.J02.pdf
ゆもつよメソッドにおけるフィーチャ
・機能も非機能も含める
・「フィーチャー一覧」を「機能一覧」と直訳して非機能を含めないで考えちゃう人もいるが、非機能の要素も入る。
ゆもつよメソッドにおけるフィーチャ一覧
・テスト対象の網羅性を確保するために使用する一覧表
・テストレベルごとに作成する
ゆもつよメソッドのコンポーネントはモジュールと異なる。
企業によっては機能一覧がない場合がある。
機能一覧とは、機能仕様書の目次から、コピーするものとは違う。
そのまんまーみたいなのは、ゆもつよもどき。
再定義の方法論は一概に決められない。
目次からフィーチャーにするためには、工数を確保してもやらないと、粒度が揃わなくなる。これは必須。
システムの機能が複数文書に点在して書かれていることがある。
（テーブル仕様書の備考欄に機能が書いてあったり・・・。これを見逃すと、機能レベルで落ちる）
この点在している機能をひとまとめにすることが、ゆもつよメソッドのフィーチャ一覧。
一般システムの現象学―よりよく生きるために 単行本 – 2005/1
https://www.amazon.co.jp/dp/4765542300/
４－３．論理的機能構造
論理的機能構造は、リファレンスモデルと呼ばれるもの。システムの内部構造を仮定モデルを作って、理解しようとするもの。
テストカテゴリを導くときのフレームが論理的機能構造。
こういうリファレンスモデルを使うと、テストのカテゴリをあげやすい。
ゆもつよメソッドは参照モデルとして論理的機能モデルを用意して、抽象度を上げて、テストカテゴリを挙げる。
参照モデルを固定したゆもつよメソッドは、シンプルで汎用性が高い。切り替えると嫌われます（みっきーさん経験談。
入力→処理→出力 が基本構造
みっきーさん
「ゆもつよメソッドではなくなるが、論理的機能構造以外に、他の参照モデルを使ってもいいと思う」
論理的機能構造に拘らなくても良いのでは？
論理的機能構造
・外部から、テスト対象の構造を推測するために用いる
・フィーチャひとつひとつに対して作られる
- 入力調整
- 出力調整
- 変換
- 貯蔵
- サポート
- 相互作用
・テストカテゴリの下位概念
・表形式で整理できる
４－４．テストカテゴリ
テストカテゴリとは
・テストすべきフィーチャを抜け漏れなく多面的に見るための分類
・みっきーさんの言葉で言い換えると、テスト条件を抽出するための取っ掛かり
そのため、テストカテゴリの意味をチーム内で理解しあうため、このテストカテゴリはどんな意味なのか、このテストカテゴリで見つける可能性のある不具合は何かについてチーム内で議論します。
決定したテストカテゴリに対して、チーム内で合意を取ります。
テストカテゴリはテスト対象の知識と過去の不具合や本番障害の知識から導出されます。
意地悪漢字はテストカテゴリに採用されない。
「ゆもつよメソッドを勝手に語る夕べ」より抜粋したものに追記
テストカテゴリと、論理的機能構造のマトリクスを作って、そこに該当するキーワードを入れていく。
例）(テストカテゴリ)起動・終了×(論理的機能構造)入力=パワーボタン
イレギュラーなものはテストカテゴリにならない(なりにくい)。
「欠陥を検出する」よりも「仕様を分類する」ことに重きを置いているから。
慣れていないドメインだと、ゆもつよメソッドは使いづらい。
例えば、上の図の論理的機能構造の「貯蔵」や「変換」がイメージしづらい。
テストカテゴリは難しい、という声が多い。テスト対象に対する知識の多寡に依存するので。
テストカテゴリを出すにはテスト対象の知識が大事。
「テストカテゴリはどうやったら一般的に出すことができるのか？」についてゆもつよさんと語り明かしたことがある。
最終的にはテストケースをリバースエンジニアリングしないと分からないのでは？という話になった。
テストカテゴリを出すためには、テストケースのリバースエンジニアリング(テストケースの意図を想像し、構造を組み立てる)を経験すると良いかも。
ゆもつよメソッドでは、テストカテゴリを抽出したあとに、どんな不具合が見つけられるか議論する。気がかりなども後付け。
テストカテゴリの例
入力調整に
・画面入力
・ボタン
出力調整に
・画面出力
・帳票出力
貯蔵に
・CRUD
などなど
非機能も同様に論理的機能構造にプロットしてテストカテゴリにあげる。
４－５．テスト条件
テスト条件とはテスト分析の結果と言えます。
テストの視点から見たテスト対象の仕様項目であるとも言っています。
ゆもつよメソッドでは、テスト条件を仕様項目と期待値の組み合わせで表現できるとしている。
湯本さん：いきなり仕様書からテスト条件から見つけ出すのは難しい。だから、1段階目として「仕様項目」を洗い出す。概念としては、テスト条件の方が広い。
ゆもつよメソッドにおけるテスト条件
・ソフトウェアではなく、テストウェアとしての仕様
みっきーさんと湯本さんが認識しているテスト条件テスト条件とは
「○○な場合、××すると～～となる」と書けるもの。
テスト対象が
○○な場合（条件、状態、前提）
××すると（トリガー、イベント、操作）
～～となる（期待結果）
湯本さん：
仕様項目っていうのはあくまで、仕様書に書いてあるレベルで「○○な場合、××すると～～となること」を洗い出していきましょう！って思いが込められています。
仕様項目はテスト条件だけど、テスト条件の全てではない。
それは因子水準やアクションのバリエーションもテスト条件だから。
○○、××、～～全部が仕様項目。ここから因子水準を「そろえて」いくと、テスト条件になる。
後々、テスト設計するときに、「○○な場合、××すると」の部分は、サイズを見直したり（ズームイン、ズームアウト）、識別した因子水準の取捨選択をしたりするけど、その際には、「～～となること」のような目的をはっきりさせとくことが役に立ちます。
質問：それ（○○、××、～～の部分）は、「Given-When-Then」と同じものですか？
湯本さんの答え：Given-When-Thenは、普段使った言葉じゃないので、同じものかはわかりません。。
湯本さん本人のツイート
テスト条件は、「テストすること」です。
例えば、飛行機の予約アプリであれば、「行きと帰りの飛行機を選択して、クラスと搭乗者を入力した時にその飛行機が予約可能であれば予約できること」がテスト条件です。
ミッキーさん的には、テスト条件まで一気に行きたい。が、ゆもつよメソッドでは、あえて、仕様項目を出すという1段階を挟む。
ゆもつよ流テスト条件の構造
「ゆもつよメソッドを勝手に語る夕べ」より抜粋
【テスト対象となるシステムをどのように認識するか】と言う話
- ・目的－手段の階層構造、または目的－機能－手段の階層構造で認識する
-
機能階層でシステムを表現する
要求工学のゴール指向アプローチでよく用いられる - ・システム全体の能力をそれを構成する個々の部分の相互作用で認識する。
- 上位システムを下位システムの相互作用に分解し、その個々の下位システムをさらにその下位に分解していく。
機能は複数のサブ機能で構成されていると認識する
機能一覧表、機能階層図としてシステムを表現する - ・データの流れ、データの変換過程として認識する
- システムを入力から出力への変換変換と認識する
複数ステップを踏んで変換する場合、データの流れとして認識する
通称「バケツリレー」と言う場合には、この見方をしている
データフロー図でシステムを表現する - ・刺激－反応のモデルとして認識する
- リクエスト－レスポンスするものとして認識する
トリガーによって、どのような反応をするのかに興味がある
状態遷移でもイベントが関係するが、この刺激－反応モデルは、状態に関心を持っていない
ユースケース仕様書などでシステムを表現する
みっきーさんが探索的テストを行うときは、この意識が強い。
⇒これだとデータフローとか状態遷移的な不具合は捉えられない。 - ・状態の変化として認識する
- 状態が変化するもの、遷移するものとして認識する
状態遷移図、状態遷移表としてシステムを表現する - ・写像、関数として認識する
- 入力と出力の対応関係とみなす。
マトリクスを用いた表現が多い
テスト技法の同値分割を使用する場合は、この見方をしている - ・論理の集合として認識する
- ルールが集まったものとして認識する
ビジネスルールの集合としてシステムを認識する
デシジョンテーブルとしてシステムを表現する - ・手順、手続き、イベントの連鎖として認識する
- データの流れとは異なり、イベントの連鎖や実行順序に関心がある
ユースケース仕様書や、システムシナリオなどでシステムを表現する - ・静的な構造として認識する
- クラス（補集合なし）、セット（補集合あり）としてシステムを表現する
上記を認識しないで失敗したプロジェクトの例：
とある生保の案件で、画面をベースに見積もった。
論理の集合を分析しないで見積もった。
⇒4億赤字出た。
生保のシステムなんて明らかに論理のカタマリなのに、論理の分析をしなかった。
論理と関数の違い？
論理
入力と出力の対応関係では済まないもの。
エンプラ系だと、ビジネスロジックは単純ではなく、複雑なもの（テーブルを見て～～して・・・）。
その複雑なものをエンプラでは論理と言っている。
論理の集合。
手順、手続、イベントの連鎖としてシステムを表現する。
イベントの連続としてシステムを見る。
ユースケースをこれだと見る事もできる。
４－６．テスト分析マトリクス
昔はテストケースを上げるために使っていた。
今は集計に使っている。
テスト分析マトリクス
・検算の道具
・どこがテストされているかを俯瞰するためのピボットテーブル
・テストカテゴリの集計に使える
・テスト不足に気付ける
テスト分析マトリクスは大概大きな表になる(フィーチャ×テストカテゴリ)。
上げてしまうとテストしなきゃならない強迫観念に駆られる(端折ると網羅性に対する説明がつきまとうから)。
ただゆもつよメソッドではテスト分析マトリクスを使ってテストケースやテスト条件を出すようには定義してない
◆質問
- 質問１：ゆもつよメソッドが適用しにくいと感じるって言っていたのはどんなとき？
- SIやるときにはばらつきを抑える目的でゆもつよを導入した場合、会社をまたぐと論理的機能モデルの解釈にバラツキがでやすい。 バッチのような画面がない場合だと当て込みにくい。 湯本さん： 自社流のモデルがあるのなら、それを使って粒度を合わせることの方が大事。 大きな会社ではゆもつよメソッド風でやってどんどん困ってきた状況になった。 フロントエンドをゆもつよメソッドのまま、バックをVSTePで分解しているということが実際あったよ。
- 質問２：ゆもつよメソッドがハマりにくいパターンってないの？
- 組込みとかは読み替えが必要。
- 質問３：ゆもつよメソッドは1つのプロジェクトで指標にするのは向いていないのか？
- ゆもつよメソッドで対象にしているテストチームの規模は10人以下 コントロール可能な人数 30人とかで揃えようとするとちょっと難しいかも
- 質問４：「条件」と言われると、「If X then A」のXの方だけを条件だと思っていて、Aもだ、といわれると違和感がある。
- 感覚としては、非常に真っ当。実際、期待結果を洗い出してから、テスト条件を洗い出す方が都合が良いときもある。 例えば、以下のようなテストケースがあったとして、 テスト条件：アカウントNoが1桁足りないこと 期待結果：拒否すること 条件だけ見ると、2桁の場合どうすんねん。になる。 期待結果を満たすには？から条件を出せば、1桁足りないだけでいいんじゃない？になる。
- 質問？：フロントエンドの整理にゆもつよメソッドは優秀（にしさん）