【第1回】自動テストはなぜ失敗するのか？

この連載では、自動テストにスポットを当て、失敗事例の解説や自動化ツールの検証、自動テストを成功させるための手法を解説していきます。

自動テストは自動化したからと言って必ずしも効率化できるわけではありません。
自動テストの理解が不十分であると効果のある自動テストの運用が続かず失敗に終わります。

では自動テストの導入を「成功」に導くにはどのようなことが必要なのでしょうか。

＜自動テストはなぜ失敗するのか連載一覧＞※クリックで開きます

【第1回】自動テストはなぜ失敗するのか？
【第2回】TestArchitect for Mobileの動作検証
 【第3回】自動テストの成功基準｜6つのポイントをチェックする

自動テスト導入前の検討
まとめ

自動テスト導入前の検討

実際の現場ではシナリオを実装した後に数回実行しただけで、「効果が得られない」「メンテナンスが追いつかない」などの問題に直面し、対策が打てず自動化を断念する現場が多く見られます。

これらの問題は導入前の検討が足りていないことが原因です。

自動テストの初心者が自動テストの経験や知識がない場合に、「取り敢えず自動化してみよう」と進めてみても、シナリオを作り切った運用段階に問題が発覚し、修正するには大きな工数がかかってしまい、自動化を断念することが多いです。

自動テストを成功させるためにはいくつもの失敗するポイントに対して事前に対策をとる必要がありますが、初見ではどこにどのようなリスクが潜んでいるかわかりません。

これらのリスクへの対応は自動テストのシナリオ作成から運用の一連の作業を成功させた経験があれば対応できます。成功経験があればどこにどのようなリスクが潜んでいるか分かるため、事前に対策を行うことができます。自動テストに失敗しないためには事前のリスクの潰しこみのための導入前の検討が重要です。導入前の検討によって1つ1つリスクを潰しこみし、自動テストを確実に成功させることができます。

自動テストの導入検討の内容は以下になります。

(1)目的と役割を決める

(2)成功基準を決める

(3)自動化するテスト内容を決める

(4)テストケースの内容を分析する

(5)評価対象のシステムを分析する

(6)自動化ツールを選定する

それぞれについて解説します。

(1) 目的と役割を決める

まず自動テストを始める際に決めることは「目的と役割を決める」です。ここが明確になっていなければ、自動テストをうまく進めることができません。

目的：テスト工数を削減し効率化
役割：デグレ確認（品質向上ではない）

自動テストは大きく効率化するものではなく、劇的に品質を上げるものでもありません。同じテストを何度も実行することでデグレ確認を効率化するものです。自動化すれば効率化できるということではありません。運用で何度も実行する自動化でなければ、実行する意味がありません。そのためには自動化する目的を明確にし、目的に合致したテストのみ自動化していくことが大事です。この目的と役割を達成することが終わりではありません。この後に何をするかが重要です。

「削減工数で追加試験を行い、総合的に品質を上げる」、「安定した品質のソフトを短期間にリリースする」などを行い、品質とスピードの両立を行うことが自動テストの本当の目的です。

やみくもに自動化することにならないよう目的と役割を明確にし方向性を持つことが必要です。

(2) 成功基準を決める

自動テストを進めるにあたり、成功の基準を導入前に決めます。

成功基準を決めずに進めてしまうことで、問題が発生しても問題と気づかず運用を続けてしまうことがあります。実施に現場で自動テストを導入した結果、ツールの選定や設計を間違えメンテナンスを行うには非効率な構造や半自動化など問題を抱えた状態で運用を進めても非効率になり続かない自動テストを行うことになります。

以下の例はシステムテストの自動テストを行う場合の成功基準になります。

導入前に基準を決めておくことでこの基準をクリアできる自動化プロセスの構築を目標にします。

30％以上の効率化/工数削減ができること
必要なテストが自動化できていること
実行途中で処理が止まらないこと
実行結果の誤判定がないこと
実行から結果確認まで自動化できること
共通関数などメンテナンス対策を行っていること
実行シナリオの維持管理（増減、変更）ができていること
実行の失敗から問題解決までの流れができていること

こういった基準を作らず成り行きで進めた自動テストの成功は困難です。成功基準を作り基準をクリアできる自動化ツールの選定や自動化システムの設計や構築を行うための指標にします。

