DevOpsチームとQAチームが注目 CIとCDの間にある「CT」とは：システムテストや統合テストとどう違うのか

CI/CDはアプリケーションの開発とリリース、改善のサイクルを高速化する。この「開発すること」と「リリースすること」の間には「品質を保つこと」という重要な要素が隠れている。本稿は、品質を高く保つために有効な「継続的テスト」（CT）について解説する。

[Amy Reichert，TechTarget]

　TechTargetは2023年10月19日（米国時間）、「継続的テスト」（Continuous Test、以下CT）に関する記事を公開した。

DevOpsにおける継続的テストは取り組むだけの価値はあるか（提供：TechTarget）

　改めて指摘するまでもなく、アプリケーション開発においてテストは重要だ。不具合だらけのアプリケーションを使いたいと思う顧客はいない。新たな顧客を引き付け、既存の顧客を維持するには、品質が高いアプリケーションをリリースする必要がある。

　こうした厳しい要望に応える方法の一つがCTの導入だ。継続的インテグレーション（CI）と継続的デプロイメント（CD）と組み合わせることで、品質とカスタマーエクスペリエンスを所定のレベルで提供するアプリケーションを確実にリリースできるようになる。DevOpsチームが導入すれば、アプリケーションリリースの迅速化、不具合を修正するための作業のやり直しの削減、テスト実行スケジュールの容易な管理など、長期的にも短期的にもメリットが得られる。

　もしかしたら「CTの導入は面倒だ」と思う人もいるかもしれない。だが、つまるところCTの導入は、手動テストや自動テストなど、さまざまな形式のテストを組み合わせ、計画することと大差ない。確かにCTの「テストスイート」（目的に合った複数のテストケースをまとめたもの）を構築し、実行ルーティンを確立し、その結果を分析してエラーを見つける（そして修正後に改めてテストする）という一連の作業には時間がかかる。そのため、CTの場合は「テストスイートがいつ、どのくらいの頻度で実行されるか」に注目する必要がある。

DevOpsにおけるCTの仕組み

　DevOpsにおけるCTは、開発サイクルの全ての段階において、文字通り継続的にテストを実行する。他のテスト（システムテスト、統合テスト、機能テスト）に取って代わることが目的ではない。そうした他のテストは、CTのように自動化された単体テストでは検出できない不具合を確認するために引き続き必要だ。CTは他のテストと競合するのではなく、他のテスト作業の範囲を狭める働きがある。

　CTに特定のテストフェーズはない。「コードのチェックイン」「メインブランチへのマージ」「ビルドプロセスへの組み込み」などそれぞれのタイミングでアプリケーションテストを実行できる。また、CTのテストスイートには、スモークテストなど手動で行うテストを含めても問題ない。回帰テスト、パフォーマンステスト、システムテスト、統合テストについても同様だ。

　QAテストチームは開発中に、手動や自動で回帰テストスイートを継続的に実行する。それと同じように、DevOpsチームは、コードがメインのコードベースにマージ（またはチェックイン）されるたびに、CTテストスイートを自動実行させる。

　DevOpsチームとQAチームは協力して、CT用の自動単体テストと自動受け入れテストのテストスイートを作成する。もちろん、自動テストツール内で作成しても、単体テストフレームワークを使用するコード内で作成しても構わない。CTテストでは、人間が介在しなくても、エラーを報告できなければならない。可能であれば、エラーの原因となるコードコンポーネントが特定されているのが理想的だ。CTの技術レベルが高いほど、報告されたエラーが不具合かどうかを判断するのに必要な時間が短縮される。

　DevOpsとCTを連携させると、コーディングからリリースまでの流れを中断してしまうテストが不要になるため、長期的にメリットがある。また、突発的なエラーや不具合に伴う負荷が生じない限り、CI/CDが中断されることがほぼなくなる。

継続的テストはどの程度継続させる？

