自動テストが DevOps の実現で果たす役割

テスト自動化とは、Web アプリケーションなどのソフトウェア製品を自動的にレビューして検証し、コード スタイル、機能 (ビジネス ロジック)、ユーザー エクスペリエンスに関する所定の品質基準を満たしているかどうかを確認するプラクティスです。

通常、テストのプラクティスには次の段階が含まれます。

• ユニット テスト: 関数などの個々のコードのユニットを検証して、期待どおりに動作することを確認します。
• 統合テスト: 意図しない結果が生じることなく、複数のコードが連携して動作することを確認します。
• エンドツーエンド テスト: アプリケーションがユーザーの期待に応えていることを検証します。
• 探索的テスト: 非構造化アプローチでアプリケーションの多数の領域をユーザーの観点からレビューして、機能的または視覚的な問題を明らかにします。

これらの各種のテストはよくピラミッドとして描かれます。ピラミッドを登るにつれて、各タイプのテストの数が減り、テストの作成と実行のコストが増加します。

従来、ピラミッド内のテストはすべて手動で実行されていました。これは、時間も費用もかかり、エラーが発生しやすいプロセスでしたが、自動テスト ツールが作成されてから一変します。

今日では、ほぼすべてのユニット テストが完全に自動化されており、ユニット テストの自動化はベスト プラクティスと考えられています。統合テストも大部分が自動化されており、そうでない場合は、手動のエンドツーエンド テストを優先して通常はスキップされます。現在のテスト自動化の取り組みの波は、主にテスト ピラミッドのエンドツーエンド層を自動化することに重点を置いており、統合テストの必要性は低下しています。

自動化ツールは 10 年以上前から存在していますが、多くはコーディング スキルを必要とし、不安定で脆弱なテストにつながることも少なくありません。しかもこうしたテストは、大規模なトラブルシューティングや保守に多額のコストがかかります。結局、多くのチームは独自のカスタム テスト自動化フレームワークを作成するようになり、チームに新規加入するメンバーは覚えなければならないことが多くなってしまうため、オンボーディングが困難になって時間もかかります。また、カスタム フレームワークも結局は変化するテクノロジー スタックに対応するために、独自の保守と改善が必要となります。その結果、ほとんどのエンドツーエンドのテストは手作業のプロセスでした。それもこれからは変わります。

組織が DevOps プラクティスを成熟させるにつれて、DevOps の主なメリット、つまり構築、テスト、リリースの迅速化と信頼性の向上、インシデント対応の合理化、チーム間のコラボレーションとコミュニケーションの向上を実現するには、ライフサイクル全体にわたってテストを自動化することが重要になります。リリース ビルドを QA チームに預けて数日経ってからようやく開発者がフィードバックを受け取り、特定された問題を修正することなどもはや論外です。QA チームは、自動化されたテスト ケースに合わせて DevOps サイクルでの作業を調整し、ほぼ 100% のコード カバレッジを実現する必要があります。環境は標準化し、QA ボックスでのデプロイは自動化する必要があります。テスト前タスク、クリーンアップ、テスト後タスクなどを自動化して、継続的インテグレーション サイクルに合わせる必要があります。

mabl のようなローコード ツールによって、CI/CD パイプラインのあらゆる段階で、信頼性が高く自動化されたエンドツーエンド テストを組み込むことが可能になり、開発ライフサイクルのかなり早い段階で問題を検出できるようになりました。リリースの問題の検出が早期であればあるほど、問題の修正がより速く、コストも低くなることは周知の事実です。

万能ソリューションはありませんが、チームのテスト自動化戦略を定義する際に考慮すべき重要な点をいくつか紹介します。