開発に寄りそう自動テストの実現 井芹 洋輝 2025/12/6 ソフトウェアテスト自動化カンファレンス2025 招待講演 1 

自己紹介 ⚫経歴 • 開発者、テストエンジニア、コンサルタント、QAエンジニアとさまざまな立場 でさまざまなプロダクトのソフトウェアテスト業務に従事 • 今回はそこでの経験則を解説します • 現在は車メーカでQA/テストテックリード、品質マネジメントアーキテクト担当 • JSTQB技術委員、テスト設計コンテストU30クラス初代審査委員長 ⚫主な著作 • 「ソフトウェアテスト徹底指南書」 「シフトレフトテストを支える現代的なテスト設計」 「システムテスト自動化標準ガイド」（共訳）など 2 

開発と並走する自動テスト 3 

自動テストの作成・実行は、開発と並走するか否かで 様変わりする ⚫開発と並走する自動テスト • PBI、ユーザーストーリなど細分化した開発単位ごとに： • 開発と一緒に・並行してテストを作成 • 動く対象ができ次第、テストを継続実施 • テスト合格をもって対象の開発完了 • 例：テスト駆動開発 ⚫開発から独立した自動テスト • 設計・実装から独立して自動テストを作成・実行 • 開発工程が終わってから、テスト工程として実行 • 例：テスト専任チーム担当のシステムテストでの自動テスト 4 

テストレベルと自動テストの併走化の関係 5 システムテスト 統合テスト ユニットテスト 開発と並走して自動テストを 作成・実行 開発から独立して自動テストを 作成・実行 テストレベルの 粒度の細かさ ユニットテストや細粒度の統合テストでは 併走化がすでに普及している 「ここの併走化も広げよう」が 本講演のテーマ 

開発と並走する自動テストの例 ⚫テスト駆動開発 • まず失敗するテストを書き、プロダクトコードを追加変更してテストを成功に 変えてプログラミングを進める • 適宜テストを活用してリファクタリングする ⚫受け入れテスト駆動開発 • まず仕様や受け入れ基準を受け入れテストとして定義する • 受け入れテストに合格するように設計・実装を進める 6 

ユーザーストーリーベース開発での受け入れテスト駆動開発 7 ユーザーストーリの開発 受け入れテストの活動 ユーザーストーリ仕様の 作成と洗練 ユーザーストーリの 開発 仕様・受け入れ基準としての 受け入れテストの 作成と洗練 受け入れテストの 改善と実行 （継続的に実行し、 合格を目指す） プロダクトバックログ の作成 リファインメント 開発スプリント中の 開発活動 

開発と併走化する自動テストでの体制 ⚫ユニットテスト：開発者が担当 ⚫統合テスト・システムテスト • 専任のテストエンジニア・QAエンジニアの有無はコンテキストに合わせる • テスト専任がいるとより的確なテスト分析・設計ができるが、密な連携が 必要なほかコストが増加する • 後述する仕組み・内部品質の整備度にも依存する 8 

自動テストを開発と併走化させる場合の恩恵： 早く気付ける・早く行動できる・開発と一体化できる ⚫コードが固まる前から、自動テストを早く作成・保守できる • 無理なくテスト容易性が確保される • テストベースが早期から改善され、バグ実装を予防する • 内部構造にとらわれない仕様や設計の洗練・具体化が促進される ⚫自動テストを早く実行できる • 即時にバグのフィードバックが行われる • リグレッションテストが早期から充実し、以降の追加変更が効率化する • 自動テストの問題に早く気付け、その洗練ができる ⚫開発と一体化して活動できる • 開発力を活かして自動テストの品質を確保できる • 自動テスト開発に開発インフラを活用できる • 開発・テスト間のコミュニケーションロスが軽減する 9 

テスト自動化の費用対効果悪化のよくある要因 ⚫不適切な目的設定の放置 ⚫テスト容易性の不足 • 例：安定性の欠落 ⚫開発力の不足 ⚫自動テストの品質不足 • 例：自動テストの保守コストの想定以上の悪化 ⚫自動テスト投入タイミングの遅れ 10 • 開発と一体となった併走化で改善する • 開発から距離をとるほど悪化する 

