これどうやってテストした？

これは、あらゆるテスターがいつかは受ける質問です。「よくやった」という意味のコメントとして言われることもあるかもしれません。しかしたいていは、何か重大な問題がプロジェクトの終盤か運用フェーズで見つかったとか、もっと悪くすればニュースになったときに尋ねられることが多いでしょう。その場合は、「おまえはなぜこの問題に気付かなかったんだ」という意味になるわけです。

円滑な組織であれば、今後同じ問題をどのように防ぐか、どのように経験を活かし、前に進むかという方向で話し合われるでしょう。しかし、私たちの多くは、円滑な環境では働いていません。それに、おおむねうまくいっている組織であっても、機能不全に陥る瞬間はあるものです。

できごとから学ぶにも、無能といういいがかりから自分を守るにも、テスターは専門的でしっかりとした、意味のある答えと情報を提供できなければなりません。もちろん、発見されなかったバグについて尋ねられた時、少しばかり言い訳がましくなることもあるでしょう。しかし私たちは、本題を見失わず、誰にとっても学ぶことがあるような有益な議論をリードすることもできるでしょう。それには、公式であれ非公式であれ、私たち自身にとって有用で、他の人たちに対しても説明の材料になったり、教訓的なツールになるような、一定レベルの記録が必要です。

テストスクリプト

スクリプトは便利で、私たちテスターやプロジェクトチームの他のメンバーが何をテストするのが重要だと考えていたかの手がかりになります。手動のものでも自動化されたものでも、テストスクリプトがどのように作成されたかを記録していますか？

文書化されたテストスクリプトによって、スクリプトの背後にある思考パターンや意図を推察できます。すると、ソフトウェアの期待動作をどのように理解したかが、いくらかわかります。

スクリプトを基にテストを行うテスターの多くは、テストが「合格」したら、合格したことを記録するだけでいいという考えで作業しています。問題があればテストは「失敗」し、少なくとも何らかの情報が記録されます。そうであればいいと思いますが、そうではないかもしれません。

他の成果物

ソフトウェアに関わる人の多くは、テストとは何かという問題を、テスト成果物に偏って理解しています。テストに関する議論の中心は、テスト計画、テストスクリプト、テストケースの集合で占められがちです。テスターやマネージャーの多くが理解しそこねているのは、それらはどのようにテストを実施できるかを表すモデルであり、テストの成果物ではないという点です。

テストの最も重要な成果物は、テスト時の記録です。テスト計画およびテスト戦略文書は、テストがどのようであるべきかを記述します。テストケースおよびテストスクリプトは、テストする必要があるシナリオです。それらは構成やソフトウェアの動作に影響を与える可能性があるその他の外部要因について記述する場合もあります。

最も重要なのは、実際のテスト、つまりテスト実行にまつわる情報です。テストが「合格」した、またはしなかったと判定されたことは、重要な情報です。テスターがどのようにしてその判定に至ったかという情報もまた重要です。

エビデンス

経験が浅いテスト組織と仕事をするとき、私はよく、テストについて適切なメモを取ることは、テストを行ったことを法廷で宣告する証拠を提出するようなものだというたとえ話をします。

どういう意味でしょうか？考えてみてください。厳密なテストでは、行ったアクションと観察された結果を記録する必要があります。それには、テストしたあと、何週間あるいは何か月かたったとき、自分や他の人が何が行われたかを再現し、把握できるようにメモを取ることも含まれます。

私たちはみな早く作業を終わらせなければないというプレッシャーにさらされています。どんな環境でソフトウェアを開発するにしても、実際に手を動かして機能をテストするときには何らかの時間の制約があるでしょう。厳密なメモと記録を残す際の困難は、どれほど時間がかかるか――そして、どうやってメモ作りがテストを「スケジュールどおり」終わらせる妨げにならないようにするかという点にあります。

私がどのようにこの問題に対処しているか、いくつか例を挙げます。

一人でやらない

メモを取ってくれるパートナー/ペアテスターと一緒に作業し、どこへどう移動したか、どんな値を入力したか、どのオプションを選択したか、さらにデータの入力またはドロップダウンのクリックにどれくらいの時間がかかったかも記録します。

