この記事は テスト自動化の成功事例を語ろう by T-DASH Advent Calendar 2023 のエントリー記事です。が、内容は成功事例というより私自身のテスト自動化の成功事例を通した「失敗しないためのTips」の話です。
そもそもテスト自動化をやるぜぇ〜という経緯や背景は企業によって様々で、他社の成功事例がそのまま流用できる保証は一切ありません。しかし、失敗談はどの会社も「あるある」とうなずくものばかりです。
ということは、失敗してきたことを意識しながらテスト自動化プロセスを進めることである程度成功に近づけることができるのではないかと考えることができそうです。
大事なこと（結論）
まず結論だけ箇条書きします。これだけ意識しておけば少なくとも失敗はしません。（成功するとは限りません）
- 業務フローにテスト自動化を組み込め
- 他人を巻き込め
- 計測せよ
- 属人化をなるべく排除すべし
- 「品質」という言葉の定義を組織で共有せよ
次章より実際どういうことなのかを説明していきたいと思います！
業務フローにテスト自動化を組み込め
ここでいう業務フローとは、下図のようにプロダクトを作ってデリバリーするまでの流れについてを示しています。その中に テスト自動化を組み込んでしまいましょう ということです。
言葉で言うのは簡単なのですが、実際は図にも示しているとおり別の問題が発生します。
最初は強制でもいいからフローを変える
「他人を巻き込め」で詳細は記述しますが、基本的に一般エンジニアができることというのは自分の業務周りの整備しかできません。
なので自分の権限の及ぶ範囲であれば、強制的に変えてしまっても良いのではないかというのが私の回答です。
例えばエンジニアであれば、単体テストを自動テストとしてCI/CDに組み込んでPRごとにテストの成否をマージ可否として判定させるなどは比較的用意に取り組める事例でしょう。
しかし結合テスト以降においては、QAやエンジニアが手動でやってるテストを自動化してしまえばOK！という単純な話ではありませんので、このあたりは他人の力を全力で借りましょう。
他人を巻き込め
業務フローを非役職者が変えることはほぼ不可能。上司に頼め
基本的に組織（業務）改革はトップダウンでしか実現できません。なぜなら業務プロセスを明確に把握しそれがビジネスへどう影響し何をリスクとして捉えるべきかを考えることができるのは、基本的に組織や業務について俯瞰的に考えることのできる（考える必要のある）役割の人しかできないためです。だいたいはマネージャー職以上かテックリードな人です。
(参考記事):
テスト自動化にも同じ問題があり、エンジニアチームやQAチーム主導でテスト自動化を進めると、そのうち「XXチームでやってるあのテスト何？」「そんなのやってたんだ」「うちでも同じことやってます」「必要なんですか？」など認知の問題や衝突が発生します。
チームの活動の共有会とかが定例やイベントとして存在していれば少しはなんとかなるかもしれませんが、上司に取り合って「なんとかして」と戦略的に取り組む方が効率的でしょう。
しかしながらエンジニアは思うわけです。「なぜ今より良くしようとしている取り組みに対して定量・定性な評価を用いて必要性を説明し、承認を得てさらに他チームのエンジニアに理解を求めなければならないのか」と。
テスト自動化の情熱 ＞＞＞ 越境（立場・役割・役職など） という不等式が成り立てば解決可能ですが、自分の業務をこなしながら役割や役職を越境するのは簡単ではありません。ということで素直に上司の力を借りるのがベターです。
計測せよ
エンジニアリングの生産性やサービスのオブザーバビリティなどでもFourKeys、DORA、SPACE、SLI、SLOなどなど指標を表すキーワードがあります。
テスト自動化にも何かしらの指標を準備しないと、「何のためにテストを自動化しているのか」を説明することも成果の是非を判断することもできません。
個人的に指標にしていたのは以下です。
-
総テスト時間
自動テスト全体の開始〜終了までにかかった時間。これが手作業のテストよりも多くなってしまった場合はテスト自動化の改善を検討する（つまりこれは現在のテスト工程のテスト時間も先に計測しておくべきということでもあります）。 -
コードカバレッジ率
特に単体テストでは気にしても良いかなという基準。100％を目指すというよりは、「ここはテストできないな（書くの大変）」というのを認識共有する感じで使ったほうがベター。 -
削減できた手動テスト数
手作業でやっていたテストをどれくらい削減できたかの指標。
特にリグレッションテストは削れば削るほど将来的なメリットが出てくるはずなので、個人的には狙い目。 -
コスト増加率
コストが下がるのがベストですが、テスト自動化ツール（MablやAutify）でカバレッジ率の増加と手動テスト削減を続けていくと、大量のテストを生産してしまいコストが逆転するという現象がまれに発生します。人手でコストを抑えることができる部分とそうでない部分を見極められるようにしておきましょう。
指標の利用例
簡単な例を示します。数値は適当ですので参考にはならないと思いますが、どのような課題と改善を行えばいいかのヒントにはなっているのではないかと。
よくある失敗談でとしては、数人で自動テストツールを使っていたが、テストコードの修正や変更、テストコードの増加などで稼働コスト（人件費、サービス利用費、メンテナンス費など）が上がってしまい本末転倒になったという話です。
テストには直接関係ないですが、経済学の世界でも「損益分岐点」という言葉があるように、どこまでコストをかけても良いのかというコストと、テストコード量との関係性みたいなのはグラフで可視化しておくと吉です。
| 指標 | A社 | B社 | C社 | 問題点 | 改善点 |
|---|---|---|---|---|---|
| 総テスト時間 | 12時間 | 8時間 | 15時間 | A社: テスト時間が長すぎる B社: 問題なし C社: 非効率なテストプロセス |
A社: テストケースの最適化、並行実行の検討 B社: - C社: 自動テストの見直し、不要なテストの削減 |
| コードカバレッジ率 | 85% | 70% | 95% | A社: 問題なし B社: カバレッジ不足 C社: 過剰なテスト |
A社: - B社: 未テストコード領域の特定、テストケースの追加 C社: 重要度に応じたテストの調整 |
| 削減できた手動テスト数 | 100 | 50 | 200 | A社: 問題なし B社: 手動テスト依存度が高い C社: 問題なし |
A社: - B社: 自動テストの拡充 C社: - |
| コスト増加率 | 5%増加 | 2%減少 | 10%増加 | A社: テスト量の増加によるコスト上昇 B社: コスト効率良好 C社: 大量のテストによるコスト逆転 |
A社: コスト効率の良いテスト戦略の検討 B社: - C社: 不要なテストの削減、効率化 |
属人化をなるべく排除すべし
テスト自動化で課題になりやすいのが「属人化」です。
テスト自動化に限らず、エンジニアチームが0からプロダクトを作ろうとするとき、「できる人」に依存するのわりとよくある話かなと思います。
この場合、他のメンバーはその人の書くコードの品質や設計に依存することとなり、仕組みやコーディングのノウハウををどれだけメンバー間で共有できるかがポイントになってきます。
中期的な取り組みとして、チームの全体平均の取りやすい施策を選択するほうがベターかと考えます。
例えばRubyの経験者が多いのであればRuby+Capybara+Selenium、Javascriptの経験者が多いのであればTypeScript+Playwright。プログラミング経験者が少ないのであればAutifyやSeleium、Mabl、T-Dashなどの自動化ツールを直接使うという感じです。
ただし、自動化ツールを使った場合も1人チームでは結局属人化してしまいます。誰かの専任制みたいなプロジェクトを発足させるのではなく、なるべくチームで取り組めるようにしたほうがよいでしょう。
また、属人化が防げるポイントとしては前述の通りリグレッションテストがおすすめです。リグレッションテストはサービスが続く限り半永久的に何度も繰り返しテストをするので、慣れやすいですし基本的にテスト作業をやったことのある人にとっては自動化のコードと手作業での手順との比較がしやすいためです。
「品質」という言葉の定義を組織で共有せよ
さて、作業フローも変えることができた、計測も始めた、属人性もなくなった……これで完璧でしょうか？
いえいえ、最後に残るのは 「品質とは」 という重要な課題です。
企業や組織、チームによって「品質向上」の意味は変わります。
ある企業では「テスト時間の短縮」かもしれませんし、ある企業では「リリース時のプロダクトの不具合検知の減少」かもしれません。
品質という言葉はかなり独り歩きしやすく、人によって最初に思い浮かべる具体的事象がバラバラです。
エンジニアが考える品質と、QAが考える品質も微妙に異なります。
エンジニアは単体テストコードを書いてある程度の機能の品質をホワイトボックステストで担保しようとし、結合テスト（E2E）としてQAがブラックボックステストで機能全体の品質を担保しようとするわけです。
ここでもメチャクチャ苦労して書いた単体テストコードと、これまためちゃくちゃ苦労して作ったE2Eテストがあったとして、どちらもテストで担保しようとしているモノが同じである場合、過剰品質になることもあります。
テスト自動化にあたっては、テスト全体の設計（単体〜総合）を意識し、その内容を共有できることが望ましいでしょう。
そういう意味では、QAとエンジニアという垣根も取っ払い、単体テストのコードが理解できるQA、E2Eテストを把握しているエンジニアという立場が存在しているかどうかも1つの指標になるかもしれませんね！
最後に
この記事を通じて、テスト自動化の成功事例だけでなく、失敗を避けるための重要なポイントに焦点を当てました。私の経験に基づいて、業務フローへの組み込み、他人の巻き込み、計測、属人化の排除、そして品質の定義の共有という5つのキーポイントを紹介しました。
特に品質の共通認識は、テスト自動化の取り組みを組織全体で支える基盤となります。テスト自動化は単にプロセスを効率化するだけでなく、組織の品質意識を高めるための手段でもあります。それには、全員が品質に対する共通の理解を持つことが不可欠です。
テスト自動化は技術的な問題だけでなく、組織的、文化的な側面も重要であることを忘れてはなりません。組織内でのコミュニケーション、協力、そして共通の目標に向かって進む姿勢が、テスト自動化を成功に導く鍵となるでしょう。
T-DASH Advent Calendar 2023の一環として、この記事がテスト自動化の取り組みに関わる全ての方々にとって有益な情報源となることを願っています。
なお、私はこの後仕様が変わってしまった画面でテストの成否が不安定になってるテストコードを書き直す旅に出る予定です……。