また導入後の振り返りでこの基準をクリアできたか検討するために使用するとよいです。

(3) 自動化するテスト内容を決める

ここでは何の試験を自動化するかを検討します。何度も実施する価値があり、不具合出ると問題になる試験を自動化するべきです。以下は自動化するテスト内容の例です。

試験内容	試験詳細
基本動作	基本機能で不具合が出ては問題のため自動化することで確認する。
市場不具合	一度市場で発生した不具合は2回出すと問題のため確認する。
顧客/ユーザの要求の高い機能	安心/安全や顧客の要求の高い機能の確認を自動化し確認する。
ユーザがよく使う機能	よく使われる機能で不具合が出ると問題なので自動化し確認する。
新機能など注目の高い機能	新機能や法律に関する機能で不具合を出すと問題のため自動化する
デグレが多い機能	開発期間でデグレが多い機能は自動化し確認する。

また似たテストを自動化することが無いよう優先順位を付けて必要なテストを絞り込むとよいです。

ここで実施するテストを定義しなければ、自動化しやすいテストを自動化するという方向に進んでしまいます。

必要のないテストを自動化しないためにも自動化するテストを明確にすることは必要です。

(4) テストケースの内容を分析する

テストケースの前提条件、実施手順、期待結果が自動化シナリオを作成できる記載になっているか確認します。シナリオ作成はテストケースをプログラム化しますが、そのためには手順、設定値、期待結果が具体的になっていることが前提です。そのような記載になっていない場合はテストケースの修正を行う必要があります。

またテストケースの手順や期待結果などの記載が正しいか確認を行わなければ、シナリオ作成時のテスト実行時にエラーが発生すると「テストケースの記載ミス」「不具合」「シナリオ作成ミス」か原因追及に時間がかかります。そのためにもシナリオ作成前には1度テスト実施し、テストケースの記載に問題ないことを確認しておくべきです。

(5) 評価対象のシステムを分析する

シナリオ作成時には評価対象を理解しておくと、必要な自動化ツールや自動化するべき品質か判断ができます。

ここで確認するのは以下の2点です。

評価対象の品質状況の調査
評価対象の仕様の理解

評価対象の品質状況を調査し自動化可能なテストか判断することが必要です。不具合が発生している機能は自動化を避け、不具合のない機能を自動化するべきです。メモリリークなどの不具合が発生している場合には長時間のシナリオの実行に影響するため自動テストの実行時に注意が必要です。

そもそも不具合が多いと自動化できないので品質が安定するまで自動化をするべきではないと判断できます。

また自動化シナリオ作成には評価対象の仕様を理解することは必須です。仕様を理解しておかなければシナリオ作成の方針が立てることができません。どのような自動化ツールを選ぶべきか判断することもできません。

この際に評価対象の調査だけでなく評価に使用するツールもあれば同様に調査が必要です。

(6) 自動化ツールを選定する

これまで検討してきた内容を踏まえて自動化ツールを選定していきます。

自動化の目的、成功基準などから自動テストの方針に合わせた自動化ツールであるか確認します。

自動テストの目的や評価対象、評価内容に合致し成功基準をクリアできる自動化ツールを選定します。

選定する際の確認ポイントの例は以下になります。

テスト対象の機能の自動化ができること
自動化対象のテスト項目の「前提条件の設定」「手順の実行」「期待結果の確認」の自動化ができること
共通関数の作成ができること
エクセルやテキストファイルの操作ができること
クロスブラウザができること
Windowsコマンドの実行ができること
データ駆動型の自動化ができること

こういった検討を行わず、最初に自動化ツールを選んでしまうとその自動化ツールで自動化できる範囲しか自動化することができず、自動化するテスト内容が限定されてしまいます。

その結果、必要なテストを自動化できず、運用段階で実行する価値のない自動化をしていることに気づき、自動化断念となってしまうことがあります。

また期待結果の確認ができないなど機能が不十分な自動化ツールを選んでしまうと実行結果を手動でログを確認するなど人間の手を入れる必要が発生するなど半自動化となってしまい、非効率になり自動化しているメリットが無くなります。そういった失敗にならないよう検討するべき内容を調査したうえで自動化ツールの選定を行わなければなりません。

当社のプロダクトであるTestArchitectでは上記の確認ポイントは一通り実現可能になります。