Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK

4,524 views

Published on

ソフトウェア品質シンポジウム2014での経験発表のスライドです。
http://www.juse.jp/sqip/symposium/detail/day1/#session_A1-3

10/09追記:ブログ記事書きました http://kokotatata.hatenablog.com/entry/2014/10/08/111353

(色の表示がslideshare上で少し変になってますので、ダウンロードした方がよいかもしれません。)

JaSSTではシステムテストを自動化するとバグ修正日数が改善するというメリットについてお話ししました。
http://www.slideshare.net/kotaroogino/jasst14-tokyo

SQiPではメトリクスを分析する事で、テストの自動化にはどういった課題があるか問題提起を行ったり、我々が行っている改善の施策を客観的にお話ししました。

Published in: Technology
  • Be the first to comment

【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK

  1. 1. 継続的システムテストについての 理解を深めるための 開発とバグのメトリクスの分析 2014/09/11 荻野 恒太郎 kotaro.ogino@mail.rakuten.com Search Platform Group, Search Section, Big Data Department, Rakuten Inc. http://www.rakuten.co.jp/
  2. 2. 2 アジェンダ バックグラウンド メトリクス 分析① 分析② 分析③ まとめと今後の課題
  3. 3. 3 バックグラウンド メトリクス 分析① 分析② 分析③ まとめと今後の課題
  4. 4. 4 背景①:開発プロセスの変化とシステムテスト • ウォーターフォールからアジャイルへ 平鍋 健児, ”ソフトウェア工学の分岐点における、アジャイルの役割” SS2010. • 早期からのシステムテストの実施 永田 敦, “アジャイル開発における品質保証部門によるシステムテストの アプローチ” JASPIC2013. • 継続的システムテスト 荻野ら, ”システムテスト自動化による大規模分散検索プラットフォームの 設計 実装 (ST) 要求(スコープ) 分析 設計 実装 システムテスト(ST) 自動化前 自動化後 時間 要求(スコープ) 時間 分析 開発工程改善” JaSST’ Tokyo 2014. 自動化により システムテストを 日次で実行
  5. 5. 5 背景②:継続的システムテストのメリット テスト自動化に関する通説 • 品質と、コストとデリバリーはトレードオフ  → 品質保証が開発プロセスから独立している事を仮定 継続的システムテスト • 自動化する事でシステムテストを開発プロセスに取り込む事が可能
  6. 6. 6 背景②:継続的システムテストのメリット システムテストを開発プロセスに取り込む JaSST’14 Tokyoの発表より
  7. 7. 7 背景②:継続的システムテストのメリット バグ修正日数が改善 JaSST’14 Tokyoの発表より
  8. 8. 8 背景②:継続的システムテストのメリット テスト自動化に関する通説 • 品質と、コストとデリバリーはトレードオフ  → 品質保証が開発プロセスから独立している事を仮定 継続的システムテスト • 自動化する事でシステムテストを開発プロセスに取り込む事が可能 バグ修正日数が減少  = コストとデリバリーも改善
  9. 9. システムテスト自動化への疑問 疑問②: システムテストを開発プロセスに取り込むって? 9 本発表の目的と手法 疑問①: 自動化されたシステムテストは質が低い? 疑問③: 開発をうまく進めるのに必要な工夫は? 目的: 継続的システムテスト環境下での 開発とシステムテストへの理解を深める事 手法: 開発、プロダクトとバグのメトリクスの分析
  10. 10. 継続的システムテストの “ありのままの姿” 10
  11. 11. 11 バックグラウンド メトリクス 分析① 分析② 分析③ まとめと今後の課題
  12. 12. 12 分析対象のメトリクス 開発者 開発メトリクス 日次の • コミット数 • コミットサイズ コミット ソースコード レポジトリ ビルド テスト バグ レポート プロダクトメトリクス 日次の • LOC      • 変更ファイル数 • 変更LOC • 追加ファイル数 • 追加LOC • 削除ファイル数 • 削除LOC • 変更なしファイル数 • 無変更LOC バグメトリクス 日次の • 検出バグ数
  13. 13. 13 メトリクスの収集方法 グループ メトリクス名 収集方法 単位 開発メトリクス 日次のコミット数 git log (*1) 回数 日次のコミットサイズ git log (*2) 行数 プロダクトメトリクス 日次のLOC cloc (*3)  行数 日次の変更LOC 日次の追加LOC 日次の削除LOC 日次の変更無しLOC cloc –diff (*4) 行数 日次の変更ファイル 日次の追加ファイル 日次の削除ファイル 日次の変更なしファイル cloc –diff (*4) ファイル数 バグメトリクス 日次のプロダクトの 検出バグ数 - システムテストで発見され たバグ -バグ票の作成日で集計 - 同じ欠陥に由来する モノは新しい方を削除 回数 (*1) https://www.atlassian.com/ja/git/tutorial/git-basics#!log (*2) コメント等を含む (*3) http://cloc.sourceforge.net/ (*3)(*4) 開発言語はJava。コメント等を含まない
  14. 14. 14 分析対象のメトリクス(2013年度1/28~10/23) コミット数とコミットサイズ 日次のコミット数の分布 コミット数 コミットサイズ 25000 20000 15000 10000 5000 0 40 30 20 10 0 Commit Commit size 200 150 100 50 0 0〜4 5〜9 10〜 14 15〜 19 20〜 24 25〜 29 30〜 34 一日のコミット数 日次の検出バグ数の分布 1日で見つかった検出バグ数 250 200 150 100 50 0 0 1 2 3 4 5 変更 LOC 追加 LOC 削除 LOC 2000 0 2000 0 2000 1000 0 時間 LOC 時間 行数 頻度 頻度
  15. 15. 15 分析対象の開発プロジェクトの開発フェーズ 大きな 機能要件 システム リファクタリング 断続的な 小さな要件 受け入れ テスト 受け入れ テスト • 継続的な開発とテストが特徴 1400 1200 1000 800 600 400 200 0 90 80 70 60 50 40 30 20 10 0 累積検出バグ数 累積コミット数 A B C 開発フェーズ 検出バグ数 コミット数 99日間 100日間 84日間
  16. 16. 16 継続的システムテストの特徴について考察 従来のシステムテスト 継続的システムテスト STの位置 実装の後 実装と平行して同時 役割 品質の門番 (品質の門番) リグレッションテスト テストの追加 信頼度成長曲線を 見ながらテスト工程で ユーザーストーリーと コードカバレッジを 見ながら実装工程で テスト期間中の コード変更 バグ修正のみ ある リファクタリング 少ない 多い
  17. 17. 17 バックグラウンド メトリクス 分析① 分析② 分析③ まとめと今後の課題
  18. 18. 18 分析①: 自動化されたシステムテストの評価 疑問①: 自動化されたシステムテストは質が低い? 分析①の目的 分析対象のプロジェクトのテストの質を調べるため テスト密度とバグ密度で業界標準と比較 • 我々の開発プロセスを逐次的なミニウォーターフォールと考え   バグとテスト追加の安定している下記のA,B,C3点で計測 累積検出バグ数 3月 5月 7月 9月 A B C
  19. 19. 19 分析①:自動化されたシステムテストの評価 2 1.5 1 0.5 IPAが提供する業界標準の値 (*1) ”ソフトウェア開発データ白書 2012-2013 定量データ分析で分かる開発の最新動向”より 50 40 30 20 10 0 新規開発 改良開発 0 新規開発 改良開発 評価指標 • バグ密度とテスト密度 • IPAが提供する業界標準の値と比較 (*1) - 最小値、P25, 中央値、P75, 最大値 → P25 ~ P75の区間が一つの目安 - 主要言語Javaの値を使用 - 新規開発と改良開発 テスト密度 バグ密度 テスト密度 = テストケース数 ÷ KLOC バグ密度 = 検出バグ数 ÷ KLOC
  20. 20. 20 分析①:テスト密度の業界標準との比較 50 40 30 20 10 0 テスト密度 (18.64) (28.71) (38.76) A B C 50 40 30 20 10 0 新規開発 改良開発 本プロジェクト 業界標準 考察: - テスト件数は規模に対して標準的 - テスト密度が継続して上昇 → フレームワークやDSLの完成後テスト追加が容易に - Cの期間ではテスト密度が若干業界標準より高い → システムテストの件数やカバレッジのための指標が必要
  21. 21. 21 分析①:バグ密度の業界標準との比較 2 1.5 1 0.5 0 新規開発 改良開発 2 1.5 1 0.5 0 バグ密度 (0.74) (0.08) (0.31) A B C 本プロジェクト 業界標準 考察: - 断続的な小さい要件のBの期間で小さいバグ密度 - 機能追加のないシステムのリファクタリングのCの期間でもバグを検出 → リファクタリングによるリグレッションを自動テストが検出 - 全体を通し業界標準のバグ密度 → バグカーブが収束するようなリグレッションテストと推察
  22. 22. 22 バックグラウンド メトリクス 分析① 分析② 分析③ まとめと今後の課題
  23. 23. 疑問②: システムテストを開発プロセスに取り込むって? 23 分析②:開発メトリクスとバグの関係 分析②の目的 プロダクトメトリクスだけでなく、開発メトリクスも バグの見つかり方と関係があるか調査する事 先行研究: プロダクトメトリクスとバグの関係を評価 - S Syedら, “Open Source, Agile and reliability Measures”, ISQI, 2009 - 下村ら, “ソフトウェアメトリクスを用いた単体テストの品質リスク評価”, SQiP2013. 開発メトリクス コミット ソースコード レポジトリ バグ レポート ビルド テスト プロダクトメトリクス バグメトリクス
  24. 24. 24 分析②:開発メトリクスとバグの関係 分析手法 • バグメトリクスとの相関を調査 - 日次の開発メトリクス、プロダクトメトリクス - 週次の積算開発メトリクス、プロダクトメトリクス 開発メトリクス プロダクトメトリクス バグメトリクス 時間 コミット数 時間 変更LOC 時間 検出バグ数 時間 コミット数 日次 データ 週次の 積算データ 時間 検出バグ数 時間 変更LOC
  25. 25. 累積検出バグ数と変更無しファイル数の 900 800 700 25 分析②:日次データでの相関 グループ 説明変数 相関係数 開発メトリクス コミット数 コミットサイズ 0.19 0.06 プロダクトメトリクス 変更LOC 追加LOC 削除LOC 無変更LOC 変更ファイル 追加ファイル 削除ファイル 変更なしファイル 0.36 0.17 0.19 -0.17 0.20 -0.09 0.06 -0.19 6 4 2 0 0 20 40 コミット数 検出バグ数 コミット数と検出バグ数の散布図 600 100 50 0 時系列データ  累積バグ数 累積検出バグ数 変更無しファイル数 考察: - すべてのメトリクスで相関は弱い→結合バグ発見までの潜在期間 - ファイルに変更を加えない事には意味がある?
  26. 26. 層別分析による検出バグ数 26 分析②:週次の積算データでの相関 グループ 説明変数 相関係数 開発メトリクス 週次コミット数 週次コミットサイズ 0.47 0.33 プロダクトメトリクス 週次変更LOC 週次追加LOC 週次削除LOC 週次無変更LOC 週次変更ファイル 週次追加ファイル 週次削除ファイル 週次変更なしファイル 0.56 0.42 0.61 -0.29 0.66 0.20 0.33 -0.31 15 10 5 0 積算変更ファイル数と 検出バグ数の散布図 0 100 200 積算変更ファイル数 検出バグ数 15 10 5 0 積算変更ファイルの 100未満 100以上 以下 検出バグ数 考察: - 開発メトリクスも中程度の相関があるがプロダクトメトリクスより弱い - 積算変更ファイル数が一番高い相関
  27. 27. 27 バックグラウンド メトリクス 分析① 分析② 分析③ まとめと今後の課題
  28. 28. 28 分析③:バグ曲線が緩やかに収束しなかった理由の考察 疑問③: 開発をうまく進めるのに必要な工夫は? 分析③の目的 継続的システムテスト環境下で早くバグを見つけるには? バグ曲線が緩やかに収束しなかった理由を考察 信頼度成長曲線 • テスト時間と発見した欠陥数に着目。潜在障害数を予測。 【ソフトウェア信頼性モデル, 山田茂, 1994】 継続的システムテスト 従来のシステムテスト 従来の開発工程 分析 設計 実装 システムテスト 継続的システムテストの 開発工程 時間 累積検出バグ数
  29. 29. 29 分析③:継続的システムテストでのバグ曲線 90 80 70 60 50 40 累積検出バグ数 検出バグ数 時間 30 20 10 0 A B C • 一定の傾きでバグが増えている • フェーズの終了とともに急速に収束
  30. 30. 30 100 80 60 40 20 0 分析③:バグ曲線が緩やかに収束しなかった理由の考察 分析手法① • 累積コミット数に対するバグ曲線による分析 時間 A 累積コミット数 100 80 60 40 20 0 B 0 200 400 600 800 1000 C A B C (検出バグ数) (検出バグ数)
  31. 31. 31 100 80 60 40 20 0 分析③:バグ曲線が緩やかに収束しなかった理由の考察 (検出バグ数) 分析手法① • 累積コミット数に対するバグ曲線による分析 時間 100 80 60 40 20 0 A B 0 200 400 600 800 1000 C 考察: - A,B,C開発期間は同じ位 コミット数が大きく異なる - 時間を横軸にとると フェーズ終了前で急に収束 - コミットを横軸によると なだらかに収束 - 小さい収束が大きな収束 A B C (検出バグ数) 累積コミット数
  32. 32. 32 100 80 60 40 20 0 分析③:バグ曲線が緩やかに収束しなかった理由の考察 (検出バグ数) 分析手法① • 累積コミット数に対するバグ曲線による分析 時間 100 80 60 40 20 0 A B 0 200 400 600 800 1000 C A B C (検出バグ数) 累積コミット数 考察: - A,B,C開発期間は同じ位 コミット数が大きく異なる - 時間を横軸にとると フェーズ終了前で急に収束 - コミットを横軸によると なだらかに収束 - 小さい収束が大きな収束
  33. 33. 33 100 80 60 40 20 0 分析③:バグ曲線が緩やかに収束しなかった理由の考察 (検出バグ数) 分析手法① • 累積コミット数に対するバグ曲線による分析 時間 100 80 60 40 20 0 A B 0 200 400 600 800 1000 C A B C (検出バグ数) 累積コミット数 考察: - A,B,C開発期間は同じ位 コミット数が大きく異なる - 時間を横軸にとると フェーズ終了前で急に収束 - コミットを横軸によると なだらかに収束 - 小さい収束が大きな収束
  34. 34. 34 100 80 60 40 20 0 分析③:バグ曲線が緩やかに収束しなかった理由の考察 (検出バグ数) 分析手法① • 累積コミット数に対するバグ曲線による分析 時間 100 80 60 40 20 0 A B 0 200 400 600 800 1000 C A B C (検出バグ数) 累積コミット数 考察: - A,B,C開発期間は同じ位 コミット数が大きく異なる - 時間を横軸にとると フェーズ終了前で急に収束 - コミットを横軸によると なだらかに収束 - 小さい収束が大きな収束
  35. 35. 35 100 80 60 40 20 0 分析③:バグ曲線が緩やかに収束しなかった理由の考察 (検出バグ数) 分析手法① • 累積コミット数に対するバグ曲線による分析 時間 100 80 60 40 20 0 A B 0 200 400 600 800 1000 C A B C (検出バグ数) 累積コミット数 考察: - A,B,C開発期間は同じ位 コミット数が大きく異なる - 時間を横軸にとると フェーズ終了前で急に収束 - コミットを横軸によると なだらかに収束 → コミットに含まれる バグの減少を示唆 - 小さい収束が大きな収束
  36. 36. 36 100 80 60 40 20 0 分析③:バグ曲線が緩やかに収束しなかった理由の考察 (検出バグ数) 分析手法① • 累積コミット数に対するバグ曲線による分析 時間 100 80 60 40 20 0 A B 0 200 400 600 800 1000 C A B C (検出バグ数) 累積コミット数 考察: - A,B,C開発期間は同じ位 コミット数が大きく異なる - 時間を横軸にとると フェーズ終了前で急に収束 - コミットを横軸によると なだらかに収束 → コミットに含まれる バグの減少を示唆 - 小さい収束が大きな収束
  37. 37. 37 100 80 60 40 20 0 分析③:バグ曲線が緩やかに収束しなかった理由の考察 (検出バグ数) 分析手法① • 累積コミット数に対するバグ曲線による分析 時間 100 80 60 40 20 0 A B 0 200 400 600 800 1000 C A B C (検出バグ数) 累積コミット数 考察: - A,B,C開発期間は同じ位 コミット数が大きく異なる - 時間を横軸にとると フェーズ終了前で急に収束 - コミットを横軸によると なだらかに収束 → コミットに含まれる バグの減少を示唆 - 小さい収束が大きな収束 → 開発者がコミット直後に   バグに気づき修正
  38. 38. 38 分析③:バグ曲線が緩やかに収束しなかった理由の考察 分析手法② • テスト種別ごとのバグ曲線による分析 累積バグ 累積バグ in スモークテスト 積バグ in その他テスト A コミット数 100 80 60 40 20 0 B C 0 200 400 600 800 1000 (検出バグ数)  システムテスト スモークテスト バージョン その他テスト 累積検出バグ数 累積検出バグ数 in スモークテスト 累積検出バグ数 in その他テスト
  39. 39. 39 分析③:バグ曲線が緩やかに収束しなかった理由の考察 分析手法② • テスト種別ごとのバグ曲線による分析 累累積積バ検グ 出バグ数 累累積積バ検グ 出in バスグモ数 ークin テススト モークテスト in in A 累積積バ検グ 出バそグの数 他テスそト の他テスト A コミット数 100 80 60 40 20 0 B C 0 200 400 600 800 1000 (検出バグ数)  システムテスト スモークテスト バージョン その他テスト 考察: - スモークテストを壊すようなコミットがAの期間では一度に集中 - Cでは2回 (見つかったバグの数はともに10) - Cではスモークテストが収束した後、すぐに全体も収束
  40. 40. 40 分析③:バグ曲線が緩やかに収束しなかった理由の考察 分析手法② • テスト種別ごとのバグ曲線による分析 累累積積バ検グ 出バグ数 累累積積バ検グ 出in バスグモ数 ークin テススト モークテスト in in A 累積積バ検グ 出バそグの数 他テスそト の他テスト A コミット数 100 80 60 40 20 0 B C 0 200 400 600 800 1000 (検出バグ数)  システムテスト スモークテスト バージョン その他テスト 考察: - スモークテストを壊すようなコミットがAの期間では一度に集中 - Cでは2回 (見つかったバグの数はともに10) - Cではスモークテストが収束した後、すぐに全体も収束
  41. 41. 41 分析③:バグ曲線が緩やかに収束しなかった理由の考察 分析手法② • テスト種別ごとのバグ曲線による分析 累累積積バ検グ 出バグ数 累累積積バ検グ 出in バスグモ数 ークin テススト モークテスト in in A 累積積バ検グ 出バそグの数 他テスそト の他テスト A コミット数 100 80 60 40 20 0 B C 0 200 400 600 800 1000 (検出バグ数)  システムテスト スモークテスト バージョン その他テスト 考察: - スモークテストを壊すようなコミットがAの期間では一度に集中 - Cでは2回 (見つかったバグの数はともに10) - Cではスモークテストが収束した後、すぐに全体も収束
  42. 42. 42 分析③:バグ曲線が緩やかに収束しなかった理由の考察 分析手法② • テスト種別ごとのバグ曲線による分析 累累積積バ検グ 出バグ数 累累積積バ検グ 出in バスグモ数 ークin テススト モークテスト in in A 累積積バ検グ 出バそグの数 他テスそト の他テスト A コミット数 100 80 60 40 20 0 B C 0 200 400 600 800 1000 (検出バグ数)  システムテスト スモークテスト バージョン その他テスト 考察: - スモークテストを壊すようなコミットがAの期間では一度に集中 - Cでは2回 (見つかったバグの数はともに10) - Cではスモークテストが収束した後、すぐに全体も収束
  43. 43. 43 分析③:バグ曲線が緩やかに収束しなかった理由の考察 分析手法② • テスト種別ごとのバグ曲線による分析 累累積積バ検グ 出バグ数 累累積積バ検グ 出in バスグモ数 ークin テススト モークテスト in in A 累積積バ検グ 出バそグの数 他テスそト の他テスト A コミット数 100 80 60 40 20 0 B C 0 200 400 600 800 1000 (検出バグ数)  システムテスト スモークテスト バージョン その他テスト 考察: - スモークテストを壊すようなコミットがAの期間では一度に集中 - Cでは2回 (見つかったバグの数はともに10) - Cではスモークテストが収束した後、すぐに全体も収束 → スモークテストを壊すような開発をイテレーションで分割 コミットを小規模化し、バグを早期に発見、修正出来る
  44. 44. 44 バックグラウンド メトリクス 分析① 分析② 分析③ まとめと今後の課題
  45. 45. 疑問②: システムテストを開発プロセスに取り込むって? 45 まとめ:システムテスト自動化に関する疑問 疑問①: 自動化されたシステムテストは質が低い? 疑問③: 開発をうまく進めるのに必要な工夫は? まとめ:   継続的システムテストへの理解を深めるため  開発、プロダクトとバグのメトリクスの分析
  46. 46. 46 まとめ:疑問①への答え 疑問①: 自動化されたシステムテストは質が低い? 答え(分析①より): 自動化されたシステムテストは“質が低い”と いう事はない • ただし、自動化した環境ではテスト密度は 上がりやすいので、 システムテストの 50 カバレッジの指標が必要 0 テスト密度 A B C
  47. 47. 疑問②: システムテストを開発プロセスに取り込むって? 47 まとめ:疑問②への答え 答え(分析②より): システムテストを開発プロセスに取り込むと プロダクトメトリクスだけでなく 開発メトリクスもバグの発見の仕方と関係 • バグの混入のされ方は、  変更無しファイル数や  変更したファイル数等と関係 層別分析による検出バグ数 15 10 5 0 積算変更ファイルの 100以上 100以下 検出バグ数
  48. 48. 48 まとめ:疑問③への答え 疑問③: 開発をうまく進めるのに必要な工夫は? 答え(分析③より): 自動化した環境では開発者に早期に フィードバックする事が重要 • コミットのタイプが機能追加からバグ修正へ • スモークテストを失敗させるような コミットをイテレーションで  分割する事でバグを早期に 発見する事が出来る コミット数 100 50 0 0 500 1000 (検出バグ数)
  49. 49. 49 今後の課題 • システムテストの評価指標  → 継続的システムテスト下でのテストの改善    - テストケースの優先順位付け    - テストの作り過ぎを防ぐ • 開発メトリクスの品質管理への利用 • 開発プロセスと品質保証の 相互作用的な変化
  50. 50. 50 Long live testing

×