なぜテストを自動化するのか

自動テストは単に仕組みやツールを導入しただけでは思ったような効果が得られないと考えています。そこで、自動テストの理解を深めてその恩恵を得られるように、テストを自動化するモチベーションを言語化してみました。

Transcript

1. なぜテストを自動化するのか
2. 目次 1. ソフトウェアテストとは？ 2. テストの自動化とは？ 3. なぜテストを自動化するのか？ 4. 結論
3. １．ソフトウェアテストとは？
4. 国際ソフトウェアテスト資格認定委員会(ISTQB)の定義 ”ソフトウェアテストは、欠陥を発見し、ソフトウェアアーティファクトの品質を評価するため の一連の活動である。” ”「テスト」と「品質保証」（QA）という用語を同じように使う人が多くいる。しかし、テストと 品質保証は同じではない。テストは品質コントロール（QC）の形式の 1 つである。” ISTQBテスト技術者資格制度 Foundation Level シラバス https://www.jstqb.jp/syllabus/
5. ソフトウェアテストとは？ • ソフトウェアを基準を満たした製品とするための品質コントロールの１つ
6. これまでの品質は「仕様通り」「バグがない」を目指す 開発スピードは上がっている…品質はどうする？ スピードと品質を両立させるためのプロダクト開発の進め方とは https://speakerdeck.com/nihonbuson/agile-and-quality
7. テストは開発の最後の工程 要求仕様 設計 実装 テスト リリース
8. 開発の大規模/複雑化、不確実なマーケット ”ソフトウェアが社会の様々な要求に答えていくにあたって、急速に大 規模化・複雑化していきました。（略）。実際に価値のあるソフトウェア の実装よりも関係調整やドキュメント化といった工程に時間を使い、 大規模になるほど失敗も多くなってきました。” ”ソフトウェアが対象とする市場も大きく様変わりしてきました。（略）。 マーケットがプロジェクト期間中に大きく変動するということが、頻繁 に発生するようになりました。” エンジニアリング組織論への招待 https://gihyo.jp/book/2018/978-4-7741-9605-3
9. バグゼロ ≠ 高品質 • 開発の大規模化・複雑化により、バグゼロを目指すための時間やコストがより膨大 になった • 多くの時間やコストをかけてバグゼロを実現しても、それがマーケットに受け入れら れるか分からなくなった たんに仕様への適合や欠陥の少なさだけを目指すのではなく、より本質的な価値を追 求するための考え方やアプローチが必要になった。
10. これからの品質は「価値の向上」を目指す 開発スピードは上がっている…品質はどうする？ スピードと品質を両立させるためのプロダクト開発の進め方とは https://speakerdeck.com/nihonbuson/agile-and-quality
11. テストは「最後の工程」から「積極的な活動」へ ”モダンなソフトウェア開発では、開発の生産性を高め、高品質と 高スピードを両立する、攻めの活動としてテストを活用する場面 が増えています。” 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3
12. ソフトウェアテストとは？ • ソフトウェアを基準を満たした製品とするための品質コントロールの１つ • 不確実な時代に、高い品質/スピードで試行錯誤を繰り返すための活動の１つ
13. 現代の開発におけるテストのあり方 さまざまな戦略におけるテスト
14. 現代の開発におけるテストのあり方１ ～Wモデル～ Vモデルの各活動に、テスト活動を並行して実施して、そこからのフィードバックで開発工 程の品質確保を目指す。 V字モデルとは？特徴やメリット・デメリットを解説 https://www.veriserve.co.jp/helloqualityworld/media/20240828001/
15. 現代の開発におけるテストのあり方２ ～アジャイル テスティング～ 『Agile Testing Condensed Japanese Edition』 https://leanpub.com/agiletesting-condensed-japanese-edition
16. 現代の開発におけるテストのあり方３ ～DevOpsと継続的テスト～ DevOpsは開発（Development）と運用 （Operations）を組み合わせて命名されたソフト ウェア開発手法。技術的な側面だけでなく、運用 部門、品質保証部門も重要な構成要素とする考 え方。 継続的テスト /ホリスティックテスト プロダクト開発サイクルの全ての段階で、プロダク トを間断なくテストする。 継続的テスト（continuous testing）とシフトレフトな活動をアジャイルにどう取り入れるか？ https://agilejourney.uzabase.com/entry/2024/06/25/103000
17. まとめ • ソフトウェアテストは、基準を満たした製品とするための品質コントロールの１つ • 以前は検品のために最後の工程として実施されることが多かったが、開発の大規 模/複雑化やマーケットの不確実性を背景に、品質やテスト捉え方が変化した • 時代に適合するさまざまな開発戦略の中で、ソフトウェアテストは高い品質/スピー ドを実現するための積極的な活動としての役割も担う
18. ２．テストの自動化とは？
19. 自動テストとは？ 自動化されたテスト活動を指す言葉で、次のような実行を自動化したものを指すのが一 般的。 • • • テストの事前条件の実現 テストの実行 実行結果と期待結果の比較 ※ 上記に限らない、各種活動の自動化を指す場合もある。
20. テストの２つの側面：確認と探索 • • 確認（Checking） ◦ 「ある条件で実行したとき、結果が◯◯になる」のような、 期待値との一致 を確認する ◦ 事前に用意したシナリオに沿って実行する必要があるため、 機械が得意な領域 探索（Exploring） ◦ 知識や経験をもとに、不具合がないか探索する ◦ 創造的な活動なので、 人間が得意な領域
21. 自動テストのレベル – ユニットテスト • プログラムの部品（モジュール）レベルを動かすテスト • 開発者が機能の実装と並行して作成する • 実行速度と正確性に優れる • 自動テスト全体の多数を構成する • 一般的に既存のテストフレームワーク（xUnit等）を使う
22. 自動テストのレベル – 統合テスト • 複数のプログラムの部品（モジュール）を組み合わせて動かすテスト • プロダクトのアーキテクチャ構成などによってバリエーションがある • Webサービスでは、よくHTTPリクエスト/レスポンスが対象になる • 主に開発者が作成する • より広い範囲を検証できるが、それよりは遅く、不安定になる
23. 自動テストのレベル – システムテスト • すべての機能が揃った状態で実施されるテスト • 自動化はプロダクトの種類に応じて変わる • 定番のツールがある場合はそれが用いられる（ない場合は自作する） ◦ Webシステムだとブラウザを操作するツールが定番 • 開発者が作成することもあるが、選任のメンバーが作成することもある • システム全体を検証できるが、さらに遅く、不安定な部分も多くなる ※ 文献によっては、UIテストやEnd to End（E2E）テストを扱っている場合もある
24. 自動テスト構成の例 テストピラミッド（Test Pyramid） https://martinfowler.com/bliki/TestPyramid.html テストトロフィー（Test Trophy） https://kentcdodds.com/blog/write-tests
25. 開発者テスト ”自動テストを積極的に活用するテストアプローチに開発者テスト があります。開発者テストは、プログラマがプログラミングの品質 やスピードを改善するために自動テストを呼吸するように活用し ます。” 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3
26. CI/CDと自動テスト 継続的インテグレーション（Continuous Integration）とは、 ”チェックインの際に各変更を検証した上で、コードの変更を高い 頻度で結合してくプロセスのことです。” そして、継続的デリバリー（Continuous Delivery）とは、 ”動作するソフトウェアを、プロジェクトにとって意味のある限り迅 速に、いつでも安全にユーザーにリリース可能な状態にしておく ソフトウェア開発手法”のことです。 自動テストは、このCI/CDプロセスにおける主要なタスクとして、 コードが意図したとおりに動作するかを検証します。 入門 継続的デリバリー https://www.oreilly.co.jp/books/9784814400690/
27. CI/CDと自動テスト リント テスト ビルド パブリッシュ デプロイ
28. まとめ • 自動テストとは、テストの準備や実行、結果の検証などを自動化したテスト活動の こと • 自動テストの構成は主にユニットテスト、統合テスト、システムテストといったテスト レベルで構成される • 自動テストはテストの専門家だけでなく、プログラミングにおいて品質やスピードを 改善する目的でも活用される • 自動テストは、ソフトウェアを迅速かつ安全にリリースするためのCI/CDにおける主 要なタスクになっている
29. ３．なぜテストを自動化するのか？
30. Googleのソフトウェア開発と運用パフォーマンスの研究
31. 質とスピードの関係 パフォーマンス レベル 変更の リードタイム デプロイの頻度 変更時の 障害率 復旧までの 時間 回答者の 割合 Elite １日未満 オンデマンド 5% 1 時間未満 19% High １日～１週間 １日１回～週１回 20% 1 日未満 22% Medium １週間～１か月 週１回～月１回 10% 1 日未満 35% Low １か月～６か月 月１回～６ヶ月に１回 40% 1 週間～1 か月 25% DORA Research: 2024 https://dora.dev/research/2024/
32. 質とスピードの関係 パフォーマンス レベル 変更の リードタイム デプロイの頻度 変更時の 障害率 復旧までの 時間 回答者の 割合 Elite １日未満 オンデマンド 5% 1 時間未満 19% High 22% 127倍 182倍 8倍 2,293倍 Medium Low 35% １か月～６か月 DORA Research: 2024 https://dora.dev/research/2024/ 月１回～６ヶ月に１回 40% 1 週間～1 か月 25%
33. 「組織のパフォーマンス」の予測材料 組織のパフォーマンス：収益性、市場占有率、生産性 ”ここ数年の分析で、ハイパフォーマーのこうした基準でのパフォーマ ンスの測定結果がローパフォーマーのそれを上回る傾向にあり、両 社の対比は一貫して2倍を超えている。この傾向が示唆するのは 「組織のソフトウェアデリバリのケイパビリティ（能力、機能）は、組織 に競争上の優位性をもたらす」という点である。” LeanとDevOpsの科学 https://book.impress.co.jp/books/1118101029
34. テスト自動化と組織のパフォーマンス Westrum推奨の 組織文化 職務満足度 テストの自動化 デプロイの自動化 継続的インテグレーション バージョン管理 ・・・ 継続的な デリバリ ソフトウェア デリバリの パフォーマンス 組織全体の パフォーマンス 帰属意識 修正作業 の減少 デプロイ関連 の負荷の軽減 LeanとDevOpsの科学 ”図A.1 本研究の全体の構成”(p.242)から抜粋 https://book.impress.co.jp/books/1118101029 バーンアウト の軽減
35. テスト自動化とITパフォーマンス ”「テストの自動化」は継続的デリバリの支柱の１つであり、その関 連プラクティスのうち、我々の分析でITパフォーマンスの予測尺度 となりうることが判明したのは次の２つである。” • • 信頼性の高い自動化テストの実施 開発者が主体となった承認テストの作成・管理、および承認 テストの容易な複製・修正 LeanとDevOpsの科学 https://book.impress.co.jp/books/1118101029
36. 品質へのアプローチ 動く ①まず仕様通り動 くものを作る ②そして、品質を 向上させる 動かない 低品質 高品質
37. 品質へのアプローチ – 手動テストのみ 動かなくなる リスクも伴う 動く 動かない 妥当なスピードで テストができないと ここに留まるしかない 低品質 高品質
38. 品質へのアプローチ – 自動テストあり 動く テストですぐに検知でき れば、自信を持って高品 質へ向かえる 動かない 低品質 高品質
39. テスト自動化のコスト • 学習コスト ◦ ◦ ◦ ◦ • • • ソフトウェアの品質やテストに関するスキル テスト自動化やソフトウェアエンジニアリングに関するスキル 自動化のためのツールやプラットフォームに関するスキル 製品の設計（テストの容易さ）に関するスキル 自動テストの作成と保守 適切な投資のための分析や計画 組織文化の醸成 自動化されたテストがその効果を発揮するには、単に自動化のツールを導入するだけ ではなく、効果的な運用のためのスキルや、継続するための取り組みが必要となる。
40. 組織に自動テストを書く文化を根付かせる戦略（2024秋版） https://speakerdeck.com/twada/building-automated-test-culture-2024-autumn-edition
41. 朗報：パフォーマンスは業界と関係しない ”DORA の調査において、業界がソフトウェアデリバリー パフォー マンスの予測因子となることはほとんどありません。高いパフォー マンスを発揮するチームは、あらゆる業種で確認されています。 これは、さまざまな業界に固有の課題がないことを示しているわ けではありませんが、ソフトウェア デリバリー パフォーマンスに関 しては、どの業界にも、特有の障害または強みがあるようには見 えません。” ※ この分析は数年の研究で一貫して変わっていない DORA Research: 2024 https://dora.dev/research/2024/
42. まとめ • ソフトウェアデリバリーのスピードと品質が相関する • 組織のソフトウェアデリバリー能力は収益性、市場占有率、生産性といった競争優 位性をもたらす • 継続的なデリバリーのプラクティスであるテスト自動化は、組織全体のパフォーマン スを支えるプラクティスの１つ • 自動化された信頼できるテストによって、高品質へのアプローチが後押しされる • テスト自動化は、それを実現するためのスキルや、持続性への投資によって、素早 く変化していくための力になる
43. ４．結論
44. • • • • • • • 不確実性の高い時代において、テストは単に「仕様通り」を確認する工程ではなく、 価値の向上を目指すための活動と捉えられている 自動化されたテストは、CI/CDプロセスなどのプラクティスとともに、製品を素早く安 全に提供するための構成要素になる 高いパフォーマンスを実現する組織は、スピードと品質が両立している 製品デリバリーの能力は、企業の業績（収益性、市場占有率、生産性）と関連が示 されている 開発者が主体となって、信頼できる自動テストを構成することが、製品デリバリーの パフォーマンスの予測材料となる テスト自動化はコストの削減ではなく、素早く変化を続ける力を得るための投資 たんにツールや仕組みを導入するのではなく、選択肢として適切に活用することが 重要
45. How do you like Testing?
46. 自己紹介 Atsushi Okui (@blue32a_jp) ソフトウェアエンジニア / Webアプリケーション エンジニア / PHPer 関心：設計、コード品質、リファクタリング、テス ト、モデリング