チームのテスト力を鍛える

Transcript

1. チームのテスト力を鍛える 井芹 洋輝 『ソフトウェアテスト徹底指南書』に学ぶ、品質とスピードを高める実践アプローチ 2025/9/16
2. 自己紹介 ⚫経歴 • 開発者、テストエンジニア、コンサルタント、QAエンジニアと様々な立場で 様々なプロダクトのソフトウェアテスト業務に従事 • 現在は車メーカーでQA/テストテックリードを担当 • JSTQB技術委員、テスト設計コンテストU30クラス初代審査委員長 ⚫著作・講演 • 「ソフトウェアテスト徹底指南書」（最近発売） 「テスト自動化の成功を支えるチームと仕組み」 「シフトレフトテストを支える現代的なテスト設計」 「テストの視点を活用したTDDアプローチの検討とその検証」（共著）など
3. ソフトウェアテスト徹底指南書 ⚫2025/6/17 発売 ⚫6月増刷決定 6月から連続で技評電子書籍月売上No.1維持 ⚫開発チームに求められるテストを総合解説 ⚫対象読者は開発チーム ⚫テストの総合力・基礎力を強化できる一冊
4. 開発チームのテスト力を 鍛える必要性
5. 現代的なソフトウェアプロダクトの様相 ⚫プロダクト形態がサービス化 • XaaS（SaaS、PaaS）など。 • パッケージや組込みも、継続的な改善・運用で顧客満足を支える ⚫開発ライフサイクルが長大化 • リリースして終わりではなく、サービスとしての継続運用や、継続的に改善を 行って、プロダクト価値をアップデートしていく →同じ開発チームが継続的にプロダクトを運用・改善。 チームの総合的な開発力を鍛えてプロダクトの成功を支える
6. 現代的なソフトウェア開発において 顧客満足を支えるチームの総合的な開発力 ⚫品質実現 ⚫開発のスピード • ユーザと開発の改善サイクルを高速化。迅速にプロダクト価値を提供 • 有限な開発リソースでより高度な品質・迅速な開発を実現 ⚫開発のレジリエンス（困難や問題に対するしなやかさ・対応力） • ユーザの不満点・不都合を迅速に是正。よりハイリスクを許容 ⚫開発持続性 • 継続的にプロダクト価値を提供 • 持続的なプロダクト改善を実現
7. 総合的なビジネスパフォーマンスは 開発チームの総合力に連動 ビジネス パフォーマンス エリート 高い 中間 低い 変更リードタイム 1日未満 1日～1週間 1週間～1か月 1か月～ デプロイ頻度 いつでも （1日複数回） 1日1回～ 1週間に1回 1週間に1回～ 1か月に1回 1か月に1回～ 変更失敗率 5% 20% 10% 40% 障害復旧時間 1時間未満 1日未満 1日未満 1週間から1か月 DORA Accelerate State of DevOps 2024 現代的なソフトウェア開発の成功のためには 品質実現だけではなく、開発チームのスピード、レジリエンス、 開発持続性の総合力強化が必要
8. テストで支えるべきチームの総合力 ⚫ソフトウェアテストでも 開発チームの品質実現/スピード/レジリエンス/開発持続性を サポートするアプローチが求められる ⚫ソフトウェアテストは、品質重視で他を犠牲にしてしまうアプローチが 見られるので留意が必要 ⚫避けるべきトレードオフのアプローチ • 独立性の高いテスト組織にテストの責務を集中 • 特定の品質ゲート（例えばシステムテスト工程）を重厚化
9. チームの総合力を高めるテストアプローチ ⚫開発チーム全体でテストを支え改善するアプローチが求められる テスト担当に閉じた努力では実現が難しい • チーム全体の連携 • 開発とテストの協働 • チーム全体でのテスト戦略の推進 • チームの開発力強化 • チームの基盤インフラ整備
10. 今回紹介するテストアプローチ ⚫テスト容易性確保×品質のシフトレフトを組み合わせる テストアプローチ ⚫ハイリスクなプロダクトで品質・開発スピード・開発のレジリエンス・開 発持続性を共立させるためにしばしば推進されている
11. テスト容易性
12. テスト容易性（試験性、テスタビリティ） ⚫テストしやすさについての内部品質特性 品質特性 内容 具体例 観測容易性 テスト対象の観測のしやすさ エラーログの充実度 制御容易性 テスト対象の操作のしやすさ APIの充実度 セットアップ容易性 テストのセットアップのやりやすさ コンストラクタの単純さ 実行容易性 実行の容易さ テスト実行のブロック要因の少なさ 分解容易性 テスト対象の分割・置換の容易さ 接合部の充実度 網羅容易性 テストでの網羅のしやすさ デッドコードの少なさ 安定性 テスト対象の安定性・バグの少なさ 変更頻度の少なさ 環境構築容易性 テスト環境の構築のしやすさ 環境の冪等性 問題検出性 バグの特定のしやすさ 解析ログの充実度
13. 今回のテストアプローチのためのテスト容易性の改善 ⚫疎結合アーキテクチャの推進 • アーキテクチャレベルで、バウンダリやコンポーネント間の結合性を下げ、コ ンポーネントをまたいだ影響を抑止する • 追加変更の影響範囲をコンポーネントに閉じ込める • マイクロサービスアーキテクチャやマルチコアアーキテクチャなど ⚫品質リスクの分離の推進 • 疎結合設計によって、品質リスクを特定コンポーネントに閉じ込める リスク事象を対象特定コンポーネント以外から発生しないようにする • ハイリスクプロダクト開発でのSoC（Separation of Concerns）の原則はこの 一種
14. テスト容易性の改善の実現 ⚫仕様化・設計・実装工程へのテストの視座の注入 • Wモデル • 受け入れテスト駆動開発 • スリーアミーゴスによるレビュー • テスト戦略に基づいたアーキテクティング、テスト中心アーキテクチャ ⚫開発とテストの並行化 • テスト駆動開発、Cover ＆ Modify • CI/CDによるシフトレフトテスト
15. 品質のシフトレフト
16. 品質のシフトレフト ⚫品質エンジニアリング活動を早期から実施し、品質の確保・保証を 早期から行う。品質問題を予防・早期対策する QAへの注力 シフトレフト プロジェクトの進展 旧来の開発
17. 今回のテストアプローチのためのシフトレフト推進手段： 開発者テストの強化 ⚫開発者のテスト力を鍛える ⚫ユニットテスト、統合テストを充実させ、開発者テストで品質を確保。 TDD、CI/CDで早期実行を行う。追加・変更をサポートさせる ⚫テストピラミッドを実現する ユニットテスト 統合テスト UIテスト 速い・早い 『Succeeding with Agile: Software Development Using Scrum』
18. 開発者テストの習慣化 （開発の中でしっかり開発者テストが書かれるようにする）の実現 1. 習慣の定着 • ガイドラインやプロセスで納得を確保 • テスト駆動開発/Cover & Modifyの奨励 • モブプログラミング/ペアプログラミングによる習慣の伝播 • CI/CDによる自動テストの資産化 2. 習慣づけへの短期フィードバック • PRレビュー/MRレビューでの有識者によるチェック • CI/CDからのカバレッジのフィードバック • フォールトインジェクション/ミューテーションテストによる評価 3. 習慣づけへの中長期フィードバック • バグ流出を評価して改善サイクルをまわす
19. テスト容易性確保×シフトレフト によるチーム総合力強化
20. テスト容易性の改善と品質のシフトレフトによる総合力強化 低リスク 高 リスク 低 リスク ・・・ 疎結合設計で品質リスクの分離を実施 （例：接合部配備、信頼できるインターフェース手段採用、カプセ ル化/状態や副作用の局所化、インターフェースのシンプル化/ 契約による設計） シフトレフトの推進 •コンポーネントレベルのQAで品質担保 •高リスクコンポーネントは、ユニットテスト・統合テスト でバグだし・品質確認
21. テスト容易性の改善と品質のシフトレフトによる総合力強化 ⚫コンポーネントレベルで品質確保し、システムテストを簡略化 ⚫低リスクコンポーネントのリリースやスピード重視のテストに絞る ⚫総体として品質と開発のスピード・レジリエンス・持続性の共立実現 高リスク コンポー ネント 低リスク コンポー ネント 高リスク リリースの テスト 低リスク リリースの テスト
22. ソフトウェアテスト徹底指南書
23. ソフトウェアテスト徹底指南書 ⚫現代的な開発において、開発チームが備えるべきテストの技術・アプ ローチ・知識を総合的に解説している ⚫開発チームのテスト力を総合的に強化するのがねらい • テスト活動それぞれを強化 • テストの作成・改善、実行、マネジメント、テストウェア開発 • テストと他活動の連携を強化 • テストを支えるチームインフラの強化 • テストに強いチームの構築 • 上記テストに関わる様々な活動をうまく組み合わせ、統合的にマネジメント する仕組み整備
24. ソフトウェアテスト徹底指南書 アウトライン ⚫ Part I ソフトウェアテストと品質マネジメント • ソフトウェアテスト/品質マネジメント ⚫ Part II テストの戦略とプロセス • テスト戦略 • シフトレフトテスト/Wモデル • アジャイル開発、継続的デリバリ、 DevOps、SPLEを支えるテスト戦略 • テストプロセスの構築 ⚫ Part III テストの作成と実行 • テスト分析 • テストアーキテクチャ設計/VSTeP • テスト設計/テスト実装 • テスト環境構築 • テスト設計技法の活用 • テストの実行 • ユニットテスト/性能テスト/ 組み合わせテスト • リスクベースドテスト/探索的テスト /ユーザーストーリーテスト/静的テスト ⚫ Part IV 自動テストの活用 • 自動テストの開発 • 自動テストの品質作りこみ/フレーキーテスト/ 脆いテスト • 自動テストの評価/ミューテーションテスト • 自動テストの設計・実装の原則 • 自動テストコードのパターン・イディオム • 開発者テスト • テスト駆動開発 ⚫ Part V テストの計画とマネジメント • テスト計画 • テストのモニタリングとコントロール • リスクマネジメント • テストで求められる能力 • テストを担う組織の構築 ⚫ Part VI テストを支える基礎作り • CI/CDの構築 • バグ管理とバグチケット設計 • テスト容易性の確保 • テスト設計を支えるモデリング • テストを支える契約による設計 • ブランチ管理とテストの連携 • システムエンジニアリングで支えるテスト
25. ソフトウェアテスト徹底指南書 アウトライン ⚫ Part I ソフトウェアテストと品質マネジメント • ソフトウェアテスト/品質マネジメント ⚫ Part II テストの戦略とプロセス • テスト戦略 • シフトレフトテスト/Wモデル • アジャイル開発、継続的デリバリ、 DevOps、SPLEを支えるテスト戦略 • テストプロセスの構築 ⚫ Part III テストの作成と実行 • テスト分析 • テストアーキテクチャ設計/VSTeP • テスト設計/テスト実装 • テスト環境構築 • テスト設計技法の活用 • テストの実行 • ユニットテスト/性能テスト/ 組み合わせテスト • リスクベースドテスト/探索的テスト /ユーザーストーリーテスト/静的テスト ⚫ Part IV 自動テストの活用 • 自動テストの開発 • 自動テストの品質作りこみ/フレーキーテスト/ 脆いテスト • 自動テストの評価/ミューテーションテスト • 自動テストの設計・実装の原則 • 自動テストコードのパターン・イディオム • 開発者テスト • テスト駆動開発 ⚫ Part V テストの計画とマネジメント • テスト計画 • テストのモニタリングとコントロール • リスクマネジメント • テストで求められる能力 • テストを担う組織の構築 ⚫ Part VI テストを支える基礎作り • CI/CDの構築 • バグ管理とバグチケット設計 • テスト容易性の確保 • テスト設計を支えるモデリング • テストを支える契約による設計 • ブランチ管理とテストの連携 • システムエンジニアリングで支えるテスト 今回解説した 内容に関連深 い箇所
26. ご清聴ありがとうございました ⚫ Part I ソフトウェアテストと品質マネジメント • ソフトウェアテスト/品質マネジメント ⚫ Part II テストの戦略とプロセス • テスト戦略 • シフトレフトテスト/Wモデル • アジャイル開発、継続的デリバリ、 DevOps、SPLEを支えるテスト戦略 • テストプロセスの構築 ⚫ Part III テストの作成と実行 • テスト分析 • テストアーキテクチャ設計/VSTeP • テスト設計/テスト実装 • テスト環境構築 • テスト設計技法の活用 • テストの実行 • ユニットテスト/性能テスト/ 組み合わせテスト • リスクベースドテスト/探索的テスト /ユーザーストーリーテスト/静的テスト ⚫ Part IV 自動テストの活用 • 自動テストの開発 • 自動テストの品質作りこみ/フレーキーテスト/ 脆いテスト • 自動テストの評価/ミューテーションテスト • 自動テストの設計・実装の原則 • 自動テストコードのパターン・イディオム • 開発者テスト • テスト駆動開発 ⚫ Part V テストの計画とマネジメント • テスト計画 • テストのモニタリングとコントロール • リスクマネジメント • テストで求められる能力 • テストを担う組織の構築 ⚫ Part VI テストを支える基礎作り • CI/CDの構築 • バグ管理とバグチケット設計 • テスト容易性の確保 • テスト設計を支えるモデリング • テストを支える契約による設計 • ブランチ管理とテストの連携 • システムエンジニアリングで支えるテスト