この記事はPeter G Walenによるゲスト投稿です。
テスターが何をするかについては、さまざまな専門家がいろいろなことを言っています。専門家たちが「テストとか何か」について挙げると膨大な数の項目ができあがります。たとえば、テスト計画やテストケースを作成すること、バグを見つけること、要件に従っているかを検証すること、ストーリーを語ること、価値を付加すること。
実のところ、これは何を意味しているのでしょうか？こういったものを読んで、「何かが間違っているのでは？」と思ったことはありませんか？私たちは顧客のために、私たち自身のために、ほかの誰かのために価値を付加しているのでしょうか、それともやれと言われたからやっているのでしょうか？私たちはもっと良い仕事をして―どんな環境にいても―品質を改善し、顧客のために価値を付加できないでしょうか。私たちは最初からバグを防げるように開発者や設計者を積極的に支援できないでしょうか？
テストに対する一般的な見方では―それが「現実」の、あるいは「正しい」見方だと考える人たちもいます―テストとは、動作を検証することです。テストは期待値に基づいて「成功」または「失敗」し、期待を確認することがテストの意味です。
このようなテストの捉え方に合わせて「品質」という概念を導入しようとすると、新たな問題が生まれます。「品質」とは何かという問題は、「鶴の一声」と結びつけられることが多いようです。ある人たちにとっては、「鶴」とは半ば伝説と化した故ジェリー・ワインバーグです。ワインバーグはこう言っていますー「品質とは、誰かにとっての価値である」。別の人たちにとってはジョゼフ・ジュランが「鶴」です。ジュランは、品質とは「使用への適合性」であると言っています。
どのようにすれば、開発中のソフトウェアについて知ることができるでしょうか？計測を可能にする接点を与えてくれるものは何でしょうか？
ソフトウェアテストのコースを受けたり、本を読んだり、「テストの方法」や「良いテスト」とは何かに関する動画を見たりすれば、さまざまな意見や相反する見方があるのがわかるでしょう。オンラインまたは紙で本や記事を読んだり、Redditなどで競合する考えや見方を探すことができます。
ソフトウェアテストに関する現在の見方と15～20年ほど前に一般的だった見方を比べてみると、核になるものはそれほど変わってはいないことがわかるでしょう。中には微妙に異なる主張もありますが、本質的には変わっていません。
それにはいろいろな理由があります。しかし核心のところは非常にあいまいです。このようなあいまいさは、そもそも「テスト」という言葉が何を意味しているかなど、さまざまな要因から発生します。では、なぜ私たちはテストするのでしょうか？
バグと品質
私はこれまで多くの開発者やマネージャーに「なぜテストをするのか？」という質問をしてきました。
よくある、ほとんど反射的な答えは「バグを見つけるため」あるいは「品質を改善するため」などです。これらの答えはもっともに聞こえますが、もう少し深く検討してみましょう。
一生懸命探せば、どんなソフトウェアにもバグは見つかります。これは、有償で利用される運用中のソフトウェアや、日々ダウンロードされ、何百万というユーザーが利用でき、現に利用されているフリーソフトウェアも例外ではありません。
このソフトウェアはテストされたでしょうか？場合によりけりです。ソフトウェアをリリースする企業が設定した何らかの基準に従ってテストされている場合もあるでしょう。そうでなければ、多少のテストは行われているでしょうが、それほど厳密にではないでしょう。GoogleのアプリやFacebookに問題がある場合、修正は数時間以内というスピードで公開されることもあります―そしてこれらのソフトウェアは基本的に無償で利用されるため、それほどテストされていません。おそらく、ビルドが完了したときに自動化されたスモークテストが行われる程度でしょう。
その他の、ビジネスや業務で利用するために、ユーザーがときに巨額の利用料を払っているような場合には、もっとテストが行われているかもしれません。医療機器、航空機、自動車など、文字通り「生死にかかわる」用途に関係するソフトウェアは、さらに徹底的にテストされます。個人情報や個人の記録を扱うソフトウェアも同様です。
それでも、あらゆるソフトウェアにはバグがあります。これは既定の事実です。
「なぜテストするのか？」という疑問に「バグを見つけるため」と答えるのは適切ではありません。それも1つの事実ではありますが、最大の理由ではありません。
品質を改善するため？それもよくある答えの1つです。しかし、テストしただけでは品質が改善することはありません。発見が誰かに伝えられ、対処されなければなりません。結果が伝達され、結果に基づいて誰かが行動を起こす必要があります。私たちは多数のバグを発見し、レポートするかもしれませんが、バグが修正されてはじめて、テストが役に立っていると言えます。
私たちは品質を改善したでしょうか？あるいは、ソフトウェアは最低限の期待を満たしているでしょうか？
それでも、「品質」という概念は、私たちの活動にとって重要です。テストは、それ自体では「品質を改善」できませんが、品質を測定し、ソフトウェアの動作とどれほど期待に近づいているかを利害関係者に知らせることはできます。
要件への忠実さ
要件というのは面白いものです。わたしが経験する中でも最大の問題は、みなが要件を不変のものとして扱うことが多いという点です。唯一の真実のお告げであり、決して疑問を抱いてはならないかのようです。要件が主にバズワードと略語から成り立っている場合、たいていは一定のあいまいさがあります。このあいまいさが、誤った理解と誤った解釈の余地を残します。
こうなる原因の多くは、要件を明確にする質問を尋ねそこなっていることです。「ここはどういう意味だかわかりません。何を意図していますか？」と尋ねないかぎり、設計され、実装されたソフトウェアがニーズや期待を満たす確率はかなり低いでしょう。
「要件への忠実さ」を考慮するなら、誰もが同じように要件の意味を理解する必要があります。そのため、一部の環境では、システムがどのようにふるまうかについて細かい面で厳密な議論を行い、変更がどのような影響を与えるか、また期待されるふるまいはどのようなものであるかを理解します。
このようなレベルの理解がなければ、ソフトウェアが完成するまで、「要件」が満たされている確証を得ることはできません。完成時では、デリバリーを計画通りに要件とのずれを修正するには遅すぎることが多々あります。
テストが「バグを見つける」ことでも「品質を改善する」ことでも、「要件への忠実さ」をチェックするものでもないなら、なぜテストを行うのでしょうか？
根本的な目的
ひょっとすると、答えは皆が見逃しがちなところに潜んでいるかもしれません。複雑な疑問や問題には、単純なひとつの答えなどないものです。この場合、ソフトウェアをテストする理由はさまざまで、複合的な場合もあります。
「サニティチェック」のためにテストする場合があるかもしれません。展示会やカンファレンスでのデモ用のパスを探すためにテストするかもしれません。標準的機能またはコア機能が期待どおり動作し続けていることを確認するためにテストするかもしれません。
これらはすべて異なる筋道であり、特定の状況でソフトウェアがどのようにふるまうかを考えるためのモデルです。これらのモデルは共通の目的に寄与します。どのモデルも、ソフトウェアについて情報を提供してくれます。
何らかのモデルをテストしていて、予期しない、あるいは誤った動作が見つかったなら、テストは何かを教えてくれています。期待や要件を満たすソフトウェアのある局面を発見した場合、何かを教えてくれます。予期しない状況でソフトウェアがどのようにふるまうかを確認した場合、それも何かを教えてくれます。
これは、おそらく「なぜソフトウェアをテストするのか？」という質問への答えになるでしょう。
私たちがソフトウェアをテストするのは、そのふるまいを意識するためです。ソフトウェアのふるまいを意識したなら、ソフトウェアの脆弱性を知り、良くも悪くも、ソフトウェアがどのような予期しない動作をするかを知ることができます。
ソフトウェアのふるまいを意識し、理解すれば、利害関係者やリーダーに正確で意味のある情報を提供できます。
これこそが私たちがソフトウェアをテストする理由です。そして情報を明らかにし、利用できるようにするのがテスターです。
Peter G. Walenは、ソフトウェア開発、テスト、アジャイルプラクティスで25年以上の経験を持っています。ソフトウェアがどのように動作し、他のソフトウェアと連携するか、またソフトウェアを利用するユーザーをチームが理解できるよう支援に尽くしています。Agile Alliance、Scrum Alliance、American Society for Quality (ASQ)のメンバーであり、ソフトウェアミートアップに熱心に参加し、カンファレンスでもたびたび講演しています。
（この記事は、開発元Gurock社の Blog 「Why Do We Test? What Do Testers Really Do?」2019年12月23日の翻訳記事です。）