対話するプロセスがバグを“予防”する　チームの共通認識を作るためのテスト観点図

『ソフトウェアテスト技法練習帳』の著者の1人であるQAエンジニア

根本紀之氏（以下、根本）：よろしくお願いします。今日は「テスト観点図でチームの知を集める方法」ということで、アジャイル札幌とJaSST東北の両方のコミュニティに所属している根本が発表します。よろしくお願いします。

簡単に自己紹介をします。名前は根本と言います。札幌の某半導体のメーカーに勤めていて、今はQAをやっているエンジニアです。コミュニティは、アジャイル札幌の代表をやっていて、2020年はスクラムフェス札幌2020をやったり、スクラムフェス三河で発表したり、いろいろ活動をしています。

もう1つ、ソフトウェアテスト系のコミュニティで、t_wadaさんの推薦図書の『ソフトウェアテスト技法練習帳』も、友人と一緒に書いています。今回、4月12日に重版出来が決まりました。どうもありがとうございます。

ほかにはテストの現状調査の翻訳『STATE OF TESTING』や、『TESTER CHAN』という、初心者向けのソフトウェアテストの漫画の英語版の翻訳のお手伝いをしています。

令和は「バグを予防する」時代

それでは今日の本題にいきたいと思います。もう令和に入って何年か経ちましたが、バグは検出の時代から予防の時代へ変化しています。昔はどうやってテストして、どういうふうにバグを出していくかにすごく着目していたと思います。

しかし、やはりそれだけではなかなかこの早いスピードについていけないということで、いかに前段階でいろいろな施策をしながらバグを作らないようにするか、作り込まないようにするかを考えていく必要が出てきています。

昔も「レビューをしっかりしよう」とか、V字モデルの派生でW字モデルなどがあって、いろいろやっていました。やはりアジャイル開発がメインになってきたこの時代において、予防というのが、さらに強く求められているということになります。

実際どうやってバグを予防するのかというところですが、これはもうシンプルです。チームみんなが早い段階から品質、テストについて考えていく。バグや手戻りがないような設計、実装をしていきます。

Agile Testingという文脈の中では、「チーム全員で戦うぞ」ということのWhole Team Approachということで、チームみんなでテスト、品質について考えていくのが大事だと言われています。

今日の話を簡単にまとめると、みんなでテスト観点図を作って、チームの共通認識を深めていくことでバグが予防でき、幸せな開発ができます、ということを伝えます。

チームにはいろいろな人がいます。開発もいる、テスターもいる、ビジネス側、POもいる、運用もいるということで、いろいろな人の知識を集めようということを、今日は伝えたいと思います。

共通認識を育てるときに役立つ例

チームの中で共通認識を育てるときに、役に立つ例が何点かあります。ほかにもたくさんありますが、メインのものを挙げています。

例えば実例型仕様（Specification by Example）、SbEと呼ばれていますが、これは自然言語によって「Given – When - Then」形式で書かれているようなものです。それをATDD、受け入れテストに流すところで使われたりします。

実例型仕様からの派生で、実例マッピングがあります。これはストーリーに対して、ルールや例、質問を考えていきます。実際に具体的な例を挙げることで、どんどん明確化していくようなアプローチになります。

あとは品質スライダー。これはジャネット・グレゴリーさんがRSGT2021で話してくれたもので、チームでどの品質に重きを置くかを考えることです。

例えばここでは、“信頼性”、“アクセシビリティ”、“パフォーマンス”のどれが今回のプロダクトで重要なのかを、「私はこう思う」「私はこうだな」と意見表明をして、みんなでディスカッションするツールの1つになります。

それに今回話すテスト観点図をツールの1つとしてもってもらえればいいかなと思い、今日は話したいと思います。

テスト観点図はどういうものか？

テスト観点図っていったいどういうものなのでしょうか？　大元は一応、テスト開発手法であるVSTePの成果物の1つです。

VSTeP自体は今回説明しませんが、簡単にいうと、テスト観点を構造化したものになります。チームメンバーの気になることを、テスト観点図として同じ図に表現します。当たり前と言ったらそのとおりですが、ロールによって気にすることが違いますよね。「いやぁ、開発者だったら……」「いやぁ、テスターだったら……」みたいなのがよくあると思います。

例えば、開発では自分が組んだロジックの処理速度、テスターは異常処理のところを気にします。運用だと「メンテナンス性高いの？」とか、ビジネスだとお客さんにウケがいい画面デザインが本当に統一されているか、色使いとかも含めて気になると。

もちろん個人にもよりますが、それぞれのロールで気にするところが違うので、それを1つのテスト観点図としてまとめて、みんなで共有しようという話です。

