テスト自動化の成果を どう評価し、どう次につなげるか 2022/11/17 QUES 井芹　洋輝 1

自己紹介 ● トヨタ自動車 　デジタルコクピットシステム開発室　テストチームテックリード ● JSTQB技術委員、テスト設計コンテストU-30クラス審査委員長 ● 開発者、テストエンジニア、コンサルタントなど様々な立場でテスト自 動化の導入・改善を手掛けてきました ● 今回は教条的な解説をベースに、口頭で自身の経験を織り交ぜながら解 説を進めたいと思います 2

この講演について ● アウトライン ○ テスト自動化によってどうなるのか ○ テスト自動化をどう評価するか ○ テスト自動化をどう次につなげるのか ● 対象とするテスト自動化： ○ ドメイン： ■ ウェブ、組み込み、アプリといった特定のドメインに依存しない知見 を解説します ○ テストレベル・テストタイプ： ■ 限定しません。 ユニットテスト～システムテストを含む、全般的な自動化が対象です 3

この講演について ● 運営者からのイベントのコンセプトに基づいて「テスト自動化のあと」 の事後の話をテーマとしています ● 事前に何をすべきかのテーマについては、過去資料「テスト自動化の成 功を支えるチームと仕組み」を参照ください ○ https://speakerdeck.com/goyoki/success-factors-for-test-automation 4

テスト自動化によってどうなるのか 5

テスト自動化のテストへのポジティブな影響 6 ● テストの有効性の改善 ○ 手動では困難なテストを実現する ○ 本質的な目的達成に貢献する ● テストの効率性の改善 ○ テスト活動にかかる時間やリソースを削減する ○ 同じリソースでできるテストを増やす ● テストの正確性と信頼性の改善 ○ 手動のミスを削減する ○ 誤差や不安定さに対応する ● テストの保守性の改善 ○ テストの品質保証、維持、修正、再利用を容易にする ○ テストのインテグリティ（一貫性）やトレーサビリティの維持を助ける ● テストの使用性の改善 ○ 自動化のステークホルダに合わせたUIを実現する ●人間の限界を超えたテスト ●リグレッションテストの繰り返し実行 ●並列実行や夜間実行 ●より包括的な自動化

テスト自動化のポジティブな副次的効果 ● スキルの獲得 ○ テストチームの開発力向上に伴うテスト活動の効率化 ● 開発の清流化 ○ 開発プロセス改善 ○ 自動化されたデプロイメントパイプラインの確立 ○ 改善のフィードバックサイクルの推進 ● 体制の改善 ○ 開発とテストの連携の仕組み化 ● QAの強化に立脚したチャレンジの促進 ○ より難しく高度な機能の実現 7 ●開発技術を他の分野にも適用する ●特定のテストを活かすための全体の戦 略やプロセス、体制を整える

テスト自動化のネガティブな影響 ● リソースとコストの消費 ○ 人・技術：メンバー、スキル、組織 ○ 物・環境：場所、機材、ツール、ライセンス、その他テストウェア ○ 労力・時間： ■ 自動テストの実現と運用 ● テスト自動化環境の構築・維持 ● 自動化テストの構築・維持 ● テスト自動化の付随作業（例：複雑化、他テストの連携）への対応 ■ テスト対象の改善/テストベースの確保 ● テスト自動化のためのテスタビリティの構築・維持 ● 自動テストのためのテストベースの確保・維持 ■ テスト自動化を支えるマネジメントの実現・維持 ● 品質のトレードオフ（次スライド） 8

テスト自動化によってプロダクトの品質はどうなるのか ● テスト自動化に関わるトレードオフ・制約は多い。一概に断言できない ● 例：自動化されたリグレッションテストの影響： 9 プロダクトの 品質特性 テスト自動化のポジティブな効果 テスト自動化のネガティブな効果 保守性 リグレッションの検出・解消の効率化 →リファクタリングやデバッグのミス削減 テスト対象の変更にテストの保守・変更の手 間が加わる→保守コスト増大 性能効率性 時系列での性能監視の実現 →性能悪化の早期検出・早期対策を実現 テスタビリティ実装部による性能低下 許容できるネガティブな代償・対価を払い、目的達成のためのポジティブな効果 を確保するのが基本アプローチ

テスト自動化の目的：視座に応じた目的がある 10 10 ビジネスレベルの目的の例 ・ユーザのニーズ・シーズやクレームへの迅速な対応 ・高度な顧客価値の実現 チームレベルの目的の例 ・開発とテストのフィードバックサイクルの高速化 ・Developer eXperienceの改善 ・高度な品質や機能の実現 テスト担当に閉じたの目的の例 ・テストの効率性・有効性・正確性の向上 （手動で実現できないテストの実現など） テスト自動化は手段の1構成要素であり、他と連動して大きな目的を実現する

