JP7296502B1 - バグ検出率閾値更新システム、バグ検出率閾値更新方法、及びバグ検出率閾値更新プログラム - Google Patents

Abstract

【課題】ソフトウェアテストにおけるバグの検出率の閾値を適切に更新するバグ検出率閾値更新システム、バグ検出率閾値更新方法及びバグ検出率閾値更新プログラムを提供する。【解決手段】バグ検出率閾値更新システムにおいて、センターサーバは、ソフトウェアのテストにおけるバグの検出率の閾値を取得し、過去にテストされた複数のテスト対象それぞれのバグの検出率を取得する。さらに、検出率に基づいて、閾値の候補を決定し、検出率に基づいて、検出率の外れ値と外れ値以外の値との境となる値と、検出率の代表値と、の基準差を決定し、閾値と候補との差が基準差未満である場合、閾値を候補で更新する。【選択図】図１

Description

本発明は、ソフトウェアのテストで検出されたバグの検出率を用いて、テストに関連する決定を行う方法に関する。

従来、開発されたソフトウェアの品質を確保するために、ソフトウェアのテストを実施することが知られている。例えば、テストエンジニア等が、テストの内容や手順等を示すテスト項目又はテストケースを予め作成する。テスト実施者は、作成されたテスト項目又はテストケースに従って、テストを実施する。テストの結果、ソフトウェアのバグが検出された場合、開発者はそのソフトウェアを修正して、バグを取り除く。また、ソフトウェアのテストとして、所謂追加テストが行われる場合がある。追加テストは、例えば予定されたテストの結果に基づき、必要と判断された場合に実施される追加的なテストである。例えば、テストで検出されたバグが比較的に多く、ソフトウェアの品質を押し上げる必要であると判断される場合に、追加テストが実施されることもある。バグの多さを示す情報として、バグ検出率がある。バグ検出率は、例えば、テストで検出されたバグ数を、実施されたテストの件数で除算することで計算されてもよい。このバグ検出率を、予め設定された閾値と比較することで、テストされたソフトウェアに関連して何らかの対応の必要性を判断することも知られている。

例えば、特許文献１には、システムに発生するバグの収束を判定するためのソフトウェア品質判定装置が開示されている。この判定装置のデータベースには、テスト観点ごとに、そのテスト観点のテストで発生したバグの検出率の基準となる特定値として、ユーザにより設定された特定値が保持される。そして、或るテスト観点のテスト実施量がテスト実施基準量に到達した後、バグ検出率が特定値以下になるまで、追加テスト実施基準量分の追加テストが繰り返し実施される。判定装置は、テストの実施が終了するたびに、その時点のバグ検出率が特定値以下であるか否かに応じて、その観点のテストのバグが収束しているか否かを判定する。

特開２０１９－１０１５８１号公報

バグの検出率が閾値以上となったことのみを理由として、必ずしも追加テストを実施すべきであると判断されるとは限らない。しかしながら、バグの検出率が閾値以上となることは、追加テストの実施の判断材料の一つとなったり、ソフトウェア開発体制又は開発環境等の見直しのきっかけになったりする場合がある。そのような判断を的確に下すためには、閾値が適切に設定されることが望ましいと考えられる。

本発明は以上の点に鑑みてなされたものであり、その課題の一例は、ソフトウェアテストにおけるバグの検出率の閾値を適切に更新可能なバグ検出率閾値更新システム、バグ検出率閾値更新方法、及びバグ検出率閾値更新プログラムを提供することにある。

上記課題を解決するために、請求項１に記載の発明は、ソフトウェアのテストにおけるバグの検出率の閾値を取得する閾値取得手段と、過去にテストされた複数のテスト対象それぞれのバグの検出率を取得するバグ検出率取得手段と、前記取得された検出率に基づいて、前記閾値の候補を決定する候補決定手段と、前記取得された検出率に基づいて、前記検出率の外れ値と該外れ値以外の値との境となる値と、前記検出率の代表値と、の基準差を決定する基準差決定手段と、前記取得された閾値と前記決定された候補との差が、前記決定された基準差未満である場合、前記閾値を前記候補で更新する更新手段と、を備えることを特徴とする。

この発明によれば、閾値の候補と閾値との差が、基準差未満である場合、閾値が閾値候補で更新される。この基準差は、外れ値とならないバグの検出率の範囲に対応する。閾値の候補及び閾値の基となるバグの検出率が期間によって変化する場合、その期間について、ソフトウェアの開発体制や開発環境に何らかの変化があった可能性がある。この変化を反映して、閾値が更新される。その一方で、変化した状態は一時的なものであり、まもなく元の状態に戻る可能性がある。或いは、開発体制や開発環境に変化があったのではなく、偶然にも閾値の第１候補と閾値との間に差が生じたのかもしれない。そこで、閾値が大きく変更される場合の影響を鑑みて、閾値の候補と閾値との差が基準差未満である場合に、閾値が更新される。一方、閾値の候補と閾値との差が基準差以上である場合、閾値は直ちに更新されないか、または他の条件に基づいて、閾値の更新の要否が決定されてもよい。従って、フトウェアテストにおけるバグの検出率の閾値を適切に更新することができる

請求項２に記載の発明は、前記基準差決定手段は、前記取得された検出率の標準偏差に基づいて、前記基準差を決定することを特徴とする。

この発明によれば、バグの検出率の標準偏差を用いることで、基準差を適切に決定することができる。

請求項３に記載の発明は、前記複数のテスト対象のそれぞれは、予定されたテストの結果に基づいて、追加テストの実施の要否が決定されたテスト対象のうち、前記追加テストを実施することが決定されたテスト対象であることを特徴とする。

この発明によれば、追加テストが実施されたテスト対象についてのバグの検出率を用いて、基準差が決定される。従って、その基準差を用いた比較の結果、更新された閾値又は更新されなかった閾値を用いて、所与のテスト対象の追加テストの可能性を適切に判定することができる。

請求項４に記載の発明は、前記バグ検出率取得手段は、前記検出率として、前記予定されたテストで検出されたバグの検出率を取得することを特徴とする。

この発明によれば、追加テストが実施されたテスト対象について、予定されたテストで検出されたバグの検出率を用いて、基準差が決定される。追加テストの実施の要否の決定に影響する可能性があるバグの検出率を用いることで、基準差を適切に決定することができる。

請求項５に記載の発明は、前記代表値は、前記取得された検出率の平均値及び中央値の何れか一方であることを特徴とする。

請求項６に記載の発明は、前記候補決定手段は、前記閾値の候補として、前記検出率の代表値を計算することを特徴とする。

請求項７に記載の発明は、コンピュータにより実行されるバグ検出率閾値更新方法において、ソフトウェアのテストにおけるバグの検出率の閾値を取得する閾値取得ステップと、過去にテストされた複数のテスト対象それぞれのバグの検出率を取得するバグ検出率取得ステップと、前記取得された検出率に基づいて、前記閾値の候補を決定する候補決定ステップと、前記取得された検出率に基づいて、前記検出率の外れ値と該外れ値以外の値との境となる値と、前記検出率の代表値と、の基準差を決定する基準差決定ステップと、前記取得された閾値と前記決定された候補との差が、前記決定された基準差未満である場合、前記閾値を前記候補で更新する更新ステップと、を含むことを特徴とする。

