はじめに

今日は、来年の5月28日に予定されているJaSST東北に向けて、JaSST東北の実行委員のメンバーのみなさんと、実際に使うことができるプロダクトを使って、ゆもつよメソッドの流れに沿ってテスト開発プロセスを進めていく実践ワークショップ合宿をしています。と言ってもオンライン合宿です。

JaSST東北の実行委員はすごい人たちで、ゆもつよメソッドをJaSST東北でワークショップをする話になってから、そのときまでに自分たちでもゆもつよメソッドを教えることができるレベルに極めるという目標を持って、去年の夏くらいからずっといろいろな題材でテスト分析〜テスト設計をやっています。私も定期的に打ち合わせに参加して質問に答えたり、合宿して一緒にテスト分析したりしています。

今日の合宿では、私はみんながワークをやってるのを横目でみながら、ディスカッションが行き詰まったらアドバイスすると言う係なので、空く時間を使って順番にどんなことをやってるのかをこのnoteにまとめます。

ちなみに、題材の内容は書けないので、ちょっとふんわりさせています。そこらへんはご了承ください。

１、テスト対象を理解しながらざっくり絵（モデル）を書く

仕様を理解しながらユーザーが使う際に判断できる機能を論理的機能構造で配置していきます。上記の絵は、過去に私の方でワークの題材に対して絵を書いた時の写真です。（JaSST東北でワークをやるためにこれまでに多分10近いテスト対象の題材でゆもつよメソッドやってるんです、すごくないですか？）

今回の合宿では実行委員の皆さんでの共同作業なので、まさに今、みんなでmiroを使ってやっています。（miroの内容は今回は掲載しません）

この作業によっていろいろなことがわかるようになってきます。例えばこんな感じです。
・入力が複数あるけど登録するのは1つの情報であるなー
・入力するけど条件により処理が異なってるぞ！
・処理結果によって出力が異なるんだな。
・出力についていろいろ書いてあるけど、実は全部連動しているのか！

ユーザーがわかる機能がどうなってるのかを上記のようにわかったら関係を線で繋いだり、補足情報を追記したりします。

２、テスト対象の仕様を整理して機能一覧を作る

機能は大きく2段階で整理します。

機能（フィーチャー）カテゴリ
上記の図では○になるところです。ユーザーに価値を与えてるレベルでグルーピングできるようなカテゴリをフィーチャーカテゴリとよびます。仕様書の目次とかには引っ張られないようにするために、１で書いた絵を基に決めてしまって良いです。機能カテゴリの目的は、テスト対象の規模が大きいときに大きくグルーピングするとどのようなことができるかというのがわかるようにするためです。テスト対象がシンプルなものであれば、機能カテゴリは1つになることもあります。また、このあとのテストケースを作るところまでは直接関係しません。ざっくりグルーピングして全体を見渡しやすくすることが効能です。

また、「ユーザーに価値を与える」が誤解を与えてしまい、先の先まで見てしまうことがあり、わかりづらくなることがあります。例えば以下のような例みたいになってしまうと機能カテゴリとしてちょっとわかりづらいです。

例えば写真を保存するアプリで、共有機能をカテゴリする場合に、これは普段会えない人に自分が元気であることを伝えるので「近況報告」という機能カテゴリにしよう！

みんなで話し合うとちょっと行き詰まってしまうこともありますが、そんなときは以下の合言葉が良いです。

　　　「いったんこれで決めて次やりましょう。
　　　　次やっててなんかおかしいと感じたら戻って見直しましょう。」

機能項目（フィーチャーアイテム）
機能項目は実際の機能をそのテスト対象のI/Fの単位で整理します。上記の図では→に相当するところになります。

仕様書がある場合は目次を列挙して、その上位項目として記載していくのも良いです。内部的な深い機能はそのあとのテストカテゴリで整理していくので、ここではあくまでテスト対象のI/Fの単位（ユーザー から見てわかる機能）で機能を決めていきます。

３、テストカテゴリを決める

論理的機能構造をテスト対象にふさわしい名前を与えたものをテストカテゴリーと呼びます。

論理的機能構造だと名前が抽象的すぎて、「これってどう言うことだろう？」ってなることがあります。そこで悩んでしまうと逆に効率が下がります。なので、「テスト対象を使う立場から言えばこの論理的機能構造はこう呼んだだほうがわかりやすい！」ってなる名前をつけます。それがテストカテゴリです。

テストカテゴリーを決める方法は以下のようになります。

1-1. 機能（フィーチャー）一覧と論理的機能構造のマトリクス表を作り、機能一覧の機能項目ごとに、論理的機能構造で見たときにその機能に該当する処理があるかどうかを列挙していきます。以下のようなイメージです。

列挙し終わったら、それらを眺めてテストカテゴリーを命名していきます。

上記の表はほんの一例ですが、例えば、入力調整だと、ログインだとパスワードチェックをするというのと計算条件設定だと入力文字チェックをするのがあると列挙しています。変換は「なし」

これらの確認をするときにふさわしいカテゴリ名ということで、「入力チェック」って名前にするというのが考えられます。出力調整だと、パスワードのマスクとエラーメッセージ表示がありますが、これらのテストするのにふさわしいテストカテゴリと言うことで「表示確認」って名前にすることが考えられます。

