テストを自動化すべきかどうか
ソフトウェアテストの勉強中。
テストを自動化することのメリットとデメリット
導入として以下の本を読んでいます。
- 作者: 高橋寿一
- 出版社/メーカー: 翔泳社
- 発売日: 2005/02/18
- メディア: 単行本
- 購入: 18人 クリック: 398回
- この商品を含むブログ (70件) を見る
- 作者: Cem Kaner,James Bach,Bret Pettichord,テスト技術者交流会
- 出版社/メーカー: 日経BP社
- 発売日: 2003/04/22
- メディア: 単行本
- 購入: 15人 クリック: 246回
- この商品を含むブログ (48件) を見る
テスト自動化について、どちらも同じようなことが書いてありました。
簡単にまとめると次のような感じ。
- メリット
- デメリット
- 自動化されたテストツールのメンテナンスに工数をかけてしまう
- 自動化されたテストが実行されることが数回しかない=かけた手間に見合わない
- GUIの場合インターフェースは頻繁に変わるが、それにテストツールのメンテナンスが追いつかない
- スキルのないテスターがテストツールのコードを書くとメンテナンス不可能な産物となる
- テストツールが高価(フリーのツールで十分じゃない?)
とにかく「メンテナンスが大変」ということと、「自動化したってそんな実行しないでしょ?」という感じ。
これについて自分の環境に置き換えて考えてみる。
メンテナンスが大変
書籍は単体テストに関しては肯定的で、対象としてはGUIに関してメンテが大変って言っているように思う。
で、WindowsアプリのようなGUIアプリは今の自分には縁がない。
Webアプリを作っているわけだけど、WebアプリはここでいうGUIのテストに含まれるかどうか。
まあ分かんないけど、ただ「変更に追従するのが大変」ってのは分かる。
SeleniumなどでHTMLの階層を読み取って「ここのpタグ内の文字列が〇〇であること」とか書いてると、
pタグがspanタグになっただけでテスト落ちてなんだよもーってなる。
そういう意味では、メンテナンスは大変。
また、「pタグ内の文字列がどう」って、テストの目的からズレてる気がします。
もうちょっと大きい粒度というか、せめて「タイトルに○○とあるかどうか」とか書きたい。
ぼくらは別にUI要素のテストをしたいわけじゃない。
最終的に実行されるコードは同じだったとしても、開発者(テスター)が書くコードとしてはこういう粒度で書きたい。
そうしないと、他の人が見た時に何をテストしているのか分かりにくくなって保守性とか下がる。
この問題に関しては継続的デリバリー8章「自動受け入れテスト」にアプローチが書かれていて、
とても面白かったので今度また読み返しておきたい。
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
- 作者: David Farley,Jez Humble,和智右桂,高木正弘
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2012/03/14
- メディア: 大型本
- 購入: 24人 クリック: 567回
- この商品を含むブログ (45件) を見る
またはBDDで挙げられる各種受け入れツールの目的も、この問題に対するアプローチの一つなんじゃないかと思ってます。
自動化したってそんな実行しないでしょ?
これはプロジェクトの開発スタイルによって変わってきますね。
書籍では大規模プロジェクトかつウォーターフォールを前提としていると感じました。
開発者とテスターが分かれている時点でそれなりの規模だと思うし、
テストフェーズを想定した記述があったりしたのでウォーターフォールなのかなと。
ウォーターフォールでしかもパッケージ製品(かつリリースしたら基本終わり。追加開発なし)とかなら、
確かにそこまでテストを繰り返さないのかもしれない。
でも毎週リリースを繰り返すような場合、テストは何回何十回と繰り返される。
書籍には「自動化したそのテストを50回も繰り返すことがあるのか」という投げかけがあるけど「あるよ」と。
でも確かにすべてがその限りではないので、何でもかんでも自動化すべきってわけではないけど。
アジャイルについて調べるとテスト自動化については推奨されているのを見るし、
捉え方は間違ってないんじゃないかなと思ってます。