JP2019101581A

JP2019101581A - ソフトウェア品質判定装置、ソフトウェア品質判定方法、及びソフトウェア品質判定プログラム

Info

Publication number: JP2019101581A
Application number: JP2017229603A
Authority: JP
Inventors: 英祐青木; Hidesuke Aoki
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2017-11-29
Filing date: 2017-11-29
Publication date: 2019-06-24
Anticipated expiration: 2037-11-29
Also published as: EP3493065A1; JP6897524B2; US11068379B2; US20190163611A1; CN110032504A

Abstract

【課題】過去のバグ発生実績データを用いなくても、バグの収束判定ができ、かつ、バグの収束判定の判定精度の低下を抑制できるソフトウェア品質判定装置を提供すること。【解決手段】ソフトウェア品質判定装置は、システムをテストする際の観点であるテスト観点毎に、該テスト観点のテストで発生したバグの検出率を算出するバグ検出率算出部と、テスト観点毎に、該テスト観点のテストの実施量が、該テスト観点の実施量の基準となる実施基準量に到達した後に、該テスト観点の算出された検出率が、該テスト観点の検出率の基準となる基準値以下であるか否かに応じて、該テスト観点のバグの収束を判定するバグ収束判定部と、を備える。【選択図】図１

Description

本発明は、ソフトウェア品質判定装置、ソフトウェア品質判定方法、及びソフトウェア品質判定プログラムに関する。

近年、システムに発生するバグの収束を判定する技術が提案されている。
例えば、特許文献１には、過去のバグ発生実績データからシステムに将来発生するバグ件数を予測し、予測したバグ件数とシステムに要求される品質を示す品質指標とに基づいて、バグが収束する収束時期を予測する技術が開示されている。

また、非特許文献１には、テスト期間の最終段階で、バグ検出率の増加率がゼロに近づくことを以って、バグが収束していると判定する技術が開示されている。

特開２０１４−１７４８９５号公報

独立行政法人情報処理推進機構技術本部ソフトウェア・エンジニアリング・センター編著、「改訂版組込みソフトウェア開発向け品質作り込みガイド」、２０１２、第１０２−１０３頁

しかし、特許文献１に開示された技術は、バグ発生実績データが必要であるため、過去にバグの収束を判定したシステムにしか利用することができないという問題がある。

他方、非特許文献１に開示された技術は、バグ発生実績データが不要であるため、過去にバグの収束を判定していないシステムにも利用でき、特許文献１の問題は生じない。
しかし、非特許文献１に開示された技術は、バグが収束していると判定した時点で、システムをテストする際の観点であるテスト観点の中で、実際にバグが発生しているテスト観点が未テストの状態である可能性がある。そのため、バグが収束していると判定した直後に、バグが発生し、バグ検出率が増加することにより、バグの収束判定の判定精度が低下してしまうという不測の事態が生じるおそれがある。

本発明は、上記を鑑みなされたものであって、過去のバグ発生実績データを用いなくても、バグの収束判定ができ、かつ、バグの収束判定の判定精度の不測の低下を抑制できるソフトウェア品質判定装置、ソフトウェア品質判定方法、及びソフトウェア品質判定プログラムを提供するものである。

本発明の一態様に係るソフトウェア品質判定装置は、
システムに発生するバグの収束を判定するソフトウェア品質判定装置であって、
前記システムをテストする際の観点であるテスト観点毎に、該テスト観点のテストで発生したバグの検出率を算出するバグ検出率算出部と、
前記テスト観点毎に、該テスト観点のテストの実施量が、該テスト観点の前記実施量の基準となる実施基準量に到達した後に、該テスト観点の前記算出された前記検出率が、該テスト観点の前記検出率の基準となる基準値以下であるか否かに応じて、該テスト観点のバグの収束を判定するバグ収束判定部と、を備える。

本発明の一態様に係るソフトウェア品質判定方法は、
システムに発生するバグの収束を判定するソフトウェア品質判定装置によるソフトウェア品質判定方法であって、
前記システムをテストする際の観点であるテスト観点毎に、該テスト観点のテストで発生したバグの検出率を算出するステップと、
前記テスト観点毎に、該テスト観点のテストの実施量が、該テスト観点の前記実施量の基準となる実施基準量に到達した後に、該テスト観点の前記算出された前記検出率が、該テスト観点の前記検出率の基準となる基準値以下であるか否かに応じて、該テスト観点のバグの収束を判定するステップと、を含む。

本発明の一態様に係るソフトウェア品質判定プログラムは、
システムに発生するバグの収束を判定するコンピュータに、
前記システムをテストする際の観点であるテスト観点毎に、該テスト観点のテストで発生したバグの検出率を算出する手順と、
前記テスト観点毎に、該テスト観点のテストの実施量が、該テスト観点の前記実施量の基準となる実施基準量に到達した後に、該テスト観点の前記算出された前記検出率が、該テスト観点の前記検出率の基準となる基準値以下であるか否かに応じて、該テスト観点のバグの収束を判定する手順と、を実行させるためのプログラムである。

