ソフトウェアテストを自動化するには｜対象選定と保守の考え方

ソフトウェアテストの自動化は、テストを実行する回数が多いほど必ず得になる、という単純な話ではありません。何を確認するか、結果をどう判定するか、変更後に誰が直すかまで決めると、投資する対象を選びやすくなります。

この記事では、繰り返す価値と、維持する負担を同じ単位で見るための整理方法を紹介します。特定のツールのランキングや、全テストを自動化する手順ではありません。

自動化するのは繰り返す確認のどこか

JSTQBのシラバスは、テスト自動化の潜在的な利点として、反復する手作業の削減や再実行性の向上などを挙げています。一方で、ツールの導入、保守、訓練に必要な労力を過小評価するリスクも説明しています。JSTQB Foundation Level 6.2

そこで、候補の作業を「準備」「実行」「判定」「失敗時の調査」に分けることを勧めます。ボタン操作だけを自動化しても、毎回のデータ準備や目視判定が大きければ、削減できる時間は限られるかもしれません。

また、正解が決まっていない作業では、まず何をもって合格とするかを整理します。現在の出力をそのまま正解として保存するだけでは、意図しない動作を固定するおそれがあります。

以下は自動化候補を比べるための編集上の整理案です。各項目の点数を足せば自動的に採否が決まるというものではありません。

重要な機能でも、自動化しやすいとは限りません。逆に、簡単に自動化できるという理由だけで、利用頻度も影響も小さい確認へ時間を使いすぎないようにします。

架空の料金表示機能を考えます。数量と割引条件から決まる金額の計算と、説明文が初めての利用者に分かりやすいかという確認では、結果の判定方法が異なります。

計算式が合意されているなら、入力と期待金額を固定したテストは自動化候補になります。境界の数量、割引の有無、無効な入力を含め、仕様へ戻って期待値を決めます。

説明文の分かりやすさは、文字列が存在することの自動確認だけでは判断しきれません。誰がどの場面で読むかを決めて、人による確認も残す案が考えられます。自動化できない部分があることを理由に、機能全体の自動化を断念する必要もありません。

この例は実測結果ではなく、判定の種類を分けるためのものです。計算の仕様自体が頻繁に変わるなら、テストデータを更新する負担も見ます。

効果を見積もる際は、同じ期間における手動実施の負担と、自動化した場合の準備・運用・保守を比べます。以下は説明用の単純計算です。

仮に手動で1回20分かかる確認を月10回行うなら、実施時間は月200分です。一方、自動化の初期作成に8時間、月の保守と失敗調査に120分かかるなら、初月から時間が減るとはいえません。

この数値は仮定であり、実績や投資回収の予測ではありません。確認漏れへの影響、結果が分かるまでの時間、実行環境の費用も別に考える必要があります。単に「自動実行は数分」とだけ比べないための例です。

試行では、手動の準備時間、自動化の作成時間、実行後に人が確認する時間、変更時に直す時間を分けて記録しましょう。

自動テストが失敗したときに、製品の不具合、テストの前提違い、環境の問題を区別できるかを確認します。失敗したら合格するまで再実行する運用だけでは、結果を判断材料として使いにくくなります。

最初は一つの安定した機能を選び、開始状態、期待結果、結果の保存先、修正担当をそろえて試すとよいでしょう。対象を広げる判断は、実行数だけでなく、保守と調査を含めて継続できるかで行います。

開発工程とテストの関係はV字モデル、実装変更の確認はコードレビューの観点も参考になります。開発体制についてはSES事業をご覧ください。