『ユースケース実践ガイド』をもとにした品質向上への取り組み　全体像を見るテスターの視点はチームへの大きな貢献になる

ビッグピクチャーとユースケース

伊藤潤平氏（以下、伊藤）：ビッグピクチャーとユースケースです。ジャネット先生と話していると、「ビッグピクチャーを理解しましょう」という話がよくあります。ビッグピクチャーは全体像という意味で、Agile Testing Daysのキーノートでもジグソーパズルの例を出して説明していました。

ジグソーパズルの1ピース1ピースがユーザーストーリーで、これを組み立てると全体像になる、というキーノートでした。あとRSGTでも、全体像をみんなが理解するまでは質問をしましょう、という話がありました。

『Agile Testing』の書籍でもビッグピクチャーについて書かれていて。チャプター21のサマリーチャプターで、7つの成功要因がまとめられています。

その中で「Success Factor 6 : Collaborate with Customers」といって、テスターがアジャイルチームに貢献する最大の価値は、顧客の要求を明確にして、優先順位づけを助けて、要求された動作やユーザーシナリオを具体的な例で説明して、それらの例を実行可能なテストに変えることであるとか。

Success Factor 7には Look at the Big Pictureって、そのまま書いてあるんですけれど。テスターは全体像を見る傾向があり、通常は顧客の視点から見ることが多い。この全体像を見る視点はチームへの大きな貢献となる、と書いてあります。

このSuccess Factor 7では、Agile Testingの4象限を作ったり、テスティングピラミッドを作ったらだいたい全体像が見えてくる、みたいなことが書いてありました。

7つの成功事例からとった現場へのアプローチ

今回の現場では、ジグソーパズルの例やお客さまに質問するだったり、顧客の要件を明確にしてユーザーシナリオに落とし込むとか、顧客の視点で見るなど、そこまでいっていないことがわかっていました。

ですので、そういう学びから私の取った行動は、直接お客さまに聞いちゃおう、ということでした。チーム全員のメンバーをZoomに呼んで、顧客側の担当者も呼んで、初顔合わせもあったんですが、「すみませんが、ユーザーシナリオをイチから教えてください！」という感じで質問しました。

そうすると、やはりユーザーも品質を上げたいという目的は一緒なので、いろいろ話してくれました。裏話までたくさんしてもらって、すごく盛り上がった会だったんですね。

内容としては、製品を使う目的だったり、そこにはどんなアクターやペルソナがいたり、どんな環境で使っているか、現場、スタッフがどこにいるかなど。そして、ログインしてからログアウトするまでの時間、あとはどんなシナリオでどんな場面で使っているかなど。そんな話を教えてもらいました。

『ユースケース実践ガイド』と現場での実践

先ほど、ジェームス・コプリエンさんのプロダクトオーナー研修を受けたお話をしましたが、そこでもジェームス・コプリエンさんがユースケース化の話をしていました。特に『ユースケース実践ガイド』という本があって。「これはユースケースの書き方が書いてあるのですごくおすすめです」という話をしていました。ただこの本、今日本語版が絶版になっていて、私は中古で買いました。

彼の提唱するユースケースとは、エンドユーザーとシステム間の関連シナリオのコレクションで、そのコレクションの中にインスタンス、つまりシナリオが複数入っているという話でした。

プロダクトオーナー研修なので、ユースケースを理解して中に入っている複数インスタンス、つまり複数のシナリオをうまいことバックログに落として優先順位づけするという話でしたが、私はこれをテストにすごく使えるなとずっと思っていました。

それを実践してみました。ユースケース、フローみたいな感じでユースケースをフローにシナリオを落として。1個のユースケースを1つのカードみたいなところに情報を集めて、その中に複数のシナリオを入れて。そのシナリオからまたサブユースケースが作れる、みたいな感じの実践をしていました。

（スライドを示して）これは実際のシナリオカードです。その中では、名前やシナリオゴール、アクター、前提条件、トリガー、あと複数のシナリオ、最低限の保証というまとめ方をしています。

この複数のシナリオを1つに集めて、リスト化しています。コプリエンさんは、ここからプロダクトバックログに落とし込みますが、私はシナリオの一覧を作って、ここからすごい数のテスト観点をバーッと導き出して、似たようなテスト観点をテストタイプに集約することをしました。

