JP6890795B1 - プログラム、方法、情報処理装置、及びシステム - Google Patents

Abstract

【課題】テストを効率的に実施すること。【解決手段】本開示のプログラムは、プロセッサと、メモリとを備えるコンピュータに実行させるためのプログラムである。プログラムは、プロセッサに、テスト工程において実施されたテストに関する情報を記憶するステップと、テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、テスト工程において、選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップとを実行させる。【選択図】図４

Description

本開示は、プログラム、方法、情報処理装置、及びシステムに関する。

ソフトウェアは、その品質を担保するため、ローンチの前に機能がテストされる。ソフトウェアの機能のテストは、一般的にテスト仕様書に基づいて行なわれる。テスト仕様書には、テストの方法、又は合否を判定するための条件等がテストケース毎に記載されている。

ソフトウェアについてのテストに関し、テスト計画を効率的に作成すること、及び精度の高いテスト計画を立てることはプロジェクトを進める上で大切である。特許文献１では、過去に行った同一又は類似のテストの実績工数に基づき、未実施のテスト項目にかかる工数を予測している。

特開２０２０−９８４１３

ソフトウェア開発では、テストを実施する順序は、プロジェクトにおけるテスト工程を計画通りに進める上で重要な要素である。例えば、不具合が発生する確率の高いテストが存在する場合、それらのテストの実施が遅くなるほど、デグレーションが発生するリスクが向上する。このため、不具合が発生しそうなテストについては、テスト工程の早期段階で実施した方が、テスト工程におけるテストを効率的に進めることが可能である。

本開示では、テストを効率的に実施することを目的とする。

上記課題を解決するため、本開示のプログラムは、プロセッサと、メモリとを備えるコンピュータに実行させるためのプログラムである。プログラムは、プロセッサに、テスト工程において実施されたテストに関する情報を記憶するステップと、テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、テスト工程において、選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップとを実行させる。

本開示によれば、テストを効率的に実施できる。

本実施形態のシステムの全体構成を示す図である。 本実施形態のシステムに含まれる端末装置の構成を示すブロック図である。 本実施形態のシステムに含まれるサーバの機能的な構成を示すブロック図である。 サーバが記憶するテストケースＤＢのデータ構造を示す図である。 テスト実施者によりテストが実施される際のシステムの動作を説明する図である。 ディスプレイに表示されるプロジェクトリストの例を表す模式図である。 ディスプレイに表示されるテストスイートのリストの例を表す模式図である。 ディスプレイに表示されるテストケースデータのリストの例を表す模式図である。 ディスプレイに表示されるチケットの入力フォームの例を表す模式図である。 ディスプレイに表示されるチケットの内容の例を表す模式図である。 開発者によりソフトウェアが改修され、改修されたソフトウェアがテスト実施者によりテストされる際のシステムの動作を説明する図である。 テストスイートに設定された優先度を設定する際のサーバの動作の例を示すフローチャートである。 分析部の動作の具体例を示すフローチャートである。 ディスプレイに表示されるテストスイートのリストの例を表す模式図である。 ディスプレイに表示されるテストケースデータのリストの例を表す模式図である。 ディスプレイに表示されるテストスイートのリストの例を表す模式図である。 ディスプレイに表示されるテストケースデータのリストの例を表す模式図である。 テスト動向を予測する際のサーバの動作の例を示すフローチャートである。 ディスプレイに表示される、テスト動向を表すグラフの例を表す模式図である。

以下、図面を参照しながら、実施の形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本開示の内容を不当に限定するものではない。また、本実施形態で説明される構成の全てが、本開示の必須構成要件であるとは限らない。

＜概要＞
本実施形態に係るシステム１は、所定のプロジェクトのテスト工程において、実施済みのテストケースを分析し、優先的にテストを実施するべきテストケースをテスト未実施のテストケースから抽出する。システム１は、抽出したテストケースについてのテストを優先的に実施するように、テスト実施者に提示する。そして、システム１は、テスト実施者、開発者、プロジェクト管理者等からの要求に応じ、テストの実施順序を変更したことにより予測されるテストの動向を要求元へ提示する。

なお、本実施形態において、テストケースは、テスト設計書に基づいて設定される。テスト設計書は、検査対象が有する機能を検査するためのテストが設計されているデータである。検査対象は、検査の対象を表し、例えば、所定のプロジェクトで開発される、ハードウェア、又はソフトウェア等である。検査対象には、例えば、試作品、中間品、最終製品が含まれる。

＜１ 全体構成＞
図１は、本実施形態のシステム１の全体構成を示す図である。図１に示すように、システム１は、端末装置１０と、サーバ２０とを備えている。端末装置１０と、サーバ２０とは、有線又は無線の通信規格を用い、ネットワーク８０を介して相互に通信可能に接続されている。ネットワーク８０は、例えば、インターネット、及び／又は通信事業者が提供する通信網等により実現される。図示の例では、複数の端末装置１０がシステム１に含まれている。

なお、図１では、サーバ２０が１台のコンピュータである場合を示しているが、サーバ２０は、複数台のコンピュータが組み合わされて実現されてもよい。

端末装置１０は、サーバ２０により提供されるサービスを利用するユーザが使用する端末である。例えば、端末装置１０−１は、テストを実施するテスト実施者が利用する端末である。端末装置１０−２は、ソフトウェアを開発する開発者が利用する端末である。なお、端末装置１０−１と、端末装置１０−２とが存在するが、装置自体の構造はほぼ同様であるため、以下では、端末装置１０として説明する。

端末装置１０は、例えば、据え置き型のＰＣ（Personal Computer）、ラップトップＰＣ、ヘッドマウントディスプレイ等により実現される。また、端末装置１０は、スマートフォン、又はタブレット端末等の携行性を備えたコンピュータであってもよい。

図１に示すように、端末装置１０は、通信ＩＦ（Interface）１２と、入力装置１３と、出力装置１４と、メモリ１５と、ストレージ１６と、プロセッサ１９とを備える。通信ＩＦ１２、入力装置１３、出力装置１４、メモリ１５、ストレージ１６、及びプロセッサ１９は、例えば、バスを介して互いに通信可能に接続されている。

通信ＩＦ１２は、端末装置１０が外部の装置と通信するため、信号を送受信するためのインタフェースである。入力装置１３は、ユーザ（従業員）からの入力操作を受け付けるための入力装置である。入力装置１３は、例えば、タッチパネル、タッチパッド、マウス等のポインティングデバイス、キーボード等を含む。出力装置１４は、ユーザに対し情報を提示するための出力装置である。出力装置１４は、例えば、ディスプレイ、スピーカ等を含む。

メモリ１５は、プログラム、及び、プログラム等で処理されるデータ等を一時的に記憶するためのものであり、例えば、ＤＲＡＭ（Dynamic Random Access Memory）等の揮発性のメモリにより実現される。ストレージ１６は、データを保存するための記憶装置であり、例えば、フラッシュメモリ、ＨＤＤ（Hard Disc Drive）等の不揮発性のメモリにより実現される。プロセッサ１９は、プログラムに記述された命令セットを実行するためのハードウェアであり、演算装置、レジスタ、周辺回路等により構成される。

サーバ２０は、テスト設計書に基づいて規定されるテストの実施状況、及び実施結果を管理する装置である。サーバ２０は、例えば、ネットワーク８０に接続されたコンピュータである。

図１に示すように、サーバ２０は、通信ＩＦ２２と、入出力ＩＦ２３と、メモリ２５と、ストレージ２６と、プロセッサ２９とを備える。通信ＩＦ２２、入出力ＩＦ２３、メモリ２５、ストレージ２６、及びプロセッサ２９は、例えば、バスを介して互いに通信可能に接続されている。

通信ＩＦ２２は、サーバ２０が外部の装置と通信するため、信号を送受信するためのインタフェースである。入出力ＩＦ２３は、ユーザからの入力操作を受け付けるための入力装置、及び、ユーザに対し情報を提示するための出力装置とのインタフェースとして機能する。メモリ２５は、プログラム、及び、プログラム等で処理されるデータ等を一時的に記憶するためのものであり、例えばＤＲＡＭ等の揮発性のメモリにより実現される。

ストレージ２６は、データを保存するための記憶装置であり、例えばフラッシュメモリ、ＨＤＤ等の不揮発性のメモリにより実現される。ストレージ２６は、必ずしも単独の回路により実現されなくてもよい。ストレージ２６は、例えば、複数の記憶回路により実現されてもよい。プロセッサ２９は、プログラムに記述された命令セットを実行するためのハードウェアであり、演算装置、レジスタ、周辺回路などにより構成される。

＜１．１ 端末装置の構成＞
図２は、本実施形態のシステム１に含まれる端末装置１０の構成を示すブロック図である。図２に示すように、端末装置１０は、通信部１２１と、入力装置１３と、出力装置１４と、記憶部１７０と、制御部１８０とを備える。

通信部１２１は、端末装置１０が他の装置と通信するための処理を行う。通信部１２１は、制御部１８０で生成された信号に送信処理を施し、外部（例えば、サーバ２０）へ送信する。通信部１２１は、外部から受信した信号に受信処理を施し、制御部１８０へ出力する。

入力装置１３は、端末装置１０を所有するユーザが指示を入力するための装置である。入力装置１３は、例えば、マウス１３１、キーボード１３２、及び、操作面へ触れることで指示が入力されるタッチ・センシティブ・デバイス１３３等により実現される。入力装置１３は、ユーザから入力される指示を電気信号へ変換し、電気信号を制御部１８０へ出力する。なお、入力装置１３は、マウス１３１、及びキーボード１３２等の物理的な操作デバイスに限定されない。入力装置１３には、例えば、外部の入力機器から入力される電気信号を受け付ける受信ポートが含まれてもよい。

出力装置１４は、端末装置１０を所有するユーザへ情報を提示するための装置である。出力装置１４は、例えば、ディスプレイ１４１等により実現される。ディスプレイ１４１は、制御部１８０の制御に応じて、画像、動画、テキスト等のデータを表示する。ディスプレイ１４１は、例えば、ＬＣＤ（Liquid Crystal Display）、又は有機ＥＬ（Electro-Luminescence）ディスプレイ等によって実現される。

記憶部１７０は、例えば、メモリ１５、及びストレージ１６等により実現され、端末装置１０が使用するデータ、及びプログラムを記憶する。

