データドリブンを目指すQAチーム・バグ発見重み付け平均(APFD)とその他計測編

この記事では、グロービスQAチームが自社プロダクトのテストデータを集計・分析した結果をまとめてみました。今回はテスト実行順序の評価に使われるAPFDやその他計測事例をご紹介します。

はじめに

鳥取からフルリモート勤務している大学院生の樋口です。大学院で研究を行う際には、論文を参考にして課題解決を行うことが多くあります。今回もテストデータを活用している論文を探していたところAPFDという算出方法を見つけたので、実際に自分たちで集計したテストデータを使って算出してみました。

データドリブンを目指すために解決したい問題

アジャイル開発の流行が象徴するように、近年のソフトウェア開発ではより素早いリリースが求められるようになっています。テストにおいても、可能な限り少ないリソースで効率的・効果的に取り組み、重大なバグを多く検出する必要があります。

それを目指し、新たなテスト技法やテスト自動化等が試みられてきました。また、テストケースの実行順序を適切に設定することで

1. 修正コストの削減
2. バグを出し切る速度を上げることで1つのプロダクトのテスト実施時間短縮させる

2つの理由によって効率的なソフトウェアテストを行うことができることが明らかになっています。

私たちQAチームが直面していたのは、まず、テストによって得られた多数のデータを分析できずにいたことで、現状を適切に把握できていないという問題でした。どういったテストケースでバグが検出されているのかを把握せずにいたため、テスト工数削減を目指す適切な対策を取れずにいたのです。

また、テストケースの実行順序はこれまでのところ、テストケースを上から順番に実施していくスクリプトテストのほか、アドホックテスト等を行うことがしばしば見られました。このように、テストケースをただ上から消化したり、経験や勘に頼ってテストを行う状態では、優先度付けの判断根拠を明確に示せません。

この問題を解決するアプローチとして、テスト実行の順番に着目しました。バグをより早期に見つけられる順序でテストを実行できたかを評価することで、テストケースの優先度を定量的に判定することができるのではないかと考えたのです。

問題に対する施策

テスト工数削減という問題に対しての施策としては、まずQAとして参加したプロジェクトのテスト工数、およびテスト結果を記録しました。次に、プロジェクト毎にバグ数およびバグ分析を行いました。

また、定量的にテストケースの実行順序を評価する手法として、バグ発見率の重み付き平均(Average of Percentage of Faults Detected, APFD)が知られており、本事例でも採用しました。式を(1)で示します。

nはテストケース数、 mはバグ数、 はTFi番目のバグを最初に発見したテストケースの位置を示します。0から1の範囲で出力され、1に近づくほど早期に多くのバグが発見できたことを示します。

なおAPFDに関しては早稲田大学と株式会社SHIFT共同の論文で分かりやすく解説されています。

↓はその論文になります。

https://www.juse.jp/sqip/symposium/archive/2015/day1/files/ronbun_A1-3.pdf

↓はスライドで分かりやすく解説されています。

https://www.juse.jp/sqip/symposium/archive/2015/day1/files/happyou_A1-3.pdf

APFDを実際に試してみた

実際にAPFDの算出とバグ分析を行いました。

まず、表1にテスト実行順序とテスト観点を示します。テスト観点1つあたり実行予定時間を1時間として粒度を揃えました。テストケースの集合であるテスト観点は汎用性のある観点を6つ設定しそれぞれの観点から探索的テストを行いました。これによって形式的テスト（スクリプトテスト）より同値のテストを行うことがなくなったことにより、テスト工数を削減できテスト実行順序の評価を行うことが可能となりテストデータの分析工程コストも削減できました。

今回は 表1の実行順序でテストを実施したところ、APFDのスコアは52%とまだ改善余地がある結果となりました。効率的なテスト順序を実行していると考えられる指標として80%を目指しているので、今後もデータの取得方法と活用を改善しながら、より効率的なテスト実施へとつなげていきます。

次に画面別のテスト実施時間を日毎に計測しました。表2は画面別に費やしたテスト実施時間とその割合を示しています。集計期間はおよそ1ヶ月分です。計測後、テストする際にどの画面で時間を費やしたのか割合を算出しました。これは違和感のある画面に対して、テストを行う時間が必然的に増えていくことから、プロダクトのバグ発生箇所の定量評価を可能とするためです。

なお、このテスト分析結果はグロービスデジタルプラットフォーム部門の全体会議でも展開されました。結成から1年にも満たないQAチームですが、テストの話題が部門内で広く取り上げられているのです。

今後の課題・展開

今回は自社プロダクトを用いたAPFDの計算手法の確立、および、画面別のテスト実施時間を記録・分析し、分析手法の有効性を示すことができました。

一方で課題も見えてきています。APFDはあくまでテストケースの実行順序の評価するためのもので、テストの実行順序を効率よくするための未来予知に使うのは難しいです。今後の展開としては、バグを記録として残すだけでなく、バグを分析した上でAPFDを計算するような流れでフレームワークを構築できれば、効率的な順序でテストができるようになり、バグを発見することが早くなり素早いリリースが出来るだろうと期待しています。

QAチームにおいてAPFDなどを使ったテストデータの活用もまだまだ発展途上です。また今回説明仕切れなかった本記事の詳細も今後書く機会があると思います。

本記事に関して詳しく知りたいところがある方はぜひ @TakahiguChannelまでご連絡ください！