要は何が言いたいかというと、ビッグピクチャーとなるユースケースを作ると、テスト設計までどんどん落とし込めることがわかりました。

これをチームのメンバーみんなに見せたところ、プロダクトマネージャーは何を言ったかというと「こういうのが欲しかったんだよ」と。要件って、一応ドキュメントに書いてあるけど、ユーザーの観点のユースケースが欲しかったそうです。

テスト設計で実際にテストケースまで落とし込んでいったので、開発者に関しては「あ、品質ってこんな感じなんだ」と。品質に対する意識が変わったという話がありました。ですので、ビッグピクチャーを全員が理解するというのはすごく大事ということがわかりました。

Whole-Teamのアプローチ

Whole-Teamのアプローチです。ビッグピクチャーを使って、わかりやすくV字でやると、要件としてはユーザーに質問をして、どんどんユースケース化していきました。

現場では、開発者が設計書や仕様書のドキュメントを書いていませんでした。なので、私の信頼するメンバーYさんをアサインして、テンプレートを作って書き方など全部を開発者にティーチングしてもらいました。そこからテスト設計して、チーム全員、実装者もほかのチームからの開発者も全員呼んで、みんなでテストしました。

テストの実行が終わったら品質を分析して、お客さまに品質の報告です。報告した内容は現在の状況の説明と、テストの計画の内容と、実行したテストの概略の報告。それによって出たバグのリスト、そこからの弱点分析を全部正直にお客さまに報告しました。

けっこうバグの数があったので、怒られるかなと思っていたんですが。お客さまの反応は、「だいぶがんばってバグ出してくれたんだな」と逆に褒められて、ちょっとうれしかったです。そのあとチーム全員が集まって、YWT（やったこと・わかったこと・次にやること）でふりかえりをしました。

（スライドを示して）これは実際のMiroの画面ですが、活動をまとめると、まず朝会をしてバックログの内容をみんなで読み合わせというか、見ながら更新していきました。

そこからテスト計画に落とし込んでいき、ユーザーにヒアリングして、ユースケースを作ったり、設計仕様書のドキュメントを書いたり。そういったテスト設計活動をしました。チーム全員でテストの実行をして、品質を分析してお客さまに報告して、振り返りを一連の流れでやりました。

そうすると、今までなかったテストに対する意識と、「テストってこんなもんなんだ」みたいな気づきがありました。それですごくテスターとプログラマーが近くなった実感がありました。

品質を上げることで製品価値も上がる

BIの開発チームは、先ほど話したプロダクトはもうリリースして、次にもっと大きいプロダクトをリリースしなきゃいけないということで、次のテストプロジェクトが始まりました。

しかし、このプロダクトがすごいプロダクトということはわかるんですが、ちょうどスライドのラーメンの絵のような、機能全部乗せ状態。機能がモリモリで、結局どうやって使うかとか、目的がよくわからない状態でした。

ユーザーに聞いても「よくわからない」みたいな話を実はしていているし、開発者側に聞くと「単体テストはやっているけど、それくらいです」とか。探索してみると、案の定深刻なバグが出ちゃっていた状態でした。

私はこれはリリースできないと思って、チーム全員と会話をしました。みんな「そう思う」みたいな。「今のようなテストをやったらたぶんたくさん（バグが）出るし、やり直したほうがいい」という話はあって。ステークホルダーに直訴して、11個くらいの課題の理由を並べて話しました。

そしたら、見事にリリースが延期できて。当然、お客さまに説明に行きますが、「お客さまの運用の目的に沿った構成にしてまた持っていきますので、あと機能面と非機能面からも品質を改善しますので延期させてください」という話をしました。

来月くらいにリリースの予定ですが、けっこういい感じで仕上がっています。そうすると、プロダクトマネージャーは「これだけ品質がよかったらもっとお金取れそうだな」みたいな話をしました。お金の話をすると、プログラマーも「品質もっと上げていかなきゃ！」みたいな話になりました。

つまりこれは、品質を上げることによって製品価値も上がるんですねという話で、みんな品質にフォーカスするようになった瞬間でした。

（次回につづく）