制御部１８０は、プロセッサ１９が記憶部１７０に記憶されるプログラムを読み込み、プログラムに含まれる命令を実行することにより実現される。制御部１８０は、端末装置１０の動作を制御する。具体的には、例えば、制御部１８０は、操作受付部１８１、送受信部１８２、表示制御部１８３としての機能を発揮する。

操作受付部１８１は、入力装置１３から入力されるユーザの操作を受け付けるための処理を行う。送受信部１８２は、端末装置１０が、サーバ２０等の外部の装置と、通信プロトコルに従ってデータを送受信するための処理を行う。表示制御部１８３は、ユーザに対して種々の情報を提示するため、出力装置１４を制御する。

＜１．２ サーバの機能的構成＞
図３は、本実施形態のシステム１に含まれるサーバ２０の機能的な構成を示すブロック図である。図３に示すように、サーバ２０は、通信部２０１、記憶部２０２、及び制御部２０３としての機能を発揮する。

通信部２０１は、サーバ２０が外部の装置と通信するための処理を行う。

記憶部２０２は、サーバ２０が使用するデータ及びプログラムを記憶する。例えば、記憶部２０２は、テストケースデータベース（ＤＢ）２８１、タスクデータベース（ＤＢ）２８２を記憶する。

テストケースＤＢ２８１は、テストケースに関する情報を記憶するためのデータベースである。

タスクＤＢ２８２は、発生したタスクを管理するためのデータベースである。タスクＤＢ２８２において、タスクは、例えば、チケット単位で管理される。

制御部２０３は、プロセッサ２９が記憶部２０２に記憶されるプログラムを読み込み、プログラムに含まれる命令を実行することにより実現される。制御部２０３は、サーバ２０の動作を制御する。具体的には、例えば、制御部２０３は、操作受付部２０３１、送受信部２０３２、記憶制御部２０３３、提示部２０３４、分析部２０３５、設定部２０３６、予測部２０３７としての機能を発揮する。

操作受付部２０３１は、ユーザからの操作を受け付ける。操作受付部２０３１は、例えば、ユーザとしてのテスト実施者によるテストケースの指定、テストの実施結果の入力等を受け付ける。また、操作受付部２０３１は、例えば、ユーザとしての開発者によるチケットに対する入力等を受け付ける。

送受信部２０３２は、サーバ２０が、端末装置１０等の外部の装置と、通信プロトコルに従ってデータを送受信する処理を制御する。

記憶制御部２０３３は、記憶部２０２への情報の記憶を制御する。具体的には、例えば、記憶制御部２０３３は、テスト実施者から、テスト実施済みのテストケースに関する情報が入力されると、入力された情報をテストケースＤＢ２８１に記憶する。記憶制御部２０３３は、開発者から、実施されたテストの結果に対する応答が入力されると、入力された応答に関する情報をテストケースＤＢ２８１に記憶する。記憶制御部２０３３は、実施されたテストの結果を分析した情報をテストケースＤＢ２８１に記憶する。記憶制御部２０３３は、実施されたテストの分析結果に基づく予測情報をテストケースＤＢ２８１に記憶する。

また、記憶制御部２０３３は、例えば、テスト実施者、又は開発者からタスクに関する情報が入力されると、入力された情報をタスクＤＢ２８２に記憶する。

提示部２０３４は、テストケースＤＢ２８１に記憶されている情報を、ユーザが望む態様で提示する。具体的には、提示部２０３４は、プロジェクトの選択画面を端末装置１０のディスプレイ１４１に表示させる。また、提示部２０３４は、テストスイートの選択画面をディスプレイ１４１に表示させる。本実施形態において、テストスイートは、例えば、所定の機能についての複数のテストケースデータを含む。テストケースデータは、例えば、テスト設計書で定義されるテストケースがテストの実施管理が可能な形式に変換されたデータである。複数のテストケースデータそれぞれは、共通のデータ構造をしている。テストスイートは、例えば、テスト実施者がテストを実施しやすい一式のテストケースデータを含む。テスト実施者がテストを実施しやすい一式のテストケースデータとは、例えば、同一の機能についてのテストケースデータ、又は、同一のモジュールについてのテストケースデータ等である。

また、提示部２０３４は、テストケースについてのテストの実施結果を入力させる画面をディスプレイ１４１に表示させる。また、提示部２０３４は、テストの実施結果に基づく分析情報を表示する画面をディスプレイ１４１に表示させる。また、提示部２０３４は、テストの実施結果に基づく予測情報を表示する画面をディスプレイ１４１に表示させる。

分析部２０３５は、テストの実施結果に関する情報を分析する。具体的には、分析部２０３５は、テストの実施結果を分析し、実施工数、生産性、不具合数、不具合率等を算出する。また、分析部２０３５は、テストの実施結果を分析し、不具合を発生しやすいテストケースを抽出する。不具合を発生しやすいテストケースは、例えば、優先してテストを実施するべきテストケースと換言可能である。分析部２０３５は、例えば、不具合が発生する件数に係る数値（不具合数、又は不具合率等）、生産性等に基づいて優先してテストを実施するべきテストケースを抽出する。

また、分析部２０３５は、テストの実施結果に対する開発者からの応答を分析し、不具合を発生しやすいテストケース、すなわち、優先してテストを実施するべきテストケースを抽出する。分析部２０３５は、例えば、発生した不具合を改修する工数に係る数値、発生した不具合の要因に基づき、優先的に対応するべきテストケースを抽出する。

設定部２０３６は、テストスイート、又はテストケースデータに対し、テストを実施するべき順序を設定する。例えば、設定部２０３６は、プロジェクトのテスト工程を開始する前に、テストスイート、又はテストケースデータに対し、テストを実施するべき順序を設定する。具体的には、設定部２０３６は、開発しているソフトウェアにおける重要な機能と対応するテストスイート、及びこのテストスイートに含まれるテストケースデータに優先的な順序を付与する。また、設定部２０３６は、過去に行った同一又は類似のテストの結果に基づき、テストスイート、又はテストケースデータに対し、優先的な順序を付与する。

また、設定部２０３６は、例えば、テスト工程において実施済みのテストの結果を利用し、テストスイート、又はテストケースデータに対し、実施するべき順序を設定する。具体的には、設定部２０３６は、分析部２０３５により抽出されたテストケースについてのデータ、及びこのテストケースデータを含むテストスイートに優先的な順序を付与する。

予測部２０３７は、ユーザにより選択された順序でテストを実施した際のテストの動向を予測する。具体的には、例えば、予測部２０３７は、実施済みのテストケースに基づき、未実施のテストケースで発生する不具合を含めた不具合の数、又は不具合率を予測する。また、予測部２０３７は、例えば、実施済みのテストケースで発生した不具合の改修工数、改修後確認工数に基づき、未実施のテストケースで発生する不具合の改修工数を含めた不具合の改修工数、改修後確認工数を予測する。

＜２ データ構造＞
図４は、サーバ２０が記憶するテストケースＤＢ２８１のデータ構造を示す図である。図４に示すテストケースＤＢ２８１は、テスト設計書においてテストケースを規定するために用いられる、「観点」、「因子」、及び「水準」を項目として含んでいる。「観点」は、テストの拠り所となる見地（考え方）を表す。「因子」は、コンピュータの状態変化に影響を与え得る要因を表す。「水準」は、「因子」の具体的な要素を表す。図４では、機能Ａにおける観点Ａの因子Ａ−水準ＡＡ〜ＡＣと、観点Ｂの因子Ｂ−水準ＢＡ〜ＢＣとについてのテストが既に実施されている場合が示されている。また、図４は一例であり、記載されていないデータを除外するものではない。

図４に示すテストケースＤＢ２８１は、例えば、所定のプロジェクトのテストケースに対して構築されたものである。プロジェクトが複数存在する場合には、テストケースＤＢ２８１は、例えば、プロジェクト毎に構築されてもよい。

図４に示すように、テストケースＤＢ２８１のレコードの各々は、項目「画面」、項目「機能」、項目「担当者」、項目「モジュール」、項目「観点」、項目「因子」、項目「水準」、項目「総ケース数」、項目「実施済みケース数」、項目「実施工数」、項目「生産性」、項目「不具合要因」、項目「実績」、項目「予測」等を含む。

項目「画面」は、機能が発現される画面に関する情報を記憶する。画面に関する情報は、例えば、画面の名称、又は、画面データへアクセスするためのリンクを含む。

項目「機能」は、ソフトウェアが有する機能に関する情報を記憶する。機能に関する情報は、例えば、「ログイン機能」のように、機能の名称を含む。機能の名称は、担当者により任意に入力されてもよいし、予め登録されているものから選択されてもよい。

項目「担当者」は、機能の開発者の名称を記憶する。なお、名称に限らず、開発者が識別可能であれば、名称に限らない。識別番号であっても、アドレス等であってもよい。

項目「モジュール」は、テスト実施者がテストを実施する際に操作するモジュールを記憶する。

項目「観点」は、テストの拠り所となる見地（考え方）を記憶する。項目「観点」は、項目「機能」が「ログイン機能」である場合、例えば、「正常認証」、「認証チェック」、「パスワード保持」等を記憶し得る。

項目「因子」は、コンピュータの状態変化に影響を与え得る要因を記憶する。項目「因子」は、項目「観点」が「正常認証」である場合、例えば、「ＩＤ／ＰＷの不整合有無」等を記憶し得る。

項目「水準」は、「因子」において具体的な操作をグループ化したもの記憶する。項目「水準」は、項目「因子」が「ＩＤ／ＰＷの不整合有無」である場合、例えば、「ＩＤが不整合」、「ＰＷが不整合」、「ＩＤ／ＰＷ両方ともに不整合」、「ＩＤ／ＰＷ共に整合」等を含む。

項目「総ケース数」は、各水準で発生するテストケースの総数を記憶する。

項目「実施済みケース数」は、テストが実施されたテストケースの数を記憶する。図４に示すテストケースＤＢ２８１では、機能Ａにおける観点Ａの因子Ａ−水準ＡＡ〜ＡＣと、観点Ｂの因子Ｂ−水準ＢＡ〜ＢＣとについて、全てのテストケースのテストが実施されている。

項目「実施工数」は、属するテストケースを実施するのにかかった工数を記憶する。工数は、テスト実施者からの申告に基づいて取得されてもよいし、テスト実施者の操作ログに基づいて自動で取得されてもよい。

