そのテスト、説明できますか？~LWテスト戦略FW~のご紹介

スクフェス金沢26で発表したテスト戦略をチームで考えるべく、対話を促す手法の紹介です

Transcript

1. そのテスト戦略、説明できますか？ “なんとなく”を卒業する Lightweightテスト戦略Frameworkのご紹介 スクラムフェスト金沢 2026/06/20 三菱電機 株式会社 FA事業本部 中原 慶
4. GPT-5.5
5. 5 アジェンダ 1.老舗の大企業の強みと弱み ～なぜLight Weigtテスト戦略 Frameworkを作ったのか～ 2.アジャイルにおけるテスト 3.Light Weightテスト戦略 Framework の全体像 4.おわりに
6. 老舗の日本企業にお勤めのかた？ 企画・開発などの業務にスクラムを 採用されているかた？ うちはAIをフル活用していてQA Agentが大活躍だぜ！というかた？ うちはアジャイルでQAがちゃんと 機能しているぜ！というかた？
7. 7 老舗の大企業の強みと弱み ～なぜLight Weigtテスト戦略 Frameworkを作ったのか～ 1
8. 8 1 . 老 舗 の 大 企 業 の 強 み と 弱 み ～ な ぜ L i g h t W e i g t テ ス ト 戦 略 F r a m e w o r k を 作 っ た の か ～ 急速な技術の進化、市場環境の変化に適応すべく、老舗大企業でも アジャイル/スクラムの導入が加速 https://www.mitsubishielectric.co.jp/fa/products/service/fa- digitalsolution/concept.html
9. 9 1 . 老 舗 の 大 企 業 の 強 み と 弱 み ～ な ぜ L i g h t W e i g t テ ス ト 戦 略 F r a m e w o r k を 作 っ た の か ～ 老舗メーカーでは派生開発が主流 https://www.cresco.co.jp/blog/entry/19014.html https://www.mitsubishielectric.co.jp/fa/products/cnt/plc/index.html
10. 10 1 . 老 舗 の 大 企 業 の 強 み と 弱 み ～ な ぜ L i g h t W e i g t テ ス ト 戦 略 F r a m e w o r k を 作 っ た の か ～ それはWaterfall？ 組織オリジナルなプロセス？ 先輩方が培ってきたやり方を踏襲 この知と経験の結集が組織の強み https://share.google/IiRbvcN6GcZnmqWSA
11. 11 1 . 老 舗 の 大 企 業 の 強 み と 弱 み ～ な ぜ L i g h t W e i g t テ ス ト 戦 略 F r a m e w o r k を 作 っ た の か ～ サービスビジネス？アジャイル？やったこと無い
12. 12 1 . 老 舗 の 大 企 業 の 強 み と 弱 み ～ な ぜ L i g h t W e i g t テ ス ト 戦 略 F r a m e w o r k を 作 っ た の か ～ https://www.scrum.org/resources/scrum-framework-poster 1. スクラムガイドの⽬的 2. スクラムの定義 3. スクラムの理論 a. 透明性 b. 検査 c. 適応 4. スクラムの価値基準 5. スクラムチーム a. 開発者 b. プロダクトオーナー c. スクラムマスター 6. スクラムイベント a. スプリント b. スプリントプランニング c. デイリースクラム d. スプリントレビュー e. スプリントレトロスペクティブ 7. スクラムの作成物 a. プロダクトバックログ b. スプリントバックログ c. インクリメント 8. 最後に 全17頁
13. 13 1. 老舗の大企業の強みと弱み ～なぜLight Weigtテスト戦略 Frameworkを作ったのか～ <<中略>>
14. 14 1 . 老 舗 の 大 企 業 の 強 み と 弱 み ～ な ぜ L i g h t W e i g t テ ス ト 戦 略 F r a m e w o r k を 作 っ た の か ～ 1. アジャイルとは、不確実かつ複雑系領域において、無駄なく価値を提供し続ける、ソフトウェア開発の考え方として誕生 2. フィードバックサイクルを小さく繰り返し、素早く学ぶことで、あらゆることを改善しながら最短距離で価値を提供する 1. スクラムガイドの⽬的 2. スクラムの定義 3. スクラムの理論 a. 透明性 b. 検査 c. 適応 4. スクラムの価値基準 5. スクラムチーム a. 開発者 b. プロダクトオーナー c. スクラムマスター 6. スクラムイベント a. スプリント b. スプリントプランニング c. デイリースクラム d. スプリントレビュー e. スプリントレトロスペクティブ 7. スクラムの作成物 a. プロダクトバックログ b. スプリントバックログ c. インクリメント 8. 最後に 全17頁 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum- Guide-Japanese.pdf いつ、誰が、どうやって • 商品企画をするの？マーケリサーチするの？ • 仮説検証設計するの？ • 要求/要件を定義するの？ • アーキや設計を考えるの？ • どんなテストをするの？ • 運用設計は？
15. 15 1 . 老 舗 の 大 企 業 の 強 み と 弱 み ～ な ぜ L i g h t W e i g t テ ス ト 戦 略 F r a m e w o r k を 作 っ た の か ～ これまでは、長年培われた規則やプロセスこそが強み！！ Scrumは画一的なプロセスではなく、複雑な状況に適応し続 けるためのフレームワーク プロセスを自ら構築し、経験をもとに最適化、改善し 続けなければならない！！！
16. 16 最低限の前提知識 + ライトに戦略立案できる仕組み LWテスト戦略FW 1 . 老 舗 の 大 企 業 の 強 み と 弱 み ～ な ぜ L i g h t W e i g t テ ス ト 戦 略 F r a m e w o r k を 作 っ た の か ～ スクラムではプロセスなど品質を確保する仕組みを 自ら構築、改善する必要あり
17. 17 アジャイルにおけるテスト戦略 2
18. 18 2. アジャイルにおけるテスト 企画 要件定義 設計 開発 評価 出荷 プロジェクト計画の提案 /審議 第三者評価者が テストケース作成 関係者が出荷に納得し、 品証が出荷を承認 手戻り ウォーターフォール型プロセス(WF)では、計画に従いいっきに開発し、開発 後半のテストで不具合を発見・除去することで品質を確保する スクラムなどの反復漸増型プロセス(Agile)では、開発項目ごとに製品全体のテス トと改修を行い、リリース可能な品質を確保する More Effective Agile https://www.amazon.co.jp/dp/B089KFKB5H/ WF型(上図)では潜在的な欠陥が長期間潜むため、真因発 見と除去に時間がかかる Agile型（下図）では欠陥が混入早期に発見、除去されるた め、計画全体を見ると不具合除去の効率が良い 【ウォーターフォール型(WF)】 【Agile型】
19. 19 2. アジ ャイルにおけ る テス ト テストは製品が保証範囲（仕様品質）を満たしているかを計測する活動。アジャイルだからと言って、計測が必要な単 位、種類は変わらない。テストの考え方と方法とタイミングが変わる 出展:eXtream Programming 技術面 テストピラミッド テスティングトロフィー
20. 20 2. アジ ャイルにおけ る テス ト • スクラム： POが然るべきタイミングを見極めリリースすることでビジネスアジリティを高める • 品質ガバナンス： 品質保証組織が横断の観点で品質を確認することで、組織としての品質ガバナンスをきかせる VS チーム 品質保証組織(QA)
21. 21 2. アジ ャイルにおけ る テス ト Exit条件としての品質保証(QA)から、チームに寄り添いチームを支援するQAへ 1. 組織としての品質ガバナンスを効かせる役割 2. 品質・テストの専門家としてチームに寄り添い、チームを支援する役割 品質ガバナンス QAのレポートラインをもちつつチームに駐在し、POに先立ち Doneの判定を行う 専門家としてチームを支援 テスト戦略/設計、テスト技法の活用、自動化などあらゆる面で チームを支援
22. 22 2. アジャイルにおけるテスト QAを含むチーム全員でテストを考える なぜ、そのテストを実施するのか？ なぜ、それで十分なのか？ 全員が理解し、説明できる 状態を目指す
23. 23 Light Weight テスト戦略 Framework の全体像 3
24. 24 3. Light Weight テスト戦略 Framework の全体像 品質保証部門/ 利害関係者 スクラムチーム 【凡例】 テスト戦略考案 品証/利害関係者との合意 出荷承認 テスト戦略に従ったテスト実施 結果レポート 開発継続 注記)テスト戦略の変更や提案非承認などの分岐は割愛 ゴールを合意 テスト実施 出荷 承認 リリース計画 出荷 品質基準と計測方法、目標 値を合意 テスト戦略合意 品質基準を常に確認 All Greenをもって 出荷承認 ゴールを合意 テスト実施 出荷承認 スプリント
25. 25 テスト目的を決定する テスト方針を決定する テスト戦略(設計方針)を決定する プロセスを構築する DoDを決定する Undone Workを決定 する テスト環境を構築する 全Sprintで必ず実施する PBIを決定する テスト戦略 3. Light Weight テスト戦略 Framework の全体像
26. 26 テスト目的を決定する テスト方針を決定する テスト戦略(設計方針)を 決定する 開発プロセスを構築する DoDと実施方法 Undone Workと対策 【テストへの要求を分析する】 ① 対象のリリースの目的は？（ビジネスゴール） ② ①の達成に向けてテストに期待することは？（テストゴール） ③ 対象のリリースで大事にする品質特性は？ ④ 絶対に起きちゃダメなことは？（リスク） 【どのような品質をどのようなテストで確認するのかを決定する】 ⑤ ②～④を満たすために、どんな観点の品質を、どんなテストで確認す るのか（⑤⑥）？ ⑦ 自チーム外にテストに責任をもつ関係者はいるか？ 【各テストの実施計画を決定する】 ⑧ 各テストを、いつ、誰が、どのように作成し、実施するのか？ ⑨ 各テストの目標値は何か？ ⑩ 各テストの実施に使う環境、ツールは何か？ チームや関係者との対話を通し、10の質問に答えることで、ロジカルにテスト戦略を立案できる 3. Light W eight テス ト戦略 Framework の全体像
27. 27 テストの目的（要求）を明らかにする 特に品質に関するステークホルダーと、 どんな品質観点を、どんなテストで確認するかを決定する Step1. どんな品質観点を確認する？ Step2. どんなテ ストで確認する？ 各テストの実施計画（目標値、作成タイミング、作成 者、レビュー者、実施方法とタイミング、レポート方法、 利用ツールなど）を決定する テスト目的を決定する テスト方針を決定する テスト戦略(設計方針)を 決定する 3. Light Weight テスト戦略 Framework の全体像
28. 28 3. Light Weight テス ト戦略 Framework の全体像 # 項目 決定する内容 テスト目的の 決定 1 ビジネスゴール 今回のテスト戦略が対象とするサービスの目的は？ 「成功の定義」、「成果指標」「期間」を明確に 2 テストゴール ビジネスゴールに対して、何(提供価値)を対象に、テストで達成すべき目的（何を確認し、 何を学び、明らかにするリスク）は？ 3 品質特性（優先度付き） サービスとして、どんな品質特性（ISO 25010）を優先するか？(利用時品質、製品品 質) 4 リスク 絶対おこっちゃだめなこと（製品リスク、プロジェクトリスクの両観点）は？ テスト方針の 決定 5 テ ス ト の 種 類 テストレベル 1～4を満たすために、V字モデルのどんなテスト（単体、結合、システム…）で、どんな品 質の観点を確認する？ やらないこととその理由も明らかに 6 テストタイプ どんな種類のテスト (回帰テスト,Secテスト,負荷…)でどんな品質の観点を確認する？ やらないこととその理由も明らかにする 7 責任分担 チーム外にテストに関する関係者（例：QA）がいる? 例：RACIで表現 テスト戦略 (設計方針) の決定 8 アプローチ いつ、だれが、どうやってテスト設計し、実装、レビュー、実行、評価、レポートする？ DoD、Undoneなどを明確にしたうえで、プロセスと計画に表現する 9 メトリクス／評価基準 現在の品質状況を提供するための先行指標（自動化比率、テスト実行時間…）と遅行指 標（障害件数、MTTR、リリース後欠陥密度…）とその基準は？ 10 ツール・環境 各テストレベル、テストタイプに対する自動化やシミュレーションの方針は？
29. 29 3. Light Weight テスト戦略 Framework の全体像 Light Weight (LW)テスト戦略 Framework(FW)は、ソフトウェアテストに対する最低限の前提知識で、チームで対話をしなが ら１０の質問にこたえることで、簡単かつ迅速にテスト戦略（設計方針）を考案することができるFrameworkである LWテスト戦略FWをもとに、DoDや開発プロセス、Undone Workの特定と対策計画を具体化することができる テスト要求の 明確化 テスト方針の決 定 テスト設計方針 の決定 プロセスと計画への 組み込み DoDの決 定 Undone Workの 決定 テスト環境の構 築 全Sprintで 必ず実施する PBIの決定 # 項目 決定する内容 テスト目的の 決定 1 ビジネスゴール 今回のテスト戦略が対象とするサービスの目的は？ 「成功の定義」、「成果指標」「期間」を明確に 2 テストゴール ビジネスゴールに対して、何(提供価値)を対象に、テストで達成すべき目的（何を確認し、何 を学び、明らかにするリスク）は？ 3 品質特性（優先度付き） サービスとして、どんな品質特性（ISO 25010）を優先するか？(利用時品質、製品品質) 4 リスク 絶対おこっちゃだめなこと（製品リスク、プロジェクトリスクの両観点）は？ テスト方針の 決定 5 テ ス ト の 種 類 テストレベル 1～4を満たすために、V字モデルのどんなテスト（単体、結合、システム…）で、どんな品質の 観点を確認する？ やらないこととその理由も明らかに 6 テストタイプ どんな種類のテスト (回帰テスト,Secテスト,負荷…)でどんな品質の観点を確認する？ やらないこととその理由も明らかにする 7 責任分担 チーム外にテストに関する関係者（例：QA）がいる? 例：RACIで表現 テスト戦略 (設計方針)の 決定 8 アプローチ いつ、だれが、どうやってテスト設計し、実装、レビュー、実行、評価、レポートする？ DoD、Undoneなどを明確にしたうえで、プロセスと計画に表現する 9 メトリクス／評価基準 現在の品質状況を提供するための先行指標（自動化比率、テスト実行時間…）と遅行指標（障 害件数、MTTR、リリース後欠陥密度…）とその基準は？ 10 ツール・環境 各テストレベル、テストタイプに対する自動化やシミュレーションの方針は？
30. 30 3. Light Weight テス ト戦略 Framework の全体像 どんな品質観点を、どんなテストで確認するかを決定する
31. 31 3. Light Weight テス ト戦略 Framework の全体像 各テストの実施計画（目標値、作成タイミング、作成者、レビュー者、実施方法とタイミング、レポー ト方法、利用ツールなど）を決定する
32. 32 テスト目的を決定する テスト方針を決定する テスト戦略(設計方針)を決定する プロセスを構築する DoDを決定する Undone Workを決定 する テスト環境を構築する 全Sprintで必ず実施する PBIを決定する テスト戦略 3. Light Weight テスト戦略 Framework の全体像
33. 33 3. Light Weight テス ト戦略 Framework の全体像 ～Definition of Done（DoD）とUndone Work～ Product Backlog Item(PBI)がDoneになるためには2つの条件を満たす必要がある DoDは、往々にしてPBIのACのように明記されないが、忘れてはいけない そのため、DoDは必ず実施されるよう自動化されるか必ず実行される活動として仕組み化する もし実施忘れがあった場合は、対象のDoDは全てのPBIのACとして明確に記載するようにする Product Backlog Product Backlog Item（PBI） Definition of Done（DoD） • インクリメントが満たすべき品質基準 つまり、PBI横断的な共通の達成基準 Acceptance Criteria（AC: 受け入れ基準） • PBI（≒ ユーザーストーリー）ごとに設定される PBIごとに明記される PBIごとに明記されない
34. DoDわすれてた！！ 品質確保できず
35. DoDは 必ず実施されるよう 自動化されるか、 必ず実行される活動として 仕組み化 実施忘れがあった場合はA/Cに 降格！！ 全てのPBIにA/Cとして明確に記載する！！ Pull Request(PR) 作成 全自動テスト実行 他者にコード レビュー依頼 Merge PR All Green Approve 自動化 仕組み化
36. 36 3. Light Weight テスト戦略 Framework の全体像 ～Definition of Done（DoD）とUndone Work～ リリースのために必ず必要だがDoDにできない活動をUndone Workという。 Undone Workはリリースへのリスクなので、戦略的に極小化し、リスクヘッジする。可能な限りDoDにすることを目指す Undone Workの例： 1. 手動の回帰テスト 2. 運用テスト 3. 脆弱性動的テスト 4. 連続稼働テスト 5. システム間結合テスト 6. 法令順守、特許回避調査、輸出管理 7. … WEB脆弱性診断 負荷テスト WEB脆弱性診断 負荷テスト リリース可 リリース可 Undone Work Undone Work
37. 37 おわりに 4
38. 38 4. おわりに １～１０の質問をいったりきたりすることで、リリースゴールや、 “やるべきこと”の理由の解像度があがった チームで対話しながら検討するで、共通の認識が醸成された いま必要な品質を、いま必要なテストで、効率よく確実に確認 するための作戦が立てられるようになった 全員が、テスト戦略を説明できるようになった
39. https://drive.google.com/file/d/1hcIMUZAMck3ReJsgZXIBSdPnY9SReVq3/view?usp=drive_link Come work with us!