上述した本発明の態様によれば、過去のバグ発生実績データを用いなくても、バグの収束判定ができ、かつ、バグの収束判定の判定精度の不測の低下を抑制できるソフトウェア品質判定装置、ソフトウェア品質判定方法、及びソフトウェア品質判定プログラムを提供することができる。

実施の形態１に係るソフトウェア品質判定装置のブロック構成の一例を示すブロック図である。実施の形態１に係るテスト観点の一例を示す図である。実施の形態１に係るテスト観点の一例を示す図である。実施の形態１に係るテスト観点の一例を示す図である。実施の形態１に係るソフトウェア品質判定装置によるソフトウェア品質判定方法の一例を示すフロー図である。図５のステップＳ１２のバグ収束判定処理の一例を示すフロー図である。実施の形態１に係るソフトウェア品質判定装置により、テスト観点のテスト実施量を判定した結果の一例を示すグラフである。実施の形態１に係るソフトウェア品質判定装置により、テスト観点のテスト実施量を判定した結果の一例を示すグラフである。実施の形態１に係るソフトウェア品質判定装置により、テスト観点のテスト実施量を判定した結果の一例を示すグラフである。実施の形態１に係るソフトウェア品質判定装置により、テスト観点のテスト実施量を判定した結果の一例を示すグラフである。実施の形態１に係るソフトウェア品質判定装置により、テスト観点のバグの収束を判定した結果の一例を示すグラフである。実施の形態１に係るソフトウェア品質判定装置により、テスト観点のバグの収束を判定した結果の一例を示すグラフである。テスト観点のバグ曲線の一例を示すグラフである。テスト観点のバグ曲線の一例を示すグラフである。テスト観点のバグ曲線の一例を示すグラフである。テスト観点のバグ曲線の一例を示すグラフである。テスト観点のバグ曲線の一例を示すグラフである。テスト観点のバグ曲線の一例を示すグラフである。テスト観点のバグ曲線の一例を示すグラフである。テスト観点のバグ曲線の一例を示すグラフである。図１５〜図２０のバグ曲線の判定結果をまとめて示す図である。テスト観点毎のテストの実施方法の一例を示す図である。実施の形態２に係るソフトウェア品質判定装置のブロック構成の一例を示すブロック図である。実施の形態２に係るテスト観点毎の単位開発規模当たりのテスト実施基準量の一例を示す図である。実施の形態２に係るテスト観点毎の単位開発規模当たりのテスト実施基準量の一例を示す図である。実施の形態２に係るソフトウェア品質判定装置によるソフトウェア品質判定方法の一例を示すフロー図である。

以下、図面を参照して本発明の実施の形態について説明する。なお、以下で説明する各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。また、以下の実施の形態で示す具体的な数値などは、発明の理解を容易とするための例示にすぎず、これに限定されるものではない。

＜実施の形態１＞
＜実施の形態１に係るソフトウェア品質判定装置の構成＞
まず、本実施の形態１に係るソフトウェア品質判定装置１の構成について説明する。
図１は、本実施の形態１に係るソフトウェア品質判定装置１のブロック構成の一例を示すブロック図である。本実施の形態１に係るソフトウェア品質判定装置１は、システム（テスト対象）に発生するバグの収束を判定するものである。

図１に示されるように、本実施の形態１に係るソフトウェア品質判定装置１は、入力部１１と、データベース１２と、バグ検出率算出部１３と、バグ収束判定部１４と、を備えている。

入力部１１は、例えば、ユーザが任意のデータ（後述のバグ検出数やテスト実施量など）をソフトウェア品質判定装置１に入力し設定するための入力装置である。入力部１１は、例えば、キーボート、マウス、タッチスクリーン、無線携帯端末（スマートフォンやタブレットなど）などの任意の入力装置である。

データベース１２は、ユーザが入力部１１に入力し設定したデータなどを保持する。
例えば、データベース１２は、システムをテストする際の観点であるテスト観点毎に、そのテスト観点のテストで発生したバグの検出数（以下、バグ検出数）を保持する。テスト観点とは、例えば、プログラムが正常に動作するか否かを確認するための、テスト項目、着眼点、発想方法といった、テストを行う上での「切り口」であり、テストを実施するときの操作や手順の着眼点である。バグは、このような着眼点を変更することによって、検出できることが知られている。

また、データベース１２は、テスト観点毎に、そのテスト観点のテストの実施量（以下、テスト実施量）を保持する。テスト実施量とは、例えば、テストの工数（以下、テスト工数）や件数（以下、テスト件数）である。

また、データベース１２は、テスト観点毎に、そのテスト観点のテストで発生したバグの検出率（以下、バグ検出率）の基準となる基準値を保持する。バグ検出率は、バグ検出数をテスト実施量で除算したものである。