項目「生産性」は、１テストケースに対してかかった時間を記憶する。図４に示す例では、１テストケースに対してかかった「分」を記憶する。

項目「不具合要因」は、テストで発生した不具合の要因毎の発生数を記憶する。項目「不具合要因」は、複数のサブ項目を含む。サブ項目には、不具合が発生した要因が割り当てられている。サブ項目に割り当てられている要因には、要因が埋め込まれた工程に応じた優先度が設定されている。

ソフトウェア開発は、例えば、要件定義、基本設計、詳細設計、コーディング、テストの順で作業工程が進められる。これらの各開発工程において、欠陥が埋め込まれる可能性がある。上流側の工程で埋め込まれた欠陥がある場合、テスト工程での検出が遅れるほど、欠陥を改修するためのコストは大きくなる。また、テスト工程での検出が遅れるほど、デグレーションが発生するリスクが向上する。そこで、不具合の要因について、要因が埋め込まれた工程に応じた優先度を設定することで発生した不具合を解消する重要度が分かるようになっている。

例えば、サブ項目に割り当てられる不具合要因に対し、上流工程に由来する要因、中流工程に由来する要因、下流工程に由来する要因とのように、要因が分類されている。上流工程に由来する要因は、例えば、要件定義で埋め込まれた欠陥に関する要因であり、中流工程に由来する要因、及び下流工程に由来する要因よりも優先度は高い。中流工程に由来する要因は、例えば、基本設計、及び詳細設計で埋め込まれた欠陥に関する要因であり、下流工程に由来する要因よりも優先度は高い。下流工程に由来する要因は、例えば、コーディング、テストで埋め込まれた欠陥に関する要因である。

不具合が発生する要因としては、例えば、「要件漏れ」、「影響範囲考慮漏れ」、「サブシステム間認識齟齬」、「仕様検討漏れ」、「機種依存」、「プログラミング誤り」、「環境設定ミス」、「単体テスト漏れ」、「既存バグ」等が存在する。このうち、例えば、「要件漏れ」、「影響範囲考慮漏れ」が上流工程に由来する要因に相当し、「サブシステム間認識齟齬」、「仕様検討漏れ」、「機種依存」が中流工程に由来する要因に相当し、「プログラミング誤り」、「環境設定ミス」、「単体テスト漏れ」、「既存バグ」が下流工程に由来する要因に相当する。なお、上記では、工程を３つに分類しているが、分類数は３つに限定されず、２つであっても、４つ以上であってもよい。

図４に示す例では、サブ項目として、「要件漏れ」、「影響考慮」、「シス間認識」、「仕様検討」、「作業ミス」、「環境異存」を含む。「要件漏れ」、「影響考慮」は上流工程に由来する要因に属し、「シス間認識」、「仕様検討」は中流工程に由来する要因に属し、「作業ミス」、「環境異存」は下流工程に由来する要因に属する。なお、サブ項目に割り当てられる要因はこれらに限定されない。その他の要因が加えられていてもよいし、一部の要因がなくてもよい。また、一部の要因がその他の要因と入れ替わっていてもよい。

項目「実績」は、実施されたテストの結果を記憶する。項目「実績」は、複数のサブ項目を含む。図４に示す例では、項目「実績」は、サブ項目「不具合数」、サブ項目「不具合率」、サブ項目「改修工数」、サブ項目「改修後確認工数」を含む。

サブ項目「不具合数」は、該当するテストケースのうち、不具合が発生した数を記憶する。サブ項目「不具合率」は、不具合が発生した確率を記憶する。サブ項目「不具合数」、サブ項目「不具合率」で表される情報は、例えば、テスト実施者から入力されるテストの実施結果に基づく。

サブ項目「改修工数」は、不具合を改修するのに要した工数を記憶する。サブ項目「改修工数」で表される情報は、例えば、プログラムの改修後に開発者から入力される情報に基づく。サブ項目「改修後確認工数」は、不具合を改修したプログラムをテストするのに要した工数を記憶する。サブ項目「改修後確認工数」で表される情報は、例えば、テスト実施者から入力される改修後のプログラムに対するテストの実施結果に基づく。

項目「予測」は、提案された優先順位でテストを実施した際に予測されるテスト結果を表す。項目「予測」は、複数のサブ項目を含む。図４に示す例では、項目「予測」は、サブ項目「不具合数」、サブ項目「不具合率」、サブ項目「改修工数」、サブ項目「改修後確認工数」を含む。サブ項目「不具合数」、サブ項目「不具合率」、サブ項目「改修工数」、サブ項目「改修後確認工数」で表される情報は、例えば、実施済みのテストの実施結果に基づいて算出される。

また、図４に示すテストケースＤＢ２８１は、項目「機能重要度」、項目「優先度」を含む。
項目「機能重要度」は、開発されているソフトウェアの機能の重要度を記憶する。図４に示す例では、重要度は「高」、「中」、「低」で表されているが、これに限定されない。重要度は数字で表されていてもよい。

項目「優先度」は、テストケースの優先度を表す。項目「優先度」は、複数のサブ項目を含む。図４に示す例では、項目「優先度」は、サブ項目「計画」、サブ項目「修正１」、サブ項目「修正２」を含む。サブ項目「計画」は、テスト工程の開始前に設定される優先度を記憶する。サブ項目「修正１」は、テスト工程中の所定のタイミングで、実施済みのテストの実施結果に基づいて設定される優先度を記憶する。図４に示す例では、サブ項目「修正１」は、サブ項目「計画」において優先度１に設定されているテストケース、例えば、機能Ａにおける観点Ａの因子Ａ、観点Ｂの因子Ｂについてのテストを実施した後に設定される優先度を記憶する。サブ項目「修正２」は、サブ項目「修正１」において優先度１に設定されているテストケース、例えば、機能Ｃにおける観点Ｄの因子Ａについてのテストを実施した後に設定される優先度を記憶する。

＜３ 動作＞
テスト実施者によりテストが実施される際のシステム１の動作について説明する。

＜３．１ テストの実施＞
図５は、テスト実施者によりテストが実施される際のシステム１の動作を説明する図である。

まず、端末装置１０−１を操作するテスト実施者は、端末装置１０−１を操作してサーバ２０にアクセスする。テスト実施者は、プロジェクトに関する情報を表示するように、端末装置１０−１を操作する。端末装置１０−１は、テスト実施者からの操作に応じ、プロジェクトに関する情報をサーバ２０に要求する。

サーバ２０は、端末装置１０−１からの要求に応じ、プロジェクトに関する情報を端末装置１０−１へ送信する。

端末装置１０−１は、サーバ２０から受信した情報をテスト実施者へ提示する。具体的には、例えば、端末装置１０−１は、プロジェクトリストをディスプレイ１４１に表示させる。

図６は、ディスプレイ１４１に表示されるプロジェクトリストの例を表す模式図である。プロジェクトリストには、現在進められているプロジェクトがリスト状に表示される。図６に示す例では、２つのプロジェクトが表示されている。各プロジェクトを表すレコードは、例えば、項目「プロジェクトキー」、項目「プロジェクト名」、項目「現状のプロセス」、項目「開始日」、項目「ステータス」を含む。

端末装置１０−１は、テスト実施者からのプロジェクトの選択を受け付ける（ステップＳ１０１）。具体的には、テスト実施者は、例えば、リストに表示されるプロジェクトのうち、テストを要するソフトウェアに関するプロジェクトを選択する。テスト実施者によりプロジェクトが選択されると、端末装置１０−１は、選択されたプロジェクトのテストスイートに関する情報をサーバ２０に要求する。

サーバ２０は、端末装置１０−１からの要求に応じ、テストスイートに関する情報をテストケースＤＢ２８１から取得する。サーバ２０は、取得した情報を端末装置１０−１へ送信する。

端末装置１０−１は、サーバ２０から受信した情報をテスト実施者へ提示する。具体的には、例えば、端末装置１０−１は、テストスイートのリストをディスプレイ１４１に表示させる。

図７は、ディスプレイ１４１に表示されるテストスイートのリストの例を表す模式図である。テストスイートのリストには、選択されたプロジェクトに含まれるテストスイートがリスト状に表示される。図７に示す例では、５つのテストスイートが表示されている。各テストスイートを表すレコードは、例えば、項目「Ｎｏ」、項目「テストスイート」、項目「担当者」、項目「優先度」、項目「Ｓｃｏｐｅ」、項目「Ｆｅａｔｕｒｅ」、項目「ケース数」、項目「進捗」、項目「更新日」を含む。項目「優先度」は、サブ項目「計画」、サブ項目「修正１」を有する。テストを実施する前の段階では、サブ項目「計画」には計画段階で設定された優先度が記憶されている。一方、サブ項目「修正１」はまだ空欄となっている。

端末装置１０−１は、テスト実施者からのテストスイートの選択を受け付ける（ステップＳ１０２）。具体的には、テスト実施者は、サブ項目「計画」を参照し、優先度１のテストスイート、つまり、最も優先的にテストを実施するべきテストスイートを選択する。テスト実施者によりテストスイートが選択されると、端末装置１０−１は、選択されたテストスイートのテストケースデータに関する情報をサーバ２０に要求する。

サーバ２０は、端末装置１０−１からの要求に応じ、テストケースデータに関する情報を端末装置１０−１へ送信する。

端末装置１０−１は、サーバ２０から受信した情報をテスト実施者へ提示する。具体的には、例えば、端末装置１０−１は、テストケースデータのリストをディスプレイ１４１に表示させる。

図８は、ディスプレイ１４１に表示されるテストケースデータのリストの例を表す模式図である。テストケースデータのリストには、選択されたテストスイートに含まれるテストケースデータがリスト状に表示される。図８に示す例では、５つのテストケースデータが表示されている。各テストケースデータを表すレコードは、例えば、項目「ＩＤ」、項目「大項目」、項目「中項目」、項目「小項目」、項目「実施結果」、項目「優先度」、項目「備考」を含む。

項目「実施結果」には、フィールドオブジェクト１４１１、１４１２が設けられている。テストを実施していないテストケースのフィールドオブジェクト１４１１には、まだ実施されていないことを表す「ＵｎＥｘｅ」が表示されている。