請求項８に記載の発明は、コンピュータを、ソフトウェアのテストにおけるバグの検出率の閾値を取得する閾値取得手段と、過去にテストされた複数のテスト対象それぞれのバグの検出率を取得するバグ検出率取得手段と、前記取得された検出率に基づいて、前記閾値の候補を決定する候補決定手段と、前記取得された検出率に基づいて、前記検出率の外れ値と該外れ値以外の値との境となる値と、前記検出率の代表値と、の基準差を決定する基準差決定手段と、前記取得された閾値と前記決定された候補との差が、前記決定された基準差未満である場合、前記閾値を前記候補で更新する更新手段、として機能させることを特徴とする。

本発明によれば、ソフトウェアテストにおけるバグの検出率の閾値を適切に更新することができる。

一実施形態に係るテスト管理システムＳの概要構成の一例を示す図である。 一実施形態に係るセンターサーバ１の概要構成の一例を示すブロック図である。 データベースに記憶される情報の例を示す図である。 一実施形態に係るセンターサーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。 閾値の更新例を示す図である。 閾値の更新例を示す図である。 バグ検出率の分布の一例を示すグラフである。 一実施形態に係るセンターサーバ１のシステム制御部１１による閾値更新制御処理の一例を示すフローチャートである。

以下、図面を参照して本発明の実施形態について詳細に説明する。実施形態においては、開発されるソフトウェアのテストが、テスト対象単位で行われる。テスト対象は、特定の一又は複数のソフトウェアであってもよい。例えば、テスト対象は、特定のソフトウェア開発プロジェクトで開発されるソフトウェアであってもよい。以降、ソフトウェア開発プロジェクトを、単に「プロジェクト」と称する。或いは、テスト対象は、開発されるソフトウェアによって実現される機能又はサービス等であってもよい。或いは、テスト対象は、モジュール、関数、オブジェクト、ルーチン、スクリプト又はライブラリ等であってもよい。テスト対象単位でテストを行うとは、対象となるソフトウェアに対して複数のテストを実施して、それらのテストの結果が集計されることを意味してもよい。

ソフトウェアのテストとして、予定されたテストと、追加テストとがあってもよい。予定されたテストは、ソフトウェアの開発スケジュールに当初から組み込まれていたテストであってもよい。以降、予定されたテストを、「本テスト」と称する。追加テストは、開発スケジュールに当初は組み込まれていなかったテストであってもよい。また、追加テストは、ソフトウェアの開発の参加者の誰か（例えば責任者等）が、本テストの結果に基づいて、実施するか否を決定するテストであってもよい。追加テストが実施される場合、ソフトウェアの完成が予定よりも遅延することがあってもよい。追加テストは、本テストで実施されたテストのうち、バグが検出されたテストの再実施であってもよい。すなわち、追加テストは再テストであってもよい。或いは、追加テストは、本テストの観点、項目又はケースとは異なる観点、項目又はケースで実施されるテストであってもよい。追加テストを実施した結果、更なる追加テストが実施されてもよい。

追加テストの実施の可能性又は必要性に影響し得る要素の一つとして、バグ検出率がある。バグ検出率は、テストで検出されたバグの数を、実施されたテストの件数で除算することで、計算されてもよい。テストの件数は、例えばテスト項目数であってもよいし、テストケース数であってもよい。一のテストケースで、一又は複数のテスト項目が確認されてもよい。バグ検出率は、テスト対象ごとに計算されてもよい。例えば、プロジェクトごとにバグ検出率が計算されてもよい。一般的に、バグ検出率が高いほど、追加テストの実施の可能性は高くなってもよい。

以下においては、テスト対象として、複数のプロジェクトそれぞれで開発されるソフトウェアのテストを管理するためのシステムに対して、本発明が適用された場合について説明する。

［１．テスト管理システムの構成］
先ず、本実施形態に係るテスト管理システムＳの構成及び機能概要について、図１を用いて説明する。図１は、本実施形態に係るテスト管理システムＳの概要構成の一例を示す図である。

図１に示すように、テスト管理システムＳは、センターサーバ１と、複数の開発端末２と、を含んで構成される。センターサーバ１と各開発端末２とは、ネットワークＮＷを介して互いに接続される。ネットワークＮＷの例として、インターネット、ＬＡＮ（Local Area Network）、ＶＰＮ（Virtual Private Network）等が挙げられる。

センターサーバ１は、ソフトウェアのテストを管理するためのサーバ装置である。センターサーバ１は、実際には複数のサーバ装置で構成されるサーバシステムであってもよい。センターサーバ１は、例えばプロジェクトごとに、テストの実施状況やテストの結果を示す情報を記憶してもよい。テストの結果は、本テスト又は追加テストにおける全テストが終了した後の最終的な結果であってもよい。テストの実施状況は、テストの途中結果を含んでもよい。センターサーバ１は、更に各プロジェクトの進捗状況を管理してもよい。例えば、センターサーバ１は、各プロジェクトについて、そのプロジェクトが現在何れの段階にあるかを管理してもよい。センターサーバ１は、プロジェクトの参加者により開発端末２に入力された情報に基づいて、テスト実施状況、テスト結果、プロジェクト進捗状況を更新してもよい。センターサーバ１は、センターサーバ１が記憶しているテストに関する情報を、開発端末２からの要求に応じて送信する。

センターサーバ１は、テストの途中結果又は最終結果の一つとして、バグ検出率を計算する。そして、センターサーバ１は、本テストにおけるバグ検出率に基づいて、そのバグ検出率に関連付けられたプロジェクトについて、追加テストの実施の可能性を示すリスク情報を、開発端末２へ提供してもよい。リスク情報は、そのプロジェクトのリスクを示す情報であるということができる。具体的に、センターサーバ１は、バグ検出率が、予め設定された閾値未満である場合、追加テストの可能性が比較的に低いことを示すリスク情報を提供してもよい。その一方で、センターサーバ１は、バグ検出率が閾値以上である場合、追加テストの可能性が比較的に高いことを示すリスク情報を提供してもよい。本テストの途中結果としてリスク情報が提供される場合、プロジェクトの責任者等は、そのリスク情報を参考にして、ソフトウェアの開発体制や開発環境の見直しを行ってもよい。開発体制の見直しの例として、プロジェクトに参加するメンバー、グループ若しくは企業の見直し、プロジェクトの参加者に対する指導若しくは教育、ソフトウェア開発に適用されるルールの見直し等を含んでもよい。開発環境の見直しは、ソフトウェアの開発に用いられる装置やシステムの見直し、開発が行われる場所の見直し等を含んでもよい。こうした見直しによって、そのプロジェクトは、追加テストを実施しなくても、開発されるソフトウェアの品質を一定品質以上に保つことを目指すことになる。一般的には、バグ検出率が閾値以上である場合、バグ検出率が閾値未満である場合よりも、前述の見直しの必要性が明確に高いと考えられる。

本テストが完了し、若しくは本テストの完了が近くなると、プロジェクトの責任者等は、追加テストを実施するか否かを決定する。例えば、責任者等は、バグ検出率、バグの内容、検出されたバグと類似する未検出のバグが残存している可能性、バグが検出された部分と同じ部分に未検出のバグが残存している可能性等に基づいて、追加テストを実施するか否かを決定してもよい。バグ検出率が閾値以上となったからという理由のみで、追加テストが実施されるとは限らず、またバグ検出率が閾値未満となったからという理由のみで、追加テストが実施されないとも限らない。しかしながら、バグ検出率が閾値以上である場合、バグ検出率が閾値未満である場合よりも、追加テストが実施される可能性は高い。