また、データベース１２は、テスト観点毎に、そのテスト観点のテスト実施量の基準となる実施基準量（以下、テスト実施基準量）を保持する。テスト実施基準量は、バグ収束判定部１４が、バグの収束判定を行うトリガとなる。すなわち、バグ収束判定部１４は、テスト観点毎に、そのテスト観点のテスト実施量が、そのテスト観点のテスト実施基準量に到達した後に、バグの収束判定を行う。

また、データベース１２は、テスト観点毎に、そのテスト観点の追加テストの実施量の基準となる実施基準量（以下、追加テスト実施基準量）を保持する。追加テストは、テスト観点毎に、そのテスト観点のテスト実施量がそのテスト観点のテスト実施基準量に到達した後に実施されるテストである。

バグ検出率算出部１３は、テスト観点毎に、そのテスト観点のバグ検出率を算出する。具体的には、バグ検出率算出部１３は、データベース１２に保持されているバグ検出数を、データベース１２に保持されているテスト実施量で除算して、バグ検出率を算出する。

バグ収束判定部１４は、テスト観点毎に、そのテスト観点のテスト実施量が、そのテスト観点のテスト実施基準量に到達した後に、そのテスト観点のバグ検出率が、そのテスト観点の基準値以下であるかに応じて、そのテスト観点のバグの収束判定を行う。具体的には、バグ収束判定部１４は、テスト観点毎に、以下の動作を行う。すなわち、バグ収束判定部１４は、データベース１２に保持されているテスト実施量が、データベース１２に保持されているテスト実施基準量に到達したか否かを判定する。テスト実施量がテスト実施基準量に到達していれば、バグ収束判定部１４は、バグ検出率算出部１３で算出されたバグ検出率が、データベース１２に保持されているバグ検出率の基準値以下であるかに応じて、バグの収束判定を行う。

テスト実施量がテスト実施基準量に到達した後のバグの収束を判定する方法は、種々の方法で行うことが可能である。例えば、以下の第１及び第２の方法が考えられる。
第１の方法は、テスト実施量がテスト実施基準量に到達した後に、追加テスト実施基準量分の追加テストの実施を終了した時点でバグ検出率が基準値以下であれば、バグが収束していると判定する方法である。
また、第２の方法は、テスト実施量がテスト実施基準量に到達した後に、追加テスト実施基準量分の追加テストを実施している期間、バグ検出率が基準値以下である状態が継続していれば、バグが収束していると判定する方法である。

なお、バグ収束判定部１４によるバグの収束判定の判定結果は、必要に応じて、不図示の表示装置に表示し、ユーザに提示することができる。表示装置は、例えば、液晶ディスプレイ、有機ＥＬ（Electro Luminescence）ディスプレイなどである。

＜実施の形態１に係るテスト観点＞
続いて、本実施の形態１に係るテスト観点の具体例について説明する。
図２に示されるように、テスト観点は、ＩＳＯ（International Organization for Standardization）９１２６の品質特性としても良い。図２の例では、テスト観点は、「機能性」、「効率性」、「信頼性」、「使用性」、「保守性」、「可搬性」となっている。

また、図３に示されるように、テスト観点は、次世代ソフトウェア品質評価規格群ＩＳＯ／ＩＥＣ（International Electrotechnical Commission）２５０００シリーズ（ＳＱｕａＲＥ：Software product Quality Requirements and Evaluation）の品質特性としても良い。図３の例では、テスト観点は、「機能適合性」、「性能適合性」、「互換性」、「使用性」、「信頼性」、「セキュリティ」、「保守性」、「移植性」となっている。

また、図４に示されるように、テスト観点は、ＯＤＣ（Orthogonal Defect Classification）分析（ＯＤＣ分析は、例えば、以下の非特許文献２を参照）でバグを発見するトリガーとなる発見トリガーとしても良い。図４の例では、テスト観点は、結合テストの場合、「基本操作」、「組み合わせ」、「順序・繰り返し」、「相互作用」となり、システムテストの場合、「負荷・ストレス」、「回復・例外」、「起動・再起動」、「構成」、「シナリオ」となっている。システムテストとは、ソフトウェア全体のテストであり、統合テスト又は総合テストとも呼ばれる。結合テストとは、一部の構成要素がない状態での全てのテストである。
非特許文献２：山崎隆オリンパスソフトウェアテクノロジー株式会社、「ＯＤＣ分析による欠陥除去と品質成熟度の可視化」、Embedded Technology West 2014 IPAセミナー、２０１４年７月２９日

＜実施の形態１に係るソフトウェア品質判定方法＞
続いて、本実施の形態１に係るソフトウェア品質判定装置１によるソフトウェア品質判定方法について説明する。
図５は、本実施の形態１に係るソフトウェア品質判定装置１によるソフトウェア品質判定方法の一例を示すフロー図である。