項目「優先度」は、サブ項目「計画」、サブ項目「修正１」を有する。テストを実施する前の段階では、サブ項目「計画」には計画段階で設定された優先度が記憶されている。図８に示す例では、優先度１のテストスイートにおけるテストケースが表示されているため、全てのテストケースに優先度１が設定されている。一方、サブ項目「修正１」はまだ空欄となっている。

テスト実施者は、サブ項目「計画」を参照し、優先度１のテストケース、つまり、最も優先的にテストを実施するべきテストケースのうちいずれかを選択する。テスト実施者によりテストケースが選択されると、端末装置１０−１は、選択されたテストケースについてのテストを実施する。

端末装置１０−１は、テスト実施者からテストの実施結果の入力を受け付ける（ステップＳ１０３）。具体的には、例えば、テスト実施者は、ＩＤ：１のテストケースのテストを実施して不具合が発生しなかった場合、フィールドオブジェクト１４１１を押下し、フィールドオブジェクト１４１１の表示を、不具合が発生しなかったことを表す表示に切り替える。これにより、フィールドオブジェクト１４１１の表示は例えば、「ＯＫ」となる。

端末装置１０−１は、不具合が発生していない旨の実施結果、テストにかかった工数を、サーバ２０へ送信する。サーバ２０は、記憶制御部２０３３により、テストの実施結果、実施工数をテストケースＤＢ２８１に記憶する。また、サーバ２０は、分析部２０３５により、テストの実施結果を分析し、例えば、実施工数、生産性、不具合数、不具合率を算出する。

テスト実施者は、フィールドオブジェクト１４１１の表示を「ＯＫ」とすると、次のテストケース、例えば、ＩＤ：２のテストケースのテストに取り掛かる。

一方、例えば、ＩＤ：１のテストケースのテストを実施して不具合が発生した場合、テスト実施者は、フィールドオブジェクト１４１１を押下し、フィールドオブジェクト１４１１の表示を、不具合が発生したことを表す表示に切り替える。これにより、フィールドオブジェクト１４１１の表示は例えば、「ＮＧ」となる。

端末装置１０−１は、不具合が発生した旨の実施結果、テストにかかった工数を、サーバ２０へ送信する。サーバ２０は、記憶制御部２０３３により、テストの実施結果、実施工数をテストケースＤＢ２８１に記憶する。また、サーバ２０は、分析部２０３５により、テストの実施結果を分析し、例えば、実施工数、生産性、不具合数、不具合率を算出する。

テスト実施者は、フィールドオブジェクト１４１１の表示を「ＮＧ」に切り替えると、開発者へ発行するチケットを作成する。チケットは、プロジェクトにおける作業を管理するための単位である。本実施形態では、チケットにより、例えば、テスト実施者と開発者との間で不具合の発生を共有し、プログラムの改修を開発者のタスクとして管理する。具体的には、例えば、テスト実施者は、フィールドオブジェクト１４１１を押下して表示を「ＮＧ」に切り替えると、フィールドオブジェクト１４１２を押下する。

端末装置１０−１は、フィールドオブジェクト１４１２が押下されると、チケットの入力フォームをディスプレイ１４１に表示させる。

図９は、ディスプレイ１４１に表示されるチケットの入力フォームの例を表す模式図である。図９に示す例によれば、ディスプレイ１４１に入力ウィンドウ１４１３が表示される。入力ウィンドウ１４１３には、例えば、「Ｐｒｏｃｅｓｓ」、「Ｔｙｐｅ」、「Ｔｉｔｌｅ」、「Ｐｒｉｏｒｉｔｙ」、「Ｓｅｖｅｒｉｔｙ」、「Ａｓｓｉｇｎｅｅ」、「Ｒｅｐｏｒｔｅｒ」、「Ｄｕｅ ｄａｔｅ」を入力するためのボックスが設けられている。

「Ｐｒｏｃｅｓｓ」には、進行中の工程が入力される。入力は、例えば、ボックスの右端の下三角マークをクリックすると選択肢が表示されるプルダウン形式で行われる。図９に示す例では、テスト工程におけるチケットの発行であるため、「Ｔｅｓｔ」が入力されている。

「Ｔｙｐｅ」には、チケットの種別が入力される。入力は、例えば、プルダウン形式で行われる。図９に示す例では、開発者に不具合を改修させるためのチケットの発行であるため、「Ｂｕｇ」が入力されている。

「Ｔｉｔｌｅ」には、チケットの題目が入力される。入力は、例えば、テスト実施者から任意の内容を受け付ける。図９に示す例では、「ＡＡＡにＢＢＢしたがＣＣＣされないという不具合が発生した」との題目が入力されている。

「Ｐｒｉｏｒｉｔｙ」には、チケットの発行により作成されるタスクの優先度が入力される。「Ｓｅｖｅｒｉｔｙ」は、チケットの発行により作成されるタスクの重大さが入力される。「Ａｓｓｉｇｎｅｅ」にはチケットの発行により作成されるタスクの担当者が入力される。一般的には、ソフトウェアの開発者が該当する。「Ｒｅｐｏｒｔｅｒ」は、チケットの作成者が入力される。これらの入力は、例えば、プルダウン形式で行われる。

「Ｄｕｅ ｄａｔｅ」は、チケットの発行により作成されるタスクの期限日が入力される。入力は、テスト実施者から直接の入力を受け付けてもよいし、カレンダーを介した日付けの指定を受け付けてもよい。

テスト実施者は、チケットへ含める内容の入力が完了すると、フィールドオブジェクト１４１４を押下する。フィールドオブジェクト１４１４が押下されると、端末装置１０−１は、テスト実施者により入力された内容をサーバ２０へ送信すると共に、送信した内容をチケットとして登録するようにサーバ２０に要求する。テスト実施者は、サーバ２０にチケットを登録すると、次のテストケース、例えば、ＩＤ：２のテストケースのテストに取り掛かる。

サーバ２０は、端末装置１０−１からの要求を受け付けると、記憶制御部２０３３により、受信した内容をタスクＤＢ２８２に記憶し、新たなチケットとして登録する。また、サーバ２０は、登録したチケットを、「Ａｓｓｉｇｎｅｅ」に記載される開発者へ発行する（ステップＳ２０１）。

開発者が操作する端末装置１０−２は、サーバ２０からチケットが発行されると、チケットが発行されたことを開発者へ通知する。開発者は、通知を受けると、発行されたチケットの内容を端末装置１０−２のディスプレイ１４１に表示させる。

図１０は、ディスプレイ１４１に表示されるチケットの内容の例を表す模式図である。端末装置１０−２は、チケットの内容を開発者に表示すると、開発者からの入力を受け付ける（ステップＳ１０４）。具体的には、例えば、開発者は、表示内容を確認し、所定のテストケースについてのテストで不具合が発生したことを把握すると、不具合が発生した要因を調査する。要因を突き止めると、開発者は、チケットにおいて不具合要因を記入する領域に不具合要因を入力する。図１０に示す例では、「Ｒｅｌａｔｉｖｅ Ｉｓｓｕｅ」が不具合要因を記入する領域に相当する。端末装置１０−２は、「Ｒｅｌａｔｉｖｅ Ｉｓｓｕｅ」に不具合要因が記入されると、チケットの内容が更新されたとして、記入された情報をサーバ２０へ送信する。開発者は、チケットに不具合要因を入力すると、不具合が発生したソフトウェアの改修を開始する。

サーバ２０は、端末装置１０−２からの情報を受信すると、記憶制御部２０３３により、受信した情報に基づいてタスクＤＢ２８２を更新する。また、サーバ２０は、チケットが更新されたことを、「Ｒｅｐｏｒｔｅｒ」に記載されるテスト実施者へ通知する（ステップＳ２０２）。

テスト実施者は、テストケースが零となるまでステップＳ１０２〜ステップＳ２０２の処理を繰り返す。

＜３．２ 改修確認テストの実施＞
開発者は、図５に示すステップＳ１０４で、チケットに不具合要因を入力すると、不具合が発生したソフトウェアの改修を開始する。

図１１は、開発者によりソフトウェアが改修され、改修されたソフトウェアがテスト実施者によりテストされる際のシステム１の動作を説明する図である。

端末装置１０−２は、開発者から、ソフトウェアの改修が完了したことの報告の入力を受け付ける（ステップＳ１０５）。具体的には、例えば、開発者は、不具合の改修内容、不具合の改修にかかった工数をチケットに入力する。端末装置１０−２は、不具合の改修内容、不具合の改修にかかった工数が入力されると、チケットの内容が更新されたとして、記入された情報をサーバ２０へ送信する。

サーバ２０は、端末装置１０−２からの情報を受信すると、記憶制御部２０３３により、受信した情報に基づいてタスクＤＢ２８２を更新する。また、サーバ２０は、チケットが更新されたことを、「Ｒｅｐｏｒｔｅｒ」に記載されるテスト実施者へ通知する（ステップＳ２０３）。

端末装置１０−１は、チケットの更新がサーバ２０から通知されると、チケットが更新されたことをテスト実施者へ通知する。テスト実施者は、通知を受けると、更新されたチケットの内容を端末装置１０−１のディスプレイ１４１に表示させる。テスト実施者は、表示の内容を参照し、不具合を発生したテストケースについて再度テストを実施する。

端末装置１０−１は、テスト実施者からテストの実施結果の入力を受け付ける（ステップＳ１０６）。具体的には、例えば、テスト実施者は、フィールドオブジェクト１４１１が「ＮＧ」のテストケースのテストを実施して不具合が発生しなかった場合、フィールドオブジェクト１４１１を押下し、フィールドオブジェクト１４１１の表示を「ＯＫ」に切り換える。

端末装置１０−１は、不具合が解消した旨の実施結果、改修後確認にかかった工数を、サーバ２０へ送信する。サーバ２０は、記憶制御部２０３３により、テストの実施結果、改修後確認工数をテストケースＤＢ２８１に記憶する。

また、例えば、フィールドオブジェクト１４１１が「ＮＧ」のテストケースのテストを実施して不具合が発生した場合、テスト実施者は、フィールドオブジェクト１４１２を押下してチケットを作成する。テスト実施者は、チケットへ含める内容の入力が完了すると、フィールドオブジェクト１４１４を押下する。フィールドオブジェクト１４１４が押下されると、端末装置１０−１は、テスト実施者により入力された内容をサーバ２０へ送信すると共に、送信した内容をチケットとして登録するようにサーバ２０に要求する。