このパートナーは、あなたが見落としたことにも気づくかもしれません。ときには、あなたが別の点に注目していたために注意していなかったレスポンスや結果にも気づくでしょう。そういった点は調査する価値があることも多いものです。パートナーは相談役にもなります。シナリオを実行しながら、アイデアを交換することもできます。ある動作が異常として記録されたが、当面行っていることのほうが重要である場合、次のイテレーションで実行すべき追加のパスとしてパートナーが思い出させてくれることもあるでしょう。

重要なこととして、他の人の目も画面を見ていることが、誠実でいられ次になすべきことに集中する助けになるでしょう。反対に、他人の目があることは、ひとつの機能に没入するあまり、他の重要なことが目に入らないという、うっかりした見落としを軽減するのにも役立つかもしれません。

すべてを記録する

医療従事者のあいだでよく言われるフレーズに、「書き留めていなかったことは起こらなかったこと」というものがあります。なぜでしょうか？記憶とは不完全なものだからです。刑事事件において、「目撃証人」による証言は批判的精査を受けますが、それは人間が一般に信じられているほど正確に物事を記憶してはいないからです。

行ったこと、起こったことをそのまま、すべて書き留めておきましょう。今「言うまでもない」ことが一週間後、一月後も「言うまでもない」とはかぎりません。メモしておきましょう。ユーザーの操作や、各アクションへの応答として起こったことを記録する画面記録ツールもあります。そういったツールは、何が起きたか、どこへ移動して何を行ったかを記録します。また応答、画面表示、メッセージも記録されます。これは、テスト時に「何がおきたか」を簡単に記録する手段になります。

ほかの選択肢もあります。テスト中にメモを取るのに役立つツールもあります。1つのウィンドウでテストアプリケーションを開き、もう1つのウィンドウでメモ作成ツールを使用できます。画面キャプチャをメモにコピーできるので、メモで何を意図しているかを正確に示すことができます。

その他のエビデンス

テストが完了した時点のビルドまたはスプリントなどの単純ですが見過ごされやすい情報を記録します。データベースやスキーマのバージョンも変わることがあるので記録します。データベース環境が変わると、後にならないと発覚しない予期せぬ影響がある可能性もあります。

テスト対象のソフトウェアの種類によっては、最小限の手間で特定し、取得できるエビデンスもあります。たとえばログです。

アプリケーションログ、データベースログ、テストを実行するデバイス上のログなどのシステムログ、システムホストのログなどのホストログ。

これらにはテスト対象に関する貴重な情報が含まれている場合があります。また、見て簡単にわかるとはかぎらないことを調査できる情報が含まれていることもあります。どちらもテスターにとって価値があり、テスト関連のエビデンスになるものとして記録に入れる価値があります。

疑問

なぜこの情報を取っておく必要があるのでしょうか？何の意味があるのでしょうか？

テストからいくつか後のイテレーションまたはビルドで、あるいは運用環境で、予期しない結果が見つかったとき、ほぼ確実に、その機能がどのようにテストされたかという疑問が浮上するでしょう。

私の経験では、エビデンスや成果物を残すことの本当の目的は、かなり単純です。それは、今現在のあなたから将来のあなたへのプレゼントです。数週間後のあなたかもしれませんし、１つか２つ後のスプリント、あるいは数か月後のあなたかもしれません。もっと後かもしれません。プレゼントを役立てるのは、誰か別の人かもしれません。受け取るのが誰であれ、調べたとき、その人はあなたが手間をかけてどうテストしたかを説明しておいてくれたことに感謝するでしょう。

多くの組織では、そこまで詳細に記録する必要はないかもしれないというのは、私も理解しています。それでも、テストに問題が多かったり、テストへの信頼が低い状況では、どんなテストをしたかに関するしっかりした証拠で対抗すれば、意識を変えることも可能ですし、変わってゆくでしょう。そうなれば、「これどうやってテストした？」はまったく別の意味を持つようになるでしょう。

Peter G. Walenは、ソフトウェア開発、テスト、アジャイルプラクティスで25年以上の経験を持っています。ソフトウェアがどのように動作し、他のソフトウェアと連携するか、またソフトウェアを利用するユーザーをチームが理解できるよう支援に尽くしています。Agile Alliance、Scrum Alliance、American Society for Quality (ASQ)のメンバーであり、ソフトウェアミートアップに熱心に参加し、カンファレンスでもたびたび講演しています。

（この記事は、開発元Gurock社の Blog 「How Was This Tested?」2020年2月6日の翻訳記事です。）