戦略から考えるテスト自動化

先日、mablのコミュニティイベントに登壇させていただき、テスト自動化の成功事例を踏まえて、SIのテスト自動化について発信させていただきました。

この記事では、SI以外にも通じるかもしれない、テスト自動化アプローチをシェアさせていただきます。

サマリ

テスト自動化の導入アプローチというと、「スモールスタート」という触れ込みで語られることが多いように思います。

しかし、現実には、スモールスタートを都合よく解釈し、痛みを避けながら自動テスト導入を進めた結果、全く進まなかったり、途中で頓挫したり、表面的な導入で満足してしまう現場が見受けられます。

この記事では、テスト自動化導入の異なる切り口として、「戦略から考える」というアイデアを説明させてください。

結論：テスト自動化は戦略から考えてほしい

テスト自動化導入を、戦略検討から始めてみていただきたいです。

戦略から計画に落とし、ステークホルダと交渉し、そこで初めて技術的な手段を考え、最後にテストを実装するという、トップダウン思考の進め方にしていただきたいです。

例えば、「どの品質レイヤを自動化するのか」「それによって何が得られるのか」ということから始めるということです。

例えば、「とりあえずxUnitを入れてみる」「試しにcypressを書いてみる」ということからは始めないということです。

【戦略から考えるイメージ】

前提

テストが自動化された状態では、手動テストの一部や大部分が自動テストに代替されます。

その結果、ビジネス部門も含めたチーム全体に作用するビジネスバリューを得ることができます。プロダクトやチームによって得られる恩恵は異なります。

• 恩恵例1：リグレッションテスト実施のコスト減によりスプリントをより短い期間で分割しやすくなる
• 恩恵例2：バグ混入を早期に検知できて組織の生産性が向上する（Shift-Left）ことで、開発にアジリティが生まれる
• 恩恵例3：手動リグレッションテストのための環境整備や環境確保が不要となり、並行開発がしやすくなる

私は、自動テスト導入に成功した状態とは、上記のように「何らかの形で、チームにとって自動テストが開発プロセス上不可欠となり、開発の世界観が変わった状態」であると思っています。

言い換えれば、例えば「個別のエンジニアが思いつきで自動テストを書いている」というフェーズは、まだテストを自動化できている状態ではないと考えます。

なぜなら、その状態では、自動テストはまだチームの品質管理上の拠り所にもなっておらず、チームの手動テストも削減しておらず、チームの世界観を変えていません。これは、自動テストのビジネスバリューを最大限に引き出している状態ではないためです。

背景

テスト自動化とはチームの世界観を変えることであるという上記前提に立ったとき、テスト自動化の導入のためには、テストコードやCI/CDのような「技術的で楽しいところ」以外にも、重要な要素があります。

• 要素1. テスト自動化の戦略
  • リスク例1：自動化目的が最適でなく、チームにとって最適な品質管理基準やテストプロセスにならないことで、ビジネスバリューを引き出しきれない
  • リスク例2：チーム内の自動化目的が統一されておらず、自動テストが恣意的になり、QA上の拠り所にできず、結局手動テストを削減できない
• 要素2. ステークホルダとの調整
  • リスク例1：モダンな開発パラダイムに理解の浅いPM/PLが、自動テストによる手動テストの代替を承認しない
  • リスク例2：業務部門などや情シスなど、非エンジニアのステークホルダも同様

こうした要素は、技術的な問題と同じくらいクリティカルです。

実際にリスクが顕在化すると、テスト自動化のビジネスバリューを引き出しきれなくなったり、テスト自動化の導入が不可能になります。

例えば、業務部門が自動テストに対してNoと言った時点で、テスト自動化の導入が頓挫することは想像しやすいかと思います。どんなに技術を突き詰めていたとしても、その努力は無に帰すことになります。

したがって、テスト自動化の導入というプロジェクトを成功させる上では、技術に加え、こうした要素についても早期にカバーしながら進める必要があります。

