自動ソフトウェア テスト

テストの自動化が継続的なデリバリーに重要な理由

継続的なデリバリー (CD) は、新しいコードのリリースをできる限り迅速に顧客に提供することだけを目的としています。その目標には、自動テストが極めて重要です。デリバリー プロセスに時間のかかる手動のステップがある場合、ユーザーへのデリバリーを自動化する方法はありません。

CD はさらに大きなデプロイ パイプラインの一部です。CD は継続的インテグレーション (CI) の後継であり、これに依存しています。CI は新しいコード変更に対する自動テストを実行し、その変更が構築された機能の中断や、新たなバグの発生の原因にならないことを検証する責任があります。CD は、継続的インテグレーションのステップが自動テスト計画に渡されるとトリガーされます。

自動テスト、CI、CD の間のこの関係によって、高ベロシティのソフトウェア チームにさまざまなメリットがもたらされます。自動テストは、新たなコミットによってバグが発生しないことを確認し、開発のすべての段階で品質を保証するため、ソフトウェアは常にデプロイ可能な状態になります。

1. エンドツーエンド テスト

実装すべき最も価値のあるテストは、エンド ツー エンド (E2E) テストであることにほぼ間違いないでしょう。E2E テストは、ソフトウェア製品のフル スタック全体でユーザー レベルのエクスペリエンスをシミュレーションします。E2E テスト計画は通常、「ユーザーがログインできる」、「ユーザーが入金できる」、「ユーザーがメールの設定を変更できる」といったユーザー レベルのストーリーをカバーしています。このようなテストの実装は、新しいコミットがプッシュされた場合でも、実際のユーザーがバグに遭遇せず、円滑に使用できることを保証するため、非常に高い価値があります。

E2E テスト ツールはユーザーのアクションをキャプチャして再生するため、E2E テスト計画が主要なユーザー エクスペリエンスのフローの記録になります。ソフトウェア製品でどのテスト範囲も自動化されていない場合、最も重要なビジネス フローに E2E テストを導入することによって最大の価値が得られます。E2E テストは、ユーザーのフロー シーケンスをキャプチャして記録することによって高額になることがあります。このソフトウェア製品が毎日の迅速なリリースを行っていない場合、人間のチームが E2E テスト計画から手動で実行した方が経済的な場合もあります。

2. ユニット テスト

その名前が示すとおり、ユニット テストは個々のコードのユニットをカバーしています。コードのユニットは、関数定義で最も正しく評価されます。ユニット テストは個々の関数をカバーし、関数に想定した入力が想定した結果と一致するかのアサーションを行います。機密性の高い計算 (財務、医療、航空宇宙に関連するもの) は、ユニット テストが最も適しています。ユニット テストはそれほど高額ではなく、実装も簡単なため、高い投資収益率を実現します。

3. 統合テスト

コードのユニットがサードパーティ サービスへの外部呼出しを行うことがあります。テスト対象のプライマリ コードベースは、このサードパーティ ユーティリティへのコードにはアクセスできません。インテグレーション テストでは、このようなサードパーティの依存関係を模して、コードのサードパーティとのインターフェイスが想定どおり動作していることを示します。

インテグレーション テストは、その記述方法とツールがユニット テストに類似しています。インテグレーション テストは E2E の廉価版として使用できますが、ユニット テストと E2E の組み合わせがすでに実施されている場合には、その投資回収率に議論の余地があります。

4. 性能テスト

ソフトウェア開発のコンテキストで使用される「パフォーマンス」とは、ソフトウェア プロジェクトが応答する速度と責任のことを示しています。パフォーマンス指標の例としては、「ページ読み込み時間」、「初回レンダリング時間」、「検索結果の応答時間」などがあります。これらの例では、パフォーマンス テストによって、さまざまな指標とアサーションが作成されます。自動パフォーマンス テストは、この指標に基づいてテスト ケースを実行し、リグレッションや速度の低下があればチームに警告します。

手動で行うべきソフトウェア テストは何か

自動化できるテストをすべて自動化することには議論の余地があります。生産性と人的な時間コストの面で、非常に大きなメリットがあります。とはいうものの、手動テストの実行と比較した場合に、自動テスト スイートの開発による ROI がそれほど割に合わないことがあります。

1. 探索的テスト

自動テストはスクリプト化されており、一連のステップを実行して動作を評価します。探索的テストの実施はさらにランダムにスクリプト化されていないシーケンスを試し、バグや予期しない動作を見つけます。ソフトウェアの探索的テスト実施スイートを構築するためのソフトウェア ツールはありますが、まだ完全なものではなく、広く採用されてもいません。手動 QA テスターを任命し、人の創造性を活用してソフトウェア製品を壊す方法を探る方がはるかに効率的な場合があります。

2. ビジュアル リグレッション テスト

ビジュアル リグレッションは、視覚的なデザインの欠陥がソフトウェア UI にあるときに生じます。これは UI 要素の配置ミス、フォントの誤り、色の誤りなどの可能性があります。探索的テストの実施とともに、自動テストを記述し、このようなリグレッションを把握できるツールがあります。このようなツールは、ソフトウェア製品のさまざまな状態のスクリーンショットをキャプチャし、OCR を使用してそれを想定される結果と比較します。これらのテストは開発に費用がかかり、ツールはそれほど普及していません。人が実際に見て、視覚的な課題が生じているかどうかを確認する方がはるかに効果的です。

3. DevOps チームのためのテスト自動化フレームワークの構築

自動テストのための包括的なソリューションはありません。チーム向けの自動テスト ソリューションを計画する場合は、いくつかの重要な考慮事項があります。

4. リリースの頻度

月次や週次など、一定の間隔でリリースされるソフトウェア製品は、手動テストの方が適している場合があります。CI と CD は自動テストに依存しているため、このようにリリースが迅速なソフトウェア製品は、自動テストの方がメリットがあります。

5. 利用可能なツールとエコシステム

各プログラミング言語には、ツールとユーティリティで補完されている独自のエコシステムがあります。自動テスト パターンの各タイプにある独自のツール セットは、特定のプログラミング言語エコシステムで使用できる場合と使用できない場合があります。自動テスト パターンを正常に実装するには、言語とツール サポートが共通している必要があります。

6. 製品市場への適合とコード ベースの成熟度

チームが、ターゲットオーディエンスやビジネス モデルにまだ実証されていない新しい製品の構築に取り組んでいる場合、自動テストに投資しても意味がありません。自動テストは、予期しないコード リグレッションの制限を保証するためのメカニズムとして機能します。チームが迅速に活動している場合、コードが急速に大きく変化している中で自動テストをアップデートし、維持するには大きなコストがかかることがあります。

自動テストを CD パイプラインの一部にする

自動テストは、現在の標準のソフトウェア開発方法になっています。優れたチームや企業は自動テストを使用しています。CI/CD は自動テストに依存しており、最高のチームが信頼できる堅牢なソフトウェアを顧客にリリースするために不可欠なものになっています。

アトラシアンの Open DevOps は、お気に入りのツールを使用して CD ベースの開発パイプラインを構築できるオープン ツールチェーン プラットフォームを提供します。アトラシアンやサードパーティのツールがどのようにワークフローのテストを DevOps テスト チュートリアルに統合するのかをご確認ください。