サーバ２０は、端末装置１０−１からの要求を受け付けると、記憶制御部２０３３により、受信した内容をタスクＤＢ２８２に記憶し、新たなチケットとして登録する。また、サーバ２０は、登録したチケットを、「Ａｓｓｉｇｎｅｅ」に記載される開発者へ発行する。

＜３．３ 優先度の設定＞
図１２は、テストスイートに設定された優先度を設定する際のサーバ２０の動作の例を示すフローチャートである。

まず、分析部２０３５は、テスト実施者から、優先度の再設定の指示があるか否かを判断する（ステップＳ２１）。例えば、図７に示すテストスイートのリスト表示、又は図８に示すテストケースデータのリスト表示において、優先度の再設定を指示するためのフィールドオブジェクトが表示されている（図示せず）。テスト実施者は、所定の理由がある場合、上記フィールドオブジェクトを押下することで、サーバ２０に対し、優先度の再設定を要求する。所定の理由とは、例えば、テストを実施している最中のテストスイート中の残りのテストケースデータにおいて不具合が発生する可能性が低いこと、優先度の再設定をしたいこと等である。

優先度の再設定の指示がある場合（ステップＳ２１のＹｅｓ）、分析部２０３５は、処理をステップＳ２３へ移行させる。優先度の再設定の指示がない場合（ステップＳ２１のＮｏ）、分析部２０３５は、テストケースデータのテストについて所定の要件が満たされたか否かを判断する（ステップＳ２２）。所定の要件とは、例えば、実施結果を分析するのに十分なテストが実施済みであることを含み、具体的には、以下である。
・選択されているテストスイートに含まれる全てのテストケースデータについてのテストが実施されたこと、発生した不具合に対して要因が入力されたこと、又は発生した不具合が解消されたこと
・選択されているテストスイートにおいて、所定の観点に係る全てのテストケースデータについてのテストが実施されたこと、発生した不具合に対して要因が入力されたこと、又は発生した不具合が解消されたこと
・選択されているテストスイートにおいて、所定の因子に係る全てのテストケースデータについてのテストが実施されたこと、発生した不具合に対して要因が入力されたこと、又は発生した不具合が解消されたこと
・選択されているテストスイートにおいて、所定の水準に係る全てのテストケースデータについてのテストが実施されたこと、発生した不具合に対して要因が入力されたこと、又は発生した不具合が解消されたこと
・選択されているテストスイートにおいて、予め設定された数のテストケースデータについてのテストが実施されたこと、発生した不具合に対して要因が入力されたこと、又は発生した不具合が解消されたこと
・予め設定された数のテストケースデータについてのテストが実施されたこと、発生した不具合に対して要因が入力されたこと、又は発生した不具合が解消されたこと
・予め設定されたテスト期間のうち、所定の時間が経過したこと

テストケースデータのテストについて所定の要件が満たされた場合（ステップＳ２２のＹｅｓ）、分析部２０３５は、処理をステップＳ２３へ移行させる。テストケースデータのテストについて所定の要件が満たされていない場合（ステップＳ２２のＮｏ）、分析部２０３５は、ステップＳ２1〜ステップＳ２２の処理を繰り返す。

ステップＳ２３において、分析部２０３５は、実施されたテストの結果を分析し、残っているテストケースのうち、優先してテストを実施するべきテストケースを抽出する。図４に示す例では、分析部２０３５は、計画時に優先度１に設定されたテストスイートに含まれるテストケースについてのテストが実施されると、実施されたこれらのテストの結果を分析し、残っているテストケースから、優先してテストを実施するべきテストケースを抽出する。なお、図４において、計画時に優先度１に設定されたテストスイートに含まれるテストケースについてのテストが実施されることは、予め設定された数のテストケースデータについてのテストが実施されたことと換言されてもよい。

図１３は、分析部２０３５の動作の具体例を示すフローチャートである。
まず、分析部２０３５は、テスト実施済みのテストケースデータについて、担当者、モジュール、観点、因子、水準、不具合要因、実績を、テストケースＤＢ２８１から読み出す（ステップＳ２３１）。

分析部２０３５は、実施結果に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択する（ステップＳ２３２）。具体的には、例えば、分析部２０３５は、不具合が発生する件数に係る数値（不具合数、不具合率等）、発生した不具合を改修する工数に係る数値、発生した不具合の要因が由来するプロジェクトの工程、又はこれらのうち少なくとも２つの組み合わせを考慮して、優先してテストを実施するべきテストケースを選択する。

より具体的には、例えば、分析部２０３５は、不具合が発生する件数に係る数値、又は発生した不具合を改修する工数に係る数値が、特別な対応が要求される限界値よりも高いテストケース群がある場合、その数値が算出されたテストケース群を選択する。本実施形態において、テストケース群とは、同様の性質のテストケースとして扱われるテストケースの群を表し、例えば、因子、又は水準等毎にまとめて表される。不具合が発生する件数に係る数値、及び発生した不具合を改修する工数に係る数値が限界値を超えない場合、分析部２０３５は、例えば、プロジェクトの上流工程に由来する要因で不具合が発生したテストケース群を選択する。

図４に示す例では、分析部２０３５は、不具合が発生する件数に係る数値、及び発生した不具合を改修する工数に係る数値が限界値を超えるテストケース群がないとして、上流工程に由来する要因である「要件漏れ」、「影響考慮」の要因が確認された因子Ａに係るテストケース群を選択する。また、分析部２０３５は、次に優先してテストを実施するべきテストケース群として、下流工程に由来する要因である「作業ミス」の要因が確認された因子Ｂに係るテストケース群を選択する。

なお、テストケース群の選択は、テストケース群を規定する他の要素単位でなされてもよい。例えば、分析部２０３５は、観点、又は水準でテストケース群を選択してもよい。

分析部２０３５は、選択したテストケースの特徴を特定する（ステップＳ２３３）。例えば、分析部２０３５は、選択したテストケースそれぞれを規定する要素、例えば、画面、機能、担当者、モジュール、観点、因子、水準等を特定する。

図４に示す例では、分析部２０３５は、上流工程に由来する要因による不具合が発生したテストケース群の特徴として、「画面Ａ、機能Ａ、担当者ＡＡＡＡ、モジュールＡ、観点Ａ、因子Ａ、水準ＡＡ〜水準ＡＣ」を特定する。また、分析部２０３５は、下流工程に由来する要因による不具合が発生したテストケース群の特徴として、「画面Ａ、機能Ａ、担当者ＡＡＡＡ、モジュールＡ、観点Ｂ、因子Ｂ、水準ＢＡ〜水準ＢＣ」を特定する。

分析部２０３５は、テスト未実施のテストケースから、特定した特徴と一致するテストケース、又は類似するテストケースを抽出する（ステップＳ２３４）。一致するテストケースとは、例えば、テストケースを規定する全ての要素、「画面、機能、担当者、モジュール、観点、因子、水準」が、実施済みのテストケースについて特定した特徴と一致するテストケースを表す。類似するテストケースとは、例えば、テストケースを規定する要素、「画面、機能、担当者、モジュール、観点、因子、水準」のうち、少なくともいずれかが、実施済みのテストケースについて特定した特徴と一致するテストケースを表す。
分析部２０３５は、一致する要素に応じて類似の度合いを異ならせるようにしてもよい。例えば、分析部２０３５は、「因子、水準」が一致していれば、テストケースの内容は近いとし、類似の度合いが高いと評価する。一方、分析部２０３５は、観点、モジュール、又は担当者が一致する場合、関連はしているが、類似の度合いは、「因子、水準」が一致する場合よりも低いと評価する。

図４に示す例では、分析部２０３５は、特定した「画面Ａ、機能Ａ、ＡＡＡＡ、モジュールＡ、観点Ａ、因子Ａ、水準ＡＡ〜水準ＡＣ」の特徴と類似度が高いテストケース群として、「因子及び水準」が一致するテストケース群を、テスト未実施のテストケースから抽出する。すなわち。分析部２０３５は、テスト未実施のテストケースの中から、「画面Ｂ、機能Ｃ、ＡＡＡＡ、モジュールＡ、観点Ｄ、因子Ａ、水準ＡＡ〜水準ＡＣ」のテストケース群を類似のテストケース群として抽出する。

また、分析部２０３５は、特定した「画面Ａ、機能Ａ、ＡＡＡＡ、モジュールＡ、観点Ａ、因子Ａ、水準ＡＡ〜水準ＡＣ」の特徴と類似度が低いテストケース群として、「画面Ｂ、機能Ｂ、ＢＢＢＢ、モジュールＣ、観点Ａ、因子Ｂ、水準ＢＡ〜水準ＢＣ」のテストケース群と、「画面Ａ、機能Ａ、ＡＡＡＡ、モジュールＢ、観点Ｃ、因子Ｃ、水準ＣＡ〜水準ＣＣ」のテストケース群とを抽出する。

また、分析部２０３５は、特定した「画面Ａ、機能Ａ、ＡＡＡＡ、モジュールＢ、観点Ｂ、因子Ｂ、水準ＢＡ〜水準ＢＣ」の特徴と類似度が高いテストケースとして、「因子及び水準」が一致するテストケースを、テスト未実施のテストケースから抽出する。すなわち。分析部２０３５は、テスト未実施のテストケースの中から、「画面Ｂ、機能Ｂ、ＢＢＢＢ、モジュールＣ、観点Ａ、因子Ｂ、水準ＢＡ〜水準ＢＣ」のテストケースを類似のテストケースとして抽出する。

また、分析部２０３５は、特定した「画面Ａ、機能Ａ、ＡＡＡＡ、モジュールＢ、観点Ｂ、因子Ｂ、水準ＢＡ〜水準ＢＣ」の特徴と類似度が低いテストケース群として、「画面Ａ、機能Ａ、ＡＡＡＡ、モジュールＡ、観点Ａ、因子Ａ、水準ＡＡ〜水準ＡＣ」のテストケース群と、「画面Ａ、機能Ａ、ＡＡＡＡ、モジュールＢ、観点Ｃ、因子Ｃ、水準ＣＡ〜水準ＣＣ」のテストケース群とを抽出する。

