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