本質的な生産性が変わればすべてに影響する 11 初期状態 テスト自動化で 能力・余力・基礎を 得る 得た能力・余力・基 礎で 更に改善する テスト自動化で 余力をなくす 力不足で必要な 改善機会を逃す 有効で発展性のある自動化の継続 （ネガティブ効果＜ポジティブ効果） 自動化の失敗、誤った自動化の継続 （ネガティブ効果＞ポジティブ効果） チームの継続的活動として本質的な改善を推進するのが重要

テスト自動化の成果をどう評価するか 12

前提：評価のために本質的な目的を理解する ● テスト自動化はチームの継続的な改善活動 本質的な目的は、テストに閉じた視座でなく、より高い視座（チーム全 体・ライフサイクル全体）から見える ● 例：自動化の目的をチームのライフサイクルで考える ○ テスト自動化施策の費用対効果がマイナスでも、施策の継続・展開でチー ム活動でのLTVがプラスにできるならば失敗とは言えない ○ ロックインされるマイナーな高級ツール導入で、案件単発で費用対効果を プラスにできても、中長期に弊害が大きくなるなら失敗である 13 チームにとって本質的な目的を見定めるのが、妥当な評価の前提

テスト自動化の成否をどう評価するか ● 評価の観点：妥当な費用対効果で目的を達成したか ○ 目的を達成したか評価する ○ 対価が妥当か評価する 14

自動化の評価の留意点：完璧な指標はない 　目的に関係する複数の観点から総合的に判断する 15 ● 例：ユニットテストの自動化が妥当だったかの判断： 観点・指標 制約 コードの網羅率 仕様の網羅率やAssertionの妥当 性は見えない テストコードについてのレビューの定量メ トリクス（レビュー密度等） ほぼ有効でない 評価者による直接のレビュー結果 スケールできない テストの欠陥検出率 デプロイ後でないと効果がわから ない 担当エンジニアの能力評価 定量評価が難しい ミューテーションスコア 妥当なミュータントの生成が難しい ・・・ ●単独の観点では評価不能 ●数を積んでも完璧にできない テストの評価は、目的に関係する複数の観点を複合して、熟練者が自身の能力・経験を 発揮しながら、総合的に判断しなければならない

自動化の評価の留意点：テストの完璧な評価は不可能 　妥当な評価結果の確保を目指して継続的に精度を高める ● 自動テストの完璧な評価は不可能 ○ テストの効果はプロダクトのLTVが確定するまで見えない ■ 例：ライフサイクル全体での市場バグのデータがないと、真の欠陥流 出は評価できない ○ 完璧なテストは実現不能。サンプリング程度の確認しかしていない ■ 例：コードカバレッジにしても、並行処理やループの網羅確認困難 ■ サンプリングが妥当であったかの妥協的な評価しかできない 16 自動テストの評価は、精度を高める仕組みを導入し、継続的に評価して精度を 高めながら、おおよそ妥当な結果の把握を目指さなければならない

テスト自動化の成否をどう評価するか ● 評価の観点：妥当な費用対効果で目的を達成したか ○ 目的を達成したか評価する ○ 対価が妥当か評価する 17

目的を達成したかの評価： 　目的を評価可能な指標にブレークダウンする 18 目的の観点の例 評価指標の例 欠陥を検出できるか リグレッションを検出できるか ★欠陥検出率、欠陥流出率 ・擬陽性/擬陰性の検出データ ★欠陥注入による評価結果（エラーシーディング、ミューテーションテス ト、TDDサイクル） ・欠陥シナリオに基づいたシナリオレビュー結果 仕様や構造の実現を確認で きているか ・仕様/モデルに対する網羅率 ・法規などのテスト要件についての監査結果 ・コードに対する網羅率 ・熟練者による総合的・属人的評価結果 テストの経済指標は妥当か ・費用対効果（自動化案件のROI、手動テストとの比較） その他自動テストの要件を実 現しているか ・求められる性能値や安定性指標 ・コンテナ化など特定の要件達成評価結果

目的を達成したかの評価： 　目的を評価可能な指標にブレークダウンする 19 アーキテクチャ設計での シーケンス仕様の実現を 高速に確認する 非機能要件と機能 要件に分ける 並列実行可能にする Fixtureを共有しセット アップ時間を短縮する テスト環境のコ ンテナ化 依存部のTest Double化 実行順序とアーキテク チャ仕様違反を検出で きる 想定規模で 1時間以下でテストを 完了できる 並列化と高速化 で対策する SuiteFixture Setup ・・・ アーキテクチャ設計変 更にテストが効率よく 追従できる ・・・ ツリーモデルの分析が最適 例えばGSNやGQMを適用できる

