テストをしながらコミュニケーションをとろう

LyRH1819
2024-10-08
2024-10-08

・テストをしながらコミュニケーションをとろう

これまでに『誰でも分かるテスト仕様書を作ろう』と言う題目で、幾つかの内容を紹介してきました。ずっと似た様な内容で続けていても飽きてしまうので、今回はちょっと別口の話にしていこうかなと思います。とは言っても急に中身が変わる訳でもなく、実質的にはこれまでの内容と地続きになっていると思ってください。上のタイトルで既に書いてありますが、取り扱うのは「テストをしながらコミュニケーションをとろう」と言う単純で簡単な事です。

テスト実施者は手に入れたテスト仕様書を元に、順番にテストを行っていくのが基本の流れになります。その中で問題が無ければそのまま継続し、問題が有れば不具合内容をまとめていきます。これらの不具合報告は最終的には全て行う訳ですが、緊急性が高い物や影響範囲が大きい物は即座に報告する必要があります。全ての項目が終わってから報告すると、多くの時間を無駄にする事になるからですね。例えばどう言う不具合が該当するか例を幾つか出してみましょう。

TEST0825-例①:テスト対象であるメイン機能が動作していない
当たり前ですが「この機能を確認して下さい」とテスト仕様書を渡されたのに、その機能が動作していなければどうしようもありません。何も出来ないのでこの場合は、ほほ全ての人が「駄目です」と報告する事になると思います。「出だしから全く駄目」と言うのは極稀にしか起きないので、一瞬テスト実施者側である自分が何か間違えているのかと疑いたくなりますが、自身をもって「実装された内容が機能していません」と報告しましょう。「何が/どうなって/このように/駄目です」と説明しなくて良いので簡単ですね。

例②:テスト対象の機能の内、部分的に機能せず影響範囲が大きい
このパターンはテストをある程度進めた時に遭遇する事が多いです。複数の機能の内、一部が正しく動作しておらずその結果多くの範囲に影響する不具合ですね。イメージし易い内容だと「商品の問い合わせページで入力した情報が保存しても保持されていない」と言った感じの不具合。何かしらの問い合わせを行った事がある人であれば容易に分かると思いますが、基本的に以下の流れになりますね。

①問い合わせページで内容を入力し保存
②確認画面で①の内容を確認
③問い合わせ送信
④①で入力したメールアドレスに自動送信内容確認メールが届く
⑤後日担当者から問い合わせに対するメールが届く

「①で入力した内容が②の時点で保持されていない」となってしまった場合、それ以降の内容を確認する意味が無くなります。そのまま無理矢理動かして④までの流れを確認する事は出来ますが、正しく機能している訳では無いのでそのテスト結果自体に価値や信頼性はありません。なのでテスト実施者は依頼者に対して不具合報告をする事になります。ここで登場するのは本題のコミュニケーションですね。この様な場合はどんな風に報告するのが良いでしょうか?

例①:「問い合わせページの情報保持が出来ていません。確認をお願いします」
不具合の内容を簡単に報告していますが、これでは足りないですね。

例②:「問い合わせページの情報保持が出来ておらず、確認画面で入力内容が初期化されています。そのまま問い合わせ送信まで行えてしまいます。他の問い合わせページも同様です」
不具合内容が詳細になり、どこまで影響があるかまで報告出来ています。とても良いですががまだ足りないです。

「不具合内容の報告が出来て、『何が/どうなって/このように/駄目です』の部分もあるのに何が駄目なのか?」と思いましたか?不具合報告的には問題無いですが、大事な部分が入っていません。その大事な部分と言うのは「このままこのテストを継続するか」と言う確認です。例えば問い合わせページのテスト項目が30項目あったとして、この不具合の影響で残りの20項目が確認する事が出来ず、更に別の問い合わせページにも影響が出ているとしたら、テスト実施者としてはこのまま継続する意味は殆どありません。ですが「大半に影響があるからこのテストは打ち止め」とテスト実施者側で勝手に判断するのは非常に危険です。なので必ず「今後どうするか」の確認を依頼者側に入れる必要があります。

例③:「問い合わせページの情報保持が出来ておらず、確認画面で入力内容が初期化されています。そのまま問い合わせ送信まで行えてしまいます。他の問い合わせページも同様です。現時点では関連項目の大半(30項目中20項目)が確認不可となり、その他の問い合わせ関連テスト(各30項目3種)も同様になり、テスト結果として信頼性が低いですがこのままテスト継続しますか?」
この様に報告する事でテスト依頼者もテスト項目の数や影響範囲から考えて、”続行/中止”の指示を出せます。殆ど場合において、この様な状態になった時は修正後の影響確認等の範囲を考えて、一旦テスト打ち止めになる事が多いですが、「最終的にやり直しになるが、確認出来る範囲だけでも先に確認して欲しい」となる事もあるので「テストを継続しますか?」の確認はとても大事です。なので勝手にテスト実施者側で打ち止め判断をしてしまうと、後々大変な事になります。


テストにおける不具合報告と言うのは、単純な報告だけでなくテスト実施者/テスト依頼者双方向へのコミュニケーションです。事務的な内容だけでなく、「相手が知りたいと思っている情報」を含める事や「今後自分がどうするべきか」の確認を相手に投げかけると言うが重要です。例として全てに影響がある場合を出しましたが、他に影響がない場合は「この関連項目のみ保留として、他の項目の確認を行います」となったりします。そうなった時にテスト依頼者側が「修正後の影響確認が全般になるので、このテストは一旦止めます」となるか「修正後の影響確認が全般になりますが、現時点での動作確認を出来る部分だけ進めてください」となるかは、その時のテスト依頼者側の判断次第となりますが。

長々と書いていますが簡単にまとめてしまうと、「1つ事柄に対して1で返すのではなく幾つか要素を追加して質問を投げかけると、後々の動きがお互いにとって分かり易いものになる」と言った話です。因みにこれは不具合報告だけでなく、通常の会話等でも同様ですね。