センターサーバ１は、前述のバグの検出率の閾値を、自動的に設定及び更新してもよい。例えば、センターサーバ１は、プロジェクトが分類されるカテゴリごとに、またはプロジェクトで開発されるソフトウェアが分類されるカテゴリごとに、閾値を更新してもよい。カテゴリは、例えば、バグの傾向に共通性又は類似性があると推定されるプロジェクト又はソフトウェアが同一のカテゴリに分類されるように、カテゴリが定められてもよい。バグの傾向の例として、バグの多さ（またはバグ検出率）の傾向、バグの内容の傾向等がある。例えば、それぞれのプロジェクトで開発されるソフトウェアが、同一のサービスに関連するソフトウェアである場合、それらのプロジェクトは、同一のカテゴリに分類されてもよい。例えば、テスト管理システムＳを利用するソフトウェア開発企業が、インターネットを通じて提供される様々なサービスのソフトウェアを開発しているとする。インターネットを通じて提供されるサービスの例として、オンラインショッピング、フリーマーケット、宿泊施設の予約、美容施設の予約、スポーツ施設の予約、宅配料理の注文の受け付け、チケット販売、公営競技の投票券の販売、ウェブ検索、動画配信、音楽配信等が挙げられる。これらのサービスは、ウェブサイトのサーバソフトウェアで提供されてもよいし、サービスの利用者が利用する端末装置上で動作するアプリケーションソフトウェアで提供されてもよい。各サービスについて、複数のプロジェクトが進められる。こうした場合、閾値は、サービスごとに設定されてもよい。或いは、プロジェクトに参加するメンバー、グループ若しくは企業の同一性に基づいて、プロジェクトがカテゴリ分けされてもよい。

各開発端末２は、ソフトウェア開発の参加者が利用する端末装置である。各開発端末２は、例えば仕様書の作成、設計書の作成、プログラムの作成、テスト項目若しくはテストケースの作成及び閲覧、テストの実施、テストの実施結果の報告及び閲覧、テストの実施状況の閲覧等に用いられてもよい。各開発端末２には、テスト管理システムＳを利用するためのアプリケーションがインストールされてもよい。或いは、各開発端末２にインストールされているウエブブラウザを介して、テスト管理システムＳの利用が可能であってもよい。開発端末２の例として、パーソナルコンピュータ、タブレット式コンピュータ等が挙げられる。

［２．センターサーバの構成］
次に、センターサーバ１の構成について、図２及び図３を用いて説明する。図２は、本実施形態に係るセンターサーバ１の概要構成の一例を示すブロック図である。図２に示すように、センターサーバ１は、システム制御部１１と、システムバス１２と、入出力インターフェース１３と、記憶部１４と、通信部１５と、を備えている。システム制御部１１と入出力インターフェース１３とは、システムバス１２を介して接続されている。

システム制御部１１は、ＣＰＵ（Central Processing Unit）１１ａ、ＲＯＭ（Read Only Memory）１１ｂ、ＲＡＭ（Random Access Memory）１１ｃ等により構成されている。

入出力インターフェース１３は、記憶部１４及び通信部１５とシステム制御部１１との間のインターフェース処理を行う。

記憶部１４は、例えば、ハードディスクドライブ等により構成されている。この記憶部１４には、例えば、プロジェクトＤＢ１４ａ、テスト報告書ＤＢ１４ｂ、サービス閾値ＤＢ１４ｃ、閾値候補ＤＢ１４ｄ、プロジェクト閾値ＤＢ１４ｅ等のデータベースが記憶されてもよい。「ＤＢ」は、データベースの略語である。図３は、データベースに記憶される情報の例を示す図である。

図３に示すように、プロジェクトＤＢ１４ａには、プロジェクトに関するプロジェクト情報が、プロジェクトごとに記憶される。プロジェクト情報は、例えばプロジェクトの責任者等により設定されてもよい。例えば、プロジェクトＤＢ１４ａには、プロジェクト情報として、プロジェクトＩＤ、サービスＩＤ、本テスト件数、本テスト完了日、追加テストフラグ、追加テスト件数等が、互いに関連付けて記憶されてもよい。プロジェクトＩＤは、プロジェクトを識別するための識別情報である。サービスＩＤは、そのプロジェクトが属するサービスを識別する識別情報である。本テスト件数は、そのプロジェクトの本テストで実施されるべきテストの件数を示す。本テスト完了フラグは、そのプロジェクトの本テストが完了したか否かを示す。本テスト完了日は、そのプロジェクトの本テストが完了した日付を示す。本テスト完了フラグ及び本テスト完了日は、プロジェクトの責任者等により設定されてもよいし、センターサーバ１が自動的に設定してもよい。例えば、センターサーバ１は、後述するテスト報書ＤＢ１４ｂに基づいて、そのプロジェクトで実施された本テストの件数を計算してもよい。センターサーバ１は、実施されたテストの件数が、プロジェクトＤＢ１４ａに記憶されている本テスト件数と一致する場合、本テスト完了フラグを、本テスト完了に設定してもよい。このとき、センターサーバ１は、テスト報書ＤＢ１４ｂに基づいて、本テストのうち最後に実施されたテストの実施日を、本テスト完了日として決定してもよい。追加テストフラグは、そのプロジェクトについて追加テストが実施の決定状況を示す。例えば、追加テストフラグは、「未確定」、「非実施」、及び「要実施」の何れかに設定されてもよい。「未確定」は、追加テストを実施するか否かがまだ決定されていない状態を示す。「非実施」は、追加テストを実施しないことが決定されたことを示す。「要実施」は、追加テストを実施することが決定されたことを示す。追加テスト件数は、そのプロジェクトの追加テストで実施されるべきテストの件数を示す。

テスト報書ＤＢ１４ｂには、テストの実施結果の報告を示す報告情報が、テストが実施されるごとに記憶される。報告情報は、例えばテストの実施者により登録されてもよい。例えば、テスト報書ＤＢ１４ｂには、報告情報として、テスト番号、プロジェクトＩＤ、テスト種別、実施日、バグ数等が、互いに関連付けて記憶されてもよい。テスト番号は、実施されたテストのテスト項目若しくはテストケースを識別するための番号である。プロジェクトＩＤは、如何なるプロジェクトについてそのテストが実施されたかを示す。テスト種別は、実施されたテストが、本テスト及び追加テストの何れであるかを示す。実施日は、そのテストが実施された日付を示す。バグ数は、そのテストで検出されたバグの数を示す。

サービス閾値ＤＢ１４ｃには、バグ検出率の閾値が、サービスごとに記憶される。例えば、サービス閾値ＤＢ１４ｃには、サービスＩＤ及び現閾値が、互いに関連付けて記憶されてもよい。サービスＩＤは、その閾値が設定されたサービスを示す。現閾値は、現在の閾値を示す。現閾値は、センターサーバ１により定期的に更新されてもよい。

