自動化の前提条件
自動化への投資は、実務の業務の推敲を支援するものでなければ意味がない。
テスト設計の不十分な状態での自動化は、まるで効果が上がらなく、自動化の得意分野をよく理解してテストを設計しないと、自動化の恩恵をうけれない。
また、テスト要件、アーキテクチャ、担当者の能力などの状況によって、自動化の戦略を考える必要もある。
目的はコストダウンではなく、開発プロセスの迅速化
テストの自動化によって迅速に情報が得られるようになれば、開発者へのフィードバックを早めることができる。
自動化による目的は、主に次のようなものになる。
- 不完全なプログラム修正の早期発見
- 回帰テストによるバグの早期発見
- 問題点の早期報告
よく使うテスト手法としては、自動スモークテスト（ビルド確認テスト）と自動単体テストとがある。
自動スモークテスト では、製品の全機能について基本的な部分のテストを実施し、もし主要部分が動かないなどの致命的なバグがあれば、動作を安定させるためにビルドを差戻す。
自動単体テストでは、製品の低レベルの関数やクラスの集合についてテストを行う。
このテストの最大の利点は、いつでも誰でもが実行できることにある。
テストによっては自動化をした方が有効なものがある
- 負荷テスト
- 性能ベンチマーク
- 構成テスト
- 耐久性テスト
- 競合状態
- 複合バグ
自動化は「銀の弾丸」にならない
自動テストを導入するだけで良いテストが常に行えるなんてことはない。
100%の自動化を達成しているような場合でも、それは複数のテスト手法を組み合わせることによって成功している。
ボタンを押すだけで自動的にバグを見つけてくれて報告してくれるようなものを作ったとしても、人手によるエラー調査は必須である。
テストツールに使われないこと
テスト作業において、ツールがやり方を教えてくれるわけではないし、混乱した事態を収集してくれるわけではない。
テストの自動化は、まずテストプロセスを安定させてから行うべき。
また、作業者が自分が行なっているテストの目的を理解せずにテストを行なっていたとしても、全く意味がない。
手動テストと自動テストは別格
人間が行うテストを自動化すればいいということではない。
テストの自動化とは、人がやるようなテストを単純にCPにやらせることではなく、明示的に手順化された固定的なテストを行うことであり、手動テストでできないことを実行させることである。
自動テストは、常に同じスピードで、同じ手順で、同じ操作によって実行される。これに対し、人手においては実施のたびに内容に差異が生じることから、このおかげで新しいバグが見つかることもある。
また、自動テストでは、通常テストにおいては特に指示をしなくても気づいて報告するような問題に気づくことはできない。
同じテストをなんども繰り返すだけでは元は取れない
よく比較される方法として、自動テストと手動テストにおいて実行回数などから実際にかかるコストを比べ、投資することでどれほどの利益があるのかを考えるというものがある。
ここでは、「手動テストと自動テストは別格」ということや、そもそも実際に同じテストを繰り返す必要があるのかを考えなくてはいけない点に気をつける必要がある。
自動化で埋もれてしまうバグはないか
自動化の作業中に行うべきことはないか、実行できるテストはないか、発見できなくなるバグはないか等、コストやリスクを考えることが大切。
また、既に完成されている自動テストにも十分注意が必要であり、本当にテストできているのか、役に立つのか、ガバレッジは大丈夫か、正しくチェックされているかを常に注意する必要がある。
GUI関係のテスト自動化
UIの変更に追随する必要があり、そのためにはインターフェース部分を抽出し、それを抽象化して自動化テストに取り組む必要がある。
自動化した回帰テストはすぐに使えなくなる
UIや出力形式の変更、環境の問題、メンテナンスの問題などの可能性を考慮し、自動化するテストの選定は慎重に行うべき。
どんなテストでも自動化を行えば、それはメンテナンスをし続けるか、捨てるしかなくなってしまう。
テストの自動化はソフトウェア開発そのものであり、決して安くない投資である
一つの手動テストをきちんと設計し自動化するものなら、手動テストを行う10倍もの時間がかかるだろう。
もちろん、ソフトウェア開発の工程のように、プログラミング、テスト、レビューやプロジェクト管理が必要となり、幅広いスキルが求められる。
このことからも、自動化計画はプロジェクトの早い段階で立てるべきである。
自動化テスト設計で注意すべき事項
- テスト環境の確認
- 期待する結果は何か
- 潜在的エラーと副作用の確認
- 潜在的なエラーから復旧する方法
- 他のテストの邪魔をすることはないか
テスト変数が多い時は
データ駆動型自動テストや、キーワード駆動型自動テストを使う。
データ駆動型自動テストとは、入力値と期待値を表計算ソフトなどの表に記入し、それを読み込むことでテストと結果の合否を評価する方法。
テストデータと実行コードとを分離することで、繰り返し使うことができるだけでなく、テスト用プログラミングの簡略化やレビューが行いやすい等のメリットがある。
キーワード駆動型テストとは、表に登録できるものがデータだけでなく、項目の組み合わせ（キーワード）であるという点が異なる。
自動単体テスト
単体テストとは、関数、クラス、メソッドなどのソフトウェアを構成する採用単位の機能をテストするものである。
本来、単体テストでは、一つの機能を完全に独立させた状態でテストを行うが、いくつかの単体テストを処理経路に沿って行うことで、スタブ（テスト対象から他のモジュールを擬似的に呼び出す）を作る必要をなくす自動単体テストには人気がある。
「テスト容易性」とは可視性と操作性である
ソフトウェアの動作を監視したり、状態を操作したりする機能を組み込めば、よりテストが容易になる。
- ソースコードの確認
- ログ出力
- 診断コード
- エラーシミュレーション
- テストポイント
- イベント鳥が
- 古いデータフォーマットとの互換
- カスタムコントロールサポート（GUIのテストツールが持っているインターフェースを操作する機能）
即効性のある自動化から始めよ
効率の改善という面から自動化の対象を選択するべき。
- システムセットアップと準備
- 診断支援
- セッション記録
- テスト生成など