「ゆもつよメソッド」というテスト開発手法を学ぶ機会に恵まれたので、掲題のテーマで書き綴ってみる。
筆者がこの手法を、セミナー受講を通して学んだ結果として感じたことを書いたものであり、ゆもつよメソッドの体系的な説明ではないことに注意。
※この手法を体系的に知りたい方はJaSST'21 Tohokuのサイトに掲載の資料を見るか（無料）、有料のセミナーを受講する方法がある。2022年7月末現在、同年12月に、セミナーが開講される予定となっている（セミナーの回し者ではないが）。
- JaSST'21 Tohoku … JaSSTソフトウェアテストシンポジウム-JaSST'21 Tohoku-レポート
- セミナー … ソフトウェアテスト分析手法 実践セミナー | セミナーサイト | 日本科学技術連盟
ゆもつよメソッドの簡単な説明
ゆもつよメソッドは、以下のような手法である （https://www.jasst.jp/symposium/jasst21tohoku/report.html より引用）。
ゆもつよメソッドとは、湯本剛氏によって提唱されるテスト開発手法です。 テスト開発するにあたり、ゆもつよメソッドではテスト分析を重要視しています。 テスト分析は、以下の3つの工程に段階的に行います。また、このテスト分析は、チームで実施することができます。
1.「何をテストするか」を考え、仕様書をテスト用に再構成します。
2.テスト用の機能一覧を作成します。
3.②の機能一覧を内部構成を意識しながら、再度「何をテストするか」を洗い出していきます。
テスト分析の全体像は、以下のJaSST'21 Tohokuの資料6ページ目に出ている。
https://www.jasst.jp/symposium/jasst21tohoku/pdf/S3-1-1.pdf
学んでみて、プロセスが体系だっているだけではなく、テストをうまく進めるための有益な仕組みを様々含んでいる手法だと感じた。
注意点とあわせて、自分なりに考えたことをまとめてみる。
有益な仕組み
段階的にテストを考えるための仕組み
テスト仕様書を読んでいきなりテストケース（スクリプト、手順）を書き始めると、大きな抜け漏れが発生しやすい。関連機能についての考慮が抜けていたとか。 また、具体的になればなるほど、他の開発案件やシステムでの経験が活かしにくくなる。
そのため、テストは段階的に考えた方がよい。が、段階的にテストを考えるというのは、案外難しい。段階を数段飛ばして、具体的なテスト内容や起こりそうな欠陥が頭にちらつくことはよくある。
ゆもつよメソッドに沿ってテスト分析を行えば、段階的にテストを考えるために次に何をすれば良いかガイドされる。 以下のような仕組みが、段階的な検討に不慣れな人の助けになる。
- 仕様を深く理解するためにモデルを描くが、そのガイド（論理的機能構造）がある。この論理的機能構造は抽象度が絶妙（他の手法だとラルフチャートも同様だと思う）。
- 自己流だとUMLで分析することがあるが、仕様の全体感を捉えたいのに、ついつい細かすぎることを考えてしまうことがある。
- 論理的機能構造くらいの抽象度なら、「分析対象の機能の本質は何か」「分析対象の機能のIN/OUTは何か」に集中しやすい。
- 論理的機能構造を知らない人に分析結果を見せたとしても、概ね理解してもらえそうなところも良い。
- 「サポート」だけは分かりづらい気がするが、エラー処理や状態遷移などが分類されるとのことである。
- 特に序盤でつくるモデルや機能一覧は、完璧を目指さなくてよい。
- 最初から完璧にと言われると、あれもこれも細かく見たくなってしまうが、そうではない。
- 機能一覧は継続して改善してテスト分析終了までに良いものにできれば良さそう。
- テスト分析の段階では、テスト設計技法や具体的なテストパラメータの検討はしないことになっている。
- 思いついたものをメモする程度。
- この考え方のお陰で、テスト分析の段階では、テストのための仕様の理解と再構成、抽象的なテストしたいこと（仕様項目）の検討に集中できる。
テスト担当者が考えたこと、理解したことを解読しやすくするための仕組み
テスト分析の成果物は、作成直後だけでなく、後日でも参照されることがよくある。テストチームの人員追加がある場合や、類似案件で参考にする場合などだ。 他人のテストドキュメントを正しく読み解くのは、その書き方によっては、苦労する。
ゆもつよメソッドでテスト分析を行うことで、後から読む人に様々なヒントを残しやすくなる。
- モデルや仕様書などを参考につくる「機能一覧」には対象システムの機能と、それに対応する仕様書の章番号を書く。機能だけでなく、仕様書との紐付きも記録しておけることで、後々テスト分析を参照したときに理解しやすくなる。
- 機能という言葉は、ここでは対象のテストレベルにおけるインタフェースという意味のようだ。
- 機能軸で考える。仕様書の構成と機能が一致していないこともあるので、仕様書の章番号を頭から書く作業ではない。
- 開発のための仕様書の構成ではなく、テスト向けに考えられた仕様の構成をつくることができる。
- テストする要素に、テストカテゴリとして自分たち自身で名前をつける。
- モデルを描いて機能一覧を作成しテスト用の機能の分割を決定したら、次にテストカテゴリを作成する。
- テストカテゴリとは、「論理的機能構造の各要素に対してテスト対象にふさわしい名前を与えたもの」である。 （引用元 https://www.jasst.jp/symposium/jasst21tohoku/pdf/S3-2.pdf 7ページ）
- 自分たちで命名することで、意図を残しやすくなるのではないか。論理的機能構造の名称をそのまま使ったり、汎用的なテストカテゴリを指定したりするのではないところが良い。
- テストカテゴリは同じプロダクトやシステムで使いまわせるため、資産にできる。
- 最終的に、「テスト分析マトリクス」で仕様項目とテストカテゴリの組み合わせに対する網羅度合いを俯瞰できる。テスト分析に携わっていない人にとって、こういった俯瞰できる資料は全体を掴むための助けになるだろう。
- マトリクスにするだけではなく、仕様項目がないテストカテゴリについてその背景も追記できれば、より理解に役立ちそうだと感じた。
テスト設計でテストの意図（テストケースの意図）を見失わないための仕組み
- テスト分析で洗い出した「テストで確認したいこと」が「仕様項目」として残るので、テスト設計のインプットになる。
- 「仕様項目」を後のプロセスでも参照すれば、テスト技法の適用やテスト値のバリエーションを考えているうちに当初のテストの意図（目的や主旨）から外れてしまうことの予防に繋がるのではないか。
- 「仕様項目」との整合性を確認することで、テスト設計の成果物がレビューしやすくなるだろう。
注意点
上述の通り、有益な手法ではあるが、適用にあたって注意したい点もあると感じた。
- テストカテゴリは同じプロダクトやシステムで使いまわせるとのことだが、作った人がいなくなったら、その意味や使い分けは失われそうな気がする。 工夫が必要。
- テストカテゴリを作成する際、「起こりうる不具合」を検討してチームで認識合わせをするプロセスになっているが、この「起こりうる不具合」をうまく保管できれば一定、理解の助けになるのではないか。
- オンボーディングで社内用語のような形で教育するのもありかもしれない。
- 体系的なプロセスと巧みな仕組みがあるとはいえ、それぞれのプロセスの成果物の抽象度は自分たちでコントロールする必要がある。
- 例えば、テストカテゴリをやたら具体的にしてしまうと、仕様項目を出すときに苦労するし、他の開発案件で使いまわせなくなるだろう。
- 先ほど述べたJaSST'21 Tohokuの資料を参考にする方法はありそう。
- 機能一覧には、機能項目（機能の名称）の他、それに紐づく仕様書の章などを書く。仕様が全くドキュメント化されていない組織の場合、ここでつまずく。
- 何かのドキュメントやシステムそのもの、あるいは、誰かの頭の中には一定の機能の情報があることがほとんどだろう。工数の捻出は必要になるが、事前にそれらを簡単にでもドキュメント化できれば解消できるように思う。