閾値候補ＤＢ１４ｄには、これまでにバグ検出率の閾値の候補となった値に関する候補情報が、サービスごとに記憶される。例えば、閾値候補ＤＢ１４ｄには、サービスＩＤが少なくとも記憶されてもよい。サービスＩＤは、閾値の候補が決定されたサービスを示す。閾値候補ＤＢ１４ｄには、更に１又は複数の候補情報が、サービスＩＤと関連付けて記憶されてもよい。例えば、閾値候補が新しく決定されるごとに、候補情報が閾値候補ＤＢ１４ｄに追加されてもよい。各候補情報は、インデックス値、当時閾値、及び閾値候補を含んでもよい。インデックス値は、その候補情報が、サービスＩＤと関連付けて記憶されている１又は複数の候補情報のうち、何番目に記憶された候補情報であるかを示す。当時閾値は、その当時閾値に関連付けられた閾値候補が決定された当時における現閾値である。なお、サービス閾値ＤＢ１４ｃに記憶されている現閾値が更新されると、閾値候補ＤＢ１４ｄに記憶されている同一サービスの候補情報は全て削除される。そのため、閾値候補ＤＢ１４ｄに記憶される当時閾値は、サービス閾値ＤＢ１４ｃに記憶される現閾値と一致する。

プロジェクト閾値ＤＢ１４ｅは、バグ検出率の閾値が、プロジェクトごとに記憶される。例えば、プロジェクト閾値ＤＢ１４ｅには、プロジェクトＩＤ及び閾値が、互いに関連付けて記憶されてもよい。プロジェクトＩＤは、その閾値が設定されたプロジェクトを示す。例えば、各プロジェクトの進捗状況を示す図示せぬデータベースが記憶部１４に記憶されてもよい。このデータベースにおいて、或るプロジェクトが、例えば実装若しくはスモークテストから本テストに進むと、センターサーバ１は、そのプロジェクトが属するサービスについて、そのときにサービス閾値ＤＢ１４ｃに記憶されている現閾値を、そのプロジェクトの閾値として、プロジェクト閾値ＤＢ１４ｅに記憶させてもよい。

記憶部１４には、更に、オペレーティングシステム、ＤＢＭＳ（Database Management System）、サーバプログラム等の各種プログラムが記憶されている。サーバプログラムは、テストを管理するための処理、プロジェクトの進捗を管理するための処理、バグ検出率の閾値を設定するための処理等をシステム制御部１１に実行させるプログラムである。サーバプログラムは、例えば、他の装置からネットワークＮＷを介して取得されるようにしてもよいし、磁気テープ、光ディスク、メモリカード等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。

通信部１５は、例えばネットワークインターフェースコントローラ等により構成されている。通信部１５は、ネットワークＮＷを介して開発端末２等の装置と接続し、接続された装置との通信状態を制御する。

［３．システム制御部の機能概要］
次に、センターサーバ１におけるシステム制御部１１の機能概要について、図４乃至図７を用いて説明する。図４は、本実施形態に係るセンターサーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。システム制御部１１は、ＣＰＵ１１ａが、サーバプログラムに含まれる各種プログラムコードを読み出し実行することにより、図４に示すように、バグ検出率取得部１１１、閾値候補決定部１１２、閾値取得部１１３、閾値更新部１１４、基準差決定部１１５、情報出力部１１６等として機能する。

［３－１．閾値の更新］
システム制御部１１は、バグ検出率の閾値の更新制御を行う。更新制御とは、閾値を更新するか否かの判定、及び、閾値を更新すると判定した場合における実際の閾値の更新を含む。例えば、システム制御部１１は、全サービスそれぞれについて定期的に（例えば、１ヶ月ごと、３ヶ月ごと、６ヶ月ごと、１年ごと等）、更新制御を実行してもよい。或いは、システム制御部１１は、センターサーバ１の管理者等からの指示があったタイミングで、特定のサービス又は全サービスそれぞれについて、更新制御を実行してもよい。

更新制御を実施するタイミングにおいて、バグ検出率取得部１１１は、過去の期間中にテストの結果が得られたテスト対象のバグ検出率を取得する。本実施形態において、テスト対象は、特定のプロジェクトで開発されるソフトウェアである。バグ検出率が取得される過去の期間を、「参照期間」と称する。参照期間は、例えば更新制御の実施日（すなわち今日）から特定される所定長の期間であってもよい。例えば、参照期間は、今日の所定月数前（例えば、１ヶ月前、３ヶ月前、６ヶ月前等）又は所定年数前（例えば、１年前、２年前、３年前等）の日から、現時点までの期間であってもよい。或いは、参照期間は、先月の初日の所定月数前又は所定年数前の日から先月の末日までの期間であってもよい。参照期間の長さと更新制御の実施間隔とは、一致してもよいし、一致しなくてもよい。参照期間は、前回の更新制御の実施日よりも後の日を含んでもよい。参照期間中にテストの結果が得られたテスト対象とは、例えば、その参照期間中に本テストが完了したプロジェクトであってもよい。本テストが開始された日が参照期間中に含まれている必要はない。バグ検出率取得部１１１は、プロジェクトＤＢ１４ａに記憶された本テスト完了日に基づいて、その参照期間中に本テストが完了したか否かを判定してもよい。或いは、バグ検出率取得部１１１は、テスト報告書ＤＢ１４ｂを参照することにより、そのプロジェクトの本テストについて完了したテストの件数を計算し、その件数と、プロジェクトＤＢ１４ａに記憶された本テスト件数とを比較することにより、本テストが完了したか否かを判定してもよい。そして、バグ検出率取得部１１１は、その本テストにおける最後のテストの実施日に基づいて、その参照期間中に本テストが完了したか否かを判定してもよい。テストで得られる結果は、例えば本テストにおける最終的なバグ検出率を含んでもよい。

バグ検出率取得部１１１は、特定されたプロジェクトごとに、バグ検出率を取得してもよい。例えば、バグ検出率取得部１１１は、テスト報告書ＤＢ１４ｂを参照して、本テストで検出されたバグの数の合計を計算してもよい。そして、バグ検出率取得部１１１は、バグ数の合計を本テスト件数で除算することにより、バグ検出率を計算してもよい。バグ検出率の取得対象となるテスト対象は、参照期間中に本テストが完了したプロジェクトのうち、閾値の更新制御の対象となるサービスに属するプロジェクトに限定されてもよい。更に、バグ検出率の取得対象となるテスト対象は、追加テストを実施することが決定されたプロジェクトに限定されてもよい。

閾値候補決定部１１２は、バグ検出率取得部１１１により取得されたバグ検出率に基づいて、閾値の候補を決定する。例えば、閾値の候補は、取得されたバグ検出率の代表値であってもよい。バグ検出率の代表値は、例えば平均値又は中央値であってもよい。追加テストが実施されるプロジェクトの本テストでのバグ検出率は、比較的に高くなる。その一方で、追加テストが実施されるプロジェクトであっても、本テストのバグ検出率が極端に高くなることは比較的に少ない。また、追加テストが実施される以上、バグ検出率が極端に低くなることも比較的に少ない。更に、同一又は極めて近いバグ検出率が取得された複数のプロジェクトが、追加テストを実施するプロジェクトと実施しないプロジェクトとに分けられる場合がある。その一方で、バグ検出率が高いほど追加テストが実施される可能性は高い。これらの事情を考慮すると、閾値を、バグ検出率の平均値又は中央値等の代表値に設定することに妥当性があると考えられる。

このタイミングで特定された参照期間を、便宜上、「第１参照期間」と称する。また、このタイミングで取得されたバグ検出率を、「第１バグ検出率」と称する。また、このタイミングで決定された閾値候補を、「第１閾値候補」と称する。

