燃えろスリーアミーゴス！作れGWT！回せフィードバックループ！〜テスト駆動開発をやめて、なお残すべき習慣とは(6)

受け入れテストの探索ループで何をつくって何を作らないかの理解を具体的にしよう

はじめに

今日は、書籍の実践テスト駆動開発やSpesification By Exampleを参考に、２重のループの外側の受け入れレベルのテストの活動のキーとなるポイントを解説します。

スリーアミーゴスが協力する

システムで具体的に何をつくったらOKなのか（何を作らなくてもよいのか）は、１人のロールで纏めるのは難しく、スリーアミーゴス（ビジネス、開発者、テスター）の３者の協力が必要です。

• ビジネス：対象ドメインに詳しい。ユーザストーリーのWhyに詳しい。ビジネス観点で何がシステム必要で不要かを判断できる。
• 開発者：ユーザストーリー実現の技術的手段のHowに詳しい。問題に対するシンプルな解き方の代案を提示できる。対象ドメインをコードで言語化し、理解を深めることができる。
• テスター：テストシナリオのパターン出し、特に顧客やユーザに損害を与えるであろう盲点の発見が得意。テストシナリオをリスクベースに評価し順序付けを提示できる。

早期に何を作り（何を作らないか）のシステムの理解をすり合わせることで、手待ちや手戻りや抜け漏れや不要な作り込みを防止することができます。仕様やテストにフォーカスするのではなく、設計にフォーカスするのであれば、CRCカードやホワイトボードを使ったワークがおすすめです。

ユーザストーリーについてはこちらを参照

https://www.slideshare.net/Ryuzee/ss-8332120
http://bliki-ja.github.io/ConversationalStories/

ユーザーストーリーを１つ選びハッピーパス＞＞エッジケースの順で進める

プロジェクト初期にすべて６ヶ月で作る分のテストシナリオを具体化することはできません。ユーザストーリーに順序付けて、イテレーションを繰り返して １つづくSTEP BY STEPでプロダクトを育てていくように、１つのユーザストーリー（バックログアイテム）を選んだ後も、それに対する受け入れテストシナリオを順序付けてSTEP BY STEPでプロダクトを育てていきます。まずは、ユーザがよく使うであろうシンプルなハッピーパスのシナリオから具体化します。エッジケースは後です。

ハッピーパスが動作し進捗が進めば、複数ロールのチームでのコラボレーションのやり方を学べ、成果によってチームで一体感が得られます。また、早期にユーザ価値にフォーカスしデモの実施や一部のユーザにリリースで検証が可能となります。

テストシナリオパターンを検討してみると、次回リリースには必須ではないシナリオや、イテレーション期間内に完成させるには規模が大きすぎると分かる場合があります。その時は、ストーリーを噛み砕いて、別のストーリーとして分割し、ユーザストーリーのやることリストに追加して順序付けてして下さい。イテレーションの着手前にリファインメントで手頃なサイズにストーリー分解する活動に力を入れるのもオススメです。

完成済み：
✓ 購買者は、新商品を知って買うことができる。

--- 本イテレーション -----
■ 購買者は、期間限定セール商品を知って買うことができる。
 ■ 購買者は、トップページの期間限定セールの一覧から商品を１つ選択して買うことができる。
 □ 購買者は、トップページの期間限定セールの一覧から商品を複数選択して買うことができる。
 □ 購買者は、期間限定セールの一覧で見ることが出来ない。セール期限外の商品の場合
 □ 購買者は、期間限定セールの商品を買うことが出来ない。セール期限切れの商品がカートに入っている場合
 □ （モヤモヤ。セール商品は、ひとりが購入できる個数に制限はあるのだろうか？？)
 etc（モヤモヤ。ほかに、検討漏れないだろうか？）

--- 次のイテレーション --
□ New!商品が新商品かつセール商品の場合、新商品一覧にもセール価格が表示され購入できる
□ 購買者は、過去にチェックした商品を買うことができる。
□ 購買者は、リコメンドされた商品を買うことができる。
（後回し）

ユビキタス言語 ＆ Given/When/Then で記述する

複数人のロールで整理する際に、バラバラの語彙を使うより、共通の語彙を使うと理解が揃いやすいです。テストシナリオを記述する際は、対象ドメインの自然言語≒ユビキタス言語を使ってビジネスの人も開発者もテスターも理解できる言葉を利用します。

ハッピーパスのテストシナリオをステップに分解する際は、Given、When、Thenの形式で整理すると分かりやすいです。（頭文字をとってGWTと呼ぶこともあります）