図５に示されるように、データベース１２は、ユーザが入力部１１に入力し設定した以下のデータを取得し保持する（ステップＳ１１）。
・テスト観点毎のバグ検出数
・テスト観点毎のテスト実施量
・テスト観点毎のバグ検出率の基準値
・テスト観点毎のテスト実施基準量
・テスト観点毎の追加テスト実施基準量

以降、バグ検出率算出部１３及びバグ収束判定部１４により、テスト観点毎に、そのテスト観点でのバグの収束を判定するためのバグ収束判定処理が行われる（ステップＳ１２）。

続いて、図５のステップＳ１２のバグ収束判定処理について説明する。
図６は、図５のステップＳ１２のバグ収束判定処理の一例を示すフロー図である。ここでは、テスト実施量がテスト実施基準量に到達した後のバグ収束を判定する方法として、上記の第１の方法を用いるものとする。なお、図６は、テスト観点Ａのバグ収束判定処理のフローの例を示している。

図６に示されるように、バグ検出率算出部１３は、データベース１２に保持されているテスト観点Ａのバグ検出数を、データベース１２に保持されているテスト観点Ａのテスト実施量で除算して、テスト観点Ａのバグ検出率を算出する（ステップＳ２１）。

バグ収束判定部１４は、バグ検出率算出部１３で算出されたテスト観点Ａのバグ検出率が、データベース１２に保持されているテスト観点Ａのバグ検出率の基準値以下であるか否かを判定する（ステップＳ２２）。バグ検出率が基準値を上回っていれば（ステップＳ２２のＮｏ）、ステップＳ２１の処理に戻る。

バグ検出率が基準値以下であれば（ステップＳ２２のＹｅｓ）、続いて、バグ収束判定部１４は、データベース１２に保持されているテスト観点Ａのテスト実施量が、データベース１２に保持されているテスト観点Ａのテスト実施基準量に到達したか否かを判定する（ステップＳ２３）。テスト実施量がテスト実施基準量に到達していなければ（ステップＳ２３のＮｏ）、ステップＳ２３の処理に戻る。

テスト実施量がテスト実施基準量に到達していれば（ステップＳ２３のＹｅｓ）、続いて、データベース１２に保持されているテスト観点Ａの追加テスト実施基準量分の追加テストが実施される。バグ収束判定部１４は、テスト観点Ａの追加テスト実施基準量分の追加テストの実施が終了した時点で、バグ検出率算出部１３で算出されたテスト観点Ａのバグ検出率が、データベース１２に保持されているテスト観点Ａのバグ検出率の基準値以下であるか否かを判定する（ステップＳ２４）。バグ検出率が基準値以下であれば（ステップＳ２４のＹｅｓ）、バグ収束判定部１４は、テスト観点Ａのバグは収束していると判定し（ステップＳ２５）、処理を終了する。

バグ検出率が基準値を上回っていれば（ステップＳ２４のＮｏ）、ステップＳ２３の処理に戻る。このように、テスト実施量がテスト実施基準量に到達した後は、バグ検出率が基準値以下になるまで、追加テスト実施基準量分の追加テストが繰り返し実施され、追加テストの実施が終了する度に、バグ収束判定部１４は、その時点のバグ検出率が基準値以下であるか否かに応じて、テスト観点Ａのバグが収束しているか否かを判定することになる。

以上がテスト観点Ａのバグ収束判定処理のフローとなる。テスト観点Ａの他にテスト観点Ｂ，Ｃ，Ｄが存在する場合は、テスト観点Ｂ，Ｃ，Ｄについても図６と同様のバグ収束判定処理のフローを実施する。
そして、バグ収束判定部１４は、テスト観点Ａ，Ｂ，Ｃ，Ｄの全ておいて、バグが収束していると判定した場合は、システムのバグが収束していると判定する。

ここで、本実施の形態１に係るソフトウェア品質判定装置１により、テスト観点毎のバグ収束判定を行った結果について具体例を挙げて説明する。
図７〜図１０は、本実施の形態１に係るソフトウェア品質判定装置１により、テスト観点Ａ，Ｂ，Ｃ，Ｄ毎のテスト実施量を判定した結果の一例を示すグラフである。図１１及び図１２は、本実施の形態１に係るソフトウェア品質判定装置１により、テスト観点Ｂ，Ｄ毎のバグ収束を判定した結果の一例を示すグラフである。ここでは、テスト実施量がテスト実施基準量に到達した後のバグの収束を判定する方法として、上記の第１の方法を用いるものとする。なお、図１１及び図１２は、テスト実施量がテスト実施基準量に到達した後の波形を示しており、図１１及び図１２の横軸の原点は、テスト実施基準量に相当する。

