【第3回】自動テストの成功基準｜6つのポイントをチェックする

私が考えた長期間で自動テストの運用が成功する基準は以下の6つになります。

1. 手動に比べ30%以上の効率化/工数削減ができること
2. 自動化が必要なテストが選別できていること
3. 実行途中で処理が止まらないこと
4. 実行結果の誤判定がないこと
5. 実行から結果確認まで自動で実行出来ること
6. メンテナンスの効率化の対策が入っていること

項目ごとに解説していきます。

1. 手動に比べ30％以上の効率化/工数削減ができること

効率化することが重要な目的であるため効率化の度合いは重要な基準になると考えています。30%以上と基準を置いたのはスクリプト作成工数を含めて、5回程度実行することで実装コストの元をとれることを想定しています。

実際にあった現場では１回あたり10％の効率化で自動化成功と考えていました。基準値を考えず成行きで自動化した結果、現状の数値で満足してしまっているパターンでした。1回あたり10％の効率化では10回程度実行しなければ、手動に比べて自動化が有効と判断できません。これでは十分自動化導入の効果が得られているとは思えず自動テストを導入する価値がありません。

30％を超えない場合、問題があると考えるべきです。この場合、使用している自動化ツールの機能が不十分で自動化できる範囲が狭いなどが考えらえます。そのため別の自動化ツールを検討する必要があります。

2. 自動化が必要なテストが選別できていること

自動テスト運用が断念する大きな要因は必要性の感じないテストを自動化することによる効果が薄く感じることにあります。運用フェーズで実行する価値のあるテストが自動化できていなければ、実行する必要性や効果が見られず実行すること自体が非効率となります。そのため必要なテストが自動化できていることは重要です。

簡単に自動化できるテストを抜粋し、自動化できる件数が多くすると考えていたプロジェクトがありました。結果的に仕様変更などでスクリプト修正が発生した際にコストをかけてまで実行する必要性がなく数回の実行で運用断念となりました。

何度も実行する価値のあるテストは何かを考えて、必要なテストを自動化することが自動テスト成功には重要な要素です。

3. 実行途中で処理が止まらないこと

途中でスクリプトの実行が止まってしまう場合、実行をやり直す必要が出てきます。夜間に実行する場合、途中で止まってしまうと再実行は次の日となり時間ロスが大きくなります。

時間ロスをなくすためには実行エラーを無くし、実行する件数が多くても最後のシナリオまで実行が止まらないようにする必要があります。そのためには実行エラーを無くすことだけでなく実行エラーが発生しても次以降のスクリプトが正常に動くような対策があることなどとるべき対策があります。

1件1件のスクリプトが正しく動いても100件、500件とまとめた件数を一度に実行することで実行エラーが発生する場合もあるためスクリプト実装時のテストはまとまった数の実行確認を行い、問題が発生しないか確認する必要があります。

4. 実行結果の誤判定がないこと

自動化することで効率化を行う場合は、再試験を行わないように実行結果の誤判定があってはなりません。誤判定が1件でもあれば自動テストの試験結果の妥当性が危うくなり、品質の低い自動テストと見られればテストとして存在意義がなくなります。

結果の誤判定は効率的にテストを進めるためには実装段階で解決しておく問題です。ツールによっては必要な結果確認ができないものもあります。そのようなツールは自動テストの考慮から外しておくべきです。

100回実行しても100回正しく実行するようなスクリプトにする必要があります。運用段階でこの問題が発覚するとやり直しが発生するためテスト実施の進捗に影響するため、実装段階の確認で問題を曖昧にせず必ず潰しこんでおかなければなりません。

5. 実行から結果確認まで自動で実行出来ること

実行から結果確認まで自動化することでテスト全体を効率化する必要があると考えています。そうすることで担当者の作業は実行前の準備と実行、結果の確認だけになり作業の効率化が実現できます。

結果確認を自動化せず、1件1件ログを見て結果確認するようなことは避けなければなりません。100件程度なら人間で対応可能ですが1000件、2000件となると人間で対応していると非常に大きな工数になります。工数がかかるという以前に作業が回せなくなります。

そういった状況に陥らないためにすべてのスクリプトの実行結果に確認処理を入れ、テストケースへ結果入力まで自動で行う仕組みを入れておく必要があります。結果確認の処理は自動化するうえで必須の処理です。必要な結果確認ができない自動化ツールはツールの選定で初めから候補を外しておく必要があります。

6. メンテナンスの効率化の対策が入っていること

仕様変更は必ず入ると想定し対策を入れ効率化を行う必要があります。処理の共通化がその対策になります。処理の共通化を行うことでスクリプト作成の効率化が行えるだけではなく仕様変更や処理追加など変更時の修正工数が大きく削減することができます。また初期処理での条件設定、変数定義なども共通化しておくとよいです。

処理の共通化は自動テストの基本です。

以上の成功基準の基準を作りその基準に沿って自動テストを実装することが必要です。しかし実装だけでは長期の運用に耐えうる自動テストができるわけではありません。実装後の振り返り、もしくは定期的な運用の改善などのタイミングで基準をもとに現状を確認することで問題の有り無しの区別ができます。

振り返り時の成功基準の活用

成功基準を使った導入後の振り返りの例を説明します。

過去に私が経験したプロジェクトで振り返り時にこの基準を使った時の考察結果です。

成功基準と照らし合わせて考察してみた上記の場合、「実行途中で処理が止まらないこと」「実行結果の誤判定がないこと」の2点に問題があることがわかりました。要因を分析すると複雑な自動化システムの構造による設定ミスによる実行エラーが原因であることがわかりましたので、取るべき対策は設定ミスを減らすための「自動化環境の構造や設定項目の簡素化」が必要になります。実行担当者でのミスを減らすことで運用が改善できるため対策をとるべきであるということがわかりました。

上記のように成功基準があることで問題が具体的になり、目的に対してやるべきことが明確になりました。実装の際の基準だけでなく振り返りの際の基準としても使うことで、自動テストを成功に近づけることができます。

定期的に成功基準に基づいた振り返りを行い、目的に見合った自動テストになっているか運用で問題が発生していないかを確認すると良いです。

まとめ

目的を細分化した成功基準を作り、その基準をクリアできる自動テストの実装をすることが成功に必要なものです。成功基準があれば導入時のとるべき対策が明確になり、振り返り時に問題点が明確になります。自動テスト成功には必須なものといえるでしょう。

自動テストの実装はできたが運用が続かない場合、自動テストの成功基準をもとに自動テストの導入を行ってみてはいかがでしょうか。

連載一覧

【第1回】自動テストはなぜ失敗するのか？
【第2回】TestArchitect for Mobileの動作検証