閾値取得部１１３は、バグ検出率の現閾値を取得する。例えば、閾値取得部１１３は、閾値の更新制御の対象となるサービスについてサービス閾値ＤＢ１４ｃに記憶されている現閾値を取得してもよい。

閾値更新部１１４は、閾値候補決定部１１２により決定された第１閾値候補と閾値取得部１１３により取得された閾値との差が、所定の基準差未満である場合、その閾値をその第１閾値候補で更新する。基準差は、例えばセンターサーバ１の管理者等により予め設定されてもよいし、後述するように、センターサーバ１が決定してもよい。一方、閾値更新部１１４は、第１閾値候補と閾値との差が基準差以上である場合、その閾値を第１閾値候補で更新しない。より一般化して述べると、閾値候補と閾値との差が基準差以上である場合、閾値を更新する場合と、更新しない場合とがある。閾値を更新する場合については後述する。

図５は、閾値の更新例を示す図である。図５に示すように、或るサービスの現閾値は３．０％である。また、バグ検出率に基づいて計算された閾値候補は、２．８％である。基準差は、０．５％であると仮定する。従って、閾値候補と現閾値との差は基準差未満であるので、現閾値は２．８％に更新される。

第１閾値候補と閾値との差が基準差以上であることにより、閾値取得部１１３により閾値が第１閾値候補で更新されなかった後、バグ検出率取得部１１１は、更新制御を実施する次のタイミングにおいて、第１参照期間よりも後の日を含む過去の期間中にテストの結果が得られたテスト対象のバグ検出率を取得する。次の更新制御時における過去の期間を、「第２参照期間」と称する。第１参照期間と第２参照期間とに重複があってもよいし、重複がなくてもよい。第２参照期間は、第１参照期間よりも前の日を含まなくてもよい。第１参照期間の長さと第２参照期間の長さとは同一であってもよいし、異なってもよい。例えば、バグ検出率取得部１１１は、第１参照期間を特定する場合と同様に、次の更新制御の実施日から特定される所定長の期間を、第２参照期間としてもよい。参照期間が異なることを除き、バグ検出率の取得方法は、第１バグ検出率の取得方法と同一であってもよい。今回の更新制御時におけるバグ検出率を、「第２バグ検出率」と称する。

閾値候補決定部１１２は、バグ検出率取得部１１１により取得された第２バグ検出率に基づいて、閾値の候補を決定する。閾値候補の決定方法は、第１閾値候補の決定方法と同一であってもよい。今回の更新制御時における閾値候補を、「第２閾値候補」と称する。

閾値更新部１１４は、閾値候補決定部１１２により決定された第２閾値候補と閾値との差が基準差未満である場合、その閾値をその第２閾値候補で更新する。この点については、第１閾値候補を用いた更新と同一である。一方、第２閾値候補と閾値との差が基準差以上である場合、前回の更新制御時において、第１閾値候補と閾値との差が基準差以上であったので、閾値更新部１１４は、閾値を第２閾値候補で更新してもよい。換言すると、前回の更新制御時に閾値が更新されなかったので、閾値更新部１１４は、閾値を更新するということもできる。

バグ検出率の閾値及び閾値候補は、参照期間に結果が得られたテスト対象のバグ検出率の代表値である。参照期間が、第１参照期間から第２参照期間に変わることで、代表値により示されるバグ検出率の傾向に変化があるとき、開発体制や開発環境等に変化があった可能性がある。或いは、追加テストの実施の要否の判断の基準に変更があった可能性がある。開発体制、開発環境、追加テスト実施の判断基準等の変化を閾値に反映することで、閾値が適切に更新されるものと考えられる。しかしながら、変化した状況は一時的なものであり、しばらく日数が経過すれば、開発体制や開発環境等は元に戻るかもしれない。或いは、開発体制や開発環境等が変化したのではなく、又はその変化とは無関係に、その時期にのみ偶然にもバグ検出率の傾向が変化しただけであるかもしれない。そのようなとき、閾値を閾値候補で更新することは、必ずしも適切であるとは限らない。そこで、閾値更新部１１４は、バグ検出率の傾向を示す閾値候補と閾値との差が１回のみ基準差以上となったとしても、その時点では更新しない。閾値更新部１１４は、閾値候補と閾値との差が連続して基準差以上となった場合、バグ検出率の傾向の変化が偶然ではなく、変化した状態は継続的なものであるとして、閾値を閾値候補で更新する。一方、閾値候補と閾値との差が基準差未満である場合には、たとえバグ検出率の傾向の変化は偶然であるか、または変化した開発体制や開発環境等は一時的なものであったとしても、閾値更新による影響は比較的に小さい。そのため、閾値更新部１１４は、閾値候補と閾値との差が基準差未満である場合、その他の条件を考慮せずに閾値を更新してもよい。

閾値更新部１１４は、第１閾値候補と閾値との差が基準差以上であることにより、閾値を第１閾値候補で更新しなかった後、第２閾値候補と閾値との差が基準差以上である場合には、更なる条件に基づいて、閾値を第２閾値候補で更新するか否かを判定してもよい。例えば、閾値更新部１１４は、第１閾値候補と閾値との大小関係と、第２閾値候補と閾値との大小関係と、が一致する場合にのみ、閾値を第２閾値候補で更新してもよい。閾値候補と閾値との大小関係とは、閾値候補が閾値よりも高いか否かを示す関係である。具体的に、第１閾値候補が閾値より高く、且つ、第２閾値候補も閾値より高い場合、大小関係は一致する。また、第１閾値候補が閾値より低く、且つ、第２閾値候補も閾値より低い場合にも、大小関係は一致する。閾値候補と閾値との差が連続して基準差以上となったとしても、第１閾値候補及び第２閾値候補の何れか一方の閾値候補が閾値よりも高い一方で、他方の閾値候補が閾値よりも低い場合、変化した開発体制や開発環境等は継続しているということはできない。

これまでに説明した閾値の更新方法の一般化した例を述べる。今回の閾値候補と閾値との差が基準差未満である場合、閾値更新部１１４は、閾値をその閾値候補で更新してもよい。今回の閾値候補と閾値との差が基準差以上である場合、閾値更新部１１４は、前回の更新制御時に、閾値をその当時の閾値候補で更新したか否かを判定してもよい。前回の更新制御時に閾値が更新されていた場合、閾値更新部１１４は、閾値を今回の閾値候補では更新しなくてもよい。前回の更新制御時に閾値が更新されていなかった場合、閾値更新部１１４は、前回の閾値候補と閾値との大小関係と、今回の閾値候補と閾値との大小関係と、が一致するか否かを判定してもよい。大小関係が一致する場合、閾値更新部１１４は、閾値を今回の閾値候補で更新してもよい。大小関係が不一致である場合、閾値更新部１１４は、閾値を今回の閾値候補で更新しなくてもよい。

閾値の初期値は、例えばセンターサーバ１の管理者により予め設定されてもよいし、これまで説明したように、バグ検出率に基づいてセンターサーバ１により設定されてもよい。

