Close

自動ソフトウェア テスト

自動ソフトウェア テストと手動でのソフトウェア テストの違いを理解し、チームの自動テスト ソリューションの計画方法を学びます。

Max Rehkopf の顔写真
Max Rehkopf

寄稿ライター


What is automated testing?


自動テストとは何か

自動テストは、ソフトウェア ツールを適用して、ソフトウェア製品に対して人間が手動で行うレビューおよび評価のプロセスを自動化するものです。最新のアジャイルおよび DevOps ソフトウェア プロジェクトには、初めから自動テストが含まれています。とはいえ、自動テストの真価を認めれば、それが広く普及するまでどうだったかを理解することができます。

手動でのテストが標準だったときには、ソフトウェア会社がフルタイムの QA チームを抱えていることが一般的でした。このチームは、ソフトウェア プロジェクトの機能が想定どおり動作することを示す一連の「テスト計画」や段階的なチェックリストを開発していました。次に QA チームは、ソフトウェア プロジェクトが新たにアップデートされたり、変更が加えられたりするたびにこのようなチェックリストを手動で実行し、その後、課題に対処するためのレビューおよびその他の開発のため、テスト計画の結果をエンジニアリング チームに戻します。

このプロセスには時間もコストもかかり、エラーも発生しやすいものでした。自動テストによって、品質保証チームのチーム効率と ROI が大きく向上しました。

自動テストによって、オーナーシップの責任がエンジニアリング チームの手に渡ります。テスト計画は、通常のロードマップ機能とともに開発され、ソフトウェアの継続的インテグレーション ツールによって自動的に実行されます。自動テストによって、QA チームの無駄のない規模への調整が促され、QA チームはさらに気密性の高い機能に集中できるようになります。

ソリューションを見る

Open DevOps によるソフトウェアの構築と運用

関連資料

DevOps の自動テスト

自動テストのグラフィカルな図

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

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

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

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

自動テスト、継続的なインテグレーションと継続的なデリバリーの関係を説明した図。

最初に自動化すべきソフトウェア テストは何か


エンドツーエンドテスト

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

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

ユニットテスト

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

統合テスト

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

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

性能テスト

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

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

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


It is arguable that any tests that can be automated should be automated. It is a huge gain in productivity and human time cost. With that said, there are times when the ROI of developing an automated test suite is not worth it when compared to executing a manual test.

探索的テスト

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

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

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

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

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

リリースの頻度

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

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

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

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

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

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

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


Automated testing is a standard modern software development practice. The best teams and companies use automated tests. CI/CD is dependant on automated tests and critical to helping the best teams ship reliable and robust software to their customers. Start exploring CI/CD solutions today

Max Rehkopf
Max Rehkopf

自称「無秩序なタイプ」である私の毎日に秩序をもたらしてくれるのが、アジャイルの実践とリーン方式です。ここから学んだことを、アトラシアンの数々の記事や講演、動画を通して他の人と共有することが、私の喜びです。


この記事を共有する

おすすめコンテンツ

次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。

DevOps のイラスト

DevOps コミュニティ

DevOps のイラスト

ブログを読む

マップのイラスト

無料で始める

DevOps ニュースレター購読

Thank you for signing up