分析可能なアジャイルQAでの取り組み
- 2. © DMM.com 2 自己紹介 名前：花上 豊幸(はなうえ ひろゆき) 所属：テクノロジー本部 QA部 2020年9月入社 勤務先：六本木本社(普段は、神奈川自宅でフルリモート) 【社内】 QA部を横断しての • テスト自動化の推進 • 不具合分析などのデータ分析基盤の構築 を担当しています 【社外】 副業として • QA組織の立ち上げ/改善提案 • テスト自動化の推進 などの業務を請負いをさせて頂いております
- 3. © DMM.com 3 目次 ● 背景 ● 分析可能な運用改善 ○ 観点チャーター ● アジャイルQAでの分析 ○ ゾーン分析 ○ メトリクス分析 ● まとめ
- 4. © DMM.com 背景
- 5. © DMM.com 5 背景 ● アジャイルQAの取り組みの中で, 開発中での不具合の約9割が探索的テストによる 検出 ● 探索的テストによる課題 ○ 第三者がテストスコープを把握しづらい ○ 属人化が進み他QAメンバーによるフォローやアサイン調整が行いづらい ○ 検出した不具合以外の指標がなく品質状態を判断/分析しづらい ➔「観点チャーター」の導入による分析可能な探索的テストの運用改善を提案
- 7. © DMM.com 7 分析可能な運用改善_観点チャーター(1/5) ● チャーターとは? ○ 探索的テストの手法の一つ ■ 「対象」「資源」「情報」を整理したチャーターを作成し, チャーターに基づいて探索的テストを 行う手法 ○ メリット ■ 探索的テストのテストスコープを第三者が把握しやすい ■ チャーターを残して行くことでナレッジの蓄積が可能 ○ デメリット ■ チャーターの作成に準備工数がかかる ■ ナレッジ化したチャーターが形骸化しやすい ➔アジャイルQAでも1度運用し, チャーターの作成を行ったが 運用されない結果となっていた
- 8. © DMM.com 8 分析可能な運用改善_観点チャーター(2/5) ● 観点チャーターの説明 ○ 検証観点ベースでのチャーターを作成 ○ 大分類として「機能系」「非機能系」に分けて, 検証対象となる機能や画面, 検証観点などを一 覧として整理する
- 9. © DMM.com 9 分析可能な運用改善_観点チャーター(3/5) ● 機能系 ○ 要件や仕様として明確となっている, 機能やデザイン/レイアウトなどの検証対象をベースの観 点に沿って検証観点としてまとめる
- 10. © DMM.com 10 分析可能な運用改善_観点チャーター(4/5) ● 非機能系 ○ 要件や仕様として明確に定義されていないが, 一般的に発生しうる操作や環境などによる検証 観点をまとめる
- 11. © DMM.com 11 分析可能な運用改善_観点チャーター(5/5) ● 観点チャーターの目的 ○ 観点チャーターから第三者がテストスコープを把握できる ○ 観点チャーターベースでのレビューが可能となる ■ レビュー指摘や開発からの確認依頼等も項目として反映可能 ○ 観点チャーターのテンプレートや参考資料での観点一覧などを作成することでナレッジ化が可 能となる ■ 各観点の不具合傾向などから分析を行い, テンプレートや観点一覧など反映することで, 探索的テストの改善が可能に ➔属人化の軽減につながる
- 13. © DMM.com 13 アジャイルQAでの分析_ゾーン分析(1/3) ● ゾーン分析とは? ○ 「テスト密度」と「バグ密度」から不具合検出の累積グラフを算出し, 不具合検出の推移がグラフ 上のどのゾーンに該当しているかを分析する手法 参照 ：https://www.qbook.jp/column/20190417_755.html
- 14. © DMM.com 14 アジャイルQAでの分析_ゾーン分析(2/3) ● アジャイルQAでのゾーン分析 ○ テスト密度の代わりに観点チャーターの検証観点に紐付ける形で不具合検出の累積グラフを 算出 ○ 不具合の見積もり件数からゾーン1(中央)の領域を設定し, どのゾーンに属するか, 不具合が多 く検出された観点などを分析する 不具合の累積 チャーター観点
- 15. © DMM.com アジャイルQAでの分析_ゾーン分析(3/3) ● ゾーン分析の仮説 ○ 視覚的に検証結果による品質状況が把握しやすくなる ○ 検証の早い段階での仕切り直しなどが判断できる ○ 不具合見積もりにより不具合による想定外の開発工数などを 軽減できる ➔各観点の不具合の検出傾向を分析し, 観点チャーターに反映する ことで探索的テストの改善を行う分析も実施 15
- 16. © DMM.com 16 アジャイルQAでの分析_メトリクス分析(1/2) ● アジャイルQAでのメトリクス分析の取り組み ○ 短いスプリント内では統計的なデータ分析は統計上の性質から現実的ではない ○ スプリントを跨いだ開発規模(コミット差分)や不具合チケットの累積に対して メトリクス分析を実施
- 17. © DMM.com 17 アジャイルQAでの分析_メトリクス分析(2/2) ● メトリクス分析の仮説 ○ 探索テストはプルリクベースで行っているため, 「修 正数(開発量)」と「不具合数」の推移から不具合傾 向や品質状況等が把握できる ■ 修正数に対する不具合数の推移に異常値が ないか ■ 過去と現在で修正数に対する不具合数の推移 に変化があった場合 ○ 不具合の起票とクローズの推移 ➔曲線が開き続けている場合などに,新機能の対応ではなく 不具合改善やリファクタリング等のスプリント計画などを提 案
- 18. © DMM.com まとめ
- 19. © DMM.com 19 まとめ(1/2) ● 探索的テストによる課題 ○ 第三者がテストスコープが把握しづらい ➔観点チャーターにより第三者でもテストスコープが把握可能に ○ 属人化が進み他QAメンバーによるフォローやアサイン調整が行いづらい ➔観点チャーターをベースにリーダがレビュー可能となるため, フォローやア サイン調整の敷居が低下 ○ 検出した不具合以外の指標がなく品質状態を判断/分析しづらい ➔ゾーン分析/メトリクス分析から品質状態の判断/分析が可能に
- 20. © DMM.com 20 まとめ(2/2) ● 今回は取り組みを始めたばかりのため, 具体的な成果としての発表はできなかった ので, 次の機会に成果発表ができるように取り組みを行っていきたい ● 現状では担当者の経験/勘所で判断している品質状態を, 最終的にはデータから品 質状況を判断できるデータ基盤や運用体制を構築したい ● アジャイルの特性上, 完全な属人化解消は現実てきではないため適度な属人化を調 整する必要がある ● 分析可能な体制づくりは属人化の軽減にもつながっているので, 今後も可能な範囲 での改善を行っていきたい