継続的テストプロセスの設計、構築、導入

継続的テストを実施することを決定した場合、次におこなう作業や知っておくべきことは何でしょう？

始めに、継続的テストはあなたが思っているほど初期コストはかかりません。スモールスタートからはじめ、段階的に拡張していきます。運用の最初に、有用性のあるテストを計画する必要があります。

まず、継続的テストの担当者が一般的な継続的テストの意味を理解する必要があります。
継続的テストは、その名が示すような停止せずにテストすることに焦点を当てたものではありません。継続的テストは、開発者が様々なタイミングでソースコードをコミットするソフトウェア開発ライフサイクル（SDLC）のコンテキストとして考えられています。

一般的な継続的テストの解釈は、変更セットの送信によって定義された各イベントがテストサイクルをトリガーするというものです。これらのテストが失敗した場合、変更セットは拒否され、アプリケーションは最後に受け入れられた状態に戻ります。
文字通りの意味では、このプラクティスは継続的テストというよりも、低レイテンシー、イベント駆動型、あるいは高速フィードバックテストと呼ぶ方がよいかもしれません。

このテーマのひとつのバリエーションは、必要な場合を除いて、決まったスケジュールでテストをおこなうことです。たとえば、ある開発プロジェクトでは、平日は 2 時間ごとにリポジトリをスキャンすると決めているかもしれません。つまり、更新があった場合にテストサイクルが開始します。

継続的テストの目的をさらに詳しく説明するなら、それは規模の異なるテストを定義することです。たとえば、以下の 3 種類の規模のテストを予定しているとします。

• 毎分、迅速な回帰単体テストを実行する。
• コミットするたびに、比較的高速な統合テストを実行し、例外が発生した場合はコミットを戻す。
• 毎日深夜 0 時半に、時間のかかるパフォーマンステスト、セキュリティテスト、および統合テストを実行する。

このようにテストを組み合わせることで、テストを最大限に活用できます。もちろん、その見返りは、エラーの発生時に、できるだけ発生源に近いエラーを特定することです。

段階的な取り組み

このように様々な可能性を明確にすることで、継続的テストへの段階的な取り組みが可能になります。開発プロジェクトの既存のワークフローをすり抜けてしまう、最も一般的で被害の大きいエラー カテゴリから始めるのが理想的です。

たとえば、認証の際に、ユーザーによって異なる、一貫性のない一過性のエラーが発生している場合、100 人のユーザーそれぞれに対して適切な長さのエンド・ツー・エンドテストを実行する大規模テストを設計できます。このテストを自動化して毎朝 1 時に開始すれば、午前 3 時前には結果が出るでしょう。これが 継続的テストの最初のステップとなり、チームはそこから構築していけばいいのです。

また、プログラマーをやっていると、ピアレビューにも合格した、一見、正しそうに見えるコードをチェックインしても、特別に設定されたホストでしか動作しないということがあります。
適切な単体テストを定義し、関連するプラットフォームの全範囲で繰り返し、回帰単体テストスイートが完了するまで変更セットの受け入れをブロックしましょう。これらの作業にかかる時間は数秒程度です。

最初のステップは、完璧であったり包括的であったりする必要はありません。意味があり、理解されやすく、メンテナンスが容易であることが重要です。優れた継続的テストの計画は、小規模なものから始めて、早期に成果を上げ、拡張や拡大を促すものです。

また、継続的テストの結果の有用性が低い場合、結果的にそれは無視されることになります。
継続的テストにおけるテストの失敗は、(⼀般的に、成果物の受け⼊れをブロックするために) 実際に影響を与える必要があります。継続的テストは、SDLCと別に実行されるものではなく、そのライフサイクルの中に組み込まれなければなりません。

継続的テストは、パッケージ化された製品ではないため、何らかの製品をひとつ導入すれば実施できるというものではありません。少なくとも今後数年間は、専門的な知識を持った人が、有用性のある継続的テストを導入するために、リポジトリ、テストツール、テストデータ、そしておそらく通知システムやチケット システムを結び付ける必要があります。

継続的テストの機会

継続的テストの計画では、2 つの特別な状況を考慮する必要があります。

まず、SDLC 全体で継続的テストを適用する場所を探します。
コードチェックインの近くで継続的テストを適用するのが最も一般的ですが、他のSDLCポイントも可能です。複雑な生成手順を持つ製品では、ソースのコミット時の単体テストで継続的テストを定義し、生成された製品を検証するために継続的テストの後の段階を定義することがあります。

また、完全に自動化せずに継続的テストをおこなうことも、少なくとも原理的には可能です。
段階的な管理のひとつの側面として、継続的テストの「ゲート」を完全に機械化する前に定義するのが賢明な場合もあります。
たとえば、人間が読むことができる、複雑な操作の結果を検証するという計画があるかもしれません。信頼できるテストスペシャリストが結果を確認してボタンを押して承認または拒否できるように、継続的テストの 1 つのステップをスタブ化することは問題ありません。
このようなステップはできるだけ早く自動化すべきですが、完全に自動化する前であっても、早い段階からテストをより大きなルーチンの一部にすることは価値があります。

要約すると、継続的テストの導入について前もって計画し、簡単にできることから始めます。
ただし、後から必ず計画を拡張できるようにしてください。
継続的テストの規模の違い、特に時間帯やプラットフォームの違いに敏感であってください。
最大のビジネスリスクをもたらすエラーを探し、そのリスクを管理する継続的テストをどのように構築するかを考えます。
また、継続的テスト自体は日々のメンテナンスと改良を必要とする可能性が高いことを認識してください。しかし、その日々の努力は、より強力な全体的なテスト戦略に還元されます。

作者について:

Cameron Laird は、受賞歴のあるソフトウェア開発者であり著作者です。業界のサポート団体や標準化団体に参加しており、Python Software Foundationの投票メンバーでもあります。長年テキサス湾岸に居を構え、お気に入りのアプリケーションは農業自動化向けのアプリケーションです。

（この記事は、開発元 Ranorex 社 Blog 「Design, Build, and Implement a Continuous Testing Process」2019年6月3日の翻訳記事です。）