2024.07.19
テスト自動化の導入を検討されている方々に聞きます。
テスト自動化を構築した後は、使えば使うほど手動テストの作業が置き変わり、リターン（ヒューマンコストの削減）だけが発生すると思いますか？
答えはNOです。
必ず、一定の運用コストが発生します。そして運用を考慮していない仕組みになっていると、かえって大幅なコスト増になり、テスト自動化の特徴であるコストメリットが失われることになります。
筆者はテスト自動化を10年近くやってきました。テスト自動化として、Selenium、Appium、T-DASH、Ranorex等いろいろなソリューションを用いて構築してきました。
アプリケーションエンジニアであれば、テスト自動化を構築することだけなら割と簡単にできます。
ただ、その先の運用フェーズを考えずに構築してしまうと、後で苦労します。筆者も運用フェーズになって、運用の非効率を感じてテスト自動化を作り直したことがあります。(詳しくは以下の記事で語っています。)
つまり、テスト自動化を有効活用するための要は、構築より運用にあるのです。
そこで、本連載記事ではテスト自動化の運用を成功させるためにおさえておきたいポイントを全５回に分けて解説します。
第1回である今回は、プロダクトの仕様が追加・修正されたときに発生する運用について解説していきます。
- もくじ
1．仕様追加・変更に伴うスクリプティングとは
プロダクトは常に成長します。そのたびに仕様の追加や変更が行われるでしょう。
仕様の追加が行われれば、テスト自動化のカバレッジが下がるために、新規スクリプトを考える必要があります。
仕様の変更が行われれば、変更内容によっては、これまで動いていたテスト自動化が動かなくなる可能性があります。
このようにプロダクトの仕様追加・変更に伴って、発生するのがテスト自動化のスクリプティングです。
プロジェクトの中では、どのようにスクリプトの追加・修正をするか、計画的に行う必要があります。なぜなら、テスト自動化がプロジェクトの期間中に期待の結果を出せなくなる可能性があるからです。
また、上記のようなネガティブな状況が続くことで、最終的にテスト自動化が正しく運用されなくなり、廃止になる可能性もあります。そのような状況にならないためにも、プロダクトの仕様追加・変更が行われた際は、テスト自動化のスクリプティングを計画的に行うことが重要です。
次章から、既存機能で仕様が変更された場合と、新規機能で仕様が追加された場合の、テスト自動化のスクリプティングについて解説していきます。
2．既存機能で仕様が【変更する場合】の運用
まず、アプリケーションの既存機能で仕様変更が行われる時の運用について、プロセス上の課題とその課題の解決策を解説していきます。
2-1 プロセス上の課題
一つのプロジェクトで各工程を時間軸で表した例が以下の図になります。
既存機能で仕様が変更される場合、仕様変更で動かなくなるテスト自動化の修正する必要があります。
ただ、テスト自動化を修正できるようになるのは、対象のアプリケーションがテスト環境にリリースされてからです（図の仕様変更のアプリケーション利用可能期間）。
一方で、この修正とテスト実行はこのプロジェクトのテスト期間に終わらせる必要があります（図の自動化修正、リグレッションテスト期間）。なぜなら、テスト自動化がこのプロジェクトのリグレッションテストとして役割を担っているからです。
このように、スクリプトの修正期間が限られてしまうというプロセス上の課題があります。
そのうえ、テスト期間中に、ユーザビリティの観点でさらなる仕様変更が入る可能性もあります。追加仕様変更がテスト期間中に発生すると、さらにスクリプト修正を行わないといけない課題も発生します。