図６は、閾値の更新例を示す図である。例えば、更新制御が１ヶ月ごとに行われるとする。また、基準差は０．５％であると仮定する。図６に示すように、４月に入ったときにおける現閾値は３．０％である。このときに計算された閾値候補は、３．８％である。従って、このときの閾値候補と現閾値との差は基準差以上である。３月には現閾値が更新されていた場合、現閾値は更新されない。５月に入ったときに計算された閾値候補は、３．７％である。この閾値候補と現閾値との差は基準差以上である。４月には現閾値は更新されていない。４月の閾値候補は現閾値よりも高く、且つ、５月の閾値候補も現閾値より高い。従って、現閾値は３．７に更新される。

［３－２．基準差の設定］
次に、基準差を自動的に設定する方法について説明する。基準差決定部１１５は、バグ検出率取得部１１１により取得されたバグ検出率に基づいて、そのバグ検出率の外れ値と外れ値以外の値との境目となる特定値と、バグ検出率の代表値と、の差を、基準差として決定してもよい。外れ値とならないバグ検出率の範囲を、「正常区間」と称する。例えば、基準差決定部１１５は、正常区間の下限値又は上限値が、代表値からどれだけ離れているかに基づいて、基準差を決定してもよい。閾値候補と閾値との差が、このように決定された基準差以上となった場合、閾値候補は外れ値である可能性がある。そこで、閾値候補が外れ値である可能性がある場合、閾値を閾値候補で更新することが適切ではない場合がある。前述したように、閾値候補と閾値との差が連続して基準差以上となった場合、閾値が更新される場合がある。

特定値は、正常区間の下限値及び上限値の少なくとも何れか一方であってもよい。バグ検出率の代表値は、平均値又は中央値であってもよい。この代表値は、閾値候補自身であってもよい。

基準差決定部１１５は、バグ検出率の標準偏差を用いて基準差を決定してもよい。この場合、基準差決定部１１５は、特定値を計算しなくてもよい。バグ検出率を確率変数とし、プロジェクト数を度数とした場合のバグ検出率の分布は、正規分布又は比較的に正規分布に近い分布になるかもしれない。基準差決定部１１５は、例えば標準偏差に、ゼロよりも大きい実数である所定の係数を乗算することにより、基準差を計算してもよい。例えば、正常区間が全バグ検出率の約９５％を占めると仮定した場合、その係数は２．０であってもよい。なお、バグ検出率の分布が実際には正規分布ではなくても、基準差決定部１１５は標準偏差を用いて基準差を決定してもよい。

図７は、バグ検出率の分布の一例を示すグラフである。図７において、バグ検出率の分布は正規分布となっている。バグ検出率の平均値をμとし、標準偏差の所定係数倍の値を、基準差ｘとする。この場合の正常区間は、μ－ｘ～μ＋ｘの範囲である。μ－ｘ以下であるバグ検出率、及び、μ＋ｘ以上であるバグ検出率は、外れ値となる。

基準差決定部１１５は、バグ検出率のパーセンタイル値を用いて基準差を決定してもよい。このパーセンタイル値は、中央値や平均値とは異なる値である。例えば、正常区間が全バグ検出率のＮ％を占めると仮定する。この場合、基準差決定部１１５は、正常区間の下限値としての（（１００－Ｎ）÷２）パーセンタイル値、及び、正常区間の上限値としての（１００－（１００－Ｎ）÷２）パーセンタイル値のうち、少なくとも何れか一方を計算してもよい。そして、基準差決定部１１５は、パーセンタイル値と代表値との差を、基準差として決定してもよい。バグ検出率の分布が正規分布ではない場合、正常区間の下限値と代表値との差と、正常区間の上限値と代表値との差と、が異なる場合がある。このとき、例えば閾値更新部１１４は、閾値候補が閾値よりも高い場合には、正常区間の下限値で計算した基準差を用い、閾値候補が閾値よりも低い場合には、正常区間の上限値で計算した基準差を用いてもよい。

［３－３．バグ検出率と閾値に基づく情報提供］
情報出力部１１６は、バグ検出率及び閾値に基づいて、情報出力を行う。例えば、テスト中である所与のテスト対象のそのテストで検出されたバグの検出率が、閾値以上であるとする。その場合、情報出力部１１６は、その所与のテスト対象について追加テストを実施する可能性が、バグの検出率が閾値未満である場合よりも高いことを示すリスク情報を出力してもよい。テスト中である状態とは、例えば本テストに含まれる全テストのうち、一部のテストは実施されているものの、残りのテストは未実施である状態であってもよい。所与のテスト対象は、例えば開発端末２の画面に情報が表示されるプロジェクト（で開発されるソフトウェア）であってもよい。例えば、開発端末２の画面に１又は複数のプロジェクトについて進捗状況が表示されているとき、本テスト中にある各プロジェクトについてリスク情報が表示されるように、情報出力部１１６はそのリスク情報を開発端末２に送信してもよい。情報出力部１１６は、そのプロジェクトのプロジェクトＩＤに関連付けてテスト報書ＤＢ１４ｂに記憶された本テストの報告情報に基づいて、バグ検出率を計算してもよい。また、情報出力部１１６は、そのプロジェクトのプロジェクトＩＤに関連付けてプロジェクト閾値ＤＢ１４ｅに記憶されている閾値を用いて判定を行ってもよい。

本テストが完了した段階の最終的なバグ検出率が閾値以上となった場合、追加テストの実施の可能性が高くなる。そこで、本テストの途中の段階でバグ検出率が閾値以上となっている場合には、リスク情報としてその旨を開発者に提示することで、追加テストの実施を回避するために開発体制や開発環境の見直しを検討するきっかけを、開発者に提供することができる。

リスク情報の表示方法としては様々考えられる。例えば、情報出力部１１６は、開発者に指定されたサービスに属する各プロジェクトの進捗状況を、開発端末２に表示させるとする。例えば、情報出力部１１６は、ウェブページで進捗状況を示す情報を表示してもよい。開発端末２の画面には、各プロジェクトを示すプロジェクト進捗情報が、そのプロジェクトの進捗状況と関連付けて表示される。プロジェクト進捗情報は、少なくともプロジェクト名を含んでもよい。プロジェクトがテスト段階にある場合、プロジェクト進捗情報は更にバグ検出率を含んでもよい。情報出力部１１６は、バグ検出率が閾値以上であるか否かに基づいて、テストの段階にあるプロジェクトのプロジェクト進捗情報の表示態様を異ならせてもよい。表示態様が異なるプロジェクト進捗情報が、リスク情報の一例である。表示態様の例として、プロジェクト進捗情報の色彩、形状、及び大きさ、プロジェクト進捗情報の輪郭の色彩、及び太さ、プロジェクト進捗情報内の文字の色彩、スタイル、大きさ、及び太さ等が挙げられる。既に追加テストが実施されているプロジェクト、または本テスト中ではあるものの、追加テストを実施することが既に決定されているプロジェクトについては、更に別の態様でプロジェクト進捗情報が表示されてもよい。或いは、情報出力部１１６は、プロジェクト進捗情報内に、追加テストの可能性が高いことを示すメッセージを、リスク情報として含ませてもよい。

［４．センターサーバの動作］
次に、センターサーバ１の動作について、図８を用いて説明する。図８は、本実施形態に係るセンターサーバ１のシステム制御部１１による閾値更新制御処理の一例を示すフローチャートである。システム制御部１１は、各サービスについて定期的に閾値更新制御処理を実行してもよいし、開発者による実施の要求を開発端末２から受信することに応じて、各サービスについて閾値更新制御処理を実行してもよい。