図７〜図１０に示されるように、テスト観点Ｂ，Ｄについては、テスト実施量がテスト実施基準量に到達している。そのため、バグ収束判定部１４は、テスト観点Ｂ，Ｄについては、テスト実施基準量に到達した後の追加テストにおいて、バグの収束を判定する。一方、テスト観点Ａ，Ｃについては、テスト実施量がテスト実施基準量に到達していない。そのため、バグ収束判定部１４は、バグの収束を判定しない。

図１１及び図１２に示されるように、テスト観点Ｂ，Ｄについては、テスト実施量がテスト実施基準量に到達した後の追加テストにおいて、バグの収束を判定する。このうち、テスト観点Ｂについては、追加テスト実施基準量分の追加テストの実施が終了した時点で、バグ検出率が基準値以下になっている。そのため、バグ収束判定部１４は、テスト観点Ｂのバグは収束していると判定する。一方、テスト観点Ｄについては、追加テスト実施基準量分の追加テストの実施が終了した時点で、バグ検出率が基準値を上回っている。そのため、バグ収束判定部１４は、テスト観点Ｄのバグは収束していないと判定する。

＜バグ曲線の応用＞
ユーザは、本実施の形態１に係るソフトウェア品質判定方法を、従来のバグ曲線（信頼度成長曲線とも呼ばれる）に応用して、テストを実施していないテスト観点があるか、すなわち、テスト漏れ（テスト抜けとも呼ばれる）がないかを確認することができる。この場合の手順を以下に示す。ここでは、テスト実施量がテスト実施基準量に到達した後のバグの収束を判定する方法として、上記の第２の方法を用いるものとする。

ステップ１：テスト観点毎に、横軸を「テスト実施量」とし、縦軸を「バグ検出率」としたグラフを作成する。
ステップ２：テストの実施を進めていくうちに、「バグ検出率」が「バグ検出率の基準値」以下になるかどうかを監視する。
ステップ３：「バグ検出率」が「バグ検出率の基準値」以下になったら、「テスト実施量」が「テスト実施基準量」に到達していれば、「追加テスト実施基準量」分の追加テストを実施する。そして、追加テストを実施している期間、「バグ検出率」が「バグ検出率の基準値」以下である状態が継続するかを監視する。
ステップ４：その結果、「バグ検出率」が「バグ検出率の基準値」以下である状態が継続していれば、バグは収束しており、品質はＯＫと判定する。一方、「バグ検出率」が「バグ検出率の基準値」以下である状態が継続していなければ、バグは収束しておらず、品質はＮＧと判定する。
上記のステップ１〜４をテスト観点毎に実施する。

図１３及び図１４は、テスト観点毎のバグ曲線の一例を示すグラフである。
図１３に示されるテスト観点は、追加テストを実施している期間、「バグ検出率」が「バグ検出率の基準値」以下である状態が継続していない。そのため、ユーザは、バグは収束しておらず、品質はＮＧと判定する。一方、図１４に示されるテスト観点は、追加テストを実施している期間、「バグ検出率」が「バグ検出率の基準値」以下である状態が継続している。そのため、ユーザは、バグは収束しており、品質はＯＫと判定する。

このように、ユーザは、図１４に示されるようなテスト観点は、バグが出し切れており、品質がＯＫと判定するが、図１３に示されるようなテスト観点は、バグが出し切れておらず、品質がＮＧと判定する。

従って、ユーザは、品質がＮＧで問題のあるテスト観点については、テストを補強するなどの具体的な方針を立てることができる。

続いて、本実施の形態１に係るソフトウェア品質判定方法を、従来のバグ曲線に応用して、テスト漏れがないかを確認する方法について、具体例を挙げて説明する。以下では、テスト観点は、ＯＤＣ分析の発見トリガーに基づき、「基本」、「相互作用」、「操作順序」、「負荷・ストレス」、「回復・例外」、「ＧＵＩ（Graphical User Interface）」の６つであるものとする。

図１５〜図２０は、テスト観点毎のバグ曲線の一例を示すグラフである。図１５は「基本」、図１６は「相互作用」、図１７は「操作順序」、図１８は「負荷・ストレス」、図１９は「回復・例外」、図２０は「ＧＵＩ」のバグ曲線をそれぞれ示している。図２１は、図１５〜図２０の判定結果をまとめて示す図である。

ユーザは、テスト実施量がテスト実施基準量に到達した後、バグ検出率が基準値を上回っている場合は、バグが収束しておらず、まだバグが検出される可能性が高いと判定する（品質はＮＧ）。一方、ユーザは、テスト実施量がテスト実施基準量に到達した後、バグ検出率が基準値以下である場合は、バグが収束しており、これからバグが検出される可能性は低いと判定する（品質はＯＫ）。

図１５〜図２１に示されるように、「基本」、「相互作用」、「ＧＵＩ」については、テスト実施量がテスト実施基準量に到達した後に、バグ検出率が基準値以下である。そのため、ユーザは、品質はＯＫと判定する。

