テスト自動化とは
ビジネスや事業において、スピードアップと継続性の両立が重要です。両立を実現する1つの手段がテスト自動化です。テスト自動化とは、ロボットやツールを使ってテスト実施して、実際の結果と期待される結果を比較するソフトウェアテスト手法です。テスト自動化は、反復テストや、手動で実行するのが難しいテストやタスクを自動化するために使用されます。
テスト自動化の時代がやってくる
-
01
これからの時代企業や組織は
ビジネスの世界、特にネット業界では1番手になることが競争優位の源泉となります。この業界で生き残るためには、いち早く新しい何かにチャレンジするしかなく、事業にはスピード感をもって取り組む必要があります。
高い競争力を持つ必要がある -
02
競争力確保のためには、スピードと
他社よりも先に世の中にリリースできるスピード感と、サービスを持続できるだけの品質の担保が必要です。
継続性を満たす必要がある -
03
解決する手段の1つが
テスト自動化によって、リリースのスピードアップが期待でき、サービスの一定品質の確保が実現できます。
「テスト自動化」
テスト自動化は何ができるか
「テスト実行」を自動化
テストのプロセスには、「テスト計画」から「テスト完了」までいくつかあります。テスト自動化は、テストを人の手にかわってロボットやソフトウェアでテストを実施する自動テスト実行を指し、テストにおけるプロセスの「テスト実行」に該当します。
デグレード、リグレッションテストの問題は苦痛、だから自動化が必要
-
テストの準備に多くのフォームを操作し、数十分かかるのも珍しくない。
テスト準備し、実行すると見たこともないシステムエラーが表示される。バグレポートを作成し、バグ管理システムに報告。
終日テストし、ほかにもいくつかバグを検出し、テスターとしての職務を全うする。 -
開発者がバグを改修し新しいバージョンがリリースされる。
初日と同じ操作で数十分かけてテストし、バグが改修されていることを確認し品質向上に貢献する。 -
開発者がバグを改修し新しいバージョンがリリースされる。
初日の問題が再現しないか、初日と同じ操作で数十分かけてテストし、バグが再現しないことを確認する。 -
絶え間なく新しいバージョンがリリースされる。
バグの再現が起きないことを、すべてのバージョンで確認を続けていた。
同じ作業の繰り返しで疲弊、退屈に感じ、また作業の正確性も徐々に低下している。 -
ユーザーから初日に検出したバグと同じ報告が挙がってくる。
リリースまでにデグレートが発生していたが、作業の正確性が低下したことにより見逃しが起きていた。
人は毎日おなじスピード、正確さなどのパフォーマンスを発揮できない。これは機械が行うこと。
同じステップを最初に実施した時と同じ速度、正確さで繰り返すには自動化が必要。
あらためてテスト自動化は
何ができるか
-
技術の進歩で様々な自動化が可能に
技術の進歩により、テスト自動化における安定性の向上と自動化できる対象が増えています。Selenium（セレニウム）を例とすると、ひと昔まえは自動テストのためのJavaScriptを挿入して、自動テストを実行をしていました。いまではWeb Driverを使ってブラウザを直接操作する関数を呼出し実行できるようになり安定性が向上しました。昨今では、AIを使ってUI要素の変更などによって生じたエラーを自己修復することも可能になっています。 -
何千、何万のテストケースを実行
テスト実行の現場では数千、数万ケースのテストを実施することも珍しくありません。これだけの量のテストを人手で実施するのは多くのリソースも必要となり大変です。テスト自動化による省力化や精度の向上が有効です。
ではいつ自動化すればいいのか？
人は毎日おなじスピード、正確さなどのパフォーマンスを発揮できない。これは機械が行うこと。
同じステップを最初に実施した時と同じ速度、正確さで繰り返すには自動化が必要。
自動化に向いているテスト・向いていないテスト
テスト自動化を導入するには自動化戦略を立てる必要があることは説明しましたが、ここではまず戦略の一部として何を自動化するか、また、何を自動化しない方がいいのかについて例をあげます。
-
-
-
基本機能の正常系テスト
新しいアプリケーションのリリースの度に疎通テストとして実施することにより、テスト実施してよいビルドかどうかの判断に使用できる。
〇
またこの自動テストをビルドごとに実施する開発プロセスに組み込むことで、テストの手間を減らし早い段階でのバグ検出が期待できる。 -
障害復旧などのフェールオーバーテスト
意図的な失敗を発生させ、アプリケーションが期待通りに動作をするかを確認するテストだが、意図的な失敗を発生させるのに、人の介入やその他のツールの操作が必要になる場合が多い。
×
このようなテストについては、自動化するコストも増える割に発生頻度も限られることから、自動化はあまり推奨されない（リスクベースドテストの考え方で判断は必要） -
E2Eのテスト
運用フローにそった一連の流れをテストすることで、アプリケーション全体が期待通りに動作しているかを判断できる。
〇
このテストは小さな機能単位でテストするというよりは、ユーザーに公開する前に実施し、リリースして問題ないか判断できる。 -
探索的テスト、アドホックテスト
テスト実施者が考えながら実施するテストで、アプリケーション自体に関係のないテストになることもある。
×
図（主題）と地（背景）の関係。 -
単機能テスト
テストパターンの網羅を確認するテストで、入力バリエーションの確認でファイルなどの種類のチェックで使用する。
〇
これはその機能に仕様変更がある場合にリグレッションテストとして利用できる。 -
一度しか実行しないテスト
テストを実施するのに、大規模な前準備が必要となり、１度テストを実行するとまた前準備をやり直す必要があるテストで、例えばデータが１件もない状態でユーザーが削除することができないデータのテストなどがそれにあたる。
×
テストするために毎回表面だけでなく、裏側の関連データも削除する必要があり、一番最初のユーザーのみが利用する初回しかありえない状況のテストである場合のテストは手動で確認したほうが効率が良い -
UIベースのテスト
ユーザーができる操作、ユーザーインタフェースを使ったテストを実行する。入力文字制限や画面遷移などのテストで、期待通りにページが表示されるかの確認で利用できる。
〇
-
テストサイクルの長いテスト・アプリケーション
テストサイクルの長いテスト・アプリケーション
×
１年に１度しかアップデートがなく、テスト実行頻度が少なすぎるものについては、手動テストで実施したほうがよ効率が良いことがある。 -
単純だが手動で実行するのが面倒な作業
テストデータの準備など、手動で実施するのが面倒な繰り返し作業を自動化することで作業の効率化を期待できる。
〇 -
手動でできないテスト
手動でできないテストについてはツールを使ってテストする必要がある
〇
何百、何千とあるデータを期待結果どおりか比較する
画像データをピクセル単位に比較する異なるブラウザや異なる端末やOSで、アプリケーションを並列してテストする大量の人数（１万人など）の負荷をかけてアプリケーションをテストする
-
-
基本機能の正常系テスト
新しいアプリケーションのリリースの度に疎通テストとして実施することにより、テスト実施してよいビルドかどうかの判断に使用できる。
〇
またこの自動テストをビルドごとに実施する開発プロセスに組み込むことで、テストの手間を減らし早い段階でバグを見つけることが期待できる. -
E2Eのテスト
運用フローにそった一連の流れをテストすることで、アプリケーション全体が期待通りに動作しているかを判断できる。
〇
このテストは小さな機能単位でテストするというよりは、ユーザーに公開する前に実施し、リリースして問題ないか判断できる。 -
単機能テスト
テストパターンの網羅を確認するテストで、入力バリエーションの確認でファイルなどの種類のチェックで使用する。
〇
これはその機能に仕様変更がある場合にリグレッションテストとして利用できる。 -
UIベースのテスト
ユーザーができる操作、ユーザーインタフェースを使ったテストを実行する。入力文字制限や画面遷移などのテストで、期待通りにページが表示されるかの確認で利用できる。
〇
-
単純だが手動で実行するのが面倒な作業
テストデータの準備など、手動で実施するのが面倒な繰り返し作業を自動化することで作業の効率化を期待できる
〇 -
手動でできないテスト
手動でできないテストについてはツールを使ってテストする必要がある
〇
何百、何千とあるデータを期待結果どおりか比較する
画像データをピクセル単位に比較する異なるブラウザや異なる端末やOSで、アプリケーションを並列してテストする大量の人数（１万人など）の負荷をかけてアプリケーションをテストする
-
-
障害復旧などのフェールオーバーテスト
意図的な失敗を発生させ、アプリケーションが期待通りに動作をするかを確認するテストだが、意図的な失敗を発生させるのに、人の介入やその他のツールの操作が必要になる場合が多い。
×
このようなテストについては、自動化するコストも増える割に発生頻度も限られることから、自動化はあまり推奨されない（リスクベースドテストの考え方で判断は必要） -
探索的テスト、アドホックテスト
テスト実施者が考えながら実施するテストで、アプリケーション自体に関係のないテストになることもある。
×
図（主題）と地（背景）の関係。 -
一度しか実行しないテスト
テストを実施するのに、大規模な前準備が必要となり、１度テストを実行するとまた前準備をやり直す必要があるテストで、例えばデータが１件もない状態でユーザーが削除することができないデータのテストなどがそれにあたる。
×
テストするために毎回表面だけでなく、裏側の関連データも削除する必要があり、一番最初のユーザーのみが利用する初回しかありえない状況のテストである場合のテストは手動で確認したほうが効率が良い -
UIベースのテスト
テストサイクルの長いテスト・アプリケーション
×
１年に１度しかアップデートがなく、テスト実行頻度が少なすぎるものについては、手動テストで実施したほうがよ効率が良いことがある。
テスト自動化のよくある勘違い
- × すべてのテストケースを自動化できる
- × テスト自動化することで、コストが大幅に削減される
- × テスト自動化ですべて成功すると、バグは発生しない
テスト自動化によって短縮できるのは、特定の種類のテストのみです。
すべてのテストを自動化すると、膨大な構築コストがかかるだけでなく、保守・メンテナンスの対象も膨大になります。
テスト自動化においては、特定な種類のテストを対象としているため、対象でない箇所の不具合は検出することができません。
何を自動化して、何を自動化しないかを適切に判断することで、時間を大幅に削減し、自動化の利点を得ることができます。
テスト自動化の導入がうまくいったプロジェクト
パッケージベンダーでユーザー納入前に毎回実施しているE2Eのテスト自動化
01月に１度のアップデートがあるスマートフォンアプリの多端末でのUIベースのテスト自動化
02同じ操作の繰り返しをする
03
レコメンドチャットボットのUIベースのテスト自動化マスター変更の度に入力パターンの網羅が必要、シミュレーション機能のUIベースのテスト自動化
04
テスト自動化の効果が得られたと感じるのは、３つあります。
ひとつめは、「１回のテスト実行によるコストメリットを感じられる」です。即効性がある反面、同じ操作で入出力する値がかわる確認作業のようなテストに限られます。
つぎに、「テスト自動化の導入コストの回収めどが立つ」です。繰り返し使い続けないと回収することはできないため、利用頻度が高くなるようなテスト（リグレッションテスト）などに限られます。
さいごに、「アプリケーションのリリースする間隔が短くなったと感じられる」です。テスト自動化を導入することによって、十分なテストも実施したにもかかわらず、リリースするまでの期間が短縮されたと感じる場合です。
テスト自動化がうまくいったプロジェクトは、テスト自動化による効果を十分に感じることができたものとなります。テスト自動化の効果については即効性があるもの、遅効性があるものがあります。何のテストに自動化を導入するか次第で変わりますので、正しく見極めてプロジェクトに導入するとよいです。
- テストの実施ができる人が限られる→ 自動テストにすることでテストの属人化から脱却
- 多端末での十分なテストが実行できない→ 全環境でリグレッションテストの実施を実現
- 単純作業の繰り返しだが、膨大な入力パターンがある→ １か月以上かかるテストを１週間で完了
- 法改定などの理由によるマスター変更でミスが許されない→ ヒューマンエラーの排除
さいごに、テスト自動化とは
テスト自動化を適切に使用することで、人と機械でやることを効率よく分離し、ビジネスや事業のスピードアップと継続できる十分な品質を担保できるようになります。
とりあえず、なんとなくでテスト自動化を導入すると、思わぬトラブルを引き起こしかねません。何を自動化して、何を自動化しないかを適切に見極めることが重要となります。
これからテスト自動化を導入するというかたは、まずは単純作業の繰り返しなどの即効性の高いテストを自動化して、小さな成功の積み重ねをしていくとよいのではないでしょうか。
