自動テストに向かないテスト
それでは、抽象化を推し進め、テストスクリプトの内部実装をほとんど意識しなくて済むようにした上で、すべてのテストを自動化することが正しいのでしょうか。
自動化にかかる工数のことを差し置いても、それは「否」です。あくまで一般論にすぎませんが、システムテストレベルにおいて、自動化が最適な選択肢とは限らない例を挙げてみましょう。
自動化が無為に終わりかねないもの
- 繰り返すつもりのないテスト
- 繰り返す必要がなく、手動での実行が難しくないのであれば、自動化する必要はないでしょう。
- 品質が安定していないソフトウェアでのテスト
- 臨機応変に対応するという点では、自動テストは手動テストに劣ります。テストが通らないながらも、いろいろ動きを確認したいという用途に、自動テストはあまり向きません。
- 仕様が安定していないソフトウェアでのテスト
- たとえば画面構成が頻繁に変わって、作ったスクリプトがすぐに使えなくなるような状況では、スクリプトのメンテナンスの方が手動テストより高コストになりかねません。
- 長いシナリオを通してのテスト
- これは必ずしも自動化が悪いわけではありません。ただギア本でも触れられているように、品質の十分でないテストスクリプトで長すぎるシナリオを自動テストしようとすると、テストが失敗するリスクが高くなります。短いシナリオで安定して動作するようになってから、長いシナリオに適用するのがよいでしょう。
ハードウェア的な関与が必要なもの
たとえば、「ハードディスクをいきなり、物理的に抜く」という操作は、自動化が難しいでしょう。シミュレータでの擬似的なイベントがどこまで可能で、またどこまでを妥当なテストとして許容するかの判断が必要です。
人が判断しながらテストすべきもの
- ユーザビリティに関するテスト
- ソフトウェアの使い勝手、画面の見やすさ、画像・音声・動画の出力の妥当性といったものに対する判断は、機械に無理やりやらせるより人が行うほうがよい場合が多いでしょう。もちろん、人の主観だと判定がぶれるという問題もありますが。
- 探索的テスト
- あらかじめしっかり決められたテスト手順に基づくのではなく、ソフトウェアの動きを確認しながら次の手順を決めて、欠陥を探していくもの。
最後の「探索的テスト」について少し述べた上で、本稿を終えたいと思います。