　開発者は、もしかしたら1日に20回コードをチェックインするかもしれない。CTは、コードがチェックインされるたびに実行するので、計20回実行することになる。

　QAテストを含むCTは毎日実施する。QAテストの担当者は、CTの実施状態とその結果を確認しつつ、それとは別のスモークテスト、回帰テストなどのテストスイートを実施できる。ユーザーのストーリーに合わせて新しいコードのテストを行った後に、CTのテストスイートを実行することも可能だ。例えば、自動化されたテストスイートは毎日実行し、複雑な手動でのテストケースは開発サイクル中に実行する、など。また、CTは開発からリリースまでのサイクルで継続的に行うため、回帰テストの時間を区切る必要はなくなる。

　CTでは、QAチームが新機能のテスト、不具合の検証、継続的なリグレッションに取り組めるようなテスト計画や戦略を作成する。自動テストスイートを維持し、エラーを容易に分析できるようにすれば、QAテスト担当者の時間を節約できる。

　DevOpsチームのテスト担当者とQAチームのテスト担当者が協力して、DevOpsのCTテストスイート内で可能な限り多くのテストを自動化し、自動テストスイートを作成する。そうすれば、テストの実行と分析を1日当たり複数回、自動的に実行できる。

DevOpsにおける継続的テストのベストプラクティス

　DevOpsチームとQAチームをサポートするため、テストの自動実行を容易にするツールを用意する必要がある。テストを解明するツールがわずかしかなければ、チームが適切にタスク（テスト）を実行できないからだ。CTの効果と効率を管理するため、チームメンバーがQAとDevOpsの計画を見直す時間を確保する必要もある。品質が急に上がることはないとしても、品質を上げるための計画を立て、実装することは可能だ。

　まず行うべきなのはDevOpsの担当者、テスト担当者、開発者間の協力的で誠実なコミュニケーションだ。DevOpsにおけるCTへの変更を計画、立案、管理するため、計画と意思決定にチームを参加させる。

　また、CTの効果を高めるには、テストと担当者の役割を結び付ける必要がある。そこで、以下の担当者を決める。

• DevOps自動テストの不具合分析担当
• 不具合の記入担当
• CTテストの開発担当
• CTテストの実行担当
• CTテストのメンテナンス担当
• 新機能のためのCTアップデート担当
• テストの管理と編成担当

　不具合はどうしても発生する。重要なのは、その不具合をリリースの前に修復することだ。言うのは簡単だが、不具合の複雑さはそれぞれ異なる。場合によっては、機能の再設計や作業の大幅なやり直しが必要なこともあるだろう。そのときは、より複雑な修正を担当する不具合対策リーダーを立て、チームの残りのメンバーが作業を継続できるようにする。最も良い策としては、DevOpsチームとQAチームが連携して、メンバーが間違った方向に引っ張られるのを防ぐことだ。

　CTのメンテナンスと更新に関する責任者も決めるべきだ。CTの保守を管理するリソースのグループを作成し、別のグループは新規テストの開発に、別のグループは不具合の管理に注力することを検討するのがいいだろう。

　QAテストの担当者は、システムテスト、統合テスト、探索的テスト、ユーザビリティテスト、受け入れテストなど、他の種類のCTも実行する必要がある。CTの取り組みからテスト担当者を外したいと思うかもしれないが、その誘惑に屈しないでほしい。CTを理解し、習得しているチームメンバーが多いほど「プロセスをサポートし、高い品質でリリースする」というチームの目標を簡単に達成できるからだ。

　テストの管理と実行の追跡にツールは不可欠だ。各テストスイートに適切なツールを把握する必要がある。テストのメンテナンスが行われ、更新されていることはテストのステータスで確認する。テストの実行ステータスにより、問題のあるコードを特定することもできる。以下に、検討対象になりそうなツールを幾つか紹介する。

• BrowserStack
• QuerySurge
• Datadog
• Jenkins
• Docker
• Tricentis Tosca
• Testim