テスト観点図の作り方と作成のタイミング

どうやって作るかです。関係者全員で、どのようなテストが必要かをまず洗い出します。誰かが作って、見てくださいっていうのはやはりちょっと遅くなるので、モブに近いスタイルで作っていくのがいいかなと思っています。一気に集まって、一気にやるということです。

なにか気になることを少しずつ言っていって、それにしっくりくる言葉を見つけてテスト観点としていきます。これはソフトウェア開発の設計で使っているモデリングや、クラスの名前を決めることと、ほぼ近い作業かなと思っています。

例えば、ボタン配置がガイドラインに沿っていること。これは“レイアウト”という言葉にしましょうというように、一つひとつテスト観点を置いていくことになります。

たくさん出てきたものを、それぞれ構造化します。構造化されたものに、さらに新しいものを追加したり、必要に応じて、追加や削除する剪定作業をしていきます。こうやってだんだん構造化していって、テスト観点図を作っていきます。

作り方はわかりましたが、じゃあどこで作るのでしょう？　ということです。作るタイミングは、どのプロセスでも作れます。「いや、テストなんだからせめて設計にいかないと作れないでしょ」という方もいると思いますが、企画段階でも作れるし、ある程度できてきた要件定義の段階でも作れます。

もちろん詳細なもの、完璧なものは作れませんが、その時点でわかっていることで作れます。プロセスを進めるごとに、解像度を少しずつ上げていくイメージがよいかなと思っています。

早い段階からチームで観点図を作るメリット

結局早い段階からチーム全員でテスト観点図を作るメリットは、いったい何でしょう。チーム全員が対話しながら作ることで、短時間で共通認識を醸成できます。

先ほどもちょっと言いましたが、誰かが作ったものをレビューする方式だと、ロールの違いによって必要なテストや「ここは本当はやりたい」とかが違うために、「いや、これ抜けてるよ」「追加しました」「ちょっと違うんだよね」みたいなやりとりがあって、ぜんぜん進みません。なので、一気に作るほうがいいと思います。

また、チーム全員のノウハウや、気になるところが同じ図に表現されます。これ、実は別の開発でも再利用できる可能性があります。似たようなプロダクトだと、次の開発に持っていけます。

個人の責任ではなく、チーム全体の責任になります。一番いいのは、チームで出し切った安心感があるので、「自分、テスト設計したけど大丈夫なんだろうか」とか「あの人に任せて大丈夫なんだろうか」みたいなことはありません。

開発者は設計、実装にフィードバックできる。これがやはり予防の効果になります。また、テスターはテスト設計のインプットとして使えます。これもとてもいいです。

テスト設計の段階になってから新たにもう1回考えるかではなく、すでに開発、運用、PO、テスター含め、みんなで作っているテスト観点図をもとにテスト設計ができるので、これも時短の効果があると思います。

テスト観点図を作る具体例

「いろいろ話してなんとなくイメージはわかったけど、実際にどうやるの？」というところを、具体的な例を見ながら話していければと思います。エクスポート機能の例になります。

あるWeb画面です。AAA画面にエクスポート機能を追加してほしいということで、要件定義の段階くらいで「ここに、こんなエクスポートボタンを追加してください」と（要件が）きました。

もちろん詳細はまだ決まりきってはいませんが、この時点でもある程度作れます。それをデモのようなかたちで見せられればと思います。みんなで集まっていろいろ出していきます。

この簡単な画面だけでも、いろいろあります。グリッドに出ているデータと、エクスポートしたデータが一致しないといけないので「正確さ、表示データと一致」のようなかたちで追加しています。

また、よく見るとクローズボタンとエクスポートボタンの大きさが若干違います。ボタン、大きさや配置場所が、本当にこの位置がいいのかもテストしたいということで、気にしていますと。

操作方法です。ボタンそのものでできるのはいいですが、右クリックメニューでもできることを思っていれば、右クリックメニューからもテストする必要があります。

あとは整合性です。実は今回AAA画面に追加しますが、BBB画面でも同じようなエクスポートがすでにあります。そちらとレイアウトやフォーマットをそろえたほうがいいと思えば、追加します。

（画面の）こちはまだきれいなテスト観点のワードにしていないので、次のページでどう変えるかを説明したいと思います。わからないときは、日本語の文章みたいなかたちで書いてもいいかなと思っています。

まず、整合性を見ていきましょう。さっき日本語で書いてあったものは、レイアウトと書いたり、エクスポートフォーマットと書いたりしています。

例えば「あ、出力形式も必要だな」と誰かが思いついた場合は、1つ追加して、CSVで書いてください。もしCSVのほかにも別の形式があれば、同じ並びで追加していきます。

