アジャイル開発に最適なQA『アジャイルQA』の導入
- 2. © DMM.com 2 自己紹介 名前：菊知伸征 所属：テクノロジー本部 QA部 2004年入社 勤務先：金沢事業所 DMMのプラットフォーム開発、サービスのバックエンド開発、スクラムマスターな どを経てQA部へ所属
- 3. © DMM.com 3 背景 スクラム開発を行っているチームへ品質改善活動の課題解決を行うためにQAとして配属 ● スクラム開発を始めて1年 ● QAメンバーはなし ● テストが計画通りに実施できていない ● よくリリースが遅延する
- 4. © DMM.com 4 スクラムチームに参加してわかった問題 ● 各ストーリーが成果物ベースではなく個人のタスク粒度になっている ○ 実装自体がスケジュールに収まらず、テストする時間がなくなる ○ テスト対象わかりずらいので、途中でテストが増加する ○ テスト漏れでリリース直前にバグが見つかり再度テストすることに 考えられる原因 バグが多い時にバッファが足りなくなりリリースが遅れている
- 5. © DMM.com 5 今回の目標 1. 計画的な実装と計画的なテスト 2. 効率の良いテストフローの構築 バグが多い時にバッファが足りなくなりリリースが遅れている 実施する対策 品質を担保しつつスケジュールが押さないスクラム開発とテ ストのフローを整備する
- 6. © DMM.com 6 進め方 2020年 2021年 9月 1月 2月 3月 4月 5月 6月 7月 8月 9月 スクラム整備 テストフロー構築 状況の把握 ストーリー粒度やスプリント計画を改善（ Try&Error） テスト方法の検討 テストフローの改善（ Try&Error）
- 7. © DMM.com 7 最初の状態 計画 実装 テスト ストーリー1 (タスク) ストーリー2 (タスク) 機能 テスト FIX ストーリー2 修正 対象を決める FIX ストーリー1 リリース スプリント1 スプリント2 ストーリーの実装後のテストでバグが出ると修正が持ち越す ● テスト対象がわかりづらく、確認などでテスト開始が遅れる ● テストに穴が見つかってテスト期間が増加する テスト 機能テスト ストーリー2 ストーリー1 遅延 ストーリー3 (タスク) FIX ストーリー3 ストーリー3 対策：各画面や機能で実装、及び検証できる粒度になるよう変更 機 能 テ スト テスト対象や範囲がはっきりしないので穴が見つかる
- 8. © DMM.com 8 課題 -ストーリー調整- 各ストーリーが成果物ベースになっておらず、個人のタスクのような粒度になっている ● どのストーリーに対してテストを実施すべきかわからない ● テスト結果が期待通りかどうか判断できない（穴が見つかる） データ取得APIの実装 ストーリー1 CSSの修正 ストーリー2 検索機能 マイページ トップページ 管理画面 テスト？ テスト？ テスト？ テスト？ 何のデータ？ どこのページ？
- 9. © DMM.com 9 ● テストを実施する対象がはっきりする ● テスト項目に照らし合わせやすく期待値が明確になる ● テスト計画が立てやすくなる ● テストの穴に気がつきやすくなる 対策 -ストーリー調整- 各画面や機能で実装、及び検証できる粒度になるよう変更 検索した商品が一覧 ページに表示される データ取得 APIの実装 トップページのバナーを 画面上部に移動する CSSを修正 検索ワードに一致した商品が一覧に表示されること バナーがトップページの上部に表示されていること ストーリー1 ストーリー2 期待値 期待値
- 10. © DMM.com 10 次の問題 ストーリーは整理したが・・・ 計画 実装 テスト ストーリー3 ストーリー2 機能テスト FIX ストーリー2 修正 対象を決める FIX ストーリー3 FIX リリース スプリント1 スプリント2 すべてのストーリーが実装完了後にテスト行っている体制では、不具合の結果によりすべてのストー リーのリリースが遅延する状況となっていた テスト 機能テスト ストーリー2 ストーリー3 遅延 対策：実装中にこまめにテストが行えるようにストーリーを分解し、テスト自体も素早くフィードバックが得られる方法に変更する ストーリー1 ストーリー1 ストーリー1
- 11. © DMM.com 検索した商品が一覧ページに表示される 11 ストーリー粒度の問題 適切なフィードバックを得られる粒度になっていない 検索した商品が一覧 ページに表示される データ取得 APIの実装 ストーリー1 実際のタスク構成は データ取得 APIの実装 データベース の構築 商品一覧ペー ジのデザイン 成果物のサイズが大きすぎる 全タスクが完了するまでテストできない フィードバックの量が多い 予定していたテスト期間を超過する ● 大きすぎるストーリーは、テスト可能になるまで時間がかかる ● フィードバックの量が多くなると、修正期間が延長されるリスクが上がる
- 12. © DMM.com 12 粒度を細分化して素早くフィードバック 細かくフィードバックをえる為に探索的テスト採用する 検索した商品が一覧ページに表示される データ取得 APIの実装 データベース の構築 商品一覧ペー ジのデザイン 静的な検索結果 ページを作成する モックデータで 検索結果ページを 作成する 全データで 検索結果ページを 作成する 分解 ● ストーリーを小さくすると、検証範囲も減り短期間でフィードバックまで可能になる ● 機能一覧で全て検証するより、要点を絞った探索的テストでバグ発見が効率的になる ● 小さい単位でスケジュールの調整が可能になる 探索的テストを実施 探索的テストを実施 探索的テストを実施 ストーリー1
- 13. © DMM.com スプリント1 13 現在の状態 改善後のスクラム体制に合わせたテストフローを構築 計画 実装／修正 テスト 対象を決める リリース ストーリー1-1 探索的テスト ストーリー1-1 FIX ストーリー1-2 探索的テスト リリース 取りやめ 判 断 ストーリー2／探索的テスト ストーリー2 FIX 実装後すぐに検証し結果をられるので、修正作業の効率がよくなる。 また、テストの結果をすぐに判断し、リリースする対象を部分的に変更することで全体的なリリース遅延を減らすことが 出来る。 スクラムチームにQAが深く入り込こむことが出来れば、 プロダクトの理解が深くなり効率のよい探索的テストが行える 計画 探索的テストだけでも品質を担保できる体制が構築できる スプリント2 ９割以上の 不具合を検出 ストーリー3／探索的テスト ストーリー3 FIX ストーリー1-2 探索的テスト 対象を決める ストーリー1-1 ストーリー2 ストーリー3
- 14. © DMM.com 14 まとめ ● ストーリーを整備することが、品質向上の最初の一歩 ● 最後にまとめて実施ではなく可能な限り細かく実施、細かくフィードバック ● プロダクトのことをよく知り探索的テストで品質を担保する ● リリースの遅延を最小限にするには、見積もりやすく、且つ柔軟な計画が必要
- 15. © DMM.com 15 今後やっていきたいこと 1. 発生した不具合の分析をして、不具合発生を未然に防ぐ 2. テストの自動化ができるところは自動化していく 3. プロダクトをよく知ることは重要ではあるが、属人化しやすいとこ ろをなんとかする