「ゆもつよメソッド」というテスト開発手法を学ぶ機会に恵まれたので、掲題のテーマで書き綴ってみる。
筆者個人がこの手法を学んでみて感じたことを書いたものであり、ゆもつよメソッドの体系的な説明ではないことに注意。
※この手法を体系的に知りたい方は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の資料を参考にする方法はありそう。
- 機能一覧には、機能項目（機能の名称）の他、それに紐づく仕様書の章などを書く。仕様が全くドキュメント化されていない組織の場合、ここでつまずく。
- 何かのドキュメントやシステムそのもの、あるいは、誰かの頭の中には一定の機能の情報があることがほとんどだろう。工数の捻出が必要になるが、事前にそれらを簡単にでもドキュメント化しておけば問題ないのではないか。