テストカテゴリーは論理的機能構造一つに対して一つが理想的ですが、複数になっても構いません。ただ、論理的機能構造に対して多くの、例えば5つ以上のテストカテゴリーが出てくるようではあまり良くありません。また、この後に見つけていくP-V（パラメーターとバリュー）になり得るものをテストカテゴリーにするのはNGです。

４、各テストカテゴリに相当する起こりうる不具合を出す

テストカテゴリは、論理的機能構造だと抽象的になってしまい悩んでしまうことを防ぐのが目的なのですが、テストカテゴリをつけてもそれでもまだ具体的に列挙しようとしたときに「これはどのテストカテゴリに属するんだろう？」と悩んでしまう可能性があります。

そこで上記の表のように不具合を想定してみて、「こういう不具合はこのテストカテゴリに分類するんだよね！」とか「こう言う不具合が出るかもしれないからこういう仕様項目必要だよね」ということをチームメンバー内で合意できると、その後の仕様項目の列挙でメンバー間でのブレが少なくなります。もしくはレビューがしやすくなります。

この作業は正式な作業ではなく、あくまでメンバー間の意識合わせのために行うものです。コンサルティングしていたときは、１−３までは１人か2人で行い、４から関係者が全員入ってくるというやり方をすることが多かったです。５はみんなでやっていくので、その前に３で決めたテストカテゴリを全員が納得できるようになればバッチリです。正式なドキュメントにするものではないので綺麗に整理する必要はありません。

５、（テストすべき）仕様項目を洗い出して列挙していく

ここがテスト分析の本丸になる作業です。（テストすべき）仕様項目とは、JSTQBではテスト条件と呼んでいるものに相当します。

機能項目（フィーチャーアイテム）ごとに、それぞれのテストカテゴリからみてテストしたほうが良いことを洗い出していきます。何を確認したいかは仕様項目、どうやって確認するかは期待結果に記載します。

もし、ある機能項目のテストカテゴリに分類できる使用項目がない場合は「なし」と記載します。

仕様項目を列挙するときに不明点というか疑問点が出てきたら「仕様整理」欄に疑問点を記載してそれ以上は悩まずに次にいきましょう。

複数の機能項目に同じ仕様項目が現れたとき

同じ仕様項目が現れてしまう可能性としては、複数の機能項目で連携して動く場合は、重複しないようにどこかにまとめることになります。ゆもつよメソッドではこの場合のルールを決めています。

・ある機能が事前条件として動き（書き込みをするとか）、レポート機能などがその書き込んだ機能を呼び出して画面表示する場合
→これは、書き込みをする機能側の「相互作用」に属する仕様項目とする

・テスト対象とは違う（OSやブラウザなど）ものが事前条件として働き、テスト対象の機能（呼び出し側）に影響を及ぼす場合
→これは、呼び出し側のテストにてテスト設計時のP-Vに含めます。

・ある機能がシステム外部に影響を与えるが、テスト対象としていったん集約して処理をして外部に渡している場合（1つのことを実現するのに外部の機能含めて3つの処理が連携して実現する場合）
→テスト対象として外部のI/Fになっている機能が何かしらの処理をしてるのであれば、その機能の相互作用の仕様項目にするのがよい。

テスト設計で考えるような細かいことを思いついたとき

また、使用項目の洗い出しの最中に細かい確認をしたいことがたくさん出てくることがあります。例えば、「途中で処理を止めたら入力した内容はどうなるのか？」とか、「割り算の計算するときに0を入れたらどうハンドリングするのか？」とかです。こういうのは、ゆもつよメソッドではテスト分析ではなくテスト設計で行うことにしています。なので、以降の７や８で正式に行うことになります。なのでそういう細かいことは深追いせず、テストすべき仕様項目の洗い出しに集中しましょう。

といっても、せっかく思いついたことは後で絶対役に立つので、テスト設計の欄に現時点で思いついたことを記載しておきます。

６、全体俯瞰（レビュー）とリファクタリング

仕様項目を洗い出して列挙したら、チームの間でレビューを行います。上記の考え方で仕様項目を複数人で列挙している場合、パスアラウンドレビューしてもよいですが、この合宿ではウオークスルーをしています。

ここでレビューをしているときには、どの機能項目に配分させるかとか、機能項目の抜け漏れが見つかるといったことがあります。今日の合宿でも実践さながらの意見がいっぱい出てきて、聴いてるこちらがとっても面白かったです。

今日はここまでで終了です。

-----

ゆもつよメソッドのプロセスとしては、この後は以下のように続いていきます。これはまた機会があれば別のnoteとして書いていくかもしれないです。

６−１、テスト分析マトリクスを作って全体俯瞰をする
６−２、リファクタリングをする場合
７、テスト概略設計をする
８、テスト詳細設計をする

さいごに

今日参加されていたJaSST東北の実行委員のみんなが本当にゆもつよメソッドをうまく使いこなせるようになっていて、感激しています。考えてみれば初めて合宿したのが去年の11月くらいで1年以上前です。そこから比べたら雲泥の差です。ほんとすごいと思います。
（以下の写真は初めて合宿したときの様子）

以上