分析部２０３５は、テストケース、又はテストスイートと関連付けられている機能仕様書に基づいて類似の判断をしてもよい。機能仕様書は、検査対象が有する機能についての仕様が記載されているデータである。テストケースを規定するテスト設計書は、機能仕様書を参照しながら作成される。テストケース、又はテストスイートには、作成の際に参照した機能仕様書についての情報が関連付けられている。分析部２０３５は、ステップＳ２３２で選択されたテストケースに機能仕様書が関連付けられている場合、テスト未実施のテストケースから、同一の機能仕様書が関連付けられているテストケースを類似のテストケースとして抽出してもよい。

図１２の説明に戻り、設定部２０３６は、ステップＳ２３で抽出されたテストケースを参照し、テスト未実施のテストケースに対して優先度を設定する（ステップＳ２４）。

具体的には、設定部２０３６は、優先してテストを実施するべきテストケースと一致するテストケース、又は類似する度合の高いテストケースに、高い優先度を設定する。より具体的には、設定部２０３６は、優先してテストを実施するべき理由、選択したテストケースとの類似の度合い等を総合的に勘案し、優先度を設定する。優先してテストを実施するべき理由には、例えば、プロジェクトに特有な事情、改修工数の程度、不具合率の程度、担当者のスキルの偏り等、様々な要因が含まれる。

図４に示す例では、設定部２０３６は、抽出した「画面Ａ、機能Ａ、ＡＡＡＡ、モジュールＡ、観点Ａ、因子Ａ、水準ＡＡ〜水準ＡＣ」のテストケース群に対して優先度１を設定する。また、設定部２０３６は、このテストスイートにおいて、実施済みのテストの不具合要因、不具合率、改修工数等に基づき、水準毎に優先度を設定してもよい。例えば、設定部２０３６は、水準ＡＡのテストケース群に優先度１、水準ＡＣのテストケース群に優先度２、水準ＡＢのテストケース群に優先度３を設定してもよい。

また、設定部２０３６は、抽出した「画面Ｂ、機能Ｂ、ＢＢＢＢ、モジュールＣ、観点Ａ、因子Ｂ、水準ＢＡ〜水準ＢＣ」のテストケース群に対して優先度２を設定する。また、設定部２０３６は、このテストスイートにおいて、実施済みのテストの不具合要因、不具合率、改修工数等に基づき、水準毎に優先度を設定してもよい。例えば、設定部２０３６は、水準ＢＡのテストケース群に優先度１、水準ＢＣのテストケース群に優先度２、水準ＢＢのテストケース群に優先度３を設定してもよい。

また、設定部２０３６は、「画面Ａ、機能Ａ、ＡＡＡＡ、モジュールＢ、観点Ｃ、因子Ｃ、水準ＣＡ〜水準ＣＣ」に対し、類似の度合いが低いとして優先度３を設定する。

なお、選択したテストケースの実績、不具合要因、及びテスト未実施のテストケースから抽出されたテストケースの類似の度合によっては、テストケースに同一の優先度が設定されることもあり得る。

記憶制御部２０３３は、設定された優先度を、修正後の優先度としてテストケースＤＢ２８１に記憶する。
図１４〜図１７は、実施済みのテスト結果に基づいて優先度が修正された際のディスプレイ１４１の表示例を表す模式図である。

図１４は、ディスプレイ１４１に表示されるテストスイートのリストの例を表す模式図である。図１４に示す例は、機能Ａ−１のテストスイートについてのテストが終了した後に、設定部２０３６により、優先度が修正される場合のディスプレイ１４１の表示画面を表している。図１４に示す例によれば、優先度４だった機能Ｃのテストスイートの優先度が１となり、優先度３だった機能Ｂのテストスイートの優先度が２となり、優先度２だった機能Ａ−２のテストスイートの優先度が３となり、優先度５だった機能Ｄのテストスイートの優先度が４となっている。

図１５は、ディスプレイ１４１に表示されるテストケースデータのリストの例を表す模式図である。図１５に示す例は、図１４において、優先度１の機能Ｃのテストスイートが選択された場合のテストケースデータのリスト表示を表している。図１５に示す例によれば、優先度４だったテストケースデータの優先度が優先度１となっている。

図１６は、ディスプレイ１４１に表示されるテストスイートのリストの例を表す模式図である。図１６に示す例は、機能Ｃのテストスイートについてのテストが終了した後に、設定部２０３６により、優先度が修正される場合のディスプレイ１４１の表示画面を表している。図１６に示す例によれば、優先度２だった機能Ｂのテストスイートの優先度が１となり、優先度３だった機能Ａ−２のテストスイートの優先度が２となり、優先度４だった機能Ｄのテストスイートの優先度が３となっている。

図１７は、ディスプレイ１４１に表示されるテストケースデータのリストの例を表す模式図である。図１７に示す例は、図１６において、優先度１の機能Ｂのテストスイートが選択された場合のテストケースデータのリスト表示を表している。図１７に示す例によれば、優先度２だったテストケースデータの優先度が優先度１となっている。

＜３．４ テスト動向の予測＞
図１８は、テスト動向を予測する際のサーバ２０の動作の例を示すフローチャートである。

テスト実施者は、テストの動向、つまり、残テストケース数の推移、不具合数の推移の予測情報等を確認したい場合、テスト動向の表示を指示するためのフィールドオブジェクトを押下する。フィールドオブジェクトは、例えば、ディスプレイ１４１に表示されている。

予測部２０３７は、フィールドオブジェクトが押下されると、テストが既にされたテストケース数が所定の要件を満たすか否かを判断する（ステップS２５）。所定の要件とは、例えば、テストの動向を予測可能な程度の数のテストが実施されていることを含み、具体的には、以下である。
・いずれかのテストスイートに含まれる全てのテストケースデータについてのテストが実施されたこと、又は発生した不具合が解消されたこと
・いずれかのテストスイートにおいて、所定の観点に係る全てのテストケースデータについてのテストが実施されたこと、又は発生した不具合が解消されたこと
・いずれかのテストスイートにおいて、所定の因子に係る全てのテストケースデータについてのテストが実施されたこと、又は発生した不具合が解消されたこと
・いずれかのテストスイートにおいて、所定の水準に係る全てのテストケースデータについてのテストが実施されたこと、又は発生した不具合が解消されたこと
・いずれかのテストスイートにおいて、予め設定された数のテストケースデータについてのテストが実施されたこと、又は発生した不具合が解消されたこと
・予め設定された数のテストケースデータについてのテストが実施されたこと、又は発生した不具合が解消されたこと

テストが既にされたテストケース数が所定の要件を満たす場合（ステップＳ２５のＹｅｓ）、分析部２０３５は、テストが実施されたテストケースの特徴を特定する（ステップＳ２６）。例えば、分析部２０３５は、テストが実施されたテストケースを規定する要素、例えば、画面、機能、担当者、モジュール、観点、因子、水準を特定する。テストが既にされたテストケース数が所定の要件を満たしていない場合（ステップＳ２５のＮｏ）、分析部２０３５は、テストケース数が要件を満たすまでステップＳ２５の処理を繰り返す。

分析部２０３５は、テスト未実施のテストケースから、特定した特徴と一致するテストケース、又は類似するテストケースを抽出する（ステップＳ２７）。例えば、分析部２０３５は、テスト未実施のテストケースから、画面、機能、担当者、モジュール、観点、因子、水準が、実施済みのテストケースについて特定した画面、機能、担当者、モジュール、観点、因子、水準と一致するテストケースを抽出する。また、分析部２０３５は、テスト未実施のテストケースから、画面、機能、担当者、モジュール、観点、因子、水準のうち少なくともいずれかが、実施済みのテストケースについて特定した画面、機能、担当者、モジュール、観点、因子、水準と一致するテストケースを抽出する。

予測部２０３７は、実施済みのテストケースの実績、不具合要因に基づき、抽出したテストケースに対し、テストの動向を表す種々のパラメータを算出する（ステップＳ２８）。具体的には、予測部２０３７は、抽出したテストケース群における不具合数、不具合率、工数、改修工数、又は改修後確認工数を、実施済みのテストケースの実績に基づいて算出する。

例えば、予測部２０３７は、実施済みのテストケースのうち、所定の因子及び水準のテストケース群と、因子及び水準が一致するテストケース群に対し、対応するテストケース群の不具合率を設定する。なお、予測部２０３７は、因子及び水準以外の要素に基づき、不具合率を補正してもよい。予測部２０３７は、因子及び水準が一致するテストケース群のケース数に、設定した不具合率をかけ、このテストケース群についての不具合数を算出する。予測部２０３７は、例えば、対応するテストケース群の不具合数と、因子及び水準が一致するテストケース群の不具合数との比に基づき、このテストケース群についての工数、改修工数、又は改修後確認工数を算出する。

上流工程に由来する要因で不具合が発生したテストケース群と、因子及び水準が一致するテストケース群がテスト未実施のテストケースにある場合、予測部２０３７は、このテストケース群から発生すると予測される不具合の数を、テストの実施が遅くなるほど、多くなるように計算してもよい。

予測部２０３７は、実施されたテストについての不具合数、工数、改修工数、又は改修後確認工数と、未実施のテストケースに対して予測した不具合数、工数、改修工数、又は改修後確認工数とに基づき、テスト工程を開始してからの期間に対する不具合数の推移、残テストケースの推移、不具合回収数の推移、又は回収数の推移を算出する。このとき、予測部２０３７は、設定されている優先度に従った順序でテストを実施した際の推移を算出する。

記憶制御部２０３３は、算出されたパラメータを、予測されたパラメータとしてテストケースＤＢ２８１に記憶する。

提示部２０３４は、算出したパラメータに基づき、テストの動向をユーザに提示する（ステップＳ２９）。具体的には、例えば、提示部２０３４は、テストの動向を表すグラフをディスプレイ１４１に表示させる。

図１９は、ディスプレイ１４１に表示される、テスト動向を表すグラフの例を表す模式図である。図１９に示す図において、横軸はテスト期間を表し、縦軸は残数又は発生件数を表す。図１９において、実線は不具合数を表し、破線は不具合の改修数を表し、一点鎖線は残ケース数を表し、二点鎖線は改修確認の残数を表す。

以上のように、本実施形態では、サーバ２０は、記憶制御部２０３３により、テスト工程におけるテストの実施結果をテストケースＤＢ２８１に記憶させる。分析部２０３５は、実施結果に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択する。分析部２０３５は、テスト工程において、選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出する。そして、設定部２０３６は、抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するようにしている。これにより、サーバ２０は、テスト工程で実施されるテストの結果に基づき、未実施のテストから優先的に実施するべきテストを設定することが可能となる。また、不具合が発生する確率の高いテストから着手可能となるため、ソフトウェアの修正に基づく新たなバグの連鎖的発生を抑えられる。つまり、デグレーションのリスクが減ることになる。

