テスト自動化のアンチパターンをご紹介ーテスト自動化が失敗する原因ー

こんにちは！
スマートな社会を目指してQA (Quality Assurance) をしている矢野です。

初めてテスト自動化を検討される方は、現状のプロダクトの品質やテストに何かしらの問題を感じているのではないでしょうか？そこでカンフル剤的な役割としてテスト自動化という選択肢があるのかもしれません。

正直なお話をしますと、テストを書く文化がない現場に対してテスト自動化を導入し、長期継続的な成功に導くことは、とても難しいことだと私は感じています。その一方で、テスト自動化を失敗に陥れてしまうことはとても簡単です。

このことはテスト自動化にチャレンジしたことのある方や、テスト自動化を現在進行形で推進されている、多くの方が感じたことがあるのではないでしょうか？

そこで、テスト自動化が失敗する原因を整理しアンチパターンとすることで、失敗する確率を減らし、悲惨な結末を迎えることを少しでも防げるのではないかと考えました。本記事では、私が日々感じているテスト自動化が失敗する可能性を高めるアンチパターンをいくつかご紹介したいと思います。

1.テスト自動化を目的にする

テスト自体もそうですが、テスト自動化も手段のひとつに過ぎません。テスト自動化自体は銀の弾丸ではないので、それ自体を目的にすることは失敗に向かう可能性が高いです。

上司や、現場のエンジニアの誰かひとりの「思い」だけで自動化する場合も同じで、例えばテスト自動化を評価目標に入れて既存のテストケースの自動化率をメトリクスにすれば、テスト自動化の導入だけはうまくいくかもしれません。

しかしテスト自動化の技術や責任が属人化している場合や、自動化したテストをどう扱うかの取り決めがチームにないならば継続的なテスト自動化が行われることは難しいと思います。

2.既存のテストを整理しない

テスト自動化は現状の手動テストにおける問題の打開策としてチャレンジする場合も多いのではないでしょうか？

しかしまず考えなければならないことは、既存のテストをそのまま自動化しても効果はあるのかということです。

例えばソフトウェアテスト7原則の1つである、殺虫剤のパラドクスのメタファーにもあるように、既存のテストがすでに効果のないテストになっていることもあります。これまでに蓄積された回帰テストの中で同じことを確認しているようなテストや、テストをすること自体が目的になっているようなテストで無駄に時間を使っているだけかもしれません。

効果のないテストをいくら自動化しても何も意味がないので、まずは自動化の前に既存のテストを整理し見直すことを考えた方が良いです。

3.自動化すべきテストか判断しない

テスト自動化の8原則にもあるように、今の技術では完全に手動のテストがなくなることはありません。自動化が苦手とするようなテストも中にはあるのではないでしょうか？

まずは整理されたテストの中からどれが自動化に適したテストなのかを判断し、手動のテストと分業することを考え、少しずつテスト自動化を推進していくことが望ましいです。

自動化すべきかどうかの判断材料のヒントは、SHIFTのオウンドメディア「シフトモ」で紹介しているこちらの記事にもまとめています。

4.フィージビリスタディを行わない

実際に自動化すべきテストが判断できたとして、いきなりそれらのテスト自動化を一度にするべきなのでしょうか？

まずは自動化の優先度の高いところから少しずつテスト自動化を実施し、実際のテスト活動やリリースフローに組み込んでみて検証を行う、フィージビリスタディを実施するのが定石です。

テスト自動化の仮説検証を行わずに、テスト自動化に夢や理想を抱きすぎて最初から多くのテストの自動化を行なうと、期待通りにならないことも多く、結果としてテスト自動化自体が志半ばで終わってしまいます。

5.自動化したテストを自動で実行しない

せっかく自動化したテストも個人のローカル環境から手動で実行を毎度を行っていると大変ですし、リリースのフローからいつの間にか抜け落ちてしまうこともあるのではないでしょうか？

また、自動化したテストは短いサイクルで繰り返し何度も実行しなければテストを自動化する労力に見合わない可能性も高いです。CI/CDパイプラインの中で繰り返しテストを自動的に実行し、品質を高頻度で確認できるようにしなければ、自動化の恩恵をあまり受けられなくなります。

6.自動テストの結果を可視化しない

どんなにテストを自動化しても、誰にも見られないテスト結果や品質の判定に使用されないものならば、その自動化したテストはシェルフウェアの運命を辿るのではないでしょうか？

テスト結果としてのレポートを自動でデプロイして可視化することや、テスト結果のサマリをメールやチャットツールで通知したりと、品質を高速かつ継続的にフィードバックすることが必要になります。

テスト結果の分析を容易にするためにも、過去のテスト結果も簡単に辿れるようにすると尚良いと思います。

7.自動テストの結果と向き合わない

テスト自動化の8原則にもあるように、テストを自動化してもテスト結果の分析という工程が生まれます。

テストの結果に何かしら異常がある場合、それが何起因で起きているものなのか切り分けなければなりません。もしテストコード側に修正が必要ならばメンテナンスを行うことや、テスト結果があてにならないフレイキーなテストも極力なくなるように工夫が必要になります。

こういったテスト結果の異常やフレイキーと向き合わずにメンテナンスを怠ると、自動化したテスト自体の品質が落ちていき、オオカミ少年のように誰からも信用されることのないテストになってしまい、最終的にはシェルフウェアになるのではないでしょうか？

またテスト自体は品質を良くしません。自動化したテストの結果と向き合わずに、品質を向上するための活動が全く起こせない場合も同様です。

8.E2Eレベルのテスト自動化だけを行う

手動で行っていたテストをそのまま自動化した場合、画面のGUIなどを直接操作するE2Eレベルでのテスト自動化が多くなりがちになるのではないでしょうか？

しかし、E2Eレベルでのテストは自動化した場合、手動ほどでないにしても実行時間はかかりますし、何か障害があったときに分析するのにも時間がかかります。

そしてSUT(System Under Test)の変更に合わせて、メンテナンスコストも大きくなりますし、フレイキーなテストも多く発生します。

テストピラミッドのように、ほかのテストレベルもうまく合わせて自動化しなければ、テストのコストや不信感が膨れ上がり、テスト自動化の魅力は次第に失われていくと思います。

まとめ

本記事では、私のなかでよく思い当たる8つのアンチパターンをご紹介させていただきました。実際の現場には、本記事で紹介した以外にも問題は沢山あるので、アンチパターンはまだまだ沢山あると思います。テスト自動化の推進において、何が障害になるのかを考える際に、何かしらのヒントになれば幸いです。

宣伝

テスト自動化を導入してみたけれど、期待通りの成果が得られずにお困りではありませんか？現在の品質やテスト工程に何かしらの疑問や問題はありませんか？
そんな時は是非、窓口までお気軽にお問い合わせください。
お客様の要望をヒアリングして、最適なテストプロセスとテスト自動化のご支援をいたします。

開発・テストプロセス標準化 サービスのご紹介| 株式会社SHIFT
テスト自動化支援 サービスのご紹介| 株式会社SHIFT

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

執筆者プロフィール：矢野崇
SHIFTの在宅勤務エンジニア第一号。QAや自動化、可視化は好きだが、テストは受験戦争のトラウマがありあまり好きではない。より良いモノをより良くツクルためにはどうすればいいのか模索している。最近注目しているものはヴィパッサナー瞑想。

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/