一方、「操作順序」、「負荷・ストレス」、「回復・例外」については、テスト実施量がテスト実施基準量に到達した後に、バグ検出率が基準値を上回っている。そのため、ユーザは、品質はＮＧと判定する。詳細には、「操作順序」については、バグ検出率と基準値との差分が大きく、バグ検出率も悪化傾向にある。「負荷・ストレス」については、バグ検出率と基準値との差分が大きいが、バグ検出率は改善傾向にある。「回復・例外」については、バグ検出率と基準値との差分が非常に大きいが、バグ検出率は改善傾向にある。

従って、ユーザは、品質がＮＧと判定した「操作順序」、「負荷・ストレス」、「回復・例外」については、テストを重点的に実施する方針とし、品質がＯＫと判定した「基本」、「相互作用」、「ＧＵＩ」については、優先度を下げる（テストの実施量を減らす、又は、テストを止める）方針とするなど、各テスト観点の方針を決めることができる。そのため、ユーザは、費用対効果の高いテストを実施することができる。

＜テスト観点毎のテストの実施方法＞
図２２は、テスト観点毎のテストの実施方法の一例を示す図である。
図２２に示されるように、ユーザは、各テスト観点のテストを実施する順番を、フェーズ（Phase）１，２，３，４，５，６のように、予め決めておき、各フェーズでテスト観点のテストを完了させる。そして、次のフェーズのテスト観点のテストを実施するときに、前のフェーズのテスト観点のテストの実施結果を振り返る。その結果、前のフェーズのテスト観点のバグの収束度合に問題があった場合は、次のフェーズのテスト観点のテストに、前のフェーズのテスト観点のバグの収束度合を改善するテストを追加していく。図２２の例では、フェーズ５の「回復・例外／起動・再起動」のテストを実施するときに、前のフェーズ４の「負荷・ストレス」のテストの実施結果を振り返ると、「負荷・ストレス」のバグの収束度合に問題があることがわかる。そのため、フェーズ５の「回復・例外／起動・再起動」のテストに、前のフェーズ４の「負荷・ストレス」のバグの収束度合を改善するテストを追加する。なお、テスト観点を実施する順番は、最もリスクが高いバグを抽出することできるテスト観点の順番を最も早くするのが良い。

＜実施の形態１の効果＞
上述したように本実施の形態１によれば、バグ検出率算出部１３は、テスト観点毎に、そのテスト観点のバグ検出率を算出し、バグ収束判定部１４は、テスト観点毎に、そのテスト観点のテスト実施量が、そのテスト観点のテスト実施基準量に到達した後に、そのテスト観点のバグ検出率が、そのテスト観点の基準値以下であるか否かに応じて、そのテスト観点のバグの収束を判定する。

従って、過去のバグ発生実績データを用いなくても、バグの収束を判定することができる。また、テスト実施量がテスト実施基準量に到達した後に、バグの収束を判定することから、テスト実施量が少ない期間やバグ検出数が多い期間といった、不確定要素の多いデータが発生する期間が経過した後に、バグの収束を判定することになる。そのため、バグの収束判定の判定精度の向上を図ることができる。また、テスト観点毎に、バグの収束を判定することから、あるテスト観点のテストが漏れることが回避されるため、バグの収束判定の不測の誤判定を抑制することができる。

＜実施の形態２＞
上記実施の形態１においては、テスト観点毎のテスト実施基準量は、ユーザが入力し設定するものであった。そのため、テスト実施基準量は、テスト観点の開発規模に応じたテスト実施基準量には必ずしもなっていなかった。開発規模とは、ソースコードの規模、ソースコードの複雑度を表す指標、ファンクションポイント（ＦＰ：Function Point）などのいずれかである。

そのため、上記実施の形態１は、テスト観点の開発規模に対して、そもそものテスト実施量が少ないために、バグが検出されておらず、バグが収束しているという誤判定してしまう可能性が少なからずあった。

これに対して、本実施の形態２は、テスト観点毎のテスト実施基準量を、各々のテスト観点の開発規模に応じたテスト実施基準量とすることで、バグの収束判定の誤判定を抑制するものである。

＜実施の形態２に係るソフトウェア品質判定装置の構成＞
まず、本実施の形態２に係るソフトウェア品質判定装置２の構成について説明する。
図２３は、本実施の形態２に係るソフトウェア品質判定装置２のブロック構成の一例を示すブロック図である。

図２３に示されるように、本実施の形態２に係るソフトウェア品質判定装置２は、上記実施の形態１と比較して、テスト実施基準量算出部１５を追加している。以下、上記実施の形態１と異なる構成について説明する。

データベース１２は、上記実施の形態１と同様のデータに加えて、テスト観点毎の開発規模及びテスト観点毎の単位開発規模当たりのテスト実施基準量を保持している。
テスト実施基準量算出部１５は、テスト観点毎に、そのテスト観点のテスト実施基準量を算出する。具体的には、テスト実施基準量算出部１５は、データベース１２に保持されている単位開発規模当たりのテスト実施基準量に、データベース１２に保持されている開発規模を乗算して、テスト実施基準量を算出する。