課題認識

しかし、テスト自動化にあたりツールや技術から着手してしまうと、テスト自動化の戦略やステークホルダとの調整といった要素をカバーすることが難しくなります。その原因は次のとおりです。

• 原因1：ツールや技術といった、私たちエンジニアにとって「楽しいところ」にのめりこんでしまい、コンセプトワークや計画詰め、交渉といった痛みに向き合う気がおきない
• 原因2：ボトムアップなアプローチになるため、テスト自動化導入のタスクや論点の全体像が見えなくなり、やるべきことが分からなくなったり、表面的な導入で満足してしまう

特に、スモールスタートを謳って技術から着手し、上記のパターンに陥ることが多いように見受けられます。

スモールスタートとは、立てた仮説の本質やリスクを、クイックに小さなコストで検証する手段であって、「やりやすいところだけつまみ食いする」ことではないと思います。

既存チームへの自動テストの導入は、大変なプロジェクトです。大志がない状態で技術から着手しまうと、やはりどこかで心が折れてしまい、大きな結果には繋がりづらいと思います。

ソリューション

技術に加え、テスト自動化の戦略やステークホルダとの調整といった要素もバランスよくカバーするためには、次のようなステップで、トップダウン思考で進めることが合理的と考えます。

• ステップ1. テスト戦略や品質管理基準を考える
• ステップ2. ステークホルダと交渉する
• ステップ3. テスト自動化を実現する

「普通では」と思った方もいらっしゃるかもしれませんが、そのとおりです。

ビジネスの世界では、立案 👉 レビュー 👉 実行といった順序で施策が進むことは普通です。私たちエンジニアの自動テスト導入も、真っ当にそのプロセスを踏むことで、成功率が高まると考えています。

もちろんスモールスタートも構いませんが、上記のステップをつまみ食いするのではなく、自動化対象やテスト種類を小さくすることでスモールスタートすべきです。

• 例1：初回はユニットテストだけを導入する
• 例2：初回は認証サービスだけ対象とし、他サービスは対象外とする。

このように進めることで、以下のように先述の失敗パターンに嵌ることを防ぎ、テスト自動化導入の成功率を高められます。

• 戦略から順に考えることで、チームが目指す世界観を意識し、ビジネスバリューを最大限に発揮できるテスト戦略をゼロベースで考えることができる
• ステークホルダとの交渉リスクに早期に着手することができ、かつ戦略検討が完了していることで整然と説明しやすい
• 技術を最後に回すことで、私たちエンジニアが上記のタスクから逃げ出し、技術に耽ることを予防する

まとめ

戦略検討から始めていただくことで、リスクを予防しながら、最大限にテスト自動化のビジネスバリューを引き出すことができます。

技術というご褒美が最後に待っていれば、エンジニアにとって気の進まない計画や調整といった問題も、速やかに片付けようという気持ちになれるのではないでしょうか。

もちろん、このようなプロセスを経る必要ないチームもあると思います。裁量の大きい方がトップダウンで進める場合や、ビジネス部門と開発部門が分かれていない場合、エンジニアが数名しかいない場合などです。

もし周りのチームがテスト自動化の導入に失敗していたり、事業ドメインがSIであったり非Tech企業の自社サービス開発だったりする場合には、このプロセスを参考にしていただけると良いかなと思います。

追伸1

今回の記事は、ボリュームの都合上、アプローチの話に終始してしまいました。

「テスト自動化の戦略」や「品質管理基準」という言葉を本文で用いておりますが、こうした用語は便宜上のもので、特定の専門用語や概念を指しているわけではありません。したがって、説明が不十分と考えています。

後続の記事で、具体的にどういうことを考えたらいいのか、より技術的な内容に踏み込んでナレッジをシェアしたいと思います。

追伸2

この記事はMagicodeから移転しました。
2022年7月あたりの記事となります。

よければTwitterもフォローお願いします！
@sumiren_t