これでどんどん仕様に近いところや、どういうところをテストするのかを含めて、すべてのチームのメンバーの考えを表していくかたちになります。要件定義はだいたいこんな感じでできたので、今度は設計にいきます。すると、また新しい情報が出てきます。

開発の人が「ここ実はデータ件数が大きい場合があって、使用するメモリがけっこう足りなくなりそうです」ということで、処理を分割してエクスポートするような設計変更、設計をすることにしました。

そのときには、また追加されることになります。正確さでなにか欠けそうなイメージがありますが、「分割のところ大丈夫かな」ということで、分割の境目を入れています。

あとは、下のほうに分割と入れて、分割されるときとされないときを両方入れています。分割しないときに、なにもデータが出ていなかったみたいなこと、よくありますよね。分割するときは出ていますが、分割されないときはぜんぜんなにも出ていないようなことがあるので、こういうところもテストしたいとか。そういうところを気にしています。

あとは今回の目的である、メモリが一定であることも確認が必要なので、メモリ、一定と追加しています。

今は追加しているだけですが、実際は行動自体がドラスティックに変わったり。新しい大きい項目ができて、その下に付けましょう、みたいなこともあるので、わかりやすいようなかたちで構造化してもらえればと思います。

テスト観点を出すときのコツ

テスト観点を出すときのコツです。テスト観点を言語化できなくても、まずは話してみましょう。「そうは言ってもテスト観点って慣れないからよくわからないんだよね」という方は、「こんなテストがあったらいいな」「こういうテストが必要だよね」というところを話してみましょう。

もしそれもちょっと難しいのであれば、「こんなバグ起きたら嫌だな」と話すだけでも、チームメンバーの誰かが言語化して、テスト観点として出してくれると思います。

あとは、些細なことも話してみる。これはすごく重要です。チームで誰かが気づいていたのに、そのバグを検出できないことが一番なくしたいことです。そのため、些細なことでも話してみて、「みんなわかっているだろうなと思うかもしれないけど、自分の中でちょっと気になった」ことを声に出して聞いてみてください。チームの誰か1人でも思いついたことは絶対に逃さないということで、がんばってみてもらえればいいかなと思っています。

あと図を作ると、本当に漏れ抜けがない完璧な図を求めることが多いんですが、その時点で納得感のある図ができればいいです。納得感というのは、チームメンバー全員で「今のところの自分たちの力を出し切って『こういうのが必要だね』っていうのを出し切った」のであれば、それはそれでいいかなと思っています。

もちろん1回ではできないので、開発の進みとともにテスト観点図も成長させていきます。今回はテスト観点図で話しましたが、図よりも大切なのは、実は対話するプロセスだということを意識して活動を進めていければなと思っています。

この人はどういうことを気にしているんだろう。どういうところをテストしないといけないと考えているかを、お互いに理解していくのが重要だと思います。

構造化のコツ

あとは構造化するときのコツです。抽象度が高い言葉が出たときは、実際に何を意図しているのかを聞いてみてください。「う～ん、パフォーマンス」と言ったときに、「あなたの言っているパフォーマンスは、メモリの話でしょうか？　CPUでしょうか？　それともエクスポートが終わるまでの処理時間だろうか？」みたいな。実はパフォーマンスと言われても、人によってぜんぜん違うので、何を意図しているのかを聞いて、その言葉どおりのテスト観点を置いていくことです。

あと、具体的な値は書きすぎない。これはExample Mappingなどとはちょっと違うところですが、あまり具体的な数値を書きすぎると、図をシンプルに保てなくなります。モデリングと一緒で、このテスト観点図のいいところは、抽象度を保ったまま、シンプルなかたちでレビューや、みんなの中で知識を共有できることです。

「ここで100、200、300」みたいな、具体的なかたちでは入れない。それを観点図に書きすぎないことが重要です。もちろんポイントになりそうな特殊な値や、「ここはよく使う」みたいなのがあれば、それは目をとおして書いておくのがいいと思いますが、すべての観点に具体的な値を書くのは、ちょっとやめたほうがいいかなと思っています。

これもオブジェクト指向のモデリングと一緒ですが、Is-aとHas-aを意識する。あとは構造化されているので、上下のノードを見て「どれくらい抽象度大丈夫かな？」「飛びすぎていないかな？」「これとこれ、実は抽象度が一緒じゃないか？」みたいなことの上下になっていることはないようにします。

あと横並びのノードを見て「粒度が合っているかな？」「ほかにこの並びだとなにかないかな？」を確認するのがいいかなと思っています。こうやっていくと、だんだんある程度きれいに構造化していって、見やすく、わかりやすく、いいものになっていくかなと思っています。