読者です 読者をやめる 読者になる 読者になる

Thanks Driven Life

日々是感謝

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

ギア本

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

章題だとひたすらキャプチャーリプレイを dis するだけの章に見えたが、そういうことではない

  • 今自分達がもってる手動テストを把握し、それを自動化する時に考えるべき事案
  • キャプチャーリプレイでできること、できないこと
  • 「比較」の自動化について
    • 詳細は今後の章で出てくるとのこと
  • 優れた自動化の枠組みについて
  • でもやっぱりキャプチャーリプレイかっこいいしさっとできるから、ちゃんと使うタイミング考えよう

みたいな感じでした。

Selenium IDE のテストケースをメインで触ったこと(保守)ないのでわからないんですが、使い続けるのはやはり大変そうなイメージはある。 めんどくさい上に検証の目的はない操作に限っていえばすばらしいツールだとは思う

*1:テストケースの品質が良いという勿論の前提がある