Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

SHIFT_EVOLVE
February 28, 2023

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

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

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

SHIFT_EVOLVE

February 28, 2023
Tweet

More Decks by SHIFT_EVOLVE

Other Decks in Business

Transcript

  1. 1 自己紹介 ◼ 名前:船橋 篤史 ◼ 所属:株式会社SHIFT​ ◼ 経歴: ◼

    アジャイル開発体制構築、自動テスト導入 ◼ Windowsネイティブアプリケーションのクラウドリフト ◼ Webアプリケーションのクラウドシフト ◼ 基幹システム構築 ◼ etc…
  2. 社名 株式会社 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兆円のブルーオーシャン市場で圧 勝
  3. 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デザイン構築をご支援 開発/インフラ支援 目的に対する確かな手段をご支援 セキュリティ支援 事業インシデントコスト削減をご支援 人材育成支援 自走化実現への育成をご支援
  4. 「品質保証の会社」から「売れるサービスを一緒につくる会社」へ 4 SHIFTは お客様のビジネス成功に コミットする会社に 「ソフトウェアテスト」 といえばSHIFT 「DX」 「売れるサービスづくり」 といえばSHIFT

    第一想起 第一想起 ソフトウェアのテストを 受託する会社 SHIFTグループは、ソフトウェア品質を起点にDXや新たな価値創造を実現し、 日本の社会問題に挑戦する会社です。
  5. 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)
  6. 15 Scrumを取り入れるとこうなりがち V字モデルからみた違い 要求 要件定義 基本設計 詳細設計 コーディング 結合テスト 単体テスト

    総合テスト 受入テスト ここだけ Scurmチーム化 なぜか取り残 される 従来の 開発チームだけで 挑戦する
  7. ◼ リリースが開発に閉じている場合も変化はない 17 アジャイル開発に切り替えた場合に起こる課題 Sprint 1 Sprint 2 Sprint X

    ・・・ テスト Sprint Release Sprint 1 Sprint 2 Sprint X ・・・ テスト Sprint Release やっぱり 総合、受入テスト相当 R R R ステークホルダーが やっと腰を上げる Releaseが開発に 閉じている
  8. 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では不具合が多発したため中止
  9. ◼ 最初からプロセスを変えることはできないからと妥協 ◼ 後追いでテストした場合、不具合を改修するころには 次の開発を行っているためうまく反映できない 19 アジャイル開発に切り替えた場合に起こる課題 Sprint 1 開発

    Sprint 2 開発 Sprint 3 開発 ・・・ Release Sprint 1 テスト Sprint 2 テスト Sprint X 開発 Sprint X-1 テスト Sprint X テスト ・・・ 後追いでテスト スプリント内で不具合解 消ができず最後にリリー ス
  10. 20 ◼ One Teamとなれば解決? 課題の解決策 要求 要件定義 基本設計 詳細設計 コーディング

    結合テスト 単体テスト 総合テスト 受入テスト Scurmチーム化
  11. ロール Day1 Day2 Day3 Day4 Day5 プロダクト オーナー ス プ

    リ ン ト プ ラ ン ニ ン グ デ イ リ ー ス ク ラ ム デ イ リ ー ス ク ラ ム デ イ リ ー ス ク ラ ム バ ッ ク ロ グ リ フ ァ イ ン メ ン ト デ イ リ ー ス ク ラ ム ス プ リ ン ト レ ビ ュ ー レ ト ロ ス ペ ク テ ィ ブ プログラマ QA スクラム マスター 21 自称One Teamでも課題はある アジャイル開発に切り替えた場合に起こる課題 非機能系テスト はいつやれば バックログA バックログA バックログA テストどこまで やれば 開発とテストの タイミングがわ からない
  12. 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不具合が多くテストケースが十分に消化できていない
  13. 25 ◼ 担当の違いは思った以上に影響がある V字モデルからみた違い 再掲 要求 要件定義 基本設計 詳細設計 コーディング

    結合テスト 単体テスト 総合テスト 受入テスト ここだけ Scurmチーム化 なぜか取り残 される 従来の 開発チームだけで 挑戦する
  14. 26 開発とQAには障壁がある ◼ 開発担当 vs 品質保証担当 ➢ 物理的な壁 ➢ 担当部署や担当企業の違い

    ➢ 関係性の壁 ➢ 成果物を作成する側と指摘する側の違い ➢ つくる側と利用する側(実際は利用しているつもり) ➢ よく知らない相手から指摘がくる ➢ そもそも品質保証担当がゲートキーパだったりする ➢ 後だしじゃんけん感がある ➢ etc...
  15. 30 ◼ アジャイルの場合、不具合を検出する活動では遅い ◼ Scrumの場合、スプリントは最大4週間 ➢ 多くのプロジェクトは1~2週間スプリントを採用 短いサイクルのなかで 検出していては 手遅れ

    アジャイルの場合どうすべきか 不具合は予防するもの What Is Shift-Left Testing?(https://www.parasoft.com/blog/what-is-shift-left-testing/) をベースに作図
  16. 34 ◼ チームビルディングでしっかりとテスト戦略を考える ◼ テスト戦略を意識した活動をする ◼ テスト戦略は適宜改善する 戦略、スプリント活動両方を考えるフレームワーク テスト戦略 スプリント

    Start テストタイプ レベル整理 テスト アプローチ 検討 完成の定義 検討 PBIの テスト方針 検討 テスト計画 テスト 分析・設計 テスト 実装・実行 テストレ ビュー
  17. 36 テストタイプの共通認識をもちましょう ◼ 単体テスト ➢ ファンクションテスト?Unit TEST?単機能テスト? ➢ TDDやってるから大丈夫!(なにが?) ◼

    パフォーマンステスト ➢ ロードテスト?ストレステスト?ロングランテスト? プロジェクト、組織内でも認識齟齬は容易に起きる 各テストタイプの意味、検証内容・範囲の認識を合わせる 必要がある テストタイプ、レベルの整理
  18. 37 ◼ テストアプローチとは 特定のプロジェクト、リリース用にテスト戦略をテーラリングしたもの (JSTQBより) ➢ 分析的アプローチ ➢ モデルベースドアプローチ ➢

    プロセス準拠アプローチ ➢ etc... このタイミングのテストアプローチは↑↑↑ではなく↓↓↓ ◼ テストアプローチとは テストの方法です (A new model for test strategies より) 各テストタイプどういった方法で実施するか検討する ➢ Scripted Approach(手動テスト) ➢ Automation Approach(自動テスト) ➢ Exploratory Approach(探索的テスト) テストアプローチの検討
  19. 39 チームビルディングの過程で ◼ 構成管理(ブランチ戦略など) ◼ 不具合管理 ◼ etc... いろいろ決めていくと思います。 検討したテストタイプをどのタイミングで実施するのかも

    完成の定義に含めてしまう 完成の定義に含めなかったテストタイプは品質バックログ としてリストアップし、どこかのスプリントで解決させる 完成の定義の検討
  20. 41 ◼ ステージング環境へデプロイされていること ➢ Releaseブランチにコードがコミットされていること ➢ 自動テストがすべて正常終了されているコードがコミットされていること ◼ シナリオテストが完了していること ➢

    不具合のトリアージが完了していること ➢ 修正を後回しにした不具合はバックログリストに載っていること ➢ 自動テストのUnit TestとAPI Testが正常終了したコードがデプロイされている環境で実施する こと ◼ 静的解析で重大な問題が検出されていないこと ◼ リグレッションテストのソースもコミットされていること ➢ プロダクトコードだけではNG ➢ リグレッションテストが正常終了していること etc… 完成の定義の一例
  21. 42 バックログリファインメントにおいて ◼ 実現した際の価値 ◼ 対応内容 ◼ 受入基準 ◼ etc...

    いろいろ決めていくなかでINVESTという特性を考慮するが、 Testableを意識する つまり、それぞれのバックログで実施が必要なテストタイ プまでチームで認識を合わせる PBIのテスト方針検討
  22. 44 スプリントでは ◼ QAもスプリントイベントに参加する ◼ レトロスペクティブなどでテスト戦略を見直すときは全員で考える ◼ 完成の定義を満たしているかをつねに確認していく ◼ テストのレビューはスプリントレビューではない

    といったことに注意して活動しましょう バックログリファンメントにも参加しているので、開発と 並行してテスト分析、設計が行えます。 テスト観点をチームで共有することで不具合の予防にもつ ながります。 スプリント
  23. 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ヶ月間ゼロ
  24. 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に変更されています ※担当するプロダクトの規模、難易度は上がっています
  25. 48 ◼ 開発とQAが協力しあいながら作業を行う フレームワークを適用した効果 ロール Day1 Day2 Day3 Day4 Day5

    プロダクト オーナー ス プ リ ン ト プ ラ ン ニ ン グ デ イ リ ー ス ク ラ ム デ イ リ ー ス ク ラ ム デ イ リ ー ス ク ラ ム バ ッ ク ロ グ リ フ ァ イ ン メ ン ト デ イ リ ー ス ク ラ ム ス プ リ ン ト レ ビ ュ ー レ ト ロ ス ペ ク テ ィ ブ プログラマ QA スクラム マスター バックログA 設計・開発 バックログA テスト 分析・設計 改修内容の共通認識が あるため開発とテストが 同時に設計できる バックログA 開発 I/Oを先に固めることで QAに影響を出さずに改修 バックログA テスト実行 担当するテスト に集中 必要に応じて テスト観点の フィードバック
  26. 49 ◼ 今回はチーム全体で品質を意識するフレームワーク ◼ ただ流れに沿うだけでは目的が達成できない フレームワークを妄信してはいけない テスト戦略 スプリント Start テストタイプ

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

    レベル整理 テスト アプローチ 検討 完成の定義 検討 PBIの テスト方針 検討 テスト計画 テスト 分析・設計 テスト 実装・実行 テストレ ビュー