システムテスト自動化標準ガイド第2章「キャプチャーリプレイはテスト自動化ではない」読みました

#ギア本今日は第2章「キャプチャーリプレイはテスト自動化ではない」を読んだ
— Wataru MIYAGUNI (@gongoZ) 2015, 1月 26

自動化を試みる前に、まずは現状を把握する

まず今やってる手動のテストが「アドホックテスト(テスト仕様書無しに雰囲気と勘で操作する)」「曖昧な手動テスト(正常なアイテムを追加する→正常とは?みたいな)」「詳細な手動テスト(3というアイテムを追加しろ→はー言いなりだわーやる気なくすわーみたいな)」のどれかを見極める
— Wataru MIYAGUNI (@gongoZ) 2015, 1月 26

自動化の開始地点としては「詳細な手動テスト」が望ましい。「アドホックテスト」はやめろ。ドキュメントが無いということは無秩序でカオスだ。カオスを自動化してもカオスが加速するだけだ！
— Wataru MIYAGUNI (@gongoZ) 2015, 1月 26

テスト仕様書無しに「とりあえずやってみるか」っていうアドホックテストと、テスト仕様書はあるもののその内容が暗黙的か、もしくは冗長的に詳細かどうか。

自動化を試みる(この章では自動テストツールに移行するという話)のであれば、「詳細な手動テスト」をスタートとするのが好ましいとしている。テストケースの品質について考える必要がなく*1、テストツールにマッピングしていく作業に集中できるから。ただ、「詳細な手動テスト」ほど工数をかけた内容となっているため、2度手間を感じるかもしれない。

アドホックテストを自動化するのは「設計をせずにプログラミング」といういきあたりばったりと同義なのでカオスしか生まれない。第1章でもあったとおり、カオスを自動化してもカオスが加速するだけである。

キャプチャーリプレイは「入力の自動化」である

「無秩序でも記録すればすぐ自動化できるではないか。すぐできるかっこいい！」 →「すぐ再生できた！すごい」 →「これでテスト流してる間はコーヒー飲めるわ。あ、再生中の値判定は目視な」テスター「え」 →暴動結局自動化できたのは入力だけで。比較の自動化しなければ効果的とはいえない
— Wataru MIYAGUNI (@gongoZ) 2015, 1月 26

自動操作スクリプトの合間に比較コード入れていくぜ →比較する値、短すぎたら他のアイテムもマッチするし、詳細に書きすぎるとあとで見てもわかりづらい… →あと、この比較失敗した時点でテストストップさせないとデータ壊れるわ。チェッカー入れないと →結局手動でやること一杯じゃねーか(憤慨
— Wataru MIYAGUNI (@gongoZ) 2015, 1月 26

テスト終了後に生成されたファイルとかDBをチェックして比較するか →このテストツール、入力や動的比較のサポートはあついけどテストプロセス終了したらもう何もできない →自分たちでテスト終わったらDB覗いてデータ取得して比較してって書かないと →結局手動でやること一杯じゃねーか(憤慨
— Wataru MIYAGUNI (@gongoZ) 2015, 1月 26

キャプチャーリプレイツール(今だと Selenium IDE が一般的だろうか)でとりあえず手動でやってたことを記録して自動で動くようにしてみると、あたかも自動でテストをしてくれていると錯覚するが、あくまで操作(入力)だけを自動でやってもらってるにすぎない。

第1章でもあった「テスティング活動」の中で言うと「実施」だけで、「比較」がまったく考慮されていないということになる。「識別」と「設計」を行ったあとであれば尚更「比較」をないがしろにしてはいけない。それはテストではない。

じゃあ比較をどうにかして挿入していけばいいんじゃね、みたいな感じになると「動的比較(リプレイ途中で値をチェックする)」「実行後比較(リプレイ完了後に値をチェックする)」といったところをそれぞれ考えないといけない。

書いていくと実感できるが、どちらも

比較を詳細に書きすぎると、システムのちょっとした変更で死ぬ
- 自動化で大事なことの一つは「やり続ける」ということ。なのに修正コスト半端ないので死ぬ。
- 例「画面の上から X px, 左から Y px にあるボタンをクリックしたら□□って表示されている。」厳密過ぎて死ぬ
比較を簡潔に書きすぎると、そもそもちゃんと確認したいことができてるか怪しすぎて品質が死ぬ
- テスティング活動「識別」で出した「検証したいこと」以外のことを見て誤爆して死ぬ
- 例「画面のボタンをクリックすると□って表示されている」→ボタン増やしたら死ぬし□って含まれる文字列一杯あって死ぬ
いい感じにまとめようとしていろんな状況に対応しようとすると、もはや比較のプログラミングになる
- 人がプログラミングを行うとバグを埋め込む可能性が発生する
- あと環境依存にもなりやすい
- 複雑になればなるほど死ぬ

などなどいろいろ考えないといけないので、つまりキャプチャーリプレイではテスティング全てを自動化しているとは言えない、ということ。

ではキャプチャーリプレイは使わない方がいいのか?

かといってリプレイが無能なわけじゃない。テストの準備(例えばテストで必要なユーザをあらかじめ作成しておく)などに使えるだろう。バージョンアップしてUIが変わったらキャプチャし直すかもしれない。ただそのコストとテスト準備コストを見比べたら有効的と言えるかもしれない
— Wataru MIYAGUNI (@gongoZ) 2015, 1月 26

テスティング全ては自動化できないが、それでもできることはある。「何をしたいか」「何をさせるか」をしっかりと考えれば効果的なことには代わりはない。

自動化の優れた枠組みは「実施が容易である(ボタンぽちっ)」「テストの前処理・後処理も考えられている」「テストの追加が容易である」。キャプチャリプレイでこれらが満たされるかと言えば、どうだろう。なのでテスティング自動化とは単純にはいかない
— Wataru MIYAGUNI (@gongoZ) 2015, 1月 26