0.はじめに

伝えたいこと

テスト自動化は難しいかもしれない
キャプチャリプレイ(操作記録)ではテスト自動化ではない

注意

私は、テスト自動化を「検討」しただけで、「実施」はしていません。
私は「テスト自動化は無意味だ」と言っている訳ではありません。
参考図書から説明できそうな部分を切り取っています。参考図書が伝えたいことのニュアンスが変わっているかもしれません。最終的には参考図書を読んで欲しいです。

参考図書

1999年に出版された『Software Test Automation』の日本語版。
この記事では、主に1~2章を参考、引用している

日本語版まえがき

「ソフトウェアテストを自動化すれば、手動よりはるかに安いコストで、はるかに速く、はるかに正確なテストを半永久的に何度でも行うことができ、ソフトウェアの品質がぐんぐん上がるので、自動テストをどんどん推進しましょう」

この文章のほとんどがまやかしであることを、本書は教えてくれます。
～省略～
本書は、まやかしのテストの自動化のせいで不幸になる前に読んでおくべき本です。

用語

1. テスト自動化のコンテキスト

良いテストケースとは何か？を表す属性

欠陥検出の効率性
- 最も重要
- 後述のグラフの「効果的」
一度の実行で複数のテスト条件をテストできるか？
- 後述のグラフの「典型的」
テストケースの実行、分析、デバッグがいかに安く行えるか
- 後述のグラフの「経済的」
ソフトウェア側の変更に対して追従するのに、どれほどの工数がかかるか？
- 後述のグラフの「発展的」

4項目のバランスを取る必要がある

テスト自動化の特徴

テストの自動化は、経済性(3番)と発展性(4番)を、自動化するだけ
テストが自動化されていることと、効率性(1番)、典型性(2番)は関係ない
何もしないテストを自動化しても、何もしないテストを効率化するだけ

自動テストを効率よく効果的にするには、まず優れたテストが必要！

[補足] 品質属性を表現したレーダーチャート

テスト自動化した最初の1回は、すべての項目で手動テストより劣る

自動化の利点

プログラムの新しいバージョンで、既存の（回帰）テストを動かす
- 最もよくある使われ方
テストをもっと頻繁に、たくさん行う
- 短い時間で多数のテストを実行できる
手動では困難まはた不可能だったテストを行う
- たとえば、200人のユーザがアクセスしたときのテストなど
リソースの有効利用
テストの一貫性と再現性
テストの再利用
市場に早く提供できる
自信が持てる
- 広範囲な自動テストが成功していることを知っていると、リリースに自信が持てる

⇒ より完全なテスティングを少ない工数で実施できると、品質と生産性の両方が高まる！

[私見]ウチのチームでは、1番と8番が関係ありそう。

テスト自動化に共通する問題（1.6章 P13)

非現実的な期待
- IT業界は、新しいツールが達成できることについては、楽観的
まずいテスティングのやり方
- ドキュメントもなく、欠陥を見つけられないようなテストの場合、テスティング自動化は考えない方がよい
- カオスを自動化してもカオスが速くなるだけ
自動テストは新しい欠陥をたくさん見つけてくれるのではないかという期待
- 同じテストをもう一度流しても、新しい欠陥は見つからない
安全に対する誤った意識
- 欠陥が見つからなかった場合、テストが不完全か、テスト自体に欠陥が含まれているかもしれない
自動テストのメンテナンス
- テストを手動で再び流すよりもテストを更新する方が工数がかかれば、テスト自動化は放棄される
技術的な問題
組織の問題

[私見] 2番、5番が大きな問題になると思う

自動テストすべきでないテスト（1.9.1章 P29)

ごくまれ(年に1回など）にしか実行されないテスト
テスト対象が頻繁に変更される場合
検証の自動化難しいテスト
- 画面配置の見栄えや色彩設計など
物理的なやりとりがあるテスト
- カードリーダにカードを通す、など

⇒ 手動テストを全て自動化しなくてもよい

自動テストの方が自動テストよりも多くの欠陥が見つかる（1.9.2章 P29)

テストは、最初に実行したときが一番欠陥を見つけやすい
手動テスティングが85%の欠陥を見つけるのに対し、自動テストは15％しか見つけられない (James Bach, 1997)

2. キャプチャリプレイはテスト自動化ではない

操作記録ツールについて

「手動で行うテストをこのツールで記録し、再生することで、同じテストを正確に繰り返し実施できる」ことが、テスト自動化だと信じる人が大勢いる。

テスト入力だけの自動化のメリットと用途（2.3.4章 P58)

比較的早く、再生可能なテストの形にできる
監査証跡
大量のデータのセットアップ
デモンストレーション

⇒ テスト実行のみの自動化はほとんど効果がない。
⇒ テスト結果の比較も自動化すべき

手動テスト記録の短所（2.3.5章 P59)

テストスクリプトが読みにくい
- 何をしているのか、目的などの説明がない
文字列や位置などと固く結びついている
- 結びついている画面のオブジェクトが変われば、テストは動かなくなる
- 再度記録するより、メンテナンス工数の方がはるかに大きくなることもある

[実演]Selenium IDEで確認

テスト結果の比較の自動化

テスト結果の全体を比較するのは非現実

どれだけ比較するか(2.4.2章 P63)

画面全体
- 一番簡単
- 現在日時などが表示されていると厄介。
最小限
2つの中間

ビットマップの比較を避ける(4.10.6章)

ハードウェアにも依存するため、比較がことごとく失敗するかもしれない
比較をするならば、可能な限り最小にするべき

3.その他

最初に何を自動化するか（9.1.3章 P293)

とても重要なテスト
- プロジェクトの中でとても重要なテスト
広範囲テスト
とても重要な機能に対するテスト
- 利用率が高い機能
- 製品を象徴するような機能
手軽に自動化できそうなテスト
最も早く見返りの得られるテスト
実効頻度の最も高いテスト

自動化の工数は手動の何倍？(P44)

キャプチャリプレイツールを使った場合

手動でテストを実行するのに必要な工数の2倍から10倍
少なくとも5倍かかると想定しよう

4. 付録

テスト自動化を検討してみた感想

プロダクションコードを多少修正する必要がある
- 要素を簡単に取得できるよう、適切なIDやclass, 属性を付与する
- 期待結果を判断しやすいようにする. たとえばJavaScriptのエラー判定など。http://daipresents.com/2012/post-4906/
「正しい結果とは何か？」を考えるのが難しい

参考サイト

テスト自動化の8原則(テスト自動化研究会）
「テスト自動化研究会の『システムテスト自動化標準ガイド』を15倍あなたの力にする話」連載一覧
テスト自動化のパターンと実践
自動テストの誤解とアンチパターン in 楽天 Tech Talk
- 「統合テスト自動化で得られる最大のメリットはテスト実装者が得る幅広いプログラミングスキルとアーキテクチャ知識である」とのこと

【社内勉強会】テスト自動化の難しさ(2017/08/25)