アジャイル開発に必要なテストの準備、進め方

アジャイル開発という言葉が世の中に出て20年あまり、今では多くの日本企業がアジャイル開発に挑戦していますが、品質を犠牲にスピードを上げてしまった結果、顧客が望むものを見誤ってしまうプロジェクトが多く存在しています。
SHIFTではアジャイル開発を定着させるため、しっかりと品質保証を行うプロセス、フレームワークを独自に構築しました。
本セッションでは、そのフレームワークの紹介を交えつつ、アジャイル開発で行うテストの準備、進め方を紹介します。

登壇者： 船橋 篤史[SHIFT]
https://event.shoeisha.jp/devsumi/20230209/session/4183/

Transcript

1. アジャイル開発に必要なテストの準備、進め方
   Developers Summit 2023
   2023.2.10
   

   View Slide

2. 1
   自己紹介
   ◼ 名前：船橋 篤史
   ◼ 所属：株式会社SHIFT​
   ◼ 経歴：
   ◼ アジャイル開発体制構築、自動テスト導入
   ◼ Windowsネイティブアプリケーションのクラウドリフト
   ◼ Webアプリケーションのクラウドシフト
   ◼ 基幹システム構築
   ◼ etc…
   

   View Slide

3. 社名 株式会社 SHIFT 代表者 代表取締役社長 丹下 大
   設立 2005年9月7日 従業員 連結：8,119人 単体：4,646人（パートナー、派遣含む）2022年2月末時点
   所在地
   【本社&東京オフィス】東京都港区麻布台2−4−5 メソニック39MTビル
   【札幌オフィス】北海道札幌市 【大阪オフィス】大阪府大阪市 【仙台オフィス】宮城県仙台市
   【福岡オフィス】福岡県福岡市 【名古屋オフィス】愛知県名古屋市 【広島オフィス】広島県広島市（予定）
   関係会社
   株式会社SHIFT SECURITY (東京都)
   株式会社メソドロジック (東京都)
   ALH株式会社 (東京都)
   Airitech株式会社 (東京都)
   株式会社さうなし（東京都）
   株式会社SHIFT PLUS（高知県）
   株式会社システムアイ（神奈川県）
   株式会社分析屋 (神奈川県)
   株式会社ナディア (東京都)
   株式会社xbs (東京都)
   株式会社エスエヌシー (大阪府)
   株式会社CLUTCH（東京都）
   株式会社ホープス（東京都）
   VISH株式会社（愛知県）
   株式会社A-STAR（東京都）
   DICO株式会社 (東京都)
   株式会社SHIFTグロース・キャピタル（東京都）
   株式会社クラフ（宮崎県）
   株式会社サーベイジシステム (東京都)
   株式会社マスラボ (東京都)
   SHIFT Global Pte Ltd（シンガポール）
   SHIFT ASIA CO.,LTD （ベトナム）
   ほか 計32社
   SHIFTを語る
   3つのポイント
   ・売上高1兆円を狙えるポテンシャル
   ・サービス開始以来、高い売上高を維持している
   ・ITはますます人材不足→2030年には、79万人の不足が予想される（経済産業省平成28年度調べ）
   ・エンジニアがやりたがらない仕事を圧倒的に優秀な人材が実施
   ・118万件に及ぶ膨大な不具合DBを活用した品質保証
   ・人材を選定するCAT検定、人材を育てるヒン大、管理をするCATを開発
   会社概要
   SHIFTグループは、ブルーオーシャン成長市場において、ソフトウェアの
   「品質保証」を手がけている会社です
   2
   グループ会社
   ソフトウェア品質保証の
   デファクトスタンダードを開発
   非エンジニアが活躍できる市場をつくっ
   た
   5.5兆円のブルーオーシャン市場で圧
   勝
   

   View Slide

