テストするか、テストしないか
テスト部門の真の目的は、単にエラーリストを作成することではなく、変化をもたらすことです。何をテストすべきでないかを考えて明確にすることで、変化をもたらす分野でより徹底したテストをおこなうためのリソースを確保することができます。今回は、再検討するべき５つのテストについて紹介します。
過去の要件のテスト
テストの価値は、テストがときどき失敗することにあります。常に合格するテストは、ほとんど情報を提供しません。一方、皆さんの多く は、「要件が変更されたという理由だけで失敗し、その失敗によって初めて要件の変更に気づくテスト」を見たことがあるでしょう。失敗するといっても、このような理由で失敗するテストは、誰もを無気力にし、何の価値もありません。
例を挙げましょう。あるソフトウェアの要件として、初期リリース時に、画面において絶対位置に文字が表示されるフィールドがありました。最初のリリースでは、すべてのテストに合格しました。やがて、更新された画面の要素に合わせて、フィールドの表示位置が数ピクセル移動しました。テストは失敗し、新しいレイアウトに合わせて調整され、合格してリリースされます。このサイクルが続きます。
しかし、このサイクルは誰の利益にもなりません。テストは物理的な場所に合わせて書くのが正しい場合もありますが、これは絶対的なルールではありません。うまくいかないときは、リリースのたびに退屈な更新が繰り返され、真の付加価値はもたらされません。
このような場合には、次のことを検討してみましょう。
- そのテストを完全に削除します。テストを維持するのに必要な労力が、テストがもたらすメリットよりも大きい場合は、テストを削除します。
- より堅牢なテストに書き換えます。たとえば、画面上にウィジェットがあったり、表示されていたり、特定のコンテンツが含まれている場合があります。あるいは、「より堅牢に」ということには、Ranorex Studioのような、UI要素を特定するために信頼性の高い方法を用いたスマートな自動化ツールを使用することが含まれるかもしれません。
もちろん、テストがより正確に要件を追跡できるように、製品管理者がより良いコミュニケーション チャネルを見つけるまで、いつでもテストを無効にすることができます。
無駄なテストを続けることは美徳ではありません。それは、もっとやりがいのある仕事からあなたの注意を奪う一種の窃盗です。
重要度の低い単体テスト
単体テストが存在しない既存コードに対して、単体テストを作成したくなることがあります。これは良いアイデアのように思えるかもしれませんが、単体テストの作成を始める前にコードを徹底的に深く分析しておかないと、本来の目的である「新しいコードのための単体テストを開発する」という目的から大きく外れてしまいがちです。
大量の既存コードのために単体テストを開発したいと思うかもしれませんが、絶対にすべきではありません。リファクタリングの努力をせずに、重要度の低いレガシーな既存コードのために単体テストを作成しようとしないでください。
単体テストの大きな価値のひとつは、開発者が事前に実装を検討するのに役立つということです。「大量の既存コード」はすでに存在しており、その問題あるアーキテクチャは変わりません。主な価値が明確に理解されていないコードのために、単体テストを作成するふりをしてはいけません。
これは、単体テストが無意味なものだと言っているのではありません。もし自分のテストが価値のない方向に向かっていると思ったら、あきらめずに他に何を変える必要があるのかを考えましょう。真のニーズに対応する提案をまとめてください。テストを意味あるものにするために必要なことをまとめるのです。
テスト vs. インスペクション
秩序立ったコードインスペクションは、ソフトウェアに問題が発生する確率を大幅に減少させる強力な手段となります。ひとつひとつのコマンドと行を丹念に確認することで、単純な単体テストでは見逃されていた問題を発見することができます。
また、より堅牢な機能テストや統合テストにおいても、「正しい」ように見えても期待通りの動作をしない部分にフォーカスしてインスペクションをおこなうことは有用です。あるレベルの単体テストや機能テストよりも、慣用的な表現の方がインスペクションに適している場合もあります。
状況によっては、ソフトウェア インスペクションの方がテストよりも費用対効果が高い（英文）こともあります。多くの場合、インスペクションと様々なレベルのテストを組み合わせることで、テストの品質を向上させることができます。
使い捨てコードのテスト
「”使い捨てのプログラム” は作成者が期待していたよりも長く生き残ることが多い」という見方があります。プロトタイプとして開発されたコードが、アプリケーションの一部のフレームワークとなる場合があります。そのような場合、コードは元の「使い捨て」コードとはほとんど似ていないことが多いのです。
コードの一部が通常とは違う、特定の短期的な目的のために作られたものであれば、少なくとも厳密なテストは必要ないかもしれません。しかし、コードの性質を考えると、「使い捨てだからテストしなくてもいい」という考え方は危険かもしれません。コードはやはりコードであり、コード自体の不正確さによって異常な動作が発生し得るということを認めるのであれば、テストをおこなう必要があります。
簡単なレポートのようなものは、テストデータを生成するコードのような綿密な検査は必要ないかもしれません。疑わしい場合は、そのプログラムが再び必要になることを想定し、それをテストすることで、期待されていることをやっているか、やっていないかを知ることができます。
代替手段があるテスト
手動テストのコストが特に安価な場合、異常な状況（すべてを手動でテストしようとするような状況）が発生することがあります。そのような場合でも、テストの一部を費用対効果の高い代替手段に委ねることが可能な場合には委譲し、自身は価値の高いテストに注力しましょう。
まとめ
開発エンジニアはトレードオフを判断します。すべてのテストには、メリットだけでなくコストもあります。あなた（テスター）は、プログラマーが誤って床に落としたゴミを片っ端から掃除する清掃員ではありません。あなたは投資家であり、価値の高いテスト能力を応用して、自分が作成できる最高のテストのポートフォリオを構築しようとしているのです。自分の仕事を貴重な商品のように扱ってください。
作者について：
Cameron Lairdは、受賞歴のあるソフトウェア開発者であり著作者です。業界のサポート団体や標準化団体に参加しており、Python Software Foundationの投票メンバーでもあります。長年テキサス湾岸に居を構え、お気に入りのアプリケーションは農業自動化向けのアプリケーションです。
（この記事は、開発元 Ranorex 社 Blog 「To Test or Not to Test」2019年10月24日の翻訳記事です。）