Given:ユーザがシステムを利用する前提の条件、状態
When:ユーザがシステムに対して行う操作
Then:ユーザがシステムから得られる結果

Given−When−Thenのほか、仕様の具体例の入出力パターンを表形式で整理する方法もオススメです。

前提条件から順に Given ＞ When ＞Thenと整理が難しい場合は、期待結果のThenを先に検討することをオススメします。プロダクトのビジョンに沿ったユーザストーリーからユーザに与えたい良いインパクトが何か（与えたくない損害のインパクトは何か）を会話で明らかにし、そのためにシステムがユーザに対して何の結果を提示すればよいかのThenを明らかにし、それに至るためのWhenは何か…と検討を進めます。以下はGiven,When,Thenの例です。

Senario:購買者は、期間限定セールの一覧から商品を１つ買うことができる。セール期限内の場合(お得に買い物できてほくほく満足)

Given:？？？
When:？？？？
When:（？：カートに入れて購入するには、何をする必要があるだろうか？？？？）
When:購買者はセール商品をカートに入れ、購入を決定する。選択商品:カメラA、個数:１つ、価格：10000円
Then:購買者は購入完了できたことを知る

https://www.agilealliance.org/glossary/gwt/

テスティングフレームワークで失敗する受け入れテストを記述する

Cucumber等を使えば、Given-When-Then＆自然言語でテストケースが記述して多くの人が読んで理解できるだけでなく、コンピュータでテスト自動実行できます。

書籍の実践テスト駆動開発では、Cucumberではなく、Javaで受け入れテストを記述しています。が、Javaを使ってもビジネスの人もテストコードから仕様を読めるように工夫を凝らします。Javaならテストコードのクラス名やメソッド名や変数名を日本語を使って記述することも可能です。

実行して失敗することを確認する

テストを記述し実行しテスト結果レポートがRedになれば、システムに対するExpected（期待） と Actual（現実）のギャップが明らかになります。実装が完了して、Greenになれば、ギャップがない状態です。 Expected:期待とActual:現実 ≒ 目標と現状の結果のギャップを明らかにして、ギャップを小さくするよう調整を続けるのがフィードバック活動の基本ですが、受け入れテストの探索ループも同じです。どうやってつくると良いかの内側のループの活動については次回に解説します。

頻繁に実行し、進捗やデグレを確認する

受け入れのテストシナリオはSTEP BY STEPで変更し頻繁に実行することで、進捗の透明性を高め、デグレを早期に発見して対処できます。

頻繁に実行するには手動でテスト実行＆レポート作成＆配備は手間ですが、Cucumberなどのツールを使っている場合は、自動実行してレポート生成し配備して誰でもアクセスできるようにしておくことは比較的楽に行うことができます。そこに見に行けば、誰でも何処まで動いて何ができていないかすぐにわかり、透明性が高まります。

テストシナリオをバージョン管理する

受け入れのテストシナリオは、プロダクションのコードやほかのテストコードと同様にバージョン管理します。対象のシステムは、イテレーションを重ねるごとに、STEP BY STEPにできることが少しづつ育っていきます。

バージョン管理を使えば、変更経緯が記録でき、テストコードとプロダクションコードの乖離が防げます。あとで不要であることに気付いた時には、ある過去の時点に戻すことも簡単にできます。

まとめ

受け入れてテストの探索ループの肝となる、スリーアミーゴス、ハッピーパスからエッジケースの順で進める、Given−When−Thenを紹介しました。受け入れテストを人が読めるカタチ＆自動実行できるようにし頻繁に実施できれば、プロダクトの現状の進捗状況やデグレが誰からも明確になり、有益なフィードバックが得られます。

ユニットレベルのTDDをやめても、何をつくるべきか（何を作らないか）を複数のロールが協力して誰もが分かる形で具体化し、実際にパスしたか否かを確認し続ける活動は欠かせません。

ただし、盲点の話を思い出して下さい。受け入れのテスト駆動の探索ループは、何をつくるか（つくるか）のWhatの深掘りは得意ですが、実際に内側のHowのどうつくるかについては言及していません。内側のHowの探索ループは別途必要なのです。

また、受け入れのテスト駆動の探索ループでは、顧客が本当に欲しかったものがなにかというWhyの深掘りは得意ではありません。作る前に雑なプロトやデモ動画で検証したり、作った後に想定顧客にデモしたり、一部のユーザに限定公開しプロダクトのフィーチャがニーズにマッチしているか否かを検証する、といったWhyの深掘り探索ループが別途必要です。

次回は、内側のどうやってつくるかのHowを深掘りするための探索ループについて言及します。