4. SHIFTのサービス一覧
   DX推進支援
   新規事業の牽引をご支援
   コ
   ン
   サ
   ル
   最
   新
   技
   術
   支
   援
   推
   進
   構想策定支援
   新規サービス開発
   DXクライテリア診断
   アジャイル開発
   ローコード開発
   オフショア開発
   DevOps
   AI／ビッグデータ支援
   アナリティクス
   マーケティング
   PMO
   教
   育
   ベーシック（品質テスト／RPA等）
   エンジニアリング（設計／DevOps／UX／RPAなど）
   マネジメント（戦略／計画／管理／CX／アジャイルなど）
   品
   質
   担
   保
   テスト計画
   テスト設計
   テスト実行
   テスト自動化
   QA推進／品質評価
   インスペクション
   PMO（PJ管理／テスト推進）
   イ
   ン
   フ
   ラ
   改
   善
   インフラ構築
   ネットワーク
   クラウド
   ERP
   開発
   オフショア開発
   IT自動化（CI／CD、RPA）
   性能改善サービス
   トラブルシュート
   コ
   ン
   サ
   ル
   診
   断
   セキュリティコンサル
   各種 脆弱性診断
   ペネトレーションテスト
   負荷テスト
   コ
   ン
   サ
   ル
   ・
   実
   装
   ECコンサルティング
   Web企画／制作
   Webマーケティング
   グラフィックデザイン
   UI／UX／CX支援サービス
   コ
   ン
   サ
   ル
   推進
   構想策定支援
   新規サービス開発
   DXクライテリア診断
   アジャイル開発
   ローコード開発
   オフショア開発
   DevOps
   AI／ビッグデータ支援
   マネジメント
   PMO
   運
   用
   展
   開
   ヘルプデスク
   24x365監視
   マニュアル作成
   FAQ／chatbot運用
   PC販売
   キッティング
   開
   発
   品質保証／テスト支援
   QCDの遵守に不可欠なご支援
   運用効率化支援
   運用コスト削減をご支援
   ITコンサルティング
   ITでビジネス課題の解決をご支援
   デジタル接点強化支援
   ECサイト／CXデザイン構築をご支援
   開発／インフラ支援
   目的に対する確かな手段をご支援 セキュリティ支援
   事業インシデントコスト削減をご支援
   人材育成支援
   自走化実現への育成をご支援
   

   View Slide

5. 「品質保証の会社」から「売れるサービスを一緒につくる会社」へ
   4
   SHIFTは
   お客様のビジネス成功に
   コミットする会社に
   「ソフトウェアテスト」
   といえばSHIFT
   「DX」
   「売れるサービスづくり」
   といえばSHIFT
   第一想起
   第一想起
   ソフトウェアのテストを
   受託する会社
   SHIFTグループは、ソフトウェア品質を起点にDXや新たな価値創造を実現し、
   日本の社会問題に挑戦する会社です。
   

   View Slide

6. 今日話すこと
   ◼ 昨今のプロジェクト事情
   ◼ アジャイル開発でみられるよくある課題
   ◼ SHIFTが生み出した品質保証フレームワーク
   ◼ フレームワークを活用した効果
   ◼ まとめ
   5
   

   View Slide

7. 6
   昨今のプロジェクト事情
   

   View Slide