図８に示すように、バグ検出率取得部１１１は、処理の対象となるサービスについて、本テスト完了日が参照期間内であるプロジェクトのバグ検出率を取得する（ステップＳ１０１）。例えば、バグ検出率取得部１１１は、参照期間として、今日の所定月数前又は所定年数前から今日までの期間を設定してもよい。バグ検出率取得部１１１は、プロジェクトＤＢ１４ａから、対象のサービスのサービスＩＤと「要実施」に設定された追加テストフラグとを含むプロジェクト情報のうち、本テスト完了日が参照期間に含まれるプロジェクト情報を検索してもよい。バグ検出率取得部１１１は、検索された各プロジェクト情報について、そのプロジェクト情報に含まれるプロジェクトＩＤと本テストを示すテスト種別との組み合わせを含む報告情報を検索してもよい。バグ検出率取得部１１１は、検索された報告情報の数を、テスト件数として計算してもよい。バグ検出率取得部１１１は、各報告情報からバグ数を取得し、バグ数の合計を計算してもよい。バグ検出率取得部１１１は、バグ数の合計をテスト件数で除算することにより、バグ検出率を計算してもよい。

次いで、基準差決定部１１５は、バグ検出率取得部１１１により取得されたバグ検出率の標準偏差を計算する（ステップＳ１０２）。次いで、基準差決定部１１５は、標準偏差に、予め設定された係数Ｋを乗算することにより、基準差を計算する（ステップＳ１０３）。次いで、閾値取得部１１３は、サービス閾値ＤＢ１４ｃから、対象のサービスのサービスＩＤに関連付けられた現閾値を取得する（ステップＳ１０４）。次いで、閾値候補決定部１１２は、閾値候補として、バグ検出率取得部１１１により取得されたバグ検出率の代表値を計算する（ステップＳ１０５）。

次いで、閾値更新部１１４は、閾値候補から現閾値を減算することにより、今回偏差を計算する（ステップＳ１０６）。次いで、閾値更新部１１４は、今回偏差の絶対値が基準差未満であるか否かを判定する（ステップＳ１０７）。

今回偏差の絶対値が基準差未満である場合（ステップＳ１０７：ＹＥＳ）、閾値更新部１１４は、現閾値を閾値候補で更新する（ステップＳ１０８）。例えば、閾値更新部１１４は、対象のサービスのサービスＩＤに関連付けてサービス閾値ＤＢ１４ｃに記憶されている現閾値を、閾値候補で書き換えてもよい（ステップＳ１０８）。次いで、閾値更新部１１４は、対象のサービスのサービスＩＤに関連付けて閾値候補ＤＢ１４ｄに少なくとも一の候補情報が記憶されている場合、それらの候補情報を閾値候補ＤＢ１４ｄから全て削除して（ステップＳ１０９）、閾値更新制御処理は終了する。

一方、今回偏差の絶対値が基準差以上である場合（ステップＳ１０７：ＮＯ）、閾値更新部１１４は、対象のサービスのサービスＩＤに関連付けて、候補情報をサービス閾値ＤＢ１４ｃに追加して記憶させる（ステップＳ１１０）。このとき、閾値更新部１１４は、当時閾値としての現閾値及び閾値候補を、候補情報に含ませる。また、閾値更新部１１４は、対象のサービスのサービスＩＤに関連付けて既に記憶されている候補情報がない場合、追加する候補情報のインデックス値を１に設定する。一方、既に記憶されている候補情報がある場合、それらの候補情報に含まれるインデックス値のうち、最大のインデックス値に１を加算して、追加する候補情報のインデックス値を計算する。次いで、閾値更新部１１４は、サービス閾値ＤＢ１４ｃに前回の候補情報が記憶されているか否かを判定する（ステップＳ１１１）。すなわち、閾値更新部１１４は、ステップＳ１１０よりも前の段階で、対象のサービスのサービスＩＤに関連付けて既に候補情報が記憶されているか否かを判定する。前回の候補情報は、今回追加された候補情報のインデックス値よりも１小さいインデックス値を有する候補情報である。前回の候補情報が記憶されていない場合（ステップＳ１１１：ＮＯ）、閾値更新部１１４は、現閾値を更新しないと決定して（ステップＳ１１４）、閾値更新制御処理は終了する。

一方、前回の候補情報が記憶されている場合（ステップＳ１１１：ＹＥＳ）、閾値更新部１１４は、前回の候補情報に含まれる前回の閾値候補から、前回の候補情報に含まれる当時閾値を減算することにより、前回偏差を計算する（ステップＳ１１２）。次いで、閾値更新部１１４は、今回偏差の符号と前回偏差の符号とが一致するか否かを判定する（ステップＳ１１３）。今回偏差が正の値であり、且つ、前回偏差も正の値である場合、符号が一致する。また、今回偏差が負の値であり、且つ、前回偏差も負の値である場合、符号が一致する。符号が一致する場合（ステップＳ１１３：ＹＥＳ）、閾値更新部１１４は、現閾値を閾値候補で更新する（ステップＳ１０８）。符号が一致しない場合（ステップＳ１１３：ＮＯ）、閾値更新部１１４は、現閾値を更新しないと決定する（ステップＳ１１４）。なお、閾値更新部１１４は、今回偏差の絶対値が基準差以上である場合（ステップＳ１０７：ＹＥＳ）、前回偏差の絶対値が、今回計算された基準差以上であるか否かを更に判定してもよい。そして、閾値更新部１１４は、前回偏差の絶対値が今回の基準差未満である場合には、現閾値を更新しなくてもよい。

以上説明したように、本実施形態において、センターサーバ１が、過去の第１参照期間中にテストの結果が得られたプロジェクトの第１バグ検出率を取得してもよい。また、センターサーバ１が、第１バグ検出率に基づいて、第１閾値候補を決定してもよい。また、センターサーバ１が、第１閾値候補と現閾値との差が基準差未満である場合、現閾値を第１閾値候補で更新してもよい。また、センターサーバ１が、現閾値が第１閾値候補で更新されなかった後、第１参照期間よりも後の日を含む過去の第２参照期間中にテストの結果が得られたプロジェクトの第２バグ検出率を取得してもよい。また、センターサーバ１が、第２バグ検出率に基づいて、第２閾値候補を決定してもよい。また、センターサーバ１が、第２閾値候補と現閾値との差が基準差以上である場合、現閾値を第２閾値候補で更新してもよい。この場合、第１閾値候補と現閾値との差が基準差以上であることで、現閾値が第１閾値候補で更新されなかった後、次のタイミングにおいても同様に、現閾値の第２閾値候補と現閾値との差が基準差以上である場合、現閾値が第２閾値候補で更新される。第１参照期間中にテストの結果が得られたプロジェクトのバグの第１バグ検出率に基づいて決定された現閾値の第１閾値候補と現閾値との間に差が生じた場合、その期間について、ソフトウェアの開発体制や開発環境に何らかの変化があった可能性がある。この変化を反映して、現閾値が更新される。その一方で、変化した状態は一時的なものであり、まもなく元の状態に戻る可能性がある。或いは、開発体制や開発環境に変化があったのではなく、偶然にも現閾値の第１閾値候補と現閾値との間に差が生じたのかもしれない。そこで、現閾値が大きく変更される場合の影響を鑑みて、現閾値は直ちには更新されない。その後、新たな第２参照期間中にテストの結果が得られたプロジェクトのバグの第２バグ検出率に基づいて決定された現閾値の第２閾値候補と現閾値との比較の結果、やはり差が大きいのであれば、変化した状態は或る程度継続されている可能性がある。そこで、現閾値が第２閾値候補で更新される。従って、ソフトウェアテストにおけるバグの検出率の閾値を適切に更新することができる。