11 自動テストは、 開発活動と一体になって開発と併走化することで、 費用対効果が改善し成功確率が高まる 

開発と併走する自動テストの実現 12 

自動テストを併走化させるためには基礎作りが必要 ⚫要点 • 開発チーム全体の自動テストのイネーブリング • 各開発活動に自動テストを任せられるようにする • 自動テストの開発・運用を効率化する仕組み・内部品質整備 • 自動テスト込みでも開発のスピード・効率を落とさない ⚫要点を推進する施策 1. 良い自動テストについての開発チーム全体の習慣づけ 2. アーキテクチャのテスト自動化容易性の確保 3. 自動テストの開発・保守を支えるテスト自動化システムの整備 4. 自動テストの開発・保守を支える開発インフラの整備 13 

(1)良い自動テストについての開発チーム全体の習慣づけ ⚫併走化では、集約から全体分散への展開が必要 それぞれの開発活動の当事者に、自動テストを開発していくための 心がけ、技術、習慣が求められる ⚫チーム全体の自動テスト力の底上げが必要 14 

(1)良い自動テストについての開発チーム全体の習慣づけ 1. 併走習慣の定着 • ガイドラインやプロセスであるべき姿を提示 • テスト駆動開発/Cover & Modifyなどの良いプラクティスの導入推進 • モブプログラミングによる総合力の共有 • CI/CDによる自動テストの資産化・価値化 2. 習慣づけへの短期フィードバック • PRレビュー/MRレビューでの有識者によるチェック • CI/CDからのカバレッジのフィードバック 3. 習慣づけへの中長期フィードバック • バグ流出を評価して改善サイクルをまわす • フォールトインジェクション/ミューテーションテストによる評価 15 

(2)アーキテクチャのテスト自動化容易性の確保 ⚫自動テスト併走化で、プログラミングで対応できるこまごまとした テスト自動化容易性の課題は解消する ⚫問題として残るのが、そこで対応できないアーキテクチャレベルの テスト自動化容易性 • 個々のプログラミングの中で対応できない • 自動テスト全体のスコープ・有効性を大きく左右する ⚫アーキテクチャのテスト自動化容易性確保は、併走化の重要な前提 16 

(2)アーキテクチャのテスト自動化容易性の確保 ⚫自動化を容易にする技術スタック選択 • 仮想化やシミュレータ/エミュレータ対応など ⚫効果的な統合テストを導入できるアーキテクチャバウンダリ確保 ⚫十分な観測容易性・制御容易性を持つインターフェース確保 ⚫テスト自動化の障害の局所化と分離 • テスト自動化を阻害する要素を特定コンポーネントに閉じ込め、置換・代替 可能にする • 外部サービス依存部、ハードウェアなどローレイヤ制御、本番環境依存部など • 疎結合設計を推進する • 共有するリソースや状態の最小化 • 適切な並行処理・並列処理設計 • DIやType Erarueといった置換可能なインターフェースの配備 17 

(3)自動テストの開発・保守を支えるテスト自動化システムの 整備 ⚫統合テスト、E2Eテストの自動化では自動テストの管理・実行をシステム化 したテスト自動化システムが、テストの作りやすさや保守性を左右する ⚫併走化ではチーム横断での事前整備が必要 18 テスト管理 テストケース テストデータ テストフレームワーク テストライブラリ （Mockなど） テスト実行 ランナー レポート テスト環境システム （実行環境、連携サービス、基盤インフ ラなど） 監視 

(4)自動テストの開発・保守を支える開発インフラの整備 ⚫自動テストの併走化ではCI/CDの整備が重要 • 作成した自動テストのリグレッションテストとしての資産化 • 継続実行による自動テストが活きた状態の維持 ⚫インフラリソースの整備が自動テストの充実度を左右 • コンテナオーケストレーションによる柔軟なリソース割り当て • 並列化による実行時間短縮 ⚫併走化では事前整備が重要 19 

まとめ ⚫開発活動と一体になって、開発と併走化することで自動テストの 費用対効果が改善し、成功確率が高まる ⚫開発との併走化の要点 • 開発チーム全体の自動テストのイネーブリング • 自動テストの開発・運用を効率化する仕組み・内部品質確保 20