データベース１２は、テスト観点毎のテスト実施基準量として、テスト実施基準量算出部１５でテスト観点毎に算出されたテスト実施基準量を保持する。
上記構成以外は、上記実施の形態１と同様である。

＜実施の形態２に係るテスト実施基準量＞
ここで、本実施の形態２に係るテスト観点毎の単位開発規模当たりのテスト実施基準量の具体例について説明する。ここでは、テスト観点は、図２と同様のテスト観点であるとする。

図２４に示されるように、テスト観点毎の単位開発規模当たりのテスト実施基準量は、テスト工数／ＫＬＯＣとしても良い。図２４の例では、「機能性」の単位開発規模当たりのテスト実施基準量をＡとした場合、「効率性」、「信頼性」、「使用性」、「保守性」、「可搬性」の単位開発規模当たりのテスト実施基準量は、それぞれ、０．１Ａ、０．４Ａ、０．６Ａ、１．１Ａ、０．２Ａとなっている。

また、図２５の例では、結合テストの場合、「機能性」の単位開発規模当たりのテスト実施基準量をＡとした場合、「効率性」、「信頼性」、「使用性」、「保守性」、「可搬性」の単位開発規模当たりのテスト実施基準量は、それぞれ、０．７Ａ、０．５Ａ、０．５Ａ、０．５Ａ、０．１Ａとなっている。また、システムテストの場合、「機能性」の単位開発規模当たりのテスト実施基準量をａとした場合、「効率性」、「信頼性」、「使用性」、「保守性」、「可搬性」の単位開発規模当たりのテスト実施基準量は、それぞれ、０．８ａ、０．３ａ、０．３ａ、０．１ａ、０．１ａとなっている。

また、テスト観点毎の単位開発規模当たりのテスト実施基準量は、以下の非特許文献３に記載された、単位開発規模当たりのテスト件数の統計データを使用しても良い。
非特許文献３：独立行政法人情報処理推進機構技術本部ソフトウェア高信頼化センター、「ソフトウェア開発データ白書２０１６−２０１７」、２０１６年１０月１日、第２１４頁

＜実施の形態２に係るソフトウェア品質判定方法＞
続いて、本実施の形態２に係るソフトウェア品質判定装置２によるソフトウェア品質判定方法について説明する。
図２６は、本実施の形態２に係るソフトウェア品質判定装置２によるソフトウェア品質判定方法を示すフロー図である。

図２６に示されるように、データベース１２は、ユーザが入力部１１に入力し設定した以下のデータを取得し保持する（ステップＳ３１）。
・テスト観点毎の開発規模
・テスト観点毎の単位開発規模当たりのテスト実施基準量
・テスト観点毎のバグ検出数
・テスト観点毎のテスト実施量
・テスト観点毎のバグ検出率の基準値
・テスト観点毎の追加テスト実施基準量

続いて、テスト実施基準量算出部１５は、テスト観点毎に、そのテスト観点の単位開発規模当たりのテスト実施基準量に、そのテスト観点の開発規模を乗算して、そのテスト観点のテスト実施基準量を算出する（ステップＳ３２）。

続いて、テスト実施基準量算出部１５は、上記で算出したテスト観点毎のテスト実施基準量をデータベース１２に登録し、データベース１２は、テスト観点毎のテスト実施基準量を保持する（ステップＳ３３）。

以降、上記実施の形態１と同様に、テスト観点毎に、そのテスト観点でのバグの収束を判定するためのバグ収束判定処理が行われる（ステップＳ１２）。なお、ステップＳ１２のバグ収束判定処理も、上記実施の形態１と同様に、図６のフローで実施される。

＜実施の形態２の効果＞
上述したように本実施の形態２によれば、テスト実施基準量算出部１５は、テスト観点毎に、そのテスト観点の開発規模に応じて、そのテスト観点のテスト実施基準量を算出し、バグ収束判定部１４は、テスト観点毎に、そのテスト観点のテスト実施量が、そのテスト観点の開発規模に応じて算出されたテスト実施基準量に到達した後に、そのテスト観点のバグの収束を判定する。

従って、テスト観点の開発規模に対して、そもそものテスト実施量が少ないために、バグが検出されておらず、この状態でバグの収束判定が行われてしまうことが抑制される。これにより、バグの収束判定の誤判定をさらに抑制することができる。
その他の効果は、上記実施の形態１と同様である。

なお、本実施の形態２においては、テスト観点毎のテスト実施基準量として、そのテスト観点毎の開発規模に応じたものを用いたが、テスト観点毎の追加テスト実施基準量も、そのテスト観点毎の開発規模に応じたものを用いても良い。この場合、データベース１２が、テスト観点毎の単位開発規模当たりの追加テスト実施基準量をさらに保持し、テスト実施基準量算出部１５が、テスト観点毎の開発規模に応じた追加テスト実施基準量を算出すれば良い。