また、本実施形態では、分析部２０３５は、テスト実施済みのテストケースから、次に優先してテストを実施するべきテストケースを選択する。分析部２０３５は、選択した次に優先してテストを実施するべきテストケースと類似するテストケースを、テスト未実施のテストケースから抽出する。そして、設定部２０３６は、抽出したテストケースについてテストを実施する優先度を、先に設定した優先度より低く設定するようにしている。これにより、サーバ２０は、テスト工程で実施されるテストの結果に基づき、未実施のテストを実施する順序を設定し直すことが可能となる。

また、本実施形態では、分析部２０３５は、テスト実施済みのテストケースを規定する要素のいずれかが一致するテストケースを類似するテストケースとして、テスト未実施のテストケースから抽出するようにしている。具体的には、例えば、分析部２０３５は、テスト実施済みのテストケースの因子及び水準と一致する因子及び水準のテストケースを、類似するテストケースとするようにしている。また、例えば、分析部２０３５は、テスト実施済みのテストケースと、作成の際に参照した機能仕様書が一致するテストケースを、類似するテストケースとするようにしている。これにより、サーバ２０は、テスト実施済みのテストケースと類似するテストケースを、テスト未実施のテストケースから高精度に抽出することが可能となる。

また、本実施形態では、分析部２０３５は、ユーザからの指示に応じ、優先してテストを実施するべきテストケースを選択するようにしている。これにより、サーバ２０は、ユーザが希望するタイミングで優先度を設定することが可能となる。

また、本実施形態では、分析部２０３５は、テストが所定数実施されると、優先してテストを実施するべきテストケースを選択するようにしている。これにより、サーバ２０は、ユーザからの指示がなくても優先度を設定することが可能となる。

また、本実施形態では、分析部２０３５は、実施結果に含まれる、不具合が発生する件数に係る数値に基づき、前記優先してテストを実施するべきテストケースを選択するようにしている。これにより、不都合率の高いケースに対しては、障害の報告が得意な人材を担当に付けることが可能となる。また、不具合の発生がテストの前半に発生すると見込めるため、開発者を効率的にアサインすることが可能となる。

また、本実施形態では、分析部２０３５は、実施結果に含まれる、発生した不具合を改修する工数に係る数値に基づき、優先してテストを実施するべきテストケースを選択するようにしている。これにより、改修工数が多いと見込まれるテストケースのテストをテスト工程の前半に実施することが可能となるため、開発者を効率的にアサインすることが可能となる。また、時間のかかるケースに専任の担当を付けることができる。

また、本実施形態では、記憶制御部２０３３は、テスト工程におけるテストで発生した不具合の要因をテストケースＤＢ２８１に記憶させる。分析部２０３５は、実施結果に含まれる、発生した不具合の要因、具体的には、要因が由来するプロジェクトの工程に基づき、優先してテストを実施するべきテストケースを選択するようにしている。これにより、ソフトウェア開発における、要件定義工程、設計工程、コーディング工程、テスト工程のうち、上流側の工程で埋め込まれた欠陥を検出するためのテストを優先的に実施させることが可能となる。このため、欠陥を改修するためのコストが小さく抑えられ、また、デグレーションが発生するリスクが抑えられる。また、サーバ２０は、プロジェクト内のテスト工程で実施されるテストの結果を用いて優先度を設定している。このため、テスト実施者は、プロジェクトに適したテストの順序をリアルタイムで把握することが可能となる。

また、本実施形態では、提示部２０３４は、設定した優先度をユーザへ提示するようにしている。これにより、テスト実施者は、優先度の高いテストケースを認識しながら、テストを実施することが可能となる。

また、本実施形態では、提示部２０３４は、一式のテストケース（テストスイート）毎、又は単一のテストケース毎に優先度を付して優先度をユーザへ提示するようにしている。これにより、テスト実施者は、優先的にテストをしないとならないテストケースに効率的にアクセスすることが可能となる。

また、本実施形態では、予測部２０３７は、抽出したテストケースのテストの結果をテストの実施結果から予測する。そして、予測部２０３７は、テスト未実施のテストケースのテストが、設定した優先度に従った順序で実施された際のテストの動向を予測するようにしている。これにより、テスト実施者は、設定される優先度に従った場合、テスト工程におけるテストがどのように進んでいくかを視覚的に把握することが可能となる。このため、テスト実施者は、設定された優先度が正しいものであるか否かを直感的に判断することが可能となる。

したがって、本実施形態に係るサーバ２０によれば、テスト工程において、テストを効率的、かつ効果的に実施できる。

＜変形例＞
なお、上記実施形態では、計画時において、テストする機能の優先度が設定されている場合を例に説明した。しかしながら、テストする機能の優先度は、計画時に設定されていなくても構わない。

また、上記実施形態では、テストスイートが計画時の優先度の順序で表示される場合を例に説明した。しかしながら、テストスイートが表示される順序は、再設定後の優先度の順序に従ってもよい。

また、上記実施形態では、表示制御部１８３がディスプレイ１４１に優先度が表示する場合を例に説明した。しかしながら、表示制御部１８３は、優先度を必ずしも表示する必要はない。表示制御部１８３は、設定されて優先度順にテストスイート、又はテストケースを配列し、テストスイート、又はテストケースを表示してもよい。これにより、上から順にテストを実施すれば最適な順序となるため、テスト実施者の負担が軽減されることになる。

以上、本開示のいくつかの実施形態を説明したが、これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものとする。

＜付記＞
以上の各実施形態で説明した事項を以下に付記する。

（付記１）
プロセッサ２９と、メモリ２５とを備えるコンピュータに実行させるためのプログラムであって、プログラムは、プロセッサに、テスト工程において実施されたテストに関する情報を記憶するステップ（ステップＳ２０１、Ｓ２０２）と、テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップ（ステップＳ２３２）と、テスト工程において、選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップ（ステップＳ２３４）と、抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップ（ステップＳ２４）とを実行させるプログラム。

（付記２）
選択するステップにおいて、テスト実施済みのテストケースから、次に優先してテストを実施するべきテストケースを選択し、抽出するステップにおいて、選択した次に優先してテストを実施するべきテストケースと類似するテストケースを、テスト未実施のテストケースから抽出し、設定するステップにおいて、抽出したテストケースについてテストを実施する優先度を、設定した優先度よりも低く設定する（付記１）に記載のプログラム。

（付記３）
抽出するステップにおいて、テスト実施済みのテストケースを規定する要素のいずれかが一致するテストケースを類似するテストケースとして、テスト未実施のテストケースから抽出する（付記１）又は（付記２）に記載のプログラム。

（付記４）
抽出するステップにおいて、テスト実施済みのテストケースの因子及び水準と一致する因子及び水準のテストケースを、類似するテストケースとする（付記３）に記載のプログラム。

（付記５）
抽出するステップにおいて、テスト実施済みのテストケースと、作成の際に参照した機能仕様書が一致するテストケースを、類似するテストケースとする（付記３）に記載のプログラム。

（付記６）
選択するステップにおいて、ユーザからの指示に応じ、優先してテストを実施するべきテストケースを選択する（ステップＳ２１）、（付記１）乃至（付記５）のいずれかに記載のプログラム。

（付記７）
選択するステップにおいて、テストが所定数実施されると、優先してテストを実施するべきテストケースを選択する（ステップＳ２２）、（付記１）乃至（付記５）のいずれかに記載のプログラム。

（付記８）
記憶するステップにおいて、テストの実施結果を記憶し、選択するステップにおいて、実施結果に含まれる、不具合が発生する件数に係る数値に基づき、優先してテストを実施するべきテストケースを選択する（付記１）乃至（付記７）のいずれかに記載のプログラム。

（付記９）
記憶するステップにおいて、テスト工程におけるテストで発生した不具合を改修する工数を記憶し、選択するステップにおいて、発生した不具合を改修する工数に係る数値に基づき、優先してテストを実施するべきテストケースを選択する（付記１）乃至（付記７）のいずれかに記載のプログラム。

（付記１０）
記憶するステップにおいて、テスト工程におけるテストで発生した不具合の要因を記憶し、選択するステップにおいて、発生した不具合の要因に基づき、優先してテストを実施するべきテストケースを選択する（付記１）乃至（付記７）のいずれかに記載のプログラム。

（付記１１）
選択するステップにおいて、要因が由来するプロジェクトの工程に基づき、優先してテストを実施するべきテストケースを選択する（付記１０）に記載のプログラム。

（付記１２）
設定した優先度をユーザへ提示するステップ（提示部２０３４）を、プロセッサに実行させる（付記１）乃至（付記１１）のいずれかに記載のプログラム。

（付記１３）
提示するステップにおいて、一式のテストケース毎、又は単一のテストケース毎に優先度を付して優先度をユーザへ提示する（付記１２）に記載のプログラム。

（付記１４）
抽出したテストケースのテストの結果をテストの実施結果から予測するステップ（ステップＳ２８）と、テスト未実施のテストケースのテストが、設定した優先度に従った順序で実施された際のテストの動向を予測するステップ（ステップＳ２８）とをプロセッサに実行させる（付記１）乃至（付記１３）のいずれかに記載のプログラム。

（付記１５）
プロセッサ２９と、メモリ２５とを備えるコンピュータが実行する方法であって、テスト工程において実施されたテストに関する情報を記憶するステップと、テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、テスト工程において、選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップとを実行する方法。

（付記１６）
プロセッサ２９と、メモリ２５とを備える情報処理装置２０であって、プロセッサが、テスト工程において実施されたテストに関する情報を記憶するステップ（記憶制御部２０３３）と、テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、テスト工程において、選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップ（分析部２０３５）と、抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップ（設定部２０３６）とを実行する情報処理装置。

（付記１７）
テスト工程において実施されたテストに関する情報を記憶する手段（記憶制御部２０３３）と、テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、テスト工程において、選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出する手段（分析部２０３５）と、抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定する手段（設定部２０３６）とを具備するシステム。