8. 7
   マーケットの変化が激しいため
   予測が困難な時代です。
   また、それらが複雑に関係しあっており
   複雑かつ不確実な世の中といえます。
   デジタル革新と多様な人々の想像・創造力の融合によって、
   社会の課題を解決し、価値を創造する社会が必要とされて
   います。
   昨今のプロジェクト事情
   経団連 Society 5.0(http://www.keidanren.or.jp/policy/2018/095_honbun.pdf) をベースに作図
   

   View Slide

9. 8
   価値とは？
   ◼ サービスをお客様に提供する
   昨今のプロジェクト事情
   機能の提供 ユーザー体験の提供
   価値共創の
   コミュニティづくり
   

   View Slide

10. 9
    昨今のプロジェクト事情
    価値とは？
    ◼ イソップ寓話（3人のレンガ職人）
    

    View Slide

11. 10
    WFのように長期間開発して
    リリースすると期待と実態が
    乖離しているかもしれません。
    マーケットの流れに迅速に追随する形でリリースすること
    が求められています。
    継続的に価値を創造するアジャイル開発の取り組みが進む
    一因です。
    昨今のプロジェクト事情
    IPA いま、なぜアジャイルが必要か？(https://www.ipa.go.jp/files/000073019.pdf) をベースに作図
    

    View Slide

12. 11
    State of Agileの調査によると、アジャイル開発に
    取り組んでいる66%のプロジェクトがスクラムを採用
    昨今のプロジェクト事情
    採用しているアジャイル手法は？ 割合
    Scrum 66%
    ScrumBan 9%
    Scrum/XP hybrid 6%
    Kanban 6%
    Iterative 4%
    XP 1%
    Lean Startup 1%
    Don’t know 5%
    Other 2%
    ※State of Agile Report
    (https://digital.ai/resource-center/analyst-reports/state-of-agile-report)
    

    View Slide

13. 12
    アジャイル開発でみられる
    よくある課題
    

    View Slide

14. 13
    そもそも今回取り上げるScrumは、従来の開発プロセスの
    主流であるWFとは大きく違います。
    従来の開発とアジャイル開発の違い
    要求
    要件定義
    基本設計
    詳細設計
    コーディング
    結合テスト
    単体テスト
    総合テスト
    受入テスト
    数ヶ月以上
    

    View Slide

15. 14
    V字モデルからみた違い
    従来のプロセスでは担当がわかれていることが多い
    要求
    要件定義
    基本設計
    詳細設計
    コーディング
    結合テスト
    単体テスト
    総合テスト
    受入テスト
    開発が担当 品証が担当
    

    View Slide

16. 15
    Scrumを取り入れるとこうなりがち
    V字モデルからみた違い
    要求
    要件定義
    基本設計
    詳細設計
    コーディング
    結合テスト
    単体テスト
    総合テスト
    受入テスト
    ここだけ
    Scurmチーム化
    なぜか取り残
    される
    従来の
    開発チームだけで
    挑戦する
    

    View Slide

17. ◼ アジャイル開発に取り組んでいるはずがリリースが行わ
    れないため、フィードバックがこない
    ◼ 結局最後にテストが行われるため、プロセスの変化がな
    い
    16
    アジャイル開発に切り替えた場合に起こる課題
    Sprint 1 Sprint 2 Sprint X
    ・・・ テスト
    Sprint
    Release
    総合、受入テスト相当
    Releaseがない
    

    View Slide

18. ◼ リリースが開発に閉じている場合も変化はない
    17
    アジャイル開発に切り替えた場合に起こる課題
    Sprint 1 Sprint 2 Sprint X
    ・・・ テスト
    Sprint
    Release
    Sprint 1 Sprint 2 Sprint X
    ・・・ テスト
    Sprint
    Release
    やっぱり
    総合、受入テスト相当
    R R R
    ステークホルダーが
    やっと腰を上げる
    Releaseが開発に
    閉じている
    

    View Slide

19. 18
    ◼ 金融プロジェクト チームA 手動テストの実績
    開発とQAが一体となれなかったチームの一例
    スプリント 実施ケース 不具合件数 検出率
    (不具合件数÷実施ケース数)
    Sprint 1 630 21 3.33%
    Sprint 2 605 59 9.75%
    Sprint 3 614 114 18.75%
    Sprint 4 153 - テスト中止
    1.5ヶ月間開発をWFに戻す
    総合テスト 2,945 400 13.5%
    不具合が徐々に増加しており、Sprint 4では不具合が多発したため中止
    

    View Slide

20. ◼ 最初からプロセスを変えることはできないからと妥協
    ◼ 後追いでテストした場合、不具合を改修するころには
    次の開発を行っているためうまく反映できない
    19
    アジャイル開発に切り替えた場合に起こる課題
    Sprint 1
    開発
    Sprint 2
    開発
    Sprint 3
    開発
    ・・・
    Release
    Sprint 1
    テスト
    Sprint 2
    テスト
    Sprint X
    開発
    Sprint X-1
    テスト
    Sprint X
    テスト
    ・・・
    後追いでテスト スプリント内で不具合解
    消ができず最後にリリー
    ス
    

    View Slide

21. 20
    ◼ One Teamとなれば解決？
    課題の解決策
    要求
    要件定義
    基本設計
    詳細設計
    コーディング
    結合テスト
    単体テスト
    総合テスト
    受入テスト
    Scurmチーム化
    

    View Slide

22. ロール Day1 Day2 Day3 Day4 Day5
    プロダクト
    オーナー
    ス
    プ
    リ
    ン
    ト
    プ
    ラ
    ン
    ニ
    ン
    グ
    デ
    イ
    リ
    ー
    ス
    ク
    ラ
    ム
    デ
    イ
    リ
    ー
    ス
    ク
    ラ
    ム
    デ
    イ
    リ
    ー
    ス
    ク
    ラ
    ム
    バ
    ッ
    ク
    ロ
    グ
    リ
    フ
    ァ
    イ
    ン
    メ
    ン
    ト
    デ
    イ
    リ
    ー
    ス
    ク
    ラ
    ム
    ス
    プ
    リ
    ン
    ト
    レ
    ビ
    ュ
    ー
    レ
    ト
    ロ
    ス
    ペ
    ク
    テ
    ィ
    ブ
    プログラマ
    QA
    スクラム
    マスター
    21
    自称One Teamでも課題はある
    アジャイル開発に切り替えた場合に起こる課題
    非機能系テスト
    はいつやれば
    バックログA
    バックログA
    バックログA
    テストどこまで
    やれば
    開発とテストの
    タイミングがわ
    からない
    

    View Slide

23. 22
    ◼ 金融プロジェクト チームB 手動テストの実績
    自称One Teamの一例
    スプリント 実施ケース 不具合件数 検出率
    (不具合件数÷実施ケース数)
    Sprint 1 93 12 12.9%
    Sprint 2 158 26 16.5%
    Sprint 3 52 0 0%
    Sprint 4 222 17 7.66%
    Sprint 5 897 98 10.9%
    Blocker不具合が多くテストケースが十分に消化できていない
    

    View Slide

24. 23
    ◼ 従来との違いが多すぎて、評価方法も変える必要がある
    アジャイル開発に切り替えた場合に起こる課題
    要求
    要件定義
    基本設計
    詳細設計
    コーディング
    結合テスト
    単体テスト
    総合テスト
    受入テスト
    数か月以上
    従来と違うから
    品質の評価が
    できない
    

    View Slide

25. 24
    SHIFTが生み出した
    品質保証フレームワーク
    

    View Slide

26. 25
    ◼ 担当の違いは思った以上に影響がある
    V字モデルからみた違い 再掲
    要求
    要件定義
    基本設計
    詳細設計
    コーディング
    結合テスト
    単体テスト
    総合テスト
    受入テスト
    ここだけ
    Scurmチーム化
    なぜか取り残
    される
    従来の
    開発チームだけで
    挑戦する
    

    View Slide

27. 26
    開発とQAには障壁がある
    ◼ 開発担当 vs 品質保証担当
    ➢ 物理的な壁
    ➢ 担当部署や担当企業の違い
    ➢ 関係性の壁
    ➢ 成果物を作成する側と指摘する側の違い
    ➢ つくる側と利用する側（実際は利用しているつもり）
    ➢ よく知らない相手から指摘がくる
    ➢ そもそも品質保証担当がゲートキーパだったりする
    ➢ 後だしじゃんけん感がある
    ➢ etc...
    

    View Slide

28. 27
    ◼ 従来の活動は、不具合を検出する活動となっている
    ◼ 従来の活動は、初期の工程から「完成」をつくっている
    開発とQAに障壁があってもなぜうまくいっていたのか
    

    View Slide

29. 28
    ◼ アジャイルの場合、不具合を検出する活動では遅い
    ◼ アジャイル、とくにScrumの場合「完成の定義」が重要
    ➢ 品質が考慮されていない
    ➢ 認識がチーム内外であっていない
    ➢ 満たす状態となっていない
    アジャイルの場合どうすべきか
    

    View Slide

30. 29
    ◼ アジャイルの場合、不具合を検出する活動では遅い
    リリースに近くなるほど
    不具合の改修コストは
    高くなる
    アジャイルの場合どうすべきか
    What Is Shift-Left Testing?(https://www.parasoft.com/blog/what-is-shift-left-testing/) をベースに作図
    

    View Slide

31. 30
    ◼ アジャイルの場合、不具合を検出する活動では遅い
    ◼ Scrumの場合、スプリントは最大4週間
    ➢ 多くのプロジェクトは１～２週間スプリントを採用
    短いサイクルのなかで
    検出していては
    手遅れ
    アジャイルの場合どうすべきか
    不具合は予防するもの
    What Is Shift-Left Testing?(https://www.parasoft.com/blog/what-is-shift-left-testing/) をベースに作図
    

    View Slide

32. 31
    ◼ シフトレフトで不具合を予防する
    ➢ 自動テストを導入して早期発見
    ➢ CI/CDを回して継続的な発見
    ➢ 設計をしっかりやれば大丈夫
    アジャイルの場合どうすべきか
    と、そう単純な話ではない
    

    View Slide

33. 32
    ◼ 「完成の定義」
    ➢ プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述
    ➢ リリースできる状態を示すものともいえる
    「機能」や「要件」「価値」の状態だけではなく
    「品質」の状態も定義が必要
    アジャイルの場合どうすべきか
    

    View Slide

34. 33
    開発、QA問わず「完成の定義」に向き合う
    QAが上流工程から入ることで～ってよくいいますが
    異物混入でしかないため壁はそう簡単に破壊できない
    チームビルディングのときからいっしょになる必要がある
    チームビルディング時にどう検討すべきかが解決の鍵
    One Teamとなるためにはどうすべきか
    

    View Slide

35. 34
    ◼ チームビルディングでしっかりとテスト戦略を考える
    ◼ テスト戦略を意識した活動をする
    ◼ テスト戦略は適宜改善する
    戦略、スプリント活動両方を考えるフレームワーク
    テスト戦略 スプリント
    Start
    テストタイプ
    レベル整理
    テスト
    アプローチ
    検討
    完成の定義
    検討
    PBIの
    テスト方針
    検討
    テスト計画
    テスト
    分析・設計
    テスト
    実装・実行
    テストレ
    ビュー
    

    View Slide

36. 35
    チームビルディング時 or 適宜
    スキルマップをつくりましょう
    システム構成の検討、整理をしましょう
    これらの情報から必要なテストタイプを洗い出す
    テストレベルの整理は…
    アジャイルの場合、テストレベルはテストタイプに
    溶け込みそう
    テストタイプ、レベルの整理
    

    View Slide

37. 36
    テストタイプの共通認識をもちましょう
    ◼ 単体テスト
    ➢ ファンクションテスト？Unit TEST？単機能テスト？
    ➢ TDDやってるから大丈夫！（なにが？）
    ◼ パフォーマンステスト
    ➢ ロードテスト？ストレステスト？ロングランテスト？
    プロジェクト、組織内でも認識齟齬は容易に起きる
    各テストタイプの意味、検証内容・範囲の認識を合わせる
    必要がある
    テストタイプ、レベルの整理
    

    View Slide

38. 37
    ◼ テストアプローチとは
    特定のプロジェクト、リリース用にテスト戦略をテーラリングしたもの
    (JSTQBより)
    ➢ 分析的アプローチ
    ➢ モデルベースドアプローチ
    ➢ プロセス準拠アプローチ
    ➢ etc...
    このタイミングのテストアプローチは↑↑↑ではなく↓↓↓
    ◼ テストアプローチとは
    テストの方法です
    (A new model for test strategies より)
    各テストタイプどういった方法で実施するか検討する
    ➢ Scripted Approach（手動テスト）
    ➢ Automation Approach（自動テスト）
    ➢ Exploratory Approach（探索的テスト）
    テストアプローチの検討
    

    View Slide

39. 38
    ◼ 各テストタイプを実施するアプローチを検討
    そのテスト手動？自動？
    APIテストは？状態遷移テストは？ストレステストは？
    画面遷移テストは探索的テストでいいかもしれない…
    このタイミングで一度検討してみましょう
    さらに、チームの成熟度などによっても変化していくと思
    います
    テストアプローチの検討
    

    View Slide

40. 39
    チームビルディングの過程で
    ◼ 構成管理（ブランチ戦略など）
    ◼ 不具合管理
    ◼ etc...
    いろいろ決めていくと思います。
    検討したテストタイプをどのタイミングで実施するのかも
    完成の定義に含めてしまう
    完成の定義に含めなかったテストタイプは品質バックログ
    としてリストアップし、どこかのスプリントで解決させる
    完成の定義の検討
    

    View Slide

41. 40
    各ブランチでどのテストまで終わらせるかまで決める
    完成の定義の検討
    SAST/Unit Test
    API/E2E
    Automation Test
    共用環境Deploy
    脆弱性診断etc
    

    View Slide

42. 41
    ◼ ステージング環境へデプロイされていること
    ➢ Releaseブランチにコードがコミットされていること
    ➢ 自動テストがすべて正常終了されているコードがコミットされていること
    ◼ シナリオテストが完了していること
    ➢ 不具合のトリアージが完了していること
    ➢ 修正を後回しにした不具合はバックログリストに載っていること
    ➢ 自動テストのUnit TestとAPI Testが正常終了したコードがデプロイされている環境で実施する
    こと
    ◼ 静的解析で重大な問題が検出されていないこと
    ◼ リグレッションテストのソースもコミットされていること
    ➢ プロダクトコードだけではNG
    ➢ リグレッションテストが正常終了していること
    etc…
    完成の定義の一例
    

    View Slide

43. 42
    バックログリファインメントにおいて
    ◼ 実現した際の価値
    ◼ 対応内容
    ◼ 受入基準
    ◼ etc...
    いろいろ決めていくなかでINVESTという特性を考慮するが、
    Testableを意識する
    つまり、それぞれのバックログで実施が必要なテストタイ
    プまでチームで認識を合わせる
    PBIのテスト方針検討
    

    View Slide

44. 43
    いざリファインメントしてみたら考慮不足などあると思います
    見ないふりせずしっかり向き合いましょう
    PBIのテスト方針検討後振り出しに戻ることもある
    テスト戦略 スプリント
    Start
    テストタイプ
    レベル整理
    テスト
    アプローチ
    検討
    完成の定義
    検討
    PBIの
    テスト方針
    検討
    テスト計画
    テスト
    分析・設計
    テスト
    実装・実行
    テストレ
    ビュー
    

    View Slide

45. 44
    スプリントでは
    ◼ QAもスプリントイベントに参加する
    ◼ レトロスペクティブなどでテスト戦略を見直すときは全員で考える
    ◼ 完成の定義を満たしているかをつねに確認していく
    ◼ テストのレビューはスプリントレビューではない
    といったことに注意して活動しましょう
    バックログリファンメントにも参加しているので、開発と
    並行してテスト分析、設計が行えます。
    テスト観点をチームで共有することで不具合の予防にもつ
    ながります。
    スプリント
    

    View Slide

46. 45
    フレームワークを活用した効果
    

    View Slide

47. 46
    ◼ 金融プロジェクト チームA 手動テストの実績
    フレームワークを適用した効果
    スプリント 実施ケース 不具合件数 検出率
    (不具合件数÷実施ケース数)
    Sprint 1 630 21 3.33%
    Sprint 2 605 59 9.75%
    Sprint 3 614 114 18.75%
    Sprint 4 153 - テスト中止
    1.5ヶ月間開発をWFに戻す
    総合テスト 2,945 400 13.5%
    スプリント 実施ケース 不具合件数 検出率
    (不具合件数÷実施ケース数)
    Sprint 1 758 5 0.6%
    Sprint 2 1,282 14 1.09%
    Sprint 3 1,277 23 1.8%
    Sprint 4 592 8 1.35%
    Sprint 5 966 18 1.86%
    ※メンバーはほぼ同じですが、一部QAメンバーがSHIFTに変更されています
    ※担当するプロダクトの規模、難易度は上がっています
    不具合の検出率が下がっており予防傾向にある
    ※本番障害6ヶ月間ゼロ
    

    View Slide

48. 47
    ◼ 金融プロジェクト チームB 手動テストの実績
    フレームワークを適用した効果
    スプリント 実施ケース 不具合件数 検出率
    (不具合件数÷実施ケース数)
    Sprint 1 93 12 12.9%
    Sprint 2 158 26 16.5%
    Sprint 3 52 0 0%
    Sprint 4 222 17 7.66%
    Sprint 5 897 98 10.9%
    スプリント 実施ケース 不具合件数 検出率
    (不具合件数÷実施ケース数)
    Sprint 1 715 8 1.11%
    Sprint 2 448 5 1.11%
    Sprint 3 534 24 4.49%
    Sprint 4 973 17 1.74%
    Sprint 5 741 18 2.42%
    テストケースの消化が安定に向かいながら、不具合も予防傾向にある
    ※本番障害6ヶ月間5件
    ※メンバーはほぼ同じですが、一部QAメンバーがSHIFTに変更されています
    ※担当するプロダクトの規模、難易度は上がっています
    

    View Slide

49. 48
    ◼ 開発とQAが協力しあいながら作業を行う
    フレームワークを適用した効果
    ロール Day1 Day2 Day3 Day4 Day5
    プロダクト
    オーナー
    ス
    プ
    リ
    ン
    ト
    プ
    ラ
    ン
    ニ
    ン
    グ
    デ
    イ
    リ
    ー
    ス
    ク
    ラ
    ム
    デ
    イ
    リ
    ー
    ス
    ク
    ラ
    ム
    デ
    イ
    リ
    ー
    ス
    ク
    ラ
    ム
    バ
    ッ
    ク
    ロ
    グ
    リ
    フ
    ァ
    イ
    ン
    メ
    ン
    ト
    デ
    イ
    リ
    ー
    ス
    ク
    ラ
    ム
    ス
    プ
    リ
    ン
    ト
    レ
    ビ
    ュ
    ー
    レ
    ト
    ロ
    ス
    ペ
    ク
    テ
    ィ
    ブ
    プログラマ
    QA
    スクラム
    マスター
    バックログA
    設計・開発
    バックログA
    テスト
    分析・設計
    改修内容の共通認識が
    あるため開発とテストが
    同時に設計できる
    バックログA
    開発
    I/Oを先に固めることで
    QAに影響を出さずに改修
    バックログA
    テスト実行
    担当するテスト
    に集中
    必要に応じて
    テスト観点の
    フィードバック
    

    View Slide

50. 49
    ◼ 今回はチーム全体で品質を意識するフレームワーク
    ◼ ただ流れに沿うだけでは目的が達成できない
    フレームワークを妄信してはいけない
    テスト戦略 スプリント
    Start
    テストタイプ
    レベル整理
    テスト
    アプローチ
    検討
    完成の定義
    検討
    PBIの
    テスト方針
    検討
    テスト計画
    テスト
    分析・設計
    テスト
    実装・実行
    テストレ
    ビュー
    

    View Slide

51. 50
    まとめ
    

    View Slide

52. 51
    ◼ 紹介したフレームワークはあくまでスターターキット
    ◼ チームの成熟度が上がるにつれて変化していく
    まとめ
    テスト戦略 スプリント
    Start
    テストタイプ
    レベル整理
    テスト
    アプローチ
    検討
    完成の定義
    検討
    PBIの
    テスト方針
    検討
    テスト計画
    テスト
    分析・設計
    テスト
    実装・実行
    テストレ
    ビュー
    

    View Slide

53. 52
    VUCA時代、アジャイル開発への取り組みが進んでいるが
    プロジェクトは
    ◼ 不具合予防する活動に変化する
    ◼ MVPには「完成の定義」の共通認識が大切
    まとめ
    

    View Slide

54. View Slide