はじめに
テスト自動化には自動化すべきテストと、すべきでないテストがありますが、その前に、どんなプロジェクトがテスト自動化に向いているのか知っておくことが、とても大切だと思ってます。そうしないと後になって、導入の目的がはっきりしない、プロジェクトの特性で効果が出にくいと言ったことも良くあります。本記事では、テスト自動化に比較的向いているプロジェクトを、さらっと５選して見ましたので、ご参考にして頂ければ思います。
１.金銭取引に関連したシステム開発・保守プロジェクト
金銭取引に影響が出るシステムの不具合はクリティカルとなり、頻繁にマネーパスを実施する必要があります。自動化することにより、正確にかつ、頻度を上げてテスト実行が可能となり、品質維持に効果を発揮します。
2.運用/保守が長く続くプロジェクト
長期のシステム運用において、テストにかかる工数の蓄積は、開発時のテスト工数を大きく上回ると言われます。これは、Windowsアップデートや、システム修正・システムのアップグレードなど幾度も行われ、何度もテストを実施する必要があるためです。つまり、運用/保守フェーズが続くシステムは、回帰テストの機会が多く自動化に適していると言えます。
3.市場リリースのライフサイクルを持つプロジェクト
市場に出る製品は、出荷する台数も多く、不具合によって大きな損失に繋がります。パッケージなどライフサイクルのあるソフトにおいては、リリースの都度変更していない機能においても、一般的に回帰テストを実施します。テストを自動化することにより、中長期的なコスト効果が期待出来ます。
4.大規模で、サブシステムや機能やデータが複雑に絡み合っているシステムの開発・保守プロジェクト
大規模で複雑に絡み合っているシステムは、少しの変更で、影響のない様に見えて、影響していることが良くあります。少しの変更で、都度、広く手動テストを実施するのは非効率です。テストを自動化することで少しの変更でも都度、コストを掛けずに広くテストが可能となります。
更に、大規模システムでは複数の請負会社からモジュール受け入れて統合ビルドするチームを作ってたりします。週何度もビルド～決められた手順でスモークテストを実施し、評価チームにリリースしますが、頻度が多く、時間短縮が課題となります。ビルドからテストまで一連の作業を自動化することで、展開までの時間短縮の課題を解決します。
5.アジャイル開発をしているプロジェクト
アジャイル開発において、ソフトウエアは継続的・持続的にデリバリーされます。比較的短い開発ライフサイクルにおいて品質を保つには、新しい機能に関するテストはもちろんのこと、並行して既存ソフトのデグレを防止するため、短いサイクルの都度、回帰テストを実施することが重要になります。テストを自動化することで、サイクルの都度、既存のソフトウェアが壊されていないかテストが可能となります。
おわりに
もう、お気づきだと思いますが、リグレッションテストの実施機会が多いプロジェクトほどテスト自動化に向いており、その観点のプロジェクト事例をご紹介させて頂いたとも言えます。ただ、ここにピックアップしたのは一例ですので、限定しているものではありません。少しでも、ご参考なれば幸いです。
尚、日本はグローバルと比較し、テスト自動化が遅れていると言われてますが、本５選でピックアップしたアジャイルやCI/CDの導入も少ないと言ったこともあるでしょう。ただ、国内の中にも先進的な取り組みにチャレンジし、テスト自動化で効果を出している事例も増えてきているので、日本での普及にも期待出来そうです。（下記はUiPath Test Suiteを活用した国内事例）
テスト自動化の基本や導入の価値、UiPath Test Suiteによるアプリケーションテスト自動化についてのコラムもご参考に！