本記事は『ソフトウェアテストをカイゼンする50のアイデア』の「Chapter 1：テストのアイデアを生み出す」から抜粋したものです。掲載にあたって一部を編集しています。
※本書はGojko Adzic、David Evans、Tom Rodenによる『Fifty Quick Ideas To Improve Your Tests』（2015、Neuri Consulting LLP）の邦訳です。
「常にある／決してない」から考えよう
チームが、新しいコンポーネントや、ビジネスドメインの中でも不慣れな分野に初めて取り組むと、テストのアイデアを考え出す際に「鶏が先か卵が先か」という状況に直面することがよくあります。また、よい具体例がより優れた反例を導いてしまう可能性もあります。
しかし、ドメインの全体像を把握するには、最初によい具体例がいくつか必要です。不慣れな分野で仕事をしていると、検討していることが基本的な内容なのか、それとも、より複雑な内容なのかを判断することが難しくなります。経験が不足しているからです。
これは危険な状況といえます。なぜなら、チーム全体がすべての重要な前提を把握し、共通の理解を得たとしつつも、ドメイン知識が不足しているため、そういった恐ろしい問題に気づけないからです。ラムズフェルドの有名な知識の分類における「知らないと知らないこと」によって、多くの問題を隠し、チームは経験不足のためにそのことに気づけていない可能性があります。
このような状況は、「常にある／決してない」というヒューリスティックな考え方が非常に役立ちます。全体像をすばやく把握するために、私たちはしばしば、常に起こるべきこと、または決して許されるべきではないことを特定する10分間のセッションを開催します。そこでは、「常にあるべき」や「決してあるべきではない」といった絶対的なステートメントから始めることによって人々が例外を考え出すように促されるため、より興味深い質問をすばやく準備できることにつながります。
例えば、eコマースシステムのコンプライアンスに取り組むとき、私たちはビジネスのステークホルダーに、決して起きてはならないと感じたいくつかのことを書きとめるように依頼しました。ステークホルダーからの最初の提案は、「取引を決して失うことはない」でした。これにより、「常に取引を監査する」という別のステートメントが作られ、開発者は失敗した取引も監査する必要があるかどうかを尋ねることができました。
次に、取引について2つの相反する見解を特定しました。ビジネス部門の人は、購入が拒否された場合でも、何かを購入しようとする試みを取引と見なしていました。しかし、開発者は成功した購入のみを取引と見なしていました。それにより、不正防止を目的として購入の試みと失敗を取得し、保存することが、実際には非常に重要であることが判明しました。「常にある／決してない」シナリオから考えることで、ドメインに関するいくつかの間違った仮定をすばやく特定することができました。
主な利点
フィーチャーまたはコンポーネントに関する絶対的なステートメントは、主要なリスクに関する議論を組み立てるために最適な方法です。「常に」または「決して」で始まるステートメントは、多くの場合、最大のビジネスリスクを示しており、人々がそれらを分析すると、残りの機能を理解するためのよりよいコンテキストが得られます。
絶対的なステートメントのもう1つの優れた点は、簡単に反論できることです。ステートメントが正しくない場合、1 つのケースを見つけて無効にし、適切なディスカッションを開始する必要があります。そのため、特に誰かが簡単に反例を思いつくような場合には、誰かが考える普遍的な真実を書きとめることが、さまざまな仮定をすばやく明らかにすることに役立ちます。これは多くの場合、用語の違い、洞察力の欠如、または異なるメンタルモデルを示しています。
これは難しいレガシーシステムを扱う場合に特に重要です。レガシーシステムで採用されていたソリューションが、誰かに提案された真実に当てはまるかどうかを、誰でもすばやく確認できるからです。例えば、あるステークホルダーが、各購入が監査レコードと一致するはずだと主張した場合も、レガシーデータベース内の過去6カ月間の購入数と監査レコード数を比較することで、それをすばやく確認できます。それらが一致しない場合、それは人々が気づいていなかった複雑な内部システムの相互作用についての興味深い発見となります。
それを機能させる方法
誰かが考える普遍的な真実についての議論は、さまざまな仮定の発見につながります。そのため、「常にある／決してない」ステートメントのすべてのリストを提供する責任を誰か1人に押しつけないようにしてください。必ず、いくつかのグループに分けて、10分または15分間別々にブレインストーミングしてから、グループをまとめて結果を比較します。または、付箋を渡し て、しばらく黙ってアイデアを書きとめてから、すべてのメモを壁に貼って、同じようなアイテムをまとめます。
普遍的な真実として考えたアイデアを整理したら、それらを1つずつ拾い上げ、反証を試みましょう。各ステートメントについて、反例や誰かが考えた普遍的な真実が成り立たない可能性のあるケースを考え出すようにしてください。また、ドメインの経験が少ない人や内部の仕組みについての十分な理解がない人に、簡単に誤解される可能性のあるケースを一覧にすることもよいでしょう。これらは、フィードバックやグループディスカッションに適したシナリオです。
決して起こらないはずのことについてのステートメントについて話し合ったあと、代わりのイベントを調べることを忘れないでください。
もちろん、誰かが考えた普遍的な真実を覆すような具体例は、重要なテストケースになるはずです。ただし、それだけでなく、ディスカッションの終わりまで絶対的なステートメントが当てはまる場合でも、その反例にならないか検討した主要なシナリオを保存し、将来のテストとして使用してください。このような具体例は、ドメインに関する知識が少ない人にとって特に役立ちます。潜在的な誤解や誤った仮定を避けられるからです。
感情を利用しよう
テスターが日常的に指摘するように、新しいソフトウェアのフィーチャーが持つリスクを適切にカバーするために必要なテストの種類に関しては、ハッピーパスは氷山の一角にすぎません。
確かに、ハッピーパスシナリオから始めることは理にかなっています。それは、強力で主要な最初の具体例と、他の可能性を考えるための土台になるからです。しかし、そこで歩みを止めるわけにはいきません。
他にどのようなことを確認するか、他にどのような手順を試すか、使用する技術をどう確認するか、は必ずしも簡単なことではありません。境界値分析や同値分割などの、一般的に教えられている手法は、特定のテストを洗い出してカバレッジを高めるよい方法ですが、それだけでは十分ではないのです。
仕様化ワークショップ、その後のテスト設計、または探索的テストセッションのいずれにおいても、テスト設計のヒューリスティックを使用すると、非常に有用な議論が促進され、他の方法では手つかずのままだった可能性のある、いくつかの目印が目立つようになります。
私たちが提案するヒューリスティックは、10の感情または行動の種類に基づいています。それは、「恐れ」「幸せ」「怒り」「非行」「恥ずかしさ」「寂しさ」「物忘れ」「優柔不断」「貪欲」「ストレス」の10個です。前ページの挿絵は私たちが思いつく限りで最高に記憶しやすくするものです。それぞれの感情や行動が何を表しているのかを思い出すのには難しい場合でも、図がヒューリスティックを調べる引き金となるはずです。
主な利点
前ページの挿絵のヒューリスティックは、仕様化ワークショップなどテスト以前の場合でも、探索的テストセッションの場合でも、チームがより完全なテストを設計することに役立ちます。これは、テストの新しいアイデアを刺激し、考慮すべき他のリスク領域を明らかにします。
これら一連のヒューリスティックの利用は、テストを設計または実行するときに、非常に迅速に幅広いカバレッジを提供できます。また、最初の主要な具体例の代替案やさまざまな視点からネガティブなケースを探している場合、ヒューリスティックは仕様化ワークショップでのよいリマインダーとなります。
それを機能させる方法
この作業を行う方法の1つは、ハッピーパスから始めて、それに沿って代替案を探すことです。ハッピーパスを歩みながら、このチェックリストを使って他のパスについて考え始めます。
ヒューリスティックを脇に置いて参照するか、ユーザーストーリーやフィーチャーを探索するときにチームとして作業します。
ここでは、テストの設計を刺激するための感情的なヒューリスティックを紹介します。これらの道に沿った感情のジェットコースターです。
スカリーパス（恐怖）
このパスをたどると、家は本当に壊され、他のすべてのものはそれとともに破壊されます。ステークホルダーにとって最もリスクの高い領域を洗い出してください。機能や変更について、各ステークホルダーを最も怖がらせるものを考えてください。
ハッピーパス（素直）
素直なケースを説明する主要な具体例であり、ポジティブなテストです。これは、私たちが考え得る振る舞いと機能の特定の領域を通る最も単純なパスです。また、これは最も単純なユーザーの操作であり、（おそらく最初の実行を除いて）毎回成功することが期待されます。
アングリーパス（怒り）
アングリーパスでは、アプリケーションの反応が悪くなったり、エラーが発生したり、うまく再生できず腹を立てたりするようなテストを探します。これらは、検証エラー、不正な入力、論理エラーである可能性があります。
ディリンクウェントパス（非行）
認証、承認、許可、データの機密性など、テストが必要なセキュリティリスクを考慮します。
エンブレシングパス（恥ずかしさ）
壊れた場合、全体的に大きな恥ずかしさを引き起こすものを考えてください。それらがビジネスの損失のような即時の大惨事ではない場合でも、それらは内部または外部の信頼性に重大な影響を与える可能性があります。これは、かつてテストジャーナルで見たような、「Qality」のような単純なスペルミスかもしれません（テスターの喜ぶ顔を考えてみてください）。
ディソレトパス（寂しさ）
これは、アプリケーションまたはコンポーネントに不完全な状態を引き起こします。ゼロ、ヌル、ブランクまたは欠落データ、切り捨てられたデータ、および、「寂しい」反応を引き起こす可能性のある不完全な入力やファイル、またはイベントを試してください。
フォゲットフルパス（忘却）
メモリとCPUをすべて使い切り、アプリケーションが何も保存できない状態にしてください。それにより、どれほどデータが保存できないかやデータが失われ始めるか、そのデータが保存されたばかりのものかすでに保存されていたものかどうかを確認してください。
インディサィスィブパス（優柔不断）
優柔不断なユーザーであり、1つの行動方針に完全に落ち着くことができないことをシミュレートしてください。オンとオフを切り替えたり、ブラウザーの［戻る］ボタンをクリックしたり、データが半分入力されたパンくずリスト間を移動してください。これらの種類のアクションは、システムが最後の状態として記憶しているものにエラーを引き起こす可能性があります。
グリーディーパス（貪欲）
すべてを選択し、すべてのボックスにチェックマークを付け、すべてのオプションにオプトインし、すべてを注文し、通常、機能を可能な限りすべてロードして、動作を確認してください。
ストレスフルパス（ストレス）
現在のシステムの規模を確認し、機能とコンポーネントの限界点を見つけてください。そして、ビジネスボリュームの将来の変化を予測できるようにします。
この手法は、複数の人がいる仕様化ワークショップで非常にうまく機能します。なぜなら、ハッピーパスではないアイデアは、まだ考えられていない質問や答えにくい質問など、興味深い会話を生み出す可能性があるためです。質問によっては取り上げて、さらなる調査が必要な場合があります（非機能特性は、繰り返し調査する傾向があります）。
テストセッションをモブで行おう
テストを計画または設計するとき、それがたとえ1人であったとしても、多くのシナリオを考えることはできます。ただし、どんな人でも、テストのための価値ある新しいアイデアを生み出すにはすぐ限界が来ます。私たちは同じ手法と種類のテストに傾倒する傾向があり（このようになってしまうことは仕方ありません）、ある種類のリスクをうまくカバーできますが、他の種類のリスクはカバーできません。その結果、リスク軽減の観点から実用的な価値がほど遠いエッジケースを作成する作業になってしまいます。
テストセッションの実行についても同じことがいえます。1人の目では、テスト対象の特定のものに自然に引き付けられ、同時に動作する製品内の他の動作が見えにくくなります。ペアになれば視野は広がりますが、パートナーは同じ目標に集中しがちです。また、多くのペアセッションでは、テストしていない人がメモを書き、テストをしている人が何をしているかを観察しています。これは時間と脳の無駄使いです。
1人で作業する代わりに、モブのテストセッションを実行してみてください。その際は、チーム全体、または他のチームや他のステークホルダーのメンバーを含む、より広いグループの人々を巻き込みましょう。
また、テスト設計もモブで行いましょう。それにより、多くのテストアイデアを迅速に生成でき、自動化のための最も価値のあるテストを簡単に絞り込めます。または、モブで探索的セッションを行うのもよいでしょう。グループのフィードバックを迅速に行い、必要な方向へ変更し、複数の領域を評価し、リスクと品質に関する強力なコンセンサスを取得できます。
主な利点
この、モブによるアプローチは、テストのための多くのアイデアを個人またはペアよりもずっと迅速に生成可能です。また、モブによる多様な思考が、より広範囲のテストのアイデアを生成します。モブのテスト設計は、必要な方針変更を可能な限り迅速にフィードバックおよび特定できるため、常に最大のリスクに対処し、最も価値のある情報を抽出できます。
モブを使用すると、2つ以上の探索経路があったとき、複数の経路に分岐しても再び合流できます。そしてそれらは、すべて同じセッション内で行えます。そして、普段のチーム以外の人々を巻き込むことでわかった興味深い効果として、巻き込んだ人々は予備知識がない分、より自由で根本的なテスト設計が可能になり、小規模なチームでは発見できなかった情報や欠陥を発見できることが挙げられます。
また、モブによるテストセッションは、チームや部署を超えたコラボレーションを促進し、関係を改善し、アプローチやアイデアの交換を増やすよい方法でもあります。
それを機能させる方法
セッションのスコープと目的を決めるところから始めましょう。それは特定のフィーチャー、ユーザーストーリー、システムの欠陥または弱点の領域でしょうか、それとも製品全体が対象でしょうか？ 次に、セッションの準備の適切なレベルを決めましょう。要件、受け入れ基準、設計、テスト環境とデータの懸念、情報の目的などに関するレベルです。
さらに、招待する人を決めましょう。チーム全体、顧客担当者、別のチーム、営業またはマーケティング担当者（「多様性は新鮮なアイデアを生み出す」ことを忘れないでください）です。加えて、人数や、全員が参加できるような場所の配置、セッションの構成や進め方について考えましょう。
私たちが参加したモブのセッションの大半は、4人から8人で行われました。20人から30人になってもうまく機能しますが、人が多すぎる場合、情報を確実に収集し共有するために、より小さなグループに分け、再び合流することを考えましょう。セッションの人数が小さいほど、よりカジュアルで、より自然なフィードバックの共有が可能になります。
いずれにせよ、明確な目標とタイムボックスを設定して、いくつかの境界線と方向性を示しましょう。そして、要件、製品、フィーチャー、問題の説明、設計、およびその他の有用なコンテキストを説明することから始めましょう。そして、全員が迅速に関与できるようにしましょう。
テスト設計セッションでは、とにかくテストのアイデアを考え出しましょう。あまりにも早く、重複を削除したり、テーマを決定したりしないでください。また、人々の発想を促すために、アイデアは最後まで残してください。そして、人々が快適に思えるよりも少し長くアイデアを考えさせましょう。最もわかりやすいアイデアをすばやく生成したあと、人々はアイデアが枯渇し始めます。すぐにやめるのではなく、もう少し長く考えさせると、珍しいけれど潜在的に非常に価値のあるアイデアがほぼ確実に浮かび上がります。
そうやって、新しいリスク、要件のギャップ、または設計上の制限が明らかになります。これらによって生まれたすべてのアイデアを収集し、それらをグループ化し、絞り込み、リスク（可能性と影響）の優先順位を付けます。それから、開発を促進するためにこれらを利用しましょう。
また、モブのテストセッションの形式を試してみてください。多くの場合、誰かがフィーチャーに関する一通りの説明を他のメンバーに行い、いくつかの典型的な利用方法で作業してみせることで開始されます。その間、他のメンバーは観察し、メモを取り、情報を要求し、調査のために領域にフラグを立てます。
モブのメンバーが何かの詳細な検査を要求すると、より興味深いものになります。例えば、新しく設計されたテストのデモとして、誰かがレポート出力を実行しようとしたところ、レポートに期待される情報が含まれていなかったとします。その場合、グループとして実験するための追加のテストのアイデアを検討します。ソースコードを調査するグループを分離する場合があれば、二手に分かれて調査をする場合もあるでしょう。
グループの数を多くすると、1 回のセッションの中でさまざまなアイデアを探求し、多くのアイデアをテストできます。それと同時に、相互に絶え間ないコミュニケーションを維持し、セッションの目的に合わせて定期的に合流できます。
メモやアイデアを書きとめるためには、ホワイトボードの用意を検討しましょう。単一のメモ帳では、大人数の場合アイデアを簡単に伝えることができません。
