「システムテスト自動化 標準ガイド」を読んだ感想
はじめに
システムテスト自動化 標準ガイドを読みましたので、その感想を書いていきます。
目次
この本を読んだ理由
E2E自動テストを導入する際にどうせなら上手く導入したい。そのために以下の内容を知りたいので読んでみました。
- 自動化のメリットとデメリット
- どのように実現するか、あるいはしないべきか。
- どこまでの範囲をテストすべきか。
- どのようにテスト自動化を導入、保守すべきか。
- 失敗談から学びを得たい。
2014年出版の本、かつ翻訳元はもっと古い（1999年出版）なので情報が古い可能性があることは注意して読み進めました。
学んだ内容
テスト自動化のコンテキスト
テストの自動化は、経済性(テストケースの実行/分析/デバッグがいかに安く行えるかどうか)や発展性(保守性、ソフトウェアの変更に対して追従するのにどれほどの工数がかかるか)を高めることだけができる。
効果性(欠陥検出の効率性がよいか)、典型性(一度のテスト実行で複数のテスト条件をテストできるか)は上げることはできない。
テスト自動化の利点
- プログラムの新しいバージョンで既存の回帰テストを動かす
- テストをもっと頻繁に多く実施する
- 手動では困難または不可能だったテストを行う
- リソースの有効利用
- 単調で退屈な仕事を自動化することにより作業者の士気も高まるし、ヒューマンエラーを防ぐこともできる
- テストの一貫性と再現性
- テストの再利用
- ソフトウェアを市場に早く提供できる
- 自信が持てる
自動化の限界
- 手動テスティングはなくならない
- 手動テストのほうが自動テストよりも多くの欠陥が見つかる
- 期待結果の正しさを検証することがより重要となる
- テスト自動化をしてもテストが効果的になるわけではない
- ソフトウェアにおける変更に対して自動テストは手動テストに比べて脆弱
- 維持にも労力が必要なので、ソフトウェアの変更や拡張の足かせになることもある
- ツールは想像力ゼロ
テストスクリプティングの技法
データ駆動スクリプト
テストにおける入力値をテストスクリプトの中ではなく別の外部ファイルに格納する技法。
メリット
- 同じスクリプトを別のテストでも素早く追加できる
- スクリプト言語についてのプログラミングの知識がないテスト担当者でも新しいテストの追加を行うことができる
- 同じテストケースで複数テストを行うのために追加のメンテナンス工数がかからない
デメリット
- 初期のセットアップに多くの工数がかかる
- プログラミングについてのサポートが必要である
- よく管理されていなくてはならない
キーワード駆動スクリプト
キーワード駆動スクリプトの発展型。テストデータとは別に操作内容をキーワードとして外部ファイル化する。そのキーワードをテストスクリプトが読み取ることでキーワードに従った操作を行う。スクリプトの数を増やさずに多くの自動テストを実装できる。
自動比較の注意点
自動比較の限界
手動テストではテスト手順書に記載されている以上にテスト結果の妥当性をチェックすることが多い。自動比較は人が手動で行っていた比較の一部分でしか無いことが多いため柔軟性に欠ける。自動ですべてチェックすることは現実的ではない。
比較ではわからないものは何か
比較ツールではテストが成功したかどうかはわからない。比較して差異がある事実がわかるだけ。そもそも期待結果が間違っている場合は予想外の差異が出ずに「テスト成功」したように見える。
自動テストの前処理と後処理について
テストの前処理*2と後処理*3も自動化すべき。手作業が必要だと、夜間や週末に無人のテストができない。
→CI/CDパイプラインが構築できない。
後処理のタスクが一つでも失敗した場合テスト結果に関わらずテストケース自体を失敗とすべき。フェイルセーフポリシー。
自動テストが正常終了の場合
すべての実行結果が期待結果と一致する場合すべての実行結果は削除してしまって良い。
期待結果と同じだとわかってしまえば実行結果を保持する意味は殆どなく、同じものを2つ保つ必要はない。同じようなもの2つ持つものはストレージ容量の無駄なため。テストステータスの情報（成功/失敗）などの情報は削除する必要はない。
※社内規定などでテスト結果の全てを保持することが求められる場合は例外。
自動テストが異常終了の場合
手に入る情報が多いほど解析（原因を調査しやすい）ため、すべての情報を保持したい。
テストケースが失敗する場合に備えてテストスクリプトの中により多くの情報を出力を生成するようにテストを設計することができる。
テストケースが成功すれば多く出力した情報はテストケースの後処理で削除して良い。失敗したときに効果を発揮し、原因解析を助けてくれる。
テストツール選択プロセス
ツール選択はツールで解決すべき問題を把握するところから始める。以下は解決すべき問題の例。重要度や組織に与えるコストによって問題点をランク付けする。
- 手動テストの問題（とても時間がかかる、退屈である、間違いを起こしやすいなど）
- ソフトウェアに対して小さな変更を加えた際の回帰テストを行う時間がない
- テストデータまたはテストケースのセットアップで間違いを起こしやすい
- テストドキュメントが十分ではない
- ソフトウェアがどれくらいテストされているかわからない
別の解決策を探る
大切なのはツールを使った解決法だけでなく、異なる解決法についても合わせて考慮すること。ツールが価値をもたらすか評価するためには、ツールを用いない代替の解決法を考えることが重要。自動化による解決に熱中するあまり他の解決策を顧みなくなることがままある。
テストツールの導入プロセス
ツール選択のプロセスが徐々に選択肢を絞るものだとすると、導入プロセスはその逆。徐々にツールの適用範囲/使い方/利益を広げていくプロセス。
最終的には生産性を向上させるツールであっても、ツールの使い始めには生産性が低下することを意識しておく。
導入時におけるのコスト
- 組織内にツールを売り込むこと
- 支援と訓練を提供すること
- 推進中のテスト自動化の枠組みを支えるインフラを構築すること
ツール導入時において人の問題を管理しないことの危険性
もし人々の仕事のやり方を間違った方法で変えようと試みるなら、疑念を生じさせ抵抗にあう。抵抗を上手く扱わないと敵意を誘発し変革の努力の妨害さえ引き起こしかねない。「我々は一度試みたもう試みるつもりはない」という態度が生まれてしまうと将来的にどのような改革の試みも非常に難しくなってしまう。
次の公式に基づいて人は変化しようとする。
変化の公式：f(a, b, c)>z a=現状に対する不満 b=共有された将来のビジョン c=はa~bへ至る工程についての具体的知識 z=個人が自らの仕事のやり方を変えるのに必要な心理的感情的コスト
abcが合わさってzより大きくなったときにだけ変化が起きる。
わからないこと
fixtureデータ駆動スクリプトにおけるファイルの認識だけどあっているのだろうか。フレームワークによって意味合いが少しづつ異なる？
本書では画像ファイルの比較はしないほうが良いと合ったが、pdfを比較したいケースもある気がする。その時はどうやってなのだろうか？浮かぶ案はdiff-pdfのようなものを使って、後で人力で確認するくらい。
感想
テスト自動化は銀の弾丸ではない
テスト自動化によるメリットとデメリットを把握できたので、あくまで手段の一つであることを認識できました。今まで殆どのテストは自動化しなければならないと思っており、自動化による解決に熱中していましたが、そうではない考えを身につけることができました。
また、自動テストは経済性と発展性を上げるものと認識できたので、今後は自動テスト実行では経済性/発展性を上げるように、自動テスト設計or手動テスト設計･実施では効果性/典型性を上げるように努めます。
変革と人の問題
自動化の技法だけではなく人の問題まで記載されていることが面白かったです。変化の公式はテスト自動化だけのか変わらない話ですし、人が変化できるようにするために変化の公式でtrueを返せるような働きかけをすることが重要である点を知れたことは良かったです。
自動テスト正常終了の話
自動テスト正常終了の後に実行結果を捨てて良いのは少し衝撃でした。でもたしかに期待結果と実行結果はほぼ同じ内容ストレージの無駄なのも納得できる。この視点はなかったので為になりました。
おわりに
最後まで読んでいただいてありがとうございました！！
この本は約450Pあります。ここまで分厚い本は今まで読んだことないので、読み進めるのに時間がかかりました...
今後もいろいろな本を読んで、知識を得るために早くアウトプットできるようにがんばります💪
*1:【社内勉強会】テスト自動化の難しさ(2017/08/25)
*2:テストを実行する前に完了すべき、テストに必要なデータの投入や更新前のファイルの退避するといったタスク
*3:自動テストの後に行われる不要データや不要ファイルの削除、やテスト結果制作物（テストレポートなど）の削除や保管