デプロイメントパイプラインのリードタイム 全体の欠陥検出率 目的を達成したかの評価 　視座を高めて評価する 20 自動テストの実行時間 自動テストの欠陥検出率 デプロイ頻度/変更のリードタイム/MTTR 変更障害率 Dev Ops テストに閉じた評価 チームレベルでの評価 Opsも加味した評価

テスト自動化の成否をどう評価するか ● 評価の観点：妥当な費用対効果で目的を達成したか ○ 目的を達成したか評価する ○ 対価が妥当か評価する 21

対価の評価： 　定番のマネジメント観点を具体化して抽出する ● リソースとコストの消費 ○ 人・技術：メンバー、組織、スキル ○ 物・環境：ラボ、機材、ツール、ライセンス、その他テストウェア ○ 労力・時間： ■ 自動テストの実現と運用 ● テスト自動化環境の構築・維持 ● 自動化テストの構築・維持 ● テスト自動化の付随作業（例：複雑化、他テストの連携）への対応 ■ テスト対象の改善/テストベースの確保 ● テスト自動化のためのテスタビリティの構築・維持 ● 自動テストのためのテストベースの確保・維持 ■ テスト自動化を支えるマネジメントの実現・維持 22 同じツリーモデルの分析が有効

テスト自動化をどう次につなげるか 23

テスト自動化のネクストステップ 24 ● 目的の適正化 ● テストの有効性の拡大 ● テストの内部品質の維持と改善

目的の適正化 ● テスト自動化の実践によりチームの能力やテスト自動化のフィージビリ ティが明らかになる ○ 自動テストがどの程度の品質保証の責務を担えるか ○ 自動テストの必要リソースや制約はどの程度か ○ 自動テストの前提をどの程度整えなければならないか ● 上記のフィードバックを活用して、テスト自動化の効果を最大化するよ うに目的を見直す 25

目的の適正化：広い活動スコープで目的を設定する ● テスト自動化活動のスコープを広げると： ○ より本質的・効果的な目的を選択できる ○ 目的達成に使える手段や関係者が増える 26 ビジネスを巻き込んだ視座 【取りえる目的の例】ビジネス要求への迅速な追従、高度な製品価値の実現 【取りえる手段の例】ユーザとの連携、プロダクトライフサイクルを通した継続的改善 開発＋テストに広げた視座 【取りえる目的の例】開発の迅速化、 Developer eXperienceの向上、全体のQAの最適化 【取りえる手段の例】テスタビリティの向上、テスト・開発の連携協力 テスト担当に限定した視座 【取りえる目的の例】特定のテスト実行工程の費用対効果の改善 【取りえる手段の例】テスト担当の作業

目的の適正化：ステップバイステップで前進する ● テスト自動化活動を継続し、テスト自動化の成功や技術を蓄積すると、 より難しい目的に対応できるようになる 27 必要な技術レベル が高い 効果の確保に時間がかかる 必要な技術レベル が低い 効果を早期に確保できる 【例】●継続的ユニットテスト ●フレームワークがサポートす るテスト自動化 ●定番のツールが普及している テスト自動化 【例】●大規模なツールチェー ンの構築 ●デプロイメントパイプライン の全体最適化

テスト自動化のネクストステップ 28 ● 目的の適正化 ● テストの有効性の拡大 ● テストの内部品質の維持と改善

テストの有効性の維持と拡大 ● 自動テストが品質保証の責務を担うようにする/責務を拡大する ○ GoogleのBoyonceルール（Googleのソフトウェアエンジニアリング） ■ 「...インフラストラクチャーの変更の結果として障害や他の問題に 陥った場合、問題が継続的インテグレーションシステムでのテストで 表面化していなかったならば、インフラストラクチャーの変更に落ち 度はない...」 ■ ≒「特定の障害が市場で発生したら、すべてCIの自動テストの責任」 29

テストの有効性の維持と拡大： 　チームの品質保証・テストの全体設計を工夫する ● 全体の品質保証・テストの設計構造を構築・維持し、開発ライフサイク ルの中で自動テストのあるべき責務を先導する ○ ある仕様項目の実現はだれが確認するか、あるバグの検出はだれがやるか 30 品質保証・テスト活動の責務設計 品質保証・テスト活動の構造設計

