効果的な継続的テストを開始するための 4 つのヒント
テストは自動的（英文）かつ徹底的（英文）におこなうことが重要です。継続的テストとは、自動テストのためのアプローチであり、早期かつ頻繁にテストをおこなうことで迅速なフィードバックを得ることができます。しかし、「継続的」といっても、すべてのテストを常に実行する必要はありません。
今回は、継続的テストシステムを構築するための4つのヒントをご紹介します。
1. 自分自身を知る
継続的テスト（CT)（英文）は、基本的にすべての開発者にとって価値のあるものです。しかし、開発者が違えば、その価値も大きく変わります。今、継続的テストが話題になっているからというだけでなく、自分の状況に合った具体的なメリットを求めて継続的テストを実行しましょう。
自動車の組み込みモジュール向けに100万ステップのJavaをコンパイルするプログラマーと、フリーランスのモバイルアプリ開発者では、関心の的が異なります。また、両者のニーズは、タンパク質の構造解析を迅速におこなうためのPythonをコーディングするデータ科学者のニーズともかけ離れています。あなた自身の状況を示す指標は何でしょうか？
- プログラマーはどのくらいの頻度で更新をコミットしますか？
- 単体テストの実行にはどのくらいの時間がかかりますか？
- ビルドプロセスにはどのくらいの時間がかかりますか？
- 自動化された統合テストの実行にはどのくらいの時間がかかりますか？
- 品質保証（QA）スタッフはどのくらいの頻度でリリースをテストできますか？
- アクティブなコミッターは何人いますか？
継続的テストの取り組みを開始する前に、自身のプロセスについてのこれらすべての観点を、大まかにでも計測してください。
作成する計画は、あなたやあなたの開発チームが実施していることについて、感覚的なものではなく現実的な指標に基づいている方がよいでしょう。
2. 誰もが単体テストを実行する
単体テスト（英文）は、自動で、安価で、簡単である必要があります。実行するのに40分かかるようなテストは、単体テストではありません。特定のハードウェアでしか実行できないテストはおそらく単体テストではありません。また、「画面上の適切な場所をクリック」など、目視の確認が必要なテストも単体テストではありません。最前線で業務をおこなっている部下のデスクで、上司が代わりにパスワードを入力しなければならない状況は間違いなく単体テストのためのものではありません。
しかし、そのようなテストが価値がないというわけではありません。そのようなテストがいつか単体テストになるかもしれません。しかし、有用な継続的テスト計画を実行するための最初のアクションの1つは、すべてのテストの中から、自動で、安価で、簡単で、現在準備ができているものを特定することです。それらを単体テストとして分離します。
単体テストに失敗したコミットは警告を出すようにし、すべてのプログラマーが単体テストの実行方法を把握するようにします。この2つの要素が揃っていれば、たとえ単体テストが、最終的に構成されるすべてのテストのごく一部しかカバーしていなくても、継続的テストは成果を上げ始めるでしょう。
3. 継続的テストに適したテストを選ぶ
次に、開発者にとっては実現可能だが、継続的テストシステムにとっては実現不可能なテスト、あるいはその逆のテストを特定します。なぜこれが必要なのでしょうか。以下はその例です。
- ある重要なテストの実行には11時間かかります。これは人間にとっては非現実的であり、継続的テストによる個々のコミットの検査結果を停滞させてはなりません。しかし継続的テストであれば、そのような長時間のテストをバックグラウンドで実行し、少なくとも1日に2、3回は結果を報告できます。
- 様々な理由から、継続的テストは開発者から離れたネットワーク上にあり、特定のリソースが不足しているかもしれません。セキュリティ上の制約から、継続的テストは少なくとも数ヶ月はテスト用のデータベースにアクセスできないかもしれませんが、開発者やQAはデータベースに依存するテスト全体を30秒で実行できます。このような場合は、統合テストの実行は人間が行うというポリシーを確立してください。そしてプロキシや新しいリソースなど、最終的に継続的テストでテストが可能になるような計画を立てます。
- いくつかのテストは、どの環境でも利用できるように見えるかもしれませんが、ライセンスの制限により、事実上、機械的なスケジュールに制限されます。そのようなテストは、継続的テストを使って実行します。そのようなテストを直接実行できないことで、プログラマーは軽いフラストレーションを感じるかもしれませんが、継続的テストによる決定論的な結果のおかげで、発生したエラーを修正する方法を見つけることができるでしょう。
すべてのテストが同じカテゴリーに入るべきではありません。単体テスト、継続的テストのみで実行される統合テスト、あらゆる環境での統合テストなど、チーム全体が理解できるようにテストを管理してください。
4. あなたが望む未来を計画する
あなたのテスト計画には、まだギャップがありますか？
テストしにくいソースのエラー処理部分や、人の介入や判断を必要とするテスト、エンドユーザーだけに表示されるエラーなどはありませんか？
何事もそうですが、最初から完璧な継続的テストはできません。ギャップを文書化し、どれが最も迅速かつ効果的に修正できるかを把握します。見返りの少ないテストはゆっくりと進め、生み出す価値以上のコストがかかるテストを見極める（英文）必要があります。
何をするにしても、継続的テストの完全性を維持することが大切です。テストに合格しない限り、ソフトウェアをリリースしてはいけません。テストを、単なる観測者やアドバイザーのようなものにしないでください。ソフトウェアのマージやリリースの前に、テストに成功しなければならないことを理解する文化を育ててください。これらのことを実行すれば、継続的テストはあなたにとって有益なものとなるでしょう。
作者について：
Cameron Laird は、受賞歴のあるソフトウェア開発者であり著作者です。業界のサポート団体や標準化団体に参加しており、Python Software Foundation の投票メンバーでもあります。長年テキサス湾岸に居を構え、お気に入りのアプリケーションは農業自動化向けのアプリケーションです。
（この記事は、開発元 Ranorex 社 Blog 「4 Tips for Launching Effective Continuous Testing」2019年8月29日の翻訳記事です。）