１…システム
１０…端末装置
１２１…通信部
１３…入力装置
１３１…マウス
１３２…キーボード
１３３…タッチ・センシティブ・デバイス
１４…出力装置
１４１…ディスプレイ
１５…メモリ
１６…ストレージ
１７０…記憶部
１８０…制御部
１８１…操作受付部
１８２…送受信部
１８３…表示制御部
１９…プロセッサ
２０…サーバ
２０１…通信部
２０２…記憶部
２０３…制御部
２０３１…操作受付部
２０３２…送受信部
２０３３…記憶制御部
２０３４…提示部
２０３５…分析部
２０３６…設定部
２０３７…予測部
２５…メモリ
２６…ストレージ
２９…プロセッサ
８０…ネットワーク

Claims (24)

1. プロセッサと、メモリとを備えるコンピュータに実行させるためのプログラムであって、前記プログラムは、前記プロセッサに、
   テスト工程において実施されたテストに関する情報を記憶するステップと、
   前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、
   前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、
   前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップと
   を実行させ、
   前記抽出するステップにおいて、前記テスト実施済みのテストケースと、作成の際に参照した機能仕様書が一致するテストケースを、前記類似するテストケースとするプログラム。
2. プロセッサと、メモリとを備えるコンピュータに実行させるためのプログラムであって、前記プログラムは、前記プロセッサに、
   テスト工程において実施されたテストに関する情報を記憶するステップと、
   前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、
   前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、
   前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップと
   を実行させ、
   前記記憶するステップにおいて、前記テスト工程におけるテストで発生した不具合を改修する工数を記憶し、
   前記選択するステップにおいて、前記発生した不具合を改修する工数に係る数値に基づき、前記優先してテストを実施するべきテストケースを選択するプログラム。
3. プロセッサと、メモリとを備えるコンピュータに実行させるためのプログラムであって、前記プログラムは、前記プロセッサに、
   テスト工程において実施されたテストに関する情報を記憶するステップと、
   前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、
   前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、
   前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップと
   を実行させ、
   前記記憶するステップにおいて、前記テスト工程におけるテストで発生した不具合の要因を記憶し、
   前記選択するステップにおいて、前記発生した不具合の要因に基づき、前記優先してテストを実施するべきテストケースを選択するプログラム。
4. プロセッサと、メモリとを備えるコンピュータに実行させるためのプログラムであって、前記プログラムは、前記プロセッサに、
   テスト工程において実施されたテストに関する情報を記憶するステップと、
   前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、
   前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、
   前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップと
   を実行させ、
   前記抽出するステップにおいて、前記テスト実施済みのテストケースの因子及び水準と一致する因子及び水準のテストケースを、前記類似するテストケースとし、
   前記因子はコンピュータの状態変化に影響を与え得る要因を表し、
   前記水準は、前記因子の具体的な要素を表すプログラム。
5. 前記選択するステップにおいて、前記要因が由来するプロジェクトの工程に基づき、前記優先してテストを実施するべきテストケースを選択する請求項３記載のプログラム。
6. 前記選択するステップにおいて、前記テスト実施済みのテストケースから、次に優先してテストを実施するべきテストケースを選択し、
   前記抽出するステップにおいて、前記選択した次に優先してテストを実施するべきテストケースと類似するテストケースを、前記テスト未実施のテストケースから抽出し、
   前記設定するステップにおいて、前記抽出したテストケースについてテストを実施する優先度を、前記設定した優先度よりも低く設定する請求項１乃至５のいずれかに記載のプログラム。
7. 前記選択するステップにおいて、ユーザからの指示に応じ、前記優先してテストを実施するべきテストケースを選択する請求項１乃至６のいずれかに記載のプログラム。
8. 前記選択するステップにおいて、前記テストが所定数実施されると、前記優先してテストを実施するべきテストケースを選択する請求項１乃至６のいずれかに記載のプログラム。
9. 前記記憶するステップにおいて、前記テストの実施結果を記憶し、
   前記選択するステップにおいて、前記実施結果に含まれる、不具合が発生する件数に係る数値に基づき、前記優先してテストを実施するべきテストケースを選択する請求項１乃至８のいずれかに記載のプログラム。
10. 前記設定した優先度をユーザへ提示するステップを、前記プロセッサに実行させる請求項１乃至９のいずれかに記載のプログラム。
11. 前記提示するステップにおいて、一式のテストケース毎、又は単一のテストケース毎に前記優先度を付して前記優先度を前記ユーザへ提示する請求項１０記載のプログラム。
12. 前記抽出したテストケースのテストの結果を前記テストの実施結果から予測するステップと、
    前記テスト未実施のテストケースのテストが、前記設定した優先度に従った順序で実施された際のテストの動向を予測するステップと
    を前記プロセッサに実行させる請求項１乃至１１のいずれかに記載のプログラム。
13. プロセッサと、メモリとを備えるコンピュータが実行する方法であって、
    テスト工程において実施されたテストに関する情報を記憶するステップと、
    前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、
    前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、
    前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップと
    を実行し、
    前記抽出するステップにおいて、前記テスト実施済みのテストケースと、作成の際に参照した機能仕様書が一致するテストケースを、前記類似するテストケースとする方法。
14. プロセッサと、メモリとを備えるコンピュータが実行する方法であって、
    テスト工程において実施されたテストに関する情報を記憶するステップと、
    前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、
    前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、
    前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップと
    を実行し、
    前記記憶するステップにおいて、前記テスト工程におけるテストで発生した不具合を改修する工数を記憶し、
    前記選択するステップにおいて、前記発生した不具合を改修する工数に係る数値に基づき、前記優先してテストを実施するべきテストケースを選択する方法。
15. プロセッサと、メモリとを備えるコンピュータが実行する方法であって、
    テスト工程において実施されたテストに関する情報を記憶するステップと、
    前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、
    前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、
    前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップと
    を実行し、
    前記記憶するステップにおいて、前記テスト工程におけるテストで発生した不具合の要因を記憶し、
    前記選択するステップにおいて、前記発生した不具合の要因に基づき、前記優先してテストを実施するべきテストケースを選択する方法。
16. プロセッサと、メモリとを備えるコンピュータが実行する方法であって、
    テスト工程において実施されたテストに関する情報を記憶するステップと、
    前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、
    前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、
    前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップと
    を実行し、
    前記抽出するステップにおいて、前記テスト実施済みのテストケースの因子及び水準と一致する因子及び水準のテストケースを、前記類似するテストケースとし、
    前記因子はコンピュータの状態変化に影響を与え得る要因を表し、
    前記水準は、前記因子の具体的な要素を表す方法。
17. プロセッサと、メモリとを備える情報処理装置であって、
    前記プロセッサが、
    テスト工程において実施されたテストに関する情報を記憶するステップと、
    前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、
    前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、
    前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップと
    を実行し、
    前記抽出するステップにおいて、前記テスト実施済みのテストケースと、作成の際に参照した機能仕様書が一致するテストケースを、前記類似するテストケースとする情報処理装置。
18. プロセッサと、メモリとを備える情報処理装置であって、
    前記プロセッサが、
    テスト工程において実施されたテストに関する情報を記憶するステップと、
    前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、
    前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、
    前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップと
    を実行し、
    前記記憶するステップにおいて、前記テスト工程におけるテストで発生した不具合を改修する工数を記憶し、
    前記選択するステップにおいて、前記発生した不具合を改修する工数に係る数値に基づき、前記優先してテストを実施するべきテストケースを選択する情報処理装置。
19. プロセッサと、メモリとを備える情報処理装置であって、
    前記プロセッサが、
    テスト工程において実施されたテストに関する情報を記憶するステップと、
    前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、
    前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、
    前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップと
    を実行し、
    前記記憶するステップにおいて、前記テスト工程におけるテストで発生した不具合の要因を記憶し、
    前記選択するステップにおいて、前記発生した不具合の要因に基づき、前記優先してテストを実施するべきテストケースを選択する情報処理装置。
20. プロセッサと、メモリとを備える情報処理装置であって、
    前記プロセッサが、
    テスト工程において実施されたテストに関する情報を記憶するステップと、
    前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択するステップと、
    前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出するステップと、
    前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定するステップと
    を実行し、
    前記抽出するステップにおいて、前記テスト実施済みのテストケースの因子及び水準と一致する因子及び水準のテストケースを、前記類似するテストケースとし、
    前記因子はコンピュータの状態変化に影響を与え得る要因を表し、
    前記水準は、前記因子の具体的な要素を表す情報処理装置。
21. テスト工程において実施されたテストに関する情報を記憶する手段と、
    前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択する手段と、
    前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出する手段と、
    前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定する手段と
    を具備し、
    前記抽出する手段は、前記テスト実施済みのテストケースと、作成の際に参照した機能仕様書が一致するテストケースを、前記類似するテストケースとするシステム。
22. テスト工程において実施されたテストに関する情報を記憶する手段と、
    前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択する手段と、
    前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出する手段と、
    前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定する手段と
    を具備し、
    前記記憶する手段は、前記テスト工程におけるテストで発生した不具合を改修する工数を記憶し、
    前記選択する手段は、前記発生した不具合を改修する工数に係る数値に基づき、前記優先してテストを実施するべきテストケースを選択するシステム。
23. テスト工程において実施されたテストに関する情報を記憶する手段と、
    前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択する手段と、
    前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出する手段と、
    前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定する手段と
    を具備し、
    前記記憶する手段は、前記テスト工程におけるテストで発生した不具合の要因を記憶し、
    前記選択する手段は、前記発生した不具合の要因に基づき、前記優先してテストを実施するべきテストケースを選択するシステム。
24. テスト工程において実施されたテストに関する情報を記憶する手段と、
    前記テストに関する情報に基づき、テスト実施済みのテストケースから、優先してテストを実施するべきテストケースを選択する手段と、
    前記テスト工程において、前記選択したテストケースと類似するテストケースをテスト未実施のテストケースから抽出する手段と、
    前記抽出したテストケースについてテストを実施する優先度を、他のテスト未実施のテストケースよりも高く設定する手段と
    を具備し、
    前記抽出する手段は、前記テスト実施済みのテストケースの因子及び水準と一致する因子及び水準のテストケースを、前記類似するテストケースとし、
    前記因子はコンピュータの状態変化に影響を与え得る要因を表し、
    前記水準は、前記因子の具体的な要素を表すシステム。

Images