ここで、バグ検出率が取得されるプロジェクトは、本テストの結果に基づいて、追加テストの実施の要否が決定されたプロジェクトのうち、追加テストの実施が決定されたプロジェクトであってもよい。この場合、追加テストが実施されたプロジェクトについてのバグの検出率を用いて、閾値候補が決定される。従って、更新された現閾値を用いて、所与のプロジェクトの追加テストの可能性を適切に判定することができる。

このとき、センターサーバ１がバグ検出率のそれぞれとして、本テストで検出されたバグの検出率を取得してもよい。この場合、追加テストが実施されたプロジェクトについて、本テストで検出されたバグの検出率を用いて、閾値候補が決定される。追加テストの実施の要否の決定に影響する可能性があるバグの検出率を用いることで、閾値候補を適切に決定することができる。

また、センターサーバ１が、第２閾値候補と現閾値との差が基準差以上であり、且つ、第１閾値候補と現閾値との差が基準差以上であるときにおいては、第２閾値候補と現閾値との間の大小関係と、第１閾値候補と現閾値との間の大小関係と、が一致する場合、現閾値を第２閾値候補で更新してもよい。この場合、変化した状態が継続している可能性を適切に現閾値に反映することができる。

また、センターサーバ１が、閾値候補として、バグの検出率の代表値を計算してもよい。また、バグ検出率の代表値は、平均値及び中央値のうち何れか一方であってもよい。

また、センターサーバ１が、テスト中である所与のプロジェクトのテストで検出されたバグ検出率が現閾値以上である場合、そのプロジェクトについて追加テストを実施する可能性が、バグ検出率が現閾値未満である場合よりも高いことを示すリスク情報を出力してもよい。この場合、リスク情報が出力されることで、追加テストの実施を回避するために開発体制や開発環境の見直しを行うきっかけを開発者に与えることができる。

また、センターサーバ１が、ソフトウェアのテストにおけるバグの検出率の現閾値を取得してもよい。また、センターサーバ１が、過去にテストされた複数のプロジェクトそれぞれのバグ検出率を取得してもよい。また、センターサーバ１が、バグ検出率に基づいて、閾値候補を決定してもよい。また、センターサーバ１が、バグ検出率に基づいて、バグ検出率の外れ値とその外れ値以外の値との境となる特定値と、バグ検出率の代表値と、の基準差を決定してもよい。また、センターサーバ１が、現閾値と閾値候補との差が基準差未満である場合、現閾値を閾値候補で更新してもよい。この場合、基準差は、外れ値とならないバグの検出率の範囲に対応する。前述の理由と同様の理由により、現閾値が大きく変更される場合の影響を鑑みて、閾値候補と現閾値との差が基準差未満である場合に、現閾値が更新される。一方、閾値候補と現閾値との差が基準差以上である場合、現閾値は直ちに更新されないか、または他の条件に基づいて、現閾値の更新の要否が決定されてもよい。従って、ソフトウェアテストにおけるバグの検出率の閾値を適切に更新することができる。

ここで、センターサーバ１が、バグ検出率の標準偏差に基づいて、基準差を決定してもよい。この場合、バグの検出率の標準偏差を用いることで、基準差を適切に決定することができる。

１ センターサーバ
２ 開発端末
１１ システム制御部
１２ システムバス
１３ 入出力インターフェース
１４ 記憶部
１４ａ プロジェクトＤＢ
１４ｂ テスト報告書ＤＢ
１４ｃ サービス閾値ＤＢ
１４ｄ 閾値候補ＤＢ
１４ｅ プロジェクト閾値ＤＢ
ＮＷ ネットワーク
１１１ バグ検出率取得部
１１２ 閾値候補決定部
１１３ 閾値取得部
１１４ 閾値更新部
１１５ 基準差決定部
１１６ 情報出力部

Claims (8)

1. ソフトウェアのテストにおけるバグの検出率の閾値を取得する閾値取得手段と、
   過去にテストされた複数のテスト対象それぞれのバグの検出率を取得するバグ検出率取得手段と、
   前記取得された検出率に基づいて、前記閾値の候補を決定する候補決定手段と、
   前記取得された検出率に基づいて、前記検出率の外れ値と該外れ値以外の値との境となる値と、前記検出率の代表値と、の基準差を決定する基準差決定手段と、
   前記取得された閾値と前記決定された候補との差が、前記決定された基準差未満である場合、前記閾値を前記候補で更新する更新手段と、
   を備えることを特徴とするバグ検出率閾値更新システム。
2. 前記基準差決定手段は、前記取得された検出率の標準偏差に基づいて、前記基準差を決定することを特徴とする請求項１に記載のバグ検出率閾値更新システム。
3. 前記複数のテスト対象のそれぞれは、予定されたテストの結果に基づいて、追加テストの実施の要否が決定されたテスト対象のうち、前記追加テストを実施することが決定されたテスト対象であることを特徴とする請求項１又は２に記載のバグ検出率閾値更新システム。
4. 前記バグ検出率取得手段は、前記検出率として、前記予定されたテストで検出されたバグの検出率を取得することを特徴とする請求項３に記載のバグ検出率閾値更新システム。
5. 前記代表値は、前記取得された検出率の平均値及び中央値の何れか一方であることを特徴とする請求項１乃至４の何れか一項に記載のバグ検出率閾値更新システム。
6. 前記候補決定手段は、前記閾値の候補として、前記検出率の代表値を計算することを特徴とする請求項１乃至５の何れか一項に記載のバグ検出率閾値更新システム。
7. コンピュータにより実行されるバグ検出率閾値更新方法において、
   ソフトウェアのテストにおけるバグの検出率の閾値を取得する閾値取得ステップと、
   過去にテストされた複数のテスト対象それぞれのバグの検出率を取得するバグ検出率取得ステップと、
   前記取得された検出率に基づいて、前記閾値の候補を決定する候補決定ステップと、
   前記取得された検出率に基づいて、前記検出率の外れ値と該外れ値以外の値との境となる値と、前記検出率の代表値と、の基準差を決定する基準差決定ステップと、
   前記取得された閾値と前記決定された候補との差が、前記決定された基準差未満である場合、前記閾値を前記候補で更新する更新ステップと、
   を含むことを特徴とするバグ検出率閾値更新方法。
8. コンピュータを、
   ソフトウェアのテストにおけるバグの検出率の閾値を取得する閾値取得手段と、
   過去にテストされた複数のテスト対象それぞれのバグの検出率を取得するバグ検出率取得手段と、
   前記取得された検出率に基づいて、前記閾値の候補を決定する候補決定手段と、
   前記取得された検出率に基づいて、前記検出率の外れ値と該外れ値以外の値との境となる値と、前記検出率の代表値と、の基準差を決定する基準差決定手段と、
   前記取得された閾値と前記決定された候補との差が、前記決定された基準差未満である場合、前記閾値を前記候補で更新する更新手段、
   として機能させることを特徴とするバグ検出率閾値更新プログラム。

Images