テストの有効性の維持と拡大： 　有効なテストを開発する ● 自動化する価値のあるテストケースを設計し、その価値を維持する ● 価値のある妥当なテストケースを実現するための要点： 31 【テスト要求分析】 広くステークホルダ（ユーザ、チーム、 PjM、PdMなど）と協力し、テストについてのニーズ・シーズ ・制約を広く掘り出し、実現すべき要求を識別する 【テストレベル設計/テスト基本設計/テストアーキテクチャ設計】 自動テストが価値を発揮できるように、テスト戦略を構築し、テスト全体の責務設計を工夫 する 【テスト設計】 適切なテスト設計アプローチで、責務を効率的に充足する自動テストのテスト ケースを設計する 【テスト設計の維持】 テストの要求や制約が変化する開発ライフサイクルの中で、自動テス トが有効であり続けるようにテスト設計を保守する 基礎・前提

テストの有効性の適用と拡大： 　テスタビリティを拡大し自動テストの範囲を広げる 32 品質特性 テスト自動化にとっての特性 実装例 実行円滑性 円滑に自動化された処理を実行できる シンプルなセットアップ手順 観測容易性 自動テストがテスト対象の出力（間接出力、副作用 含む）を観測しやすい エラー認識手段の充実、適切なログ設計、十分な副作用 対策(ステートレスなど)、観測用デバッグ機能 制御容易性 自動テストがテスト対象の入力（間接入力含む）を操 作しやすい 使いやすいAPI、間接入力の制御手段（Stubなど）、デバッ ガサポート 分解容易性 対象から自動テスト可能なテスト対象を切り出しや すい。自動テストの障害を分離しやすい 適度に配置された接合部（ DI、Dependency lookup）、適 切な結合性設計 単純性 テスト対象の仕様や構造、実行方法が単純 冗長性の少ない仕様やコード 安定性 自動テストの支障となるテスト対象のバグや不安定 さ（変更が頻繁など）が少ない テスト対象のバグの少なさ、仕様変更の少なさ、 IFの不変 さ 理解容易性 テスト対象の仕様や構造、実行方法が分かりやすい 理解しやすい仕様やコード、適切なドキュメンテーション ※品質特性定義：ロジャー・S・プレスマン『実践ソフトウェアエンジニアリング（日科技連出版）』

テスト自動化のネクストステップ 33 ● 目的の適正化 ● テストの有効性の拡大 ● テストの内部品質の維持と改善

テストの内部品質の維持と改善 ● テスト自動化の次のステップとして、成果の運用と拡大のため、主にテ ストの保守性と信頼性の確保が求められる ○ 多くの場合で、テスト自動化チャレンジとして許容してきた自動テストの 技術的負債の返済が求められる ○ ネクストステップとして、テストの技術的負債の未然の予防も求められる 34

テストの内部品質の維持と改善 35 ● 一般的なソフトウェア開発のエンジニアリングやノウハウの活用でテス トシステム・テストコードの品質を作りこむ。要点となる品質： 品質特性 確保すべき特性 保守性 自動テストの保守を容易にする ※監視容易性（問題の監視が容易）、試験性（正しいか・妥当かの確認が容易）、解析性・修正 性（問題発生時の特定・是正が容易）、可読性（TaDとして運用可能） 信頼性 偽陽性/偽陰性の削減、安定性の確保を容易にする ※継続的自動テストはFragile Test/Flaky Testとの戦いに直面する 性能効率性 フィードバックを迅速化する。並行実行や頻繁な変更時実行が可能なように必要リソースを削減 する 拡張性 少ない対価で自動テストのカバレッジを拡張可能にする 例：パラメータ化テスト、データ駆動テスト、環境仮想化、モデル駆動テスト 使用性 チームにとっての使いやすさや魅力を向上する 例：フィードバックの手軽さ、結果の見やすさ

テストの内部品質の維持と改善 ● 自動テストコードの品質を支える良い習慣の例： ○ FIRSTの原則 ■ Fast、Independent、Repeatable、Self-Validating、Timely ○ xUTP12の原則 ○ 「Googleのソフトウェアエンジニアリング」ユニットテストの原則 ■ 変化しないテストを目指せ。 ■ 公開API経由でテストせよ。 ■ 相互作用ではなく、状態をテストせよ。 ■ テストを完全かつ簡潔にせよ。 ■ メソッドではなく、挙動をテストせよ。 ■ 挙動に重点を置いてテストを構成せよ。 ■ テスト対象の挙動にちなんでテストに命名せよ。 ■ テストにロジックを入れるな。 ■ 明確な失敗メッセージを書け。 ■ テスト用コードを共有する場合、DRYよりDAMPに従え。 36 「Googleのソフトウェアエンジニアリング」（オライリー、 Titus Winters他）

ご清聴ありがとうございました ● テスト自動化によってどうなるのか ● テスト自動化をどう評価するか ● テスト自動化をどう次につなげるのか 37