以上、実施の形態を参照して本発明を説明したが、本発明は、上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。
例えば、上記実施の形態１，２に係るソフトウェア品質判定装置１，２は、設計及び実装のレビュー工程に適用されても良い。この場合、テスト実施量をレビュー工数、開発規模をドキュメントのボリューム（行数、頁数、文字数など）、テスト観点をレビュー観点に置き換えて適用できる。なお、レビュー観点は、例えば、組織が有する観点表を用いても良いし、ＯＤＣ分析のレビュー工程の発見トリガーを用いても良い。

また、上記実施の形態１，２に係るソフトウェア品質判定装置１，２は、例えば、演算処理などを行うＣＰＵ（Central Processing Unit）などのプロセッサ、プロセッサによって実行されるプログラムや各種のデータなどを記憶するＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）などからなるメモリ、及び、外部と信号の入出力を行うインターフェイス部（Ｉ／Ｆ）などからなるハードウェア構成のコンピュータで実現される。プロセッサ、メモリ及びインターフェイス部は、データバスなどを介して相互に接続される。

メモリは、データベース１２の役割を果たす。また、メモリは、バグ検出率算出部１３、バグ収束判定部１４、及びテスト実施基準量算出部１５の機能を実現するプログラムを記憶し、プロセッサは、これらプログラムを実行することで、バグ検出率算出部１３、バグ収束判定部１４、及びテスト実施基準量算出部１５の機能をそれぞれ実現する。

また、上記プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ−ＲＯＭ（Compact Disc-Read Only Memory）、ＣＤ−Ｒ（CD-Recordable）、ＣＤ−Ｒ／Ｗ（CD-ReWritable）、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバなどの有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

１，２ソフトウェア品質判定装置
１１入力部
１２データベース
１３バグ検出率算出部
１４バグ収束判定部
１５テスト実施基準量算出部

Claims

システムに発生するバグの収束を判定するソフトウェア品質判定装置であって、
前記システムをテストする際の観点であるテスト観点毎に、該テスト観点のテストで発生したバグの検出率を算出するバグ検出率算出部と、
前記テスト観点毎に、該テスト観点のテストの実施量が、該テスト観点の前記実施量の基準となる実施基準量に到達した後に、該テスト観点の前記算出された前記検出率が、該テスト観点の前記検出率の基準となる基準値以下であるか否かに応じて、該テスト観点のバグの収束を判定するバグ収束判定部と、を備える、ソフトウェア品質判定装置。
前記バグ収束判定部は、前記テスト観点毎に、該テスト観点の前記実施量が、該テスト観点の前記実施基準量に到達した後に、該テスト観点の前記算出された前記検出率が該テスト観点の前記基準値以下である状態が、予め設定された期間、継続しているか否かに応じて、該テスト観点のバグの収束を判定する、請求項１に記載のソフトウェア品質判定装置。
前記バグ収束判定部は、前記テスト観点毎に、該テスト観点の前記算出された前記検出率が該テスト観点の前記基準値以下となり、その後に、該テスト観点の前記実施量が、該テスト観点の前記実施基準量に到達した後に、該テスト観点のバグの収束を判定する、請求項１又は２に記載のソフトウェア品質判定装置。
前記テスト観点毎に、該テスト観点の開発規模に応じて、該テスト観点の前記実施基準量を算出する実施基準量算出部をさらに備え、
前記バグ収束判定部は、前記テスト観点毎に、該テスト観点のテストの実施量が、該テスト観点の前記算出された前記実施基準量に到達した後に、該テスト観点のバグの収束を判定する、請求項１から３のいずれか１項に記載のソフトウェア品質判定装置。
システムに発生するバグの収束を判定するソフトウェア品質判定装置によるソフトウェア品質判定方法であって、
前記システムをテストする際の観点であるテスト観点毎に、該テスト観点のテストで発生したバグの検出率を算出するステップと、
前記テスト観点毎に、該テスト観点のテストの実施量が、該テスト観点の前記実施量の基準となる実施基準量に到達した後に、該テスト観点の前記算出された前記検出率が、該テスト観点の前記検出率の基準となる基準値以下であるか否かに応じて、該テスト観点のバグの収束を判定するステップと、を含む、ソフトウェア品質判定方法。
システムに発生するバグの収束を判定するコンピュータに、
前記システムをテストする際の観点であるテスト観点毎に、該テスト観点のテストで発生したバグの検出率を算出する手順と、
前記テスト観点毎に、該テスト観点のテストの実施量が、該テスト観点の前記実施量の基準となる実施基準量に到達した後に、該テスト観点の前記算出された前記検出率が、該テスト観点の前記検出率の基準となる基準値以下であるか否かに応じて、該テスト観点のバグの収束を判定する手順と、を実行させるためのソフトウェア品質判定プログラム。