Outline
テスト自動化研究会にて、テスト自動化の8原則が掲げられています。
その８項目の中で
「自動テストで新種のバグが見つかることは稀である」
とあります。
テストエンジニアになり、ISTQBを勉強している人にこれを説明する機会がありました。
その時の持論がとても理解してもらったので、忘れないためにブログに残しました。
前提
テスト自動化の前提は以下の通りです
- Webアプリケーション
- Ranorex等のcapture方式で実装、もしくはwebdriverでスクリプトを組む
- ウォーターフォール、もしくはアジャイル
- テスト自動化の実装部隊は、いわゆるQA部署（開発ではない）
テスト自動化の工程
なぜ、新種のバグを見つけにくいのかを知るには、工程を知るとわかりやすい
自動化の工程は単純に言うと
- テスト対象を構築する
- テスト対象からオブジェクトを抽出しながら（XPathやID、イメージ等）スクリプトを実装する
- テスト自動化が正しいかを検証する
- テスト自動化が仕様通りにならない場合、テスト対象にバグがあるため、テスト対象を改修し、テスト自動化のテストを再開する
- テスト自動化スクリプトが完成
Step3の”テスト自動化が正しいこと”を検証するフェーズは重要になります。
大きく２つポイントがあり
- テスト自動化が最後まで動くことを確認
- テスト自動化が仕様通りに動くことを確認
２番目は、当たり前なんですが、別の見方をすると
「テスト対象がバグがあると、それを元に作ったテスト自動化が動いても、テスト自動化が正しいとは言えない」
のです。
そのため、Step4の工程が発生します。
自動化を作る過程でバグが見つかり、テスト対象をエンジニアに直してもらう。
この過程で、Step5 テスト自動化が完成します。
ここから、このテスト自動化がテストとして動かすことができます。
ただ、ここで考えてみてください。
このときに、テスト自動化を実施して、何が起きるでしょうか？
基本的に、テスト自動化を実施したときバグはあまり出てきません。
なぜなら、上記工程でテスト自動化を作ってるからです。
ただ、完全にバグゼロかと言うと、そうではありません。
- 繰り返し実施することで見つかるバグ
- バリエーションテスト（データ・ドリブンなど）で見つかるバグ
などは、見つけることはあります。
ただ、新種のバグはやはり見つけることは稀になります。
正しく動くテスト対象に対してテスト自動化を作ることから、そこから逸脱しない、リグレッションテストとしては非常に有効になります。