JP2014092980A - 判定装置、判定方法及び判定プログラム - Google Patents
判定装置、判定方法及び判定プログラム Download PDFInfo
- Publication number
- JP2014092980A JP2014092980A JP2012243700A JP2012243700A JP2014092980A JP 2014092980 A JP2014092980 A JP 2014092980A JP 2012243700 A JP2012243700 A JP 2012243700A JP 2012243700 A JP2012243700 A JP 2012243700A JP 2014092980 A JP2014092980 A JP 2014092980A
- Authority
- JP
- Japan
- Prior art keywords
- test
- man
- hour
- manual
- automatic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
- G06Q10/06311—Scheduling, planning or task assignment for a person or group
- G06Q10/063118—Staff planning in a project environment
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Human Resources & Organizations (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Educational Administration (AREA)
- Game Theory and Decision Science (AREA)
- Development Economics (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Tourism & Hospitality (AREA)
- General Business, Economics & Management (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Abstract
【課題】仕様変更時に自動テストと手動テストとのいずれを採用すべきかを判断可能とする。
【解決手段】ソフトウェアのテストについて、自動テスト又は手動テストのいずれが有利であるかを判定する判定装置１は、自動テスト用のコードの作成又は修正に要する自動テスト推定工数と、手動テストの手順の作成又は修正、及び手動テストに要する手動テスト推定工数とを算出する判定処理部５（算出部）と、自動テスト推定工数と手動テスト推定工数との比較に基づいて、手動テスト又は自動テストのいずれか一方を提示する結果表示部６（提示部）と、を備える。
【選択図】図１
【解決手段】ソフトウェアのテストについて、自動テスト又は手動テストのいずれが有利であるかを判定する判定装置１は、自動テスト用のコードの作成又は修正に要する自動テスト推定工数と、手動テストの手順の作成又は修正、及び手動テストに要する手動テスト推定工数とを算出する判定処理部５（算出部）と、自動テスト推定工数と手動テスト推定工数との比較に基づいて、手動テスト又は自動テストのいずれか一方を提示する結果表示部６（提示部）と、を備える。
【選択図】図１
Description
本発明は、判定装置、判定方法及び判定プログラムに関する。
従来、ソフトウェアの開発においては、アプリケーションや設定などを情報通信技術（Information and Communication Technology：ＩＣＴ）システムに配備するリリースを、１〜数年の頻度で行なうことが多かった。このような手法の例として、例えば、ウォーターフォールモデルがある。
ウォーターフォールモデルでは、開発プロジェクトを時系列に、要求定義、外部設計、内部設計、開発、テスト、運用などの作業工程に分割し、原則として前工程が完了しないと次工程に進むことができない。これにより、前工程への戻りを最小限に押さえている。
ウォーターフォールモデルでは、開発プロジェクトを時系列に、要求定義、外部設計、内部設計、開発、テスト、運用などの作業工程に分割し、原則として前工程が完了しないと次工程に進むことができない。これにより、前工程への戻りを最小限に押さえている。
しかし、近年、頻繁にリリースを行なう手法が注目されている。このような手法の例として、アジャイルソフトウェア開発がある。
この手法は、１回のリリースにおける変更量を少なくすることで、変更のリスク（障害など）を小さくできるとともに、市場に迅速に対応できるとされている。
図１２（ａ）、（ｂ）は、アジャイルモデルとウォーターフォールモデルとの比較を示す図である。
この手法は、１回のリリースにおける変更量を少なくすることで、変更のリスク（障害など）を小さくできるとともに、市場に迅速に対応できるとされている。
図１２（ａ）、（ｂ）は、アジャイルモデルとウォーターフォールモデルとの比較を示す図である。
図１２（ａ）は、アジャイルモデル、図１２（ｂ）は、ウォーターフォールモデルのそれぞれの修正頻度と修正度合いとの関係を示す。前述のように、図１２（ａ）のアジャイルモデルのほうが、障害などの変更のリスクを低減できるとされ、近年注目されている。
図１２（ｂ）に示す従来のウォーターフォールモデルなどの大きな変更を稀に実施する手法では、手動テストが多く実施される。これは、リリース頻度が低いので、それに伴うテストの頻度も低く、自動化するメリットが低いためである。
図１２（ｂ）に示す従来のウォーターフォールモデルなどの大きな変更を稀に実施する手法では、手動テストが多く実施される。これは、リリース頻度が低いので、それに伴うテストの頻度も低く、自動化するメリットが低いためである。
手動テストに際しては、手動テストの手順を示すテスト手順書を作成し、作業者がこのテスト手順書に従って、テストを実施する。
一方、図１２（ａ）に示すアジャイルモデルなどの頻繁にリリースを行なう手法では、テストを自動化している。
この手法では、リリース回数が増えるので、それに伴ってテストが繰り返されるため、手動テストを行なうのでは、テストに要する工数が大きくなる。そこで、工数を削減するために、テストの自動化用にテストコードを作成し、このテストコードを用いて自動化したテストを行なう。
一方、図１２（ａ）に示すアジャイルモデルなどの頻繁にリリースを行なう手法では、テストを自動化している。
この手法では、リリース回数が増えるので、それに伴ってテストが繰り返されるため、手動テストを行なうのでは、テストに要する工数が大きくなる。そこで、工数を削減するために、テストの自動化用にテストコードを作成し、このテストコードを用いて自動化したテストを行なう。
テストを自動化すると、テストの実施に要する工数はゼロにできる。しかし、テストを自動化するために、テストコードの作成・保守に要する工数はゼロではない。当然、リリース回数が増えると、ソフトウェアの仕様変更の回数も多くなる。
このため、ソフトウェア開発において、頻繁にリリースを行なう手法を採用した場合でも、自動化用のテストコードを作成・修正する工数よりも、テスト手順書を作成して作業者が手動でテストを実行する工数の方が少なくなる場合もある。それは、以下の理由による。
このため、ソフトウェア開発において、頻繁にリリースを行なう手法を採用した場合でも、自動化用のテストコードを作成・修正する工数よりも、テスト手順書を作成して作業者が手動でテストを実行する工数の方が少なくなる場合もある。それは、以下の理由による。
テストコードの作成は、通常の開発プロセスと同様に、テストが正常に動作することを確認したり、デバッグ作業などが必要となる。このため、例えば、一度しか実施しないテストの場合、テストコードを作成するよりも手動でテストを行なうほうが早い場合が多い。例えば、手動テストでは、多少のエラーであれば作業者が気づいて修正できるため、テストコードを作成するよりも工数が少なくて済むためである。
従って、頻繁にリリースを行なう手法などでは、自動テスト、手動テストのいずれがコスト的に有利であるかをトータルのコストで判断することが求められる。
しかしながら、従来においては、仕様変更（仕様の追加も含む）時に、自動テストと手動テストとのいずれを実施したほうが有利かを判断することができない。
例えば、前述のように、図１２（ａ）に示すような頻繁にリリースを行なう手法では、工数削減のために、テストの自動化用のテストコードを作成する。この場合、仕様変更に合わせてそのテストコードを修正する工数が多くなることがある。
例えば、前述のように、図１２（ａ）に示すような頻繁にリリースを行なう手法では、工数削減のために、テストの自動化用のテストコードを作成する。この場合、仕様変更に合わせてそのテストコードを修正する工数が多くなることがある。
一般に、テストごとに、自動化、手動のいずれか一方のみが行なわれる。自動化、手動のいずれか一方の工数のデータしか存在しないため、自動テストの工数と手動テストの工数とを比較することができない。
又、過去に、自動テストと手動テストとの両方の工数のデータがあったとしても、幾度ものリリースを挟むと、大幅な変更が行なわれているため、そのデータを比較に用いることができないこともある。
又、過去に、自動テストと手動テストとの両方の工数のデータがあったとしても、幾度ものリリースを挟むと、大幅な変更が行なわれているため、そのデータを比較に用いることができないこともある。
このように、通常は、自動テストの工数と手動テストの工数の一方しか信頼できるデータがなく、仕様変更時に、自動テストと手動テストとのいずれにより工数をより削減できるかの妥当な判断ができなかった。
１つの側面では、本発明は、仕様変更時に自動テストと手動テストとのいずれを採用すべきかを判断可能とすることを目的とする。
１つの側面では、本発明は、仕様変更時に自動テストと手動テストとのいずれを採用すべきかを判断可能とすることを目的とする。
なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。
この判定装置は、ソフトウェアのテストについて、自動テスト又は手動テストのいずれが有利であるかを判定する判定装置であって、前記自動テスト用のコードの作成又は修正に要する自動テスト推定工数と、前記手動テストの手順の作成又は修正、及び前記手動テストに要する手動テスト推定工数とを算出する算出部と、前記自動テスト推定工数と前記手動テスト推定工数との比較に基づいて、前記手動テスト又は前記自動テストのいずれか一方を提示する提示部と、を備える。
また、この判定方法は、ソフトウェアのテストについて、自動テスト又は手動テストのいずれが有利であるかを判定する判定方法であって、前記自動テスト用のコードの作成又は修正に要する自動テスト推定工数と、前記手動テストの手順の作成又は修正、及び前記手動テストに要する手動テスト推定工数とを算出し、前記自動テスト推定工数と前記手動テスト推定工数との比較に基づいて、前記手動テスト又は前記自動テストのいずれか一方を提示する。
さらに、この判定プログラムは、ソフトウェアのテストについて、自動テスト又は手動テストのいずれが有利であるかを判定する判定プログラムであって、コンピュータで実行されたときに、前記コンピュータに、前記自動テスト用のコードの作成又は修正に要する自動テスト推定工数と、前記手動テストの手順の作成又は修正、及び前記手動テストに要する手動テスト推定工数とを算出させ、前記自動テスト推定工数と前記手動テスト推定工数との比較に基づいて、前記手動テスト又は前記自動テストのいずれか一方を提示させる。
開示の技術によれば、仕様変更時に自動テストと手動テストとのいずれを採用すべきかを判断可能とすることができる。
（Ａ）実施の形態
以下、図面を参照して本発明の実施の形態を説明する。
図１は、実施形態の一例に係るソフトウェア開発システム１０を示す模式図である。
ソフトウェア開発システム１０は、テスト判定システム（判定装置）１、テストシステム７、バージョン管理システム８、リリース管理システム９及びＩＣＴシステム１１を備える。
以下、図面を参照して本発明の実施の形態を説明する。
図１は、実施形態の一例に係るソフトウェア開発システム１０を示す模式図である。
ソフトウェア開発システム１０は、テスト判定システム（判定装置）１、テストシステム７、バージョン管理システム８、リリース管理システム９及びＩＣＴシステム１１を備える。
テスト判定システム１は、ソフトウェアの仕様変更時に、自動テストの工数と手動テストの工数とを予測し、両者のうち工数の少ない方を提示する。テスト判定システム１の構成については後述する。
テストシステム７は、テストコードに基づいて、開発したソフトウェアやそのリリースが正しく動作することを確認する自動テストを行なう。又、テストシステム７は、ユーザによる手動テストの支援も行なう。テストシステム７としては、例えば、ＪＵｎｉｔなどの既存のテストシステムを用いることができる。
テストシステム７は、テストコードに基づいて、開発したソフトウェアやそのリリースが正しく動作することを確認する自動テストを行なう。又、テストシステム７は、ユーザによる手動テストの支援も行なう。テストシステム７としては、例えば、ＪＵｎｉｔなどの既存のテストシステムを用いることができる。
バージョン管理システム８は、ソフトウェアのバージョンを管理する。バージョン管理システム８としては、例えば、Ｓｕｂｖｅｒｓｉｏｎ（登録商標）などの既存のバージョン管理システムを用いることができる。
リリース管理システム９は、開発され、テストシステム７によるテストにより正常に動作することが確認されたソフトウェアや必要な設定（これらを総称してリリースと呼ぶ）を、後述するＩＣＴシステム１１に配置する。リリース管理システム９としては、例えば、Ｊｅｎｋｉｎｓなどの既存のリリース管理システムを用いることができる。
リリース管理システム９は、開発され、テストシステム７によるテストにより正常に動作することが確認されたソフトウェアや必要な設定（これらを総称してリリースと呼ぶ）を、後述するＩＣＴシステム１１に配置する。リリース管理システム９としては、例えば、Ｊｅｎｋｉｎｓなどの既存のリリース管理システムを用いることができる。
ＩＣＴシステム１１は、ソフトウェアを実行する情報処理装置であり、不図示のCentral Processing Unit（ＣＰＵ）やメモリを備える。ＩＣＴシステム１１は、例えば既存のサーバシステムなどの情報処理装置である。
テスト判定システム１は、判定実行部２と仕様／テスト管理データベース（database：ＤＢ）（データセット）３とを備える。
テスト判定システム１は、判定実行部２と仕様／テスト管理データベース（database：ＤＢ）（データセット）３とを備える。
仕様／テスト管理ＤＢ３は、ソフトウェアの各リリースについて、その仕様とテストに関する情報とを記憶している。
図２は、実施形態の一例に係る仕様／テスト管理ＤＢ３におけるデータ間の関係を例示する図である。
図２に示すように、仕様／テスト管理ＤＢ３は、仕様と、テストケースと、テスト工程レコードとを記憶している。具体的には、仕様／テスト管理ＤＢ３は、テストケース管理表２０、テスト工程レコードエントリ表３０及び仕様変更管理表４０（図５，図６参照）を有する。これらの表については、図５，図６を用いて後述する。
図２は、実施形態の一例に係る仕様／テスト管理ＤＢ３におけるデータ間の関係を例示する図である。
図２に示すように、仕様／テスト管理ＤＢ３は、仕様と、テストケースと、テスト工程レコードとを記憶している。具体的には、仕様／テスト管理ＤＢ３は、テストケース管理表２０、テスト工程レコードエントリ表３０及び仕様変更管理表４０（図５，図６参照）を有する。これらの表については、図５，図６を用いて後述する。
通常、ソフトウェアの開発においては、仕様に合わせて、ソースコードとともに、テストコード又はテスト手順書が記述される。
仕様／テスト管理ＤＢ３は、リリースごと、テストケースごとに、テストのステップ数、作成・修正工数、実行工数、及び実行回数等を記録する。
ここで、テストケースとは、テスト手順書とテストコードとを紐付けて管理する情報である。
仕様／テスト管理ＤＢ３は、リリースごと、テストケースごとに、テストのステップ数、作成・修正工数、実行工数、及び実行回数等を記録する。
ここで、テストケースとは、テスト手順書とテストコードとを紐付けて管理する情報である。
図３（ａ）、（ｂ）は、実施形態の一例に係る仕様／テスト管理ＤＢ３におけるテスト手順書とテストコードとの関係を例示する図である。
ここで、テストとは、ソフトウェアの正常動作を確認する作業を意味し、テストは１以上のステップを含む。なお、テストのステップとは、サーバへのログイン、コマンド実行、結果の比較などを意味する。
ここで、テストとは、ソフトウェアの正常動作を確認する作業を意味し、テストは１以上のステップを含む。なお、テストのステップとは、サーバへのログイン、コマンド実行、結果の比較などを意味する。
図３（ａ）は、手動テストに用いられるテスト手順書を例示し、図３（ｂ）は、自動テストに用いられるテストコードを例示する。図３（ａ）のテスト手順書と、図３（ｂ）のテストコードとはそれぞれ、テストにおいて、サーバのランレベルの確認を行なう１ステップ（図中、上の太線で囲まれた部分）と、サーバのｈｔｔｐｄサービス状態の確認を行なう１ステップ（図中、下の太線で囲まれた部分）とを示す。このように、テスト手順書とテストコードとはほぼ対応している。
このため、自動テストの工数におけるテストコードの作成工数と、手動テストの工数におけるテスト手順書の作成工数及び手動テスト実施工数は、テストのステップ数に比例すると考えられる。
つまり、一般に、テストコード及びテスト手順書においてはステップが順番に記述されるため、テストコード及びテスト手順書の作成・修正に要する工数とは、いずれも、ステップ数に比例して増加すると考えられる。
つまり、一般に、テストコード及びテスト手順書においてはステップが順番に記述されるため、テストコード及びテスト手順書の作成・修正に要する工数とは、いずれも、ステップ数に比例して増加すると考えられる。
このため、実施形態の一例に係る仕様／テスト管理ＤＢ３においては、テスト手順書とテストコードとを紐付けて、テストケースとして維持・管理している。
図４は、実施形態の一例に係る仕様／テスト管理ＤＢ３に維持・管理されるテストケースと他のデータ間の関連を例示する図である。ここでは、例として、データ間の関連をUnified Modeling Language（ＵＭＬ）を用いて表現している。
図４は、実施形態の一例に係る仕様／テスト管理ＤＢ３に維持・管理されるテストケースと他のデータ間の関連を例示する図である。ここでは、例として、データ間の関連をUnified Modeling Language（ＵＭＬ）を用いて表現している。
図４の仕様／テスト管理ＤＢ３のデータを、図５〜図６にテーブル形式で示す。
図５は、実施形態の一例に係る仕様／テスト管理ＤＢ３のテストケース管理表２０及びテスト工程レコードエントリ表３０を例示する図であり、図６は、仕様変更管理表４０を例示する図である。
テストケース管理表２０は、テストコードを管理するテーブルである。テストケース管理表２０は、後述する判定実行部２の記録処理部４（図１参照）によって作成される。
図５は、実施形態の一例に係る仕様／テスト管理ＤＢ３のテストケース管理表２０及びテスト工程レコードエントリ表３０を例示する図であり、図６は、仕様変更管理表４０を例示する図である。
テストケース管理表２０は、テストコードを管理するテーブルである。テストケース管理表２０は、後述する判定実行部２の記録処理部４（図１参照）によって作成される。
図５に例示するテストケース管理表２０は、テストケースＩＤフィールド２１、仕様ＩＤフィールド２２、テストコードＩＤフィールド２３、テスト手順書ＩＤフィールド２４、及びテスト工程レコードエントリＩＤフィールド２５を有する。
テストケースＩＤフィールド２１は、テストケースを一意に示す識別子を格納する。
仕様ＩＤフィールド２２は、テスト対象の仕様を一意に示す識別子（仕様の管理ＩＤや仕様名）を格納する。ここで、仕様とは、プログラムの機能であり、例えば、「ユーザはアカウント名とパスワードでログインできる」、「ユーザはパスワード（８文字以内）を変更できる」、「ユーザは商品をカートに入れられる」などである。
テストケースＩＤフィールド２１は、テストケースを一意に示す識別子を格納する。
仕様ＩＤフィールド２２は、テスト対象の仕様を一意に示す識別子（仕様の管理ＩＤや仕様名）を格納する。ここで、仕様とは、プログラムの機能であり、例えば、「ユーザはアカウント名とパスワードでログインできる」、「ユーザはパスワード（８文字以内）を変更できる」、「ユーザは商品をカートに入れられる」などである。
テストコードＩＤフィールド２３は、仕様ＩＤフィールド２２の仕様に対応するテストコードを一意に示す識別子を格納する。例えば、テストコードＩＤフィールド２３には、仕様ＩＤフィールド２２の仕様に対応するテストコードのメソッド名やシェルスクリプト名が格納される。
テスト手順書ＩＤフィールド２４は、仕様ＩＤフィールド２２の仕様に対応するテスト手順書を一意に示す識別子を格納する。例えば、テスト仕様書ＩＤフィールド２４には、仕様ＩＤフィールド２２の仕様に対応するテスト手順書コードのファイル名が格納される。テストコードＩＤフィールド２３とテスト手順書ＩＤフィールド２４には、いずれか一方にエントリが存在すれば、他方のエントリが空欄（ＮＵＬＬなど）でもよい。
テスト手順書ＩＤフィールド２４は、仕様ＩＤフィールド２２の仕様に対応するテスト手順書を一意に示す識別子を格納する。例えば、テスト仕様書ＩＤフィールド２４には、仕様ＩＤフィールド２２の仕様に対応するテスト手順書コードのファイル名が格納される。テストコードＩＤフィールド２３とテスト手順書ＩＤフィールド２４には、いずれか一方にエントリが存在すれば、他方のエントリが空欄（ＮＵＬＬなど）でもよい。
テスト工程レコードエントリＩＤフィールド２５は、テストケースＩＤフィールド２１のテストケースに対応する、後述するテスト工程レコードエントリ表３０のテスト工程レコードエントリＩＤ３１の値を示す。このテスト工程レコードエントリＩＤフィールド２５には、複数の値が入力されていてもよい。図５の例のテストケース管理表２０の１行目において、テストケース「testcase1」は仕様ＩＤ「spec1」に対するものであり、テストコードのスクリプト名が「code1」、手順書ファイル名が「runbook1」、テスト工程レコードエントリ表３０のエントリＩＤ３１の「entry1」、「entry3」、「entry5」に対応することを示す。
テスト工程レコードエントリ表３０は、テストケースの実行記録を格納するテーブルである。テスト工程レコードエントリ表３０は、後述する判定実行部２の記録処理部４（図１参照）によって作成される。
図５に例示するテスト工程レコードエントリ表３０は、テスト工程レコードエントリＩＤ３１、リリースＩＤ３２、テスト実行回数３３、テストステップ数３４、テストコード作成工程３５、ステップ修正数３６、手順書作成工数３７及び手動テスト実施工数３８の各フィールドを有する。
図５に例示するテスト工程レコードエントリ表３０は、テスト工程レコードエントリＩＤ３１、リリースＩＤ３２、テスト実行回数３３、テストステップ数３４、テストコード作成工程３５、ステップ修正数３６、手順書作成工数３７及び手動テスト実施工数３８の各フィールドを有する。
テスト工程レコードエントリＩＤフィールド３１は、テストケースの実行記録を一意に示すＩＤである。このフィールドには、前述のテストケース管理表２０のテスト工程レコードエントリＩＤフィールド２５の値に対応している。
リリースＩＤフィールド３２は、実行されたテストケースに対応するリリースを一意に示すＩＤである。例えば、リリースＩＤフィールド３２には、リリースＩＤやリリース名が格納される。
リリースＩＤフィールド３２は、実行されたテストケースに対応するリリースを一意に示すＩＤである。例えば、リリースＩＤフィールド３２には、リリースＩＤやリリース名が格納される。
テスト実行回数フィールド３３は、そのテストケースでリリースＩＤフィールド３２が示すリリースに対するテストの総実行回数を示す値を格納する。この回数は、以前のリリースでの実行回数が用いられたり、ユーザが手入力してもよい。
テストステップ数フィールド３４は、リリースＩＤフィールド３２が示すリリースに対するテストの総ステップ数を示す値を格納する。このステップ数は、既存の手動テスト／自動テストのステップ数に等しい。又、修正によりステップ数が変わる場合、ステップ数をユーザが手入力してもよい。
テストステップ数フィールド３４は、リリースＩＤフィールド３２が示すリリースに対するテストの総ステップ数を示す値を格納する。このステップ数は、既存の手動テスト／自動テストのステップ数に等しい。又、修正によりステップ数が変わる場合、ステップ数をユーザが手入力してもよい。
テストコード作成工数フィールド３５は、テストコードの作成又は変更に要した工数を記録する。後述のステップ修正数フィールド３６に有効な値（例えばＮＵＬＬ以外の値）が存在する場合は、その値のステップが修正されたことを指すため、テストコード作成工数フィールド３５はこのステップの修正に要した工数を表す。一方、ステップ修正数フィールド３６が例えばＮＵＬＬの場合、全ステップが修正されたことを示す。
ステップ修正数フィールド３６は、テストコードで修正されたステップ数を示す値を格納する。
手順書作成工数フィールド３７は、テスト手順書の作成又は変更に要した工数を記録する。前述のステップ修正数フィールド３６に有効な値（例えばＮＵＬＬ以外の値）が存在する場合は、その値のステップが修正されたことを指すため、手順書作成工数フィールド３７はこのステップの修正に要した工数を表す。一方、ステップ修正数フィールド３６が例えばＮＵＬＬの場合、全ステップが修正されたことを示す。
手順書作成工数フィールド３７は、テスト手順書の作成又は変更に要した工数を記録する。前述のステップ修正数フィールド３６に有効な値（例えばＮＵＬＬ以外の値）が存在する場合は、その値のステップが修正されたことを指すため、手順書作成工数フィールド３７はこのステップの修正に要した工数を表す。一方、ステップ修正数フィールド３６が例えばＮＵＬＬの場合、全ステップが修正されたことを示す。
手動テスト実施工数フィールド３８は、手動テストの実施に要した工数を記録する。なお、前述のように、自動テストの場合、テストの実施に工数が掛からない（つまり、工数は０）ので、自動テスト実行工数のフィールドは存在しない。
図５に例示するテスト工程レコードエントリ表３０の１行目には、「entry1」が、リリースＩＤ「release1」のときの記録で、このリリースにおける総テスト実行回数は１、テストステップ数は１０、自動化されていないのでテストコード作成工数とステップ修正数はなし、手順書作成工数は４ｈ、手動テストの実施工数は０．５ｈである。
図５に例示するテスト工程レコードエントリ表３０の１行目には、「entry1」が、リリースＩＤ「release1」のときの記録で、このリリースにおける総テスト実行回数は１、テストステップ数は１０、自動化されていないのでテストコード作成工数とステップ修正数はなし、手順書作成工数は４ｈ、手動テストの実施工数は０．５ｈである。
仕様変更管理表４０は、仕様の変更とリリースとの関連を維持・格納するテーブルである。仕様変更管理表４０は、後述する判定実行部２の記録処理部４（図１参照）によって作成される。
ここで仕様の変更とは、仕様を変更することを指す。例えば、仕様「ユーザはパスワード（８文字以内）を変更できる」を「ユーザはパスワード（１６文字以内）を変更できる」に、仕様「ユーザはユーザ名（８文字以内英数字）を変更できる」を「ユーザはユーザ名（８文字以内英数字記号）を変更できる」に変更することを指す。
ここで仕様の変更とは、仕様を変更することを指す。例えば、仕様「ユーザはパスワード（８文字以内）を変更できる」を「ユーザはパスワード（１６文字以内）を変更できる」に、仕様「ユーザはユーザ名（８文字以内英数字）を変更できる」を「ユーザはユーザ名（８文字以内英数字記号）を変更できる」に変更することを指す。
図６に例示する仕様変更管理表４０は、ＩＤフィールド４１、仕様ＩＤフィールド４２及びリリースＩＤフィールド４３を有する。
ＩＤフィールド４１は、仕様の変更とリリースとの組み合わせを一意に識別する識別子である。
仕様ＩＤフィールド４２は、テスト対象の仕様を示す識別子（仕様の管理ＩＤや仕様名）を格納する。
ＩＤフィールド４１は、仕様の変更とリリースとの組み合わせを一意に識別する識別子である。
仕様ＩＤフィールド４２は、テスト対象の仕様を示す識別子（仕様の管理ＩＤや仕様名）を格納する。
リリースＩＤフィールド４３は、仕様ＩＤフィールド４２の仕様が変更されたリリースを示すＩＤである。リリースＩＤフィールド４３には、リリースＩＤやリリース名が格納される。
図６に例示する仕様変更管理表４０の１行目は、仕様ＩＤ「spec1」が、リリースＩＤ「release1」のときに変更されたことを示している。
図６に例示する仕様変更管理表４０の１行目は、仕様ＩＤ「spec1」が、リリースＩＤ「release1」のときに変更されたことを示している。
図１に示す判定実行部２は、記録入力部１２、記録処理部（記録部）４、判定処理部（算出部）５及び結果表示部（提示部）６を有する。
記録入力部１２は、例えば入力装置であり、ユーザからの入力を受け取り、後述する記録処理部４に渡す。記録入力部１２としては、キーボード、マウス、トラックボール、マイクロフォンなどの公知のユーザインタフェースを用いることができる。
記録入力部１２は、例えば入力装置であり、ユーザからの入力を受け取り、後述する記録処理部４に渡す。記録入力部１２としては、キーボード、マウス、トラックボール、マイクロフォンなどの公知のユーザインタフェースを用いることができる。
記録処理部４は、テストの仕様、テストケース、テストコード、テスト手順書、実際に実行されたテストの実績を、仕様／テスト管理ＤＢ３のテストケース管理表２０、テスト工程レコードエントリ表３０及び仕様変更管理表４０に記録する。その際、記録処理部４は、記録入力部１２が受け付けたユーザから入力された情報に基づいて記録を行なってもよく、又、過去の実績（平均、直近の実績など）を利用して記録を行なってもよい。
前述のように、手動テストでは、ステップが順番に実行されるため、ステップ数に比例して、作業者が手動テストを実施する工数が増加する。本実施形態は、アジャイルモデルのようなリリース回数が多く、リリースあたりのコード修正量が少ない状況を想定している。このような状況では、同時に多くの変更を行わないので、ステップ数と、テストコード（又はテスト手順書）の作成又は修正工数とがほぼ比例するといえる。
そこで、記録処理部４は、過去データを用いて、テストケースごとに、ステップ数と、テストコードの作成工数、テスト手順書の作成工数、手動テストの実施工数とを、仕様／テスト管理ＤＢ３に記録する。記録処理部４による記録方法としては、どのような方法を用いることができる。例えば、Ｒｅｄｍｉｎｅを利用して工数を記録してもよいし、工数をユーザが手入力してもよい。記録処理部４による具体的な記録処理については、図８を用いて後述する。
なお、工数とは、作業量を表す数量概念であり、一般に、工数＝時間×人員数として求められる。工数を表す単位として、秒、分、時、日など時間の単位が慣例的に使用される。
判定処理部５は、記録処理部４によって記録された仕様／テスト管理ＤＢ３のデータに基づいて、テストケースごとに、自動テスト・手動テストでそれぞれ実施した場合に要する工数を推定する。
判定処理部５は、記録処理部４によって記録された仕様／テスト管理ＤＢ３のデータに基づいて、テストケースごとに、自動テスト・手動テストでそれぞれ実施した場合に要する工数を推定する。
又、判定処理部５は、自動テストと手動テストとの推定工数に基づき、自動テスト、手動テストのいずれが有利かを判定する。判定処理部５による具体的な推定処理については、図９を用いて後述する。
結果表示部６は、判定処理部５が推定した推定結果をテストケースごとに、例えば、不図示のPersonal Computer（ＰＣ）のディスプレイに表示する。結果表示部６による具体的な表示処理については、図１０を用いて後述する。
結果表示部６は、判定処理部５が推定した推定結果をテストケースごとに、例えば、不図示のPersonal Computer（ＰＣ）のディスプレイに表示する。結果表示部６による具体的な表示処理については、図１０を用いて後述する。
次に、図７を用いてテスト判定システム１の処理を示す。
図７は、実施形態の一例に係るテスト判定システム１の処理を示すフローチャートである。
ステップＳＢ１において、テスト判定システム１の記録処理部４が記録処理を行なう。
次に、ステップＳＢ２において、テスト判定システム１の判定処理部５が判定処理を行なう。
図７は、実施形態の一例に係るテスト判定システム１の処理を示すフローチャートである。
ステップＳＢ１において、テスト判定システム１の記録処理部４が記録処理を行なう。
次に、ステップＳＢ２において、テスト判定システム１の判定処理部５が判定処理を行なう。
最後に、ステップＳＢ３において、テスト判定システム１の結果表示部６が、判定処理部５の判定結果の表示を行なう。
以下、これらの各処理の詳細を説明する。
最初に、記録処理部４の処理について説明する。
図８は、実施形態の一例に係る記録処理部４の処理を示すフローチャートである。
以下、これらの各処理の詳細を説明する。
最初に、記録処理部４の処理について説明する。
図８は、実施形態の一例に係る記録処理部４の処理を示すフローチャートである。
ステップＳ１１において、例えば、記録入力部１２がユーザからの入力を受け付け、変更のあった仕様ＩＤごとに、仕様変更管理表４０に追記する。
ステップＳ１２において、記録処理部４は、全テストケースについて、ステップＳ１４までの処理を繰り返す。
ステップＳ１３において、記録処理部４は、ステップＳ１２で取得したテストケースについて、例えば、記録入力部１２が受け付けたユーザからの入力に基づいて、テスト実行回数、作成・修正したテストのステップ数、テストコードの作成・修正工数、又はテスト手順の作成・修正工数、及び手動テスト実施工数を記録する。記録処理部４は、これらを、テストケース管理表２０、テスト工程レコードエントリ表３０及び仕様変更管理表４０に記録する。
ステップＳ１２において、記録処理部４は、全テストケースについて、ステップＳ１４までの処理を繰り返す。
ステップＳ１３において、記録処理部４は、ステップＳ１２で取得したテストケースについて、例えば、記録入力部１２が受け付けたユーザからの入力に基づいて、テスト実行回数、作成・修正したテストのステップ数、テストコードの作成・修正工数、又はテスト手順の作成・修正工数、及び手動テスト実施工数を記録する。記録処理部４は、これらを、テストケース管理表２０、テスト工程レコードエントリ表３０及び仕様変更管理表４０に記録する。
その後、処理がステップＳ１４に進む。
なお、ステップＳ１４では、ステップＳ１２に対応するループ端処理が実行される。ここで全テストケースについて処理が終了すると本フローが終了する。
次に、判定処理部５の処理について説明する。
図９は、実施形態の一例に係る判定処理部５の処理を示すフローチャートである。
なお、ステップＳ１４では、ステップＳ１２に対応するループ端処理が実行される。ここで全テストケースについて処理が終了すると本フローが終了する。
次に、判定処理部５の処理について説明する。
図９は、実施形態の一例に係る判定処理部５の処理を示すフローチャートである。
ステップＳ２１において、判定処理部５は、テスト工数レコードエントリ表３０を用いて、ステップ数と、テストコードの作成工数、テスト手順書の作成工数、手動テストの実施工数の各々との比例定数Ｃａｃ、Ｃｒｃ、Ｃｒｅを求める。
ここで、比例定数Ｃａｃは、ステップ数とテストコードの作成工数との比例定数であり、次式（１）により求められる。
ここで、比例定数Ｃａｃは、ステップ数とテストコードの作成工数との比例定数であり、次式（１）により求められる。
比例定数Ｃａｃ＝テストコードの作成又は修正工数／ステップ数 ……式（１）
又、比例定数Ｃｒｃは、ステップ数とテスト手順書の作成工数との比例定数であり、次式（２）により求められる。
比例定数Ｃｒｃ＝テスト手順書の作成又は修正工数／ステップ数 ……式（２）
さらに、比例定数Ｃｒｅは、ステップ数と手動テスト実施工数との比例定数であり、次式（３）により求められる。
又、比例定数Ｃｒｃは、ステップ数とテスト手順書の作成工数との比例定数であり、次式（２）により求められる。
比例定数Ｃｒｃ＝テスト手順書の作成又は修正工数／ステップ数 ……式（２）
さらに、比例定数Ｃｒｅは、ステップ数と手動テスト実施工数との比例定数であり、次式（３）により求められる。
比例定数Ｃｒｅ＝手動テスト実施工数／ステップ数 ……式（３）
例えば、テストケースが「testcase1」、ステップ数が１０、テストコードの作成工数が８ｈ、テスト手順書の作成工数が４ｈ、手動テスト実施工数が０．５ｈの場合、記録処理部４は、上記式（１）〜（３）に従って、各比例定数Ｃａｃ、Ｃｒｃ、Ｃｒｅを算出する。
例えば、テストケースが「testcase1」、ステップ数が１０、テストコードの作成工数が８ｈ、テスト手順書の作成工数が４ｈ、手動テスト実施工数が０．５ｈの場合、記録処理部４は、上記式（１）〜（３）に従って、各比例定数Ｃａｃ、Ｃｒｃ、Ｃｒｅを算出する。
Ｃａｃ＝８ｈ（テストコードの作成工数）／１０（ステップ数）＝０．８ｈ
Ｃｒｃ＝４ｈ（テスト手順書の作成工数）／１０（ステップ数）＝０．４ｈ
Ｃｒｅ＝０．５ｈ（手動テスト実施工数／１０（ステップ数）＝０．０５ｈ
上記の例では、判定処理部５は、一つのテストケースの記録のみから比例定数を算出しているが、複数のテストケースの記録がある場合には、テストケースごとに比例定数を求め、それらの平均値を算出する。
Ｃｒｃ＝４ｈ（テスト手順書の作成工数）／１０（ステップ数）＝０．４ｈ
Ｃｒｅ＝０．５ｈ（手動テスト実施工数／１０（ステップ数）＝０．０５ｈ
上記の例では、判定処理部５は、一つのテストケースの記録のみから比例定数を算出しているが、複数のテストケースの記録がある場合には、テストケースごとに比例定数を求め、それらの平均値を算出する。
又、手動テスト、自動テストのいずれかしか実施されていない場合には、判定処理部５は、仕様／テスト管理ＤＢ３に登録されている過去の同様のソフトウェア開発における手動テスト及び自動テストの実施実績を用いて、各比例係数Ｃａｃ、Ｃｒｃ、Ｃｒｅを算出する。
ステップＳ２２において、判定処理部５は、テストケース管理表２０の全テストケースについて、ステップＳ３０までの処理を繰り返す。
ステップＳ２２において、判定処理部５は、テストケース管理表２０の全テストケースについて、ステップＳ３０までの処理を繰り返す。
ステップＳ２３において、判定処理部５は、ステップＳ２２で取得したテストケースについて、仕様変更があるかどうかを判定する。その際、例えば、判定処理部５は、テスト工程レコードエントリ表３０のテストケースに対応するエントリのステップ修正数フィールド３６に有効な値（例えば、ＮＵＬＬ値以外）が記録されている場合、仕様変更ありと判定する。
ステップＳ２３で仕様変更がない場合（ステップＳ２３のＮＯルート参照）、判定処理部５はステップＳ３０に移動して、テストケース管理表２０の次のテストケースを取得する。
一方、ステップＳ２３で仕様変更がある場合（ステップＳ２３のＹＥＳルート参照）、判定処理部５は、ステップＳ２４において、テスト工程レコードエントリ表３０から、テスト実行回数、テストステップ数及びステップ修正数を取得する。詳細には、判定処理部５は、テスト工程レコードエントリ表３０の対応するエントリのテスト実行回数フィールド３３、テストステップ数フィールド３４、及びステップ修正数フィールド３６のそれぞれの値を取得する。
一方、ステップＳ２３で仕様変更がある場合（ステップＳ２３のＹＥＳルート参照）、判定処理部５は、ステップＳ２４において、テスト工程レコードエントリ表３０から、テスト実行回数、テストステップ数及びステップ修正数を取得する。詳細には、判定処理部５は、テスト工程レコードエントリ表３０の対応するエントリのテスト実行回数フィールド３３、テストステップ数フィールド３４、及びステップ修正数フィールド３６のそれぞれの値を取得する。
次に、ステップＳ２５において、判定処理部５は、自動テストの工数ａを算出する。自動テストは、前述のようにテストの実行工数がゼロであるため、自動テストの工数ａは、テストコードの作成又は修正工数と等しい。このため、判定処理部５は、ステップＳ２１で求めた比例定数ＣａｃとステップＳ２４で取得したステップ数とに基づいて自動テストの工数ａを以下の式（４）から求める。
自動テストの工数ａ＝テストコードの作成又は修正工数＝テストコード作成の比例定数Ｃａｃ×ステップ数（テストステップ数又はステップ修正数） ……式（４）
上記式（４）で使用する「ステップ」数は、ステップＳ２４で取得したステップ修正数の値が存在しないか無効な値（ＮＵＬＬなど）である場合は、仕様変更ではなく仕様の新規作成であるため、テストステップ数を使用する。一方、ステップＳ２４で取得したステップ修正数の値が有効である場合、仕様変更であるため、ステップ修正数の値を用いる。
上記式（４）で使用する「ステップ」数は、ステップＳ２４で取得したステップ修正数の値が存在しないか無効な値（ＮＵＬＬなど）である場合は、仕様変更ではなく仕様の新規作成であるため、テストステップ数を使用する。一方、ステップＳ２４で取得したステップ修正数の値が有効である場合、仕様変更であるため、ステップ修正数の値を用いる。
次に、ステップＳ２６において、判定処理部５は、手動テストの工数ｂを算出する。手動テストは、テスト手順書の作成又は修正工数と、手動テスト実施工数との和である。そこで、判定処理部５は、ステップＳ２１で求めた比例定数Ｃｒｃ、ＣｒｅとステップＳ２４で取得したステップ数及びテスト実行回数とに基づいて、手動テストの工数ｂを以下の式（５）から求める。
手動テストの工数ｂ＝テスト手順書の作成又は修正工数＋手動テスト実施工数×テスト実行回数＝テスト手順書の作成の比例定数Ｃｒｃ×ステップ数（テストステップ数又はステップ修正数）＋手動テストの比例定数Ｃｒｅ×テストステップ数×テスト実行回数 ……式（５）
上記式（５）で使用する「ステップ」数も、ステップＳ２４で取得したステップ修正数の値が存在しないか無効な値（ＮＵＬＬなど）である場合は、仕様変更ではなく仕様の新規作成であるため、テストステップ数を使用する。一方、ステップＳ２４で取得したステップ修正数の値が有効である場合、仕様変更であるため、ステップ修正数の値を用いる。
上記式（５）で使用する「ステップ」数も、ステップＳ２４で取得したステップ修正数の値が存在しないか無効な値（ＮＵＬＬなど）である場合は、仕様変更ではなく仕様の新規作成であるため、テストステップ数を使用する。一方、ステップＳ２４で取得したステップ修正数の値が有効である場合、仕様変更であるため、ステップ修正数の値を用いる。
次に、ステップＳ２７において、判定処理部５は、ステップＳ２５で求めた自動テストの工数ａが、ステップＳ２６で求めた手動テストの工数ｂよりも大きいかどうかを判定する。
自動テストの工数ａが手動テストの工数ｂよりも大きい場合（ステップＳ２７のＹＥＳルート参照）、ステップＳ２８において、判定処理部５は、手動テストのほうが推定工数が少ないと判定する。
自動テストの工数ａが手動テストの工数ｂよりも大きい場合（ステップＳ２７のＹＥＳルート参照）、ステップＳ２８において、判定処理部５は、手動テストのほうが推定工数が少ないと判定する。
一方、自動テストの工数ａが手動テストの工数ｂ以下の場合（ステップＳ２７のＮＯルート参照）、ステップＳ２９において、判定処理部５は、自動テストのほうが推定工数が少ないと判定する。
その後、処理がステップＳ３０に進み、ステップＳ２８，Ｓ２９の結果を不図示の判定結果表に書き込む。
その後、処理がステップＳ３０に進み、ステップＳ２８，Ｓ２９の結果を不図示の判定結果表に書き込む。
なお、ステップＳ３０では、ステップＳ２２に対応するループ端処理が実行される。ここで判定処理部５は、全テストケースについて処理が終了すると本フローが終了する。
次に、結果表示部６の処理について説明する。
図１０は、実施形態の一例に係る結果表示部６の処理を示すフローチャートである。
ステップＳ３１において、結果表示部６は、判定処理部５が作成した不図示の判定結果表の全テストケースについて、ステップＳ３３までの処理を繰り返す。
次に、結果表示部６の処理について説明する。
図１０は、実施形態の一例に係る結果表示部６の処理を示すフローチャートである。
ステップＳ３１において、結果表示部６は、判定処理部５が作成した不図示の判定結果表の全テストケースについて、ステップＳ３３までの処理を繰り返す。
ステップＳ３２において、結果表示部６は、ステップＳ３１で取得したテストケースについて、判定結果（自動テスト又は手動テスト）を表示する。
その後、処理がステップＳ３３に進む。
なお、ステップＳ３３では、ステップＳ３１に対応するループ端処理が実行される。ここで全テストケースについて処理が終了すると本フローが終了する。
その後、処理がステップＳ３３に進む。
なお、ステップＳ３３では、ステップＳ３１に対応するループ端処理が実行される。ここで全テストケースについて処理が終了すると本フローが終了する。
次に、図６、図１１を用いて、本実施形態の処理を具体的に挙げて説明する。
図１１は、実施形態の一例に係る仕様／テスト管理データベースのテストケース管理表及びテスト工程レコードエントリ表を例示する図である。
ここで、以下のようなプロジェクトを想定する。
仕様は、「spec1：ユーザはパスワード（８文字以内）を変更できる」、「spec2：ユーザはユーザ名（８文字以内英数字）を変更できる」の２つであり、今回のリリースは「release4」である。
図１１は、実施形態の一例に係る仕様／テスト管理データベースのテストケース管理表及びテスト工程レコードエントリ表を例示する図である。
ここで、以下のようなプロジェクトを想定する。
仕様は、「spec1：ユーザはパスワード（８文字以内）を変更できる」、「spec2：ユーザはユーザ名（８文字以内英数字）を変更できる」の２つであり、今回のリリースは「release4」である。
図６の仕様変更管理表４０の例に示すように、これらの２つの仕様が、「release4」も含め、過去のリリース「release1」〜「release3」において変更されている。
「release4」においては、仕様「spec1」の内容を「ユーザはパスワード（８文字以内）を変更できる」から「ユーザはパスワード（１６文字以内）を変更できる」に変更する。又、仕様「spec2」の内容を「ユーザはユーザ名（８文字以内英数字）を変更できる」から「ユーザはユーザ名（８文字以内英数字記号）を変更できる」に変更する。
「release4」においては、仕様「spec1」の内容を「ユーザはパスワード（８文字以内）を変更できる」から「ユーザはパスワード（１６文字以内）を変更できる」に変更する。又、仕様「spec2」の内容を「ユーザはユーザ名（８文字以内英数字）を変更できる」から「ユーザはユーザ名（８文字以内英数字記号）を変更できる」に変更する。
このときのテストケースと仕様との間の対応は、図１１のテストケース管理表２０に示したとおりである。
このような場合に、テスト判定システム１がテストの判定を行なう場合を想定する。
まず、記録処理部４が、記録入力部１２を介して入力されたユーザからの入力に基づいて、仕様／テスト管理ＤＢ３に、図１１に示すテストケース管理表２０及びテスト工程レコードエントリ表３０と、図６に示す仕様変更管理表４０とを記録する。
このような場合に、テスト判定システム１がテストの判定を行なう場合を想定する。
まず、記録処理部４が、記録入力部１２を介して入力されたユーザからの入力に基づいて、仕様／テスト管理ＤＢ３に、図１１に示すテストケース管理表２０及びテスト工程レコードエントリ表３０と、図６に示す仕様変更管理表４０とを記録する。
この例では、「release1」において、テスト手順書を作成し手動テストを実行している。このため、図１１のテスト工程レコードエントリ表３０の１〜２行目に示すように、テストコード作成工程フィールド３５が空欄である。
又、「release2」においては、テストコードを作成し自動テストを実行している。このため、図１１のテスト工程レコードエントリ表３０の３〜４行目に示すように、手順書作成工程フィールド３７及び手動テスト実施工数フィールド３８が空欄である。又、仕様「spec1」の全１０ステップのうち１０ステップが変更され、仕様「spec2」の全５ステップのうち５ステップが変更されているため、ステップ修正数フィールド３６も空欄である。
又、「release2」においては、テストコードを作成し自動テストを実行している。このため、図１１のテスト工程レコードエントリ表３０の３〜４行目に示すように、手順書作成工程フィールド３７及び手動テスト実施工数フィールド３８が空欄である。又、仕様「spec1」の全１０ステップのうち１０ステップが変更され、仕様「spec2」の全５ステップのうち５ステップが変更されているため、ステップ修正数フィールド３６も空欄である。
「release3」においては、テストコードを作成し自動テストを実行している。このため、図１１のテスト工程レコードエントリ表３０の５〜６行目に示すように、手順書作成工程フィールド３７及び手動テスト実施工数フィールド３８が空欄である。又、仕様「spec1」の全１０ステップのうち４ステップのみが変更され、仕様「spec2」の全５ステップのうち４ステップのみが変更されているため、ステップ修正数フィールド３６にそれぞれ値「４」が記録されている。なお、前述のように、テストコード作成工数フィールド３５の値は、これら４ステップの修正に要した工数を表している。
まず、判定処理部５は、図９のステップＳ２１において、テスト工数レコードエントリ表３０を用いて比例定数Ｃａｃ、Ｃｒｃ、Ｃｒｅを算出する。このとき、それぞれのエントリで、工数／ステップ数で比例係数を求め、比例係数の平均値を算出する。
最初に、判定処理部５は、上記式（１）からテストコード作成の比例定数Ｃａｃを求める。
最初に、判定処理部５は、上記式（１）からテストコード作成の比例定数Ｃａｃを求める。
テストコード作成工数フィールド３５にはentry3〜entry6のデータが存在する。
entry3、entry4は作成工数なので、判定処理部５は、ステップ数としてテストステップ数フィールド３４の値（entry3では１０、entry4では５）を使用する。
entry5、entry6は修正工数なので、判定処理部５は、式（１）のステップ数としてステップ修正数フィールド３６の値（entry5では４、entry6では４）を使用する。
entry3、entry4は作成工数なので、判定処理部５は、ステップ数としてテストステップ数フィールド３４の値（entry3では１０、entry4では５）を使用する。
entry5、entry6は修正工数なので、判定処理部５は、式（１）のステップ数としてステップ修正数フィールド３６の値（entry5では４、entry6では４）を使用する。
Ｃａｃ＝（８ｈ／１０＋６ｈ／５＋４ｈ／４＋４ｈ／４）／４＝１．０
次に、判定処理部５は、上記式（２）からテスト手順書作成の比例定数Ｃｒｃを求める。
手順書作成工数フィールド３７には、entry1〜entry2のデータが存在する。
Ｃｒｃ＝（４ｈ／１０＋３ｈ／５）／２＝０．５
次に、判断処理部５は、上記式（３）から手動テスト実施工数の比例定数Ｃｒｅを求める。
手動テスト実施工数フィールド３８には、entry1〜entry2のデータが存在する。
次に、判定処理部５は、上記式（２）からテスト手順書作成の比例定数Ｃｒｃを求める。
手順書作成工数フィールド３７には、entry1〜entry2のデータが存在する。
Ｃｒｃ＝（４ｈ／１０＋３ｈ／５）／２＝０．５
次に、判断処理部５は、上記式（３）から手動テスト実施工数の比例定数Ｃｒｅを求める。
手動テスト実施工数フィールド３８には、entry1〜entry2のデータが存在する。
Ｃｒｅ＝（０．５ｈ／１０＋０．２５ｈ／５）／２＝０．０５
次に、判定処理部５は、図９のステップＳ２２〜２３において、テストケースごとに、仕様変更の有無を調べる。
まず、テストケース「testcase1」について、判定処理部５は、テストケース管理表２０からこのテストケースに対応する仕様ＩＤ（「spec1」）を取得し、その仕様ＩＤが今回のリリース（「release4」）で変更されているかを、仕様変更管理表４０を用いて判定する。
次に、判定処理部５は、図９のステップＳ２２〜２３において、テストケースごとに、仕様変更の有無を調べる。
まず、テストケース「testcase1」について、判定処理部５は、テストケース管理表２０からこのテストケースに対応する仕様ＩＤ（「spec1」）を取得し、その仕様ＩＤが今回のリリース（「release4」）で変更されているかを、仕様変更管理表４０を用いて判定する。
仕様変更管理表４０にこの仕様ＩＤ（「spec1」）が今回のリリース（「release4」）に登録されていれば、ステップＳ２４に移動する。登録されていない場合、判定処理部５は、次のテストケースについて変更有無を調べる。
図１１のテスト工程レコードエントリ表３０では、「testcase1」についてエントリが存在するのでＹｅｓとなる。
図１１のテスト工程レコードエントリ表３０では、「testcase1」についてエントリが存在するのでＹｅｓとなる。
次に、ステップＳ２４において、判定処理部５は、ステップ数及びテスト実行回数を取得する。
テスト工程レコードエントリ表３０のentry5から、前回の「release3」のときのテストステップ数フィールド３４から１０、ステップ修正数フィールド３６から４、テスト実行回数フィールド３３から２を、それぞれ取得する。
テスト工程レコードエントリ表３０のentry5から、前回の「release3」のときのテストステップ数フィールド３４から１０、ステップ修正数フィールド３６から４、テスト実行回数フィールド３３から２を、それぞれ取得する。
次に、ステップＳ２５において、判定処理部５は、上記式（４）から自動テストの工数ａを算出する。ここで、過去データが存在するので、判定処理部５は、式（４）のステップ数として修正ステップ数の４を使用する。
テストコードの作成又は修正工数ａ＝テストコードの作成の比例定数Ｃａｃ×ステップ数
＝Ｃａｃ×４＝１．０×４＝４．０
次に、ステップＳ２６において、判定処理部５は、上記式（５）から手動テストの工数ｂを算出する。ここでも、過去データが存在するので、判定処理部５は、式（５）のステップ数として修正ステップ数の４を使用する。又、判定処理部５は、式（５）のテスト手動実行のステップ数として、１０を使用する。
テスト手順書の作成又は修正工数＋手動テスト実施工数×テスト実行回数
＝テスト手順書の作成の比例定数Ｃｒｃ×ステップ数＋手動テストの比例定数Ｃｒｅ×ステップ数×テスト実行回数
＝Ｃｒｃ×４＋Ｃｒｅ×１０×２＝０．５×４＋０．０５×１０×２＝２＋１＝３．０
次に、ステップＳ２７において、判定処理部５は、自動テストの工数ａが手動テストの工数ｂよりも大きいかを判定する。
テストコードの作成又は修正工数ａ＝テストコードの作成の比例定数Ｃａｃ×ステップ数
＝Ｃａｃ×４＝１．０×４＝４．０
次に、ステップＳ２６において、判定処理部５は、上記式（５）から手動テストの工数ｂを算出する。ここでも、過去データが存在するので、判定処理部５は、式（５）のステップ数として修正ステップ数の４を使用する。又、判定処理部５は、式（５）のテスト手動実行のステップ数として、１０を使用する。
テスト手順書の作成又は修正工数＋手動テスト実施工数×テスト実行回数
＝テスト手順書の作成の比例定数Ｃｒｃ×ステップ数＋手動テストの比例定数Ｃｒｅ×ステップ数×テスト実行回数
＝Ｃｒｃ×４＋Ｃｒｅ×１０×２＝０．５×４＋０．０５×１０×２＝２＋１＝３．０
次に、ステップＳ２７において、判定処理部５は、自動テストの工数ａが手動テストの工数ｂよりも大きいかを判定する。
４．０＞３．０なので、ステップＳ２８において、テストケース「testcase1」についての結果は「手動テスト」となる。
次に、テストケース「testcase2」に移り、判定処理部５は、テストケース管理表２０からこのテストケースに対応する仕様ＩＤ（「spec1」）を取得し、その仕様ＩＤが今回のリリース（「release4」）で変更されているかを、仕様変更管理表４０を用いて判定する。
次に、テストケース「testcase2」に移り、判定処理部５は、テストケース管理表２０からこのテストケースに対応する仕様ＩＤ（「spec1」）を取得し、その仕様ＩＤが今回のリリース（「release4」）で変更されているかを、仕様変更管理表４０を用いて判定する。
仕様変更管理表４０にこの仕様ＩＤ（「spec2」）が今回のリリース（「release4」）に登録されていれば、ステップＳ２４に移動する。登録されていない場合、判定処理部５は、次のテストケースについて変更有無を調べる。
図１１のテスト工程レコードエントリ表３０では、「testcase2」についてエントリが存在するのでＹｅｓとなる。
図１１のテスト工程レコードエントリ表３０では、「testcase2」についてエントリが存在するのでＹｅｓとなる。
次に、ステップＳ２４において、判定処理部５は、ステップ数及びテスト実行回数を取得する。
テスト工程レコードエントリ表３０のentry6から、前回の「release3」のときのテストステップ数フィールド３４から５、ステップ修正数フィールド３６から４、テスト実行回数フィールド３３から２を、それぞれ取得する。
テスト工程レコードエントリ表３０のentry6から、前回の「release3」のときのテストステップ数フィールド３４から５、ステップ修正数フィールド３６から４、テスト実行回数フィールド３３から２を、それぞれ取得する。
次に、ステップＳ２５において、判定処理部５は、上記式（４）から自動テストの工数ａを算出する。ここで、過去データが存在するので、判定処理部５は、式（４）のステップ数として修正ステップ数の４を使用する。
テストコードの作成又は修正工数＝テストコードの作成の比例定数Ｃａｃ×ステップ数
＝Ｃａｃ×４＝１．０×４＝４．０
次に、ステップＳ２６において、判定処理部５は、上記式（５）から手動テストの工数ｂを算出する。ここでも、過去データが存在するので、判定処理部５は、式（５）のステップ数として修正ステップ数の４を使用する。又、判定処理部５は、式（５）のテスト手動実行のステップ数として、５を使用する。
テスト手順書の作成又は修正工数＋手動テスト実施工数×テスト実行回数
＝テスト手順書の作成の比例定数Ｃｒｃ×ステップ数＋手動テストの比例定数Ｃｒｅ×ステップ数×テスト実行回数
＝Ｃｒｃ×４＋Ｃｒｅ×５×２＝０．５×４＋０．０５×５×２＝２＋０．５＝２．５
次に、ステップＳ２７において、判定処理部５は、自動テストの工数ａが手動テストの工数ｂよりも大きいかを判定する。
テストコードの作成又は修正工数＝テストコードの作成の比例定数Ｃａｃ×ステップ数
＝Ｃａｃ×４＝１．０×４＝４．０
次に、ステップＳ２６において、判定処理部５は、上記式（５）から手動テストの工数ｂを算出する。ここでも、過去データが存在するので、判定処理部５は、式（５）のステップ数として修正ステップ数の４を使用する。又、判定処理部５は、式（５）のテスト手動実行のステップ数として、５を使用する。
テスト手順書の作成又は修正工数＋手動テスト実施工数×テスト実行回数
＝テスト手順書の作成の比例定数Ｃｒｃ×ステップ数＋手動テストの比例定数Ｃｒｅ×ステップ数×テスト実行回数
＝Ｃｒｃ×４＋Ｃｒｅ×５×２＝０．５×４＋０．０５×５×２＝２＋０．５＝２．５
次に、ステップＳ２７において、判定処理部５は、自動テストの工数ａが手動テストの工数ｂよりも大きいかを判定する。
４．０＞２．５なので、ステップＳ２８において、テストケース「testcase2」についても結果は「手動テスト」となる。
なお、上記の場合、テスト実行回数が２であり、「testcase1」、「testcase2」のいずれについても手動テストのほうが工数が少ないが、テスト実行回数が増えると（例えば上記ならの例から８回を超える場合）、自動テストのほうが工数が少なくなる。
なお、上記の場合、テスト実行回数が２であり、「testcase1」、「testcase2」のいずれについても手動テストのほうが工数が少ないが、テスト実行回数が増えると（例えば上記ならの例から８回を超える場合）、自動テストのほうが工数が少なくなる。
テストケースが存在しないので、結果表示部６は、図１０のＳ３１〜Ｓ３３において、変更のあった仕様に対応するテストケースごとに、判定結果（「手動」又は「自動」）を提示する。上記の例では、
testcase1：手動テストを推奨します
testcase2：手動テストを推奨します
などのテキストを、不図示のディスプレイに表示する。
testcase1：手動テストを推奨します
testcase2：手動テストを推奨します
などのテキストを、不図示のディスプレイに表示する。
上記の実施形態の一例によれば、仕様変更時に自動テストと手動テストとのいずれを採用すべきかを判断可能とすることができる。
これにより、工数の少ないテストを採用することでソフトウェアのテストのコストを削減することができ、ひいては、ソフトウェアの開発コスト全体も削減することができる。
又、実際の実績に基づいて推定工数を算出するため、正確な判断を行なうことができる。
これにより、工数の少ないテストを採用することでソフトウェアのテストのコストを削減することができ、ひいては、ソフトウェアの開発コスト全体も削減することができる。
又、実際の実績に基づいて推定工数を算出するため、正確な判断を行なうことができる。
さらに、自動化、手動のいずれか一方の工数のデータしか存在しない場合でも、過去の同様のソフトウェア開発における手動テスト及び自動テストの実施実績を用いて、判断を行なうことができる。
（Ｂ）変形例
なお、上記の実施形態にかかわらず、様々に変更して実施することができる。
（Ｂ）変形例
なお、上記の実施形態にかかわらず、様々に変更して実施することができる。
例えば、テストケースに対応した仕様の変更されやすさを反映するように変更することが考えられる。テストケースによっては、毎回のように仕様変更される仕様もあれば、ほとんど仕様変更されないものもある。サービス開発の場合、サービスを継続的に改善していくため、一般には、機能の追加や削除が頻繁に行なわれる。
一方で、アプリケーション開発の場合は、アプリケーションが完成に近づくに伴い仕様が固定化されるため、やがて、仕様変更がほとんどなくなる。
一方で、アプリケーション開発の場合は、アプリケーションが完成に近づくに伴い仕様が固定化されるため、やがて、仕様変更がほとんどなくなる。
このようにほとんど変更されない仕様の場合、手動テストを選択すると、将来の工数が大きくなることがある。つまり、ほとんど仕様変更されないので、テストケースが変更されず、手動テストが今後繰り返されることとなり、工数が大きくなる。
そこで、上記実施形態の第１変形例として、過去の仕様変更の割合から、今後変更されずに手動テストを続けた場合の手動テスト実施想定工数を算出し、自動テスト・手動テストのいずれが有利かを判定することが考えられる。
そこで、上記実施形態の第１変形例として、過去の仕様変更の割合から、今後変更されずに手動テストを続けた場合の手動テスト実施想定工数を算出し、自動テスト・手動テストのいずれが有利かを判定することが考えられる。
例えば、仕様変更の割合から、今後も変更されないで手動テストを続けた場合の工数を、確率論から想定することができる。以下にその方法を説明する。
あるテストケースにおいて、仕様変更されていない割合は、仕様変更管理表４０の記録から
仕様変更されていない回数÷リリース数
によって求めることができる。
あるテストケースにおいて、仕様変更されていない割合は、仕様変更管理表４０の記録から
仕様変更されていない回数÷リリース数
によって求めることができる。
この割合をｒ（０≦ｒ≦１）としたとき、今後ｎ回後のリリースまで仕様変更されない確率を、ｒｎと想定することができる。
従って、今回の手動テスト実施工数がｅ（既述の通り、手動テストの比例定数Ｃｒｅ×ステップ数として求める）のとき、ｎ回後まで仕様変更されない場合の手動テストの実施工数の合計（手動テスト実施想定工数）は、
ｅ＋ｅｒ＋ｅｒ２＋…＋ｅｒｎ
即ち、
ｅｒ（１−ｒｎ）／（１−ｒ）（０≦ｒ＜１の場合）
ｅｎ（ｒ＝１の場合） ……式（６）
と想定できる。
従って、今回の手動テスト実施工数がｅ（既述の通り、手動テストの比例定数Ｃｒｅ×ステップ数として求める）のとき、ｎ回後まで仕様変更されない場合の手動テストの実施工数の合計（手動テスト実施想定工数）は、
ｅ＋ｅｒ＋ｅｒ２＋…＋ｅｒｎ
即ち、
ｅｒ（１−ｒｎ）／（１−ｒ）（０≦ｒ＜１の場合）
ｅｎ（ｒ＝１の場合） ……式（６）
と想定できる。
この場合、図６のステップＳ２６の手動テストの工数ｂ′の算出式を、以下の式に変更する。
手動テストの工数ｂ′＝テスト手順書の作成又は修正工数＋手動テスト実施想定工数×テスト実行回数 ……式（７）
上記式（７）の「手動テスト実施想定工数」に上記の式（６）の値を代入する。
手動テストの工数ｂ′＝テスト手順書の作成又は修正工数＋手動テスト実施想定工数×テスト実行回数 ……式（７）
上記式（７）の「手動テスト実施想定工数」に上記の式（６）の値を代入する。
その後既述の通り、ステップＳ２７において、判定処理部５が、自動テストの工数ａと手動テストの工数ｂ′とを比較する。
なお、上記ｎは、適当な値（例えばユーザが、３や∞などの任意の値）に設定して評価すればよい。
例えば、過去に２／３の割合で変更されないテストケースの、手動テストの実施工数が０．５ｈである場合、ｎ→∞のとき、上記式の値は、
ｅｒ／（１−ｒ）（０≦ｒ＜１の場合）
∞（ｒ＝１の場合）
となる。これにｅ＝０．５、ｒ＝２／３を代入すると、
手動テスト実施想定工数＝（０．５）×（２／３）／（１−２／３）＝１ｈとなる。
なお、上記ｎは、適当な値（例えばユーザが、３や∞などの任意の値）に設定して評価すればよい。
例えば、過去に２／３の割合で変更されないテストケースの、手動テストの実施工数が０．５ｈである場合、ｎ→∞のとき、上記式の値は、
ｅｒ／（１−ｒ）（０≦ｒ＜１の場合）
∞（ｒ＝１の場合）
となる。これにｅ＝０．５、ｒ＝２／３を代入すると、
手動テスト実施想定工数＝（０．５）×（２／３）／（１−２／３）＝１ｈとなる。
この第１変形例の動作、図６，図１１に示した例を用いて後述する。
図９のステップＳ２４において、判定処理部５は、テストケース「testcase1」について、ステップ数及びテスト実行回数を取得する。
テスト工程レコードエントリ表３０のentry5から、前回の「release3」のときのテストステップ数フィールド３４から１０、ステップ修正数フィールド３６から４、テスト実行回数フィールド３３から２を、それぞれ取得する。
図９のステップＳ２４において、判定処理部５は、テストケース「testcase1」について、ステップ数及びテスト実行回数を取得する。
テスト工程レコードエントリ表３０のentry5から、前回の「release3」のときのテストステップ数フィールド３４から１０、ステップ修正数フィールド３６から４、テスト実行回数フィールド３３から２を、それぞれ取得する。
次に、ステップＳ２５において、判定処理部５は、上記式（４）から自動テストの工数ａを算出する。
テストコードの作成又は修正工数＝テストコードの作成の比例定数Ｃａｃ×ステップ数
＝Ｃａｃ×４＝１．０×４＝４．０
次に、ステップＳ２６において、判定処理部５は、上記式（７）から手動テストの工数ｂ′を算出する。
手動テストの工数＝テスト手順書の作成又は修正工数＋手動テスト実施想定工数×テスト実行回数
＝テスト手順書の作成の比例定数Ｃｒｃ×ステップ数＋手動テスト実施想定工数×テスト実行回数
ここで、手動テスト実施工数をｅとすると、ｅ＝手動テストの比例定数Ｃｒｅ×ステップ数＝０．０５×１０＝０．５
手動テスト実施想定工数＝ｅｒ／（１−ｒ）＝（０．５）×（０．７５）／（１−０．７５）＝１．５ｈ
＝Ｃｒｃ×４＋１．５×２＝０．５×４＋３．０＝５．０ｈ
次に、ステップＳ２７において、判定処理部５は、自動テストの工数ａが手動テストの工数ｂ′よりも大きいかを判定する。
テストコードの作成又は修正工数＝テストコードの作成の比例定数Ｃａｃ×ステップ数
＝Ｃａｃ×４＝１．０×４＝４．０
次に、ステップＳ２６において、判定処理部５は、上記式（７）から手動テストの工数ｂ′を算出する。
手動テストの工数＝テスト手順書の作成又は修正工数＋手動テスト実施想定工数×テスト実行回数
＝テスト手順書の作成の比例定数Ｃｒｃ×ステップ数＋手動テスト実施想定工数×テスト実行回数
ここで、手動テスト実施工数をｅとすると、ｅ＝手動テストの比例定数Ｃｒｅ×ステップ数＝０．０５×１０＝０．５
手動テスト実施想定工数＝ｅｒ／（１−ｒ）＝（０．５）×（０．７５）／（１−０．７５）＝１．５ｈ
＝Ｃｒｃ×４＋１．５×２＝０．５×４＋３．０＝５．０ｈ
次に、ステップＳ２７において、判定処理部５は、自動テストの工数ａが手動テストの工数ｂ′よりも大きいかを判定する。
４．０＞５．０なので、ステップＳ２９において、テストケース「testcase1」についての結果は「自動テスト」となる。
このように、仕様変更がない場合は自動テストと判定される。
上記の実施形態の一例の変形例によれば、上記の実施形態の一例の効果に加えて、仕様の変更頻度を考慮した判断を行なうことができるという効果が得られる。
このように、仕様変更がない場合は自動テストと判定される。
上記の実施形態の一例の変形例によれば、上記の実施形態の一例の効果に加えて、仕様の変更頻度を考慮した判断を行なうことができるという効果が得られる。
（Ｃ）その他
なお、開示の技術は上述した実施形態に限定されるものではなく、本実施形態の趣旨を逸脱しない範囲で種々変形して実施することができる。
例えば、上記の実施形態においては、テスト判定システム１が、仕様変更時に、自動テストの工数と手動テストの工数とを予測し、両者のうち工数の少ない方を提示すると説明したが、テスト判定システム１は、ソフトウェアの新規開発時においても同様の予測を行なうことができる。
なお、開示の技術は上述した実施形態に限定されるものではなく、本実施形態の趣旨を逸脱しない範囲で種々変形して実施することができる。
例えば、上記の実施形態においては、テスト判定システム１が、仕様変更時に、自動テストの工数と手動テストの工数とを予測し、両者のうち工数の少ない方を提示すると説明したが、テスト判定システム１は、ソフトウェアの新規開発時においても同様の予測を行なうことができる。
又、上記の実施形態においては、過去の全記録を用いて予測を行なう場合を説明した。
しかし、工数記録とテストのステップ数から比例係数を算出する場合や、テスト実行回数を求める場合に、過去の全ての記録を使用すると、最新の傾向が反映されない場合がある。
そこで、最新ｎ回の記録の平均を用いるなどにより、比例係数の算出時に、最新の傾向を反映させるようにしてもよい。
しかし、工数記録とテストのステップ数から比例係数を算出する場合や、テスト実行回数を求める場合に、過去の全ての記録を使用すると、最新の傾向が反映されない場合がある。
そこで、最新ｎ回の記録の平均を用いるなどにより、比例係数の算出時に、最新の傾向を反映させるようにしてもよい。
又、上記実施形態では、自動テスト又は手動テストのいずれが工数が少ないかを判定していたが、これに加えて、ユーザの選択に合わせて、自動テストの実行対象を制御してもよい。
即ち、ユーザが手動テストを選択した場合は、自動テストの実行対象から該当テストケースを外し、自動テストを選択した場合は、自動テストの実行対象に該当テストケースを入れてもよい。
即ち、ユーザが手動テストを選択した場合は、自動テストの実行対象から該当テストケースを外し、自動テストを選択した場合は、自動テストの実行対象に該当テストケースを入れてもよい。
なお、判定実行部２の記録処理部４及び判定処理部５としての機能を実現する際には、内部記憶装置（不図示）に格納されたプログラムがコンピュータのマイクロプロセッサ（本実施形態では不図示のＣＰＵなど）によって実行される。
このとき、記憶媒体に記録されたプログラムをコンピュータが読み取って実行するようにしてもよい。
このとき、記憶媒体に記録されたプログラムをコンピュータが読み取って実行するようにしてもよい。
なお、判定実行部２の記録処理部４及び判定処理部５としての機能を実現するためのプログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷ等），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ＋Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋ＲＷ，ＨＤ ＤＶＤ等），ブルーレイディスク，磁気ディスク，光ディスク，光磁気ディスク等の、コンピュータ読取可能な記憶媒体に記録された形態で提供される。そして、コンピュータはその記憶媒体からプログラムを読み取って内部記憶装置又は外部記憶装置に転送し格納して用いる。又、そのプログラムを、例えば磁気ディスク，光ディスク，光磁気ディスク等の記憶装置（記憶媒体）に記録しておき、その記憶装置から通信経路を介してコンピュータに提供するようにしてもよい。
なお、本実施形態において、コンピュータとは、ハードウェアとオペレーティングシステムとを含む概念であり、オペレーティングシステムの制御の下で動作するハードウェアを意味している。又、オペレーティングシステムが不要でアプリケーションプログラム単独でハードウェアを動作させるような場合には、そのハードウェア自体がコンピュータに相当する。ハードウェアは、少なくとも、ＣＰＵ等のマイクロプロセッサと、記憶媒体に記録されたコンピュータプログラムを読み取るための手段とをそなえており、本実施形態においては、ストレージ装置３がコンピュータとしての機能を有しているのである。
なお、本実施形態において、コンピュータとは、ハードウェアとオペレーティングシステムとを含む概念であり、オペレーティングシステムの制御の下で動作するハードウェアを意味している。
（Ｄ）付記
以上の実施形態に関し、更に以下の付記を開示する。
（Ｄ）付記
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
ソフトウェアのテストについて、自動テスト又は手動テストのいずれが有利であるかを判定する判定装置であって、
前記自動テスト用のコードの作成又は修正に要する自動テスト推定工数と、前記手動テストの手順の作成又は修正、及び前記手動テストに要する手動テスト推定工数とを算出する算出部と、
前記自動テスト推定工数と前記手動テスト推定工数との比較に基づいて、前記手動テスト又は前記自動テストのいずれか一方を提示する提示部と、
を備えることを特徴とする判定装置。
ソフトウェアのテストについて、自動テスト又は手動テストのいずれが有利であるかを判定する判定装置であって、
前記自動テスト用のコードの作成又は修正に要する自動テスト推定工数と、前記手動テストの手順の作成又は修正、及び前記手動テストに要する手動テスト推定工数とを算出する算出部と、
前記自動テスト推定工数と前記手動テスト推定工数との比較に基づいて、前記手動テスト又は前記自動テストのいずれか一方を提示する提示部と、
を備えることを特徴とする判定装置。
（付記２）
前記判定装置は、前記自動テスト推定工数と前記手動テスト推定工数との算出に用いるデータセットを備えることを特徴とする付記１記載の判定装置。
（付記３）
前記データセットは、前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を記録していることを特徴とする付記２記載の判定装置。
前記判定装置は、前記自動テスト推定工数と前記手動テスト推定工数との算出に用いるデータセットを備えることを特徴とする付記１記載の判定装置。
（付記３）
前記データセットは、前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を記録していることを特徴とする付記２記載の判定装置。
（付記４）
前記算出部は、前記テストステップ数と前記テストコード作成工数とに基づいて第１比例定数を、前記テストステップ数と前記手順作成工数とに基づいて第２比例定数を、前記テストステップ数と前記実施工数とに基づいて第３比例定数を算出し、算出した前記第１比例定数ないし前記第３比例定数を用いて前記手動テスト推定工数及び前記自動テスト推定工数を算出することを特徴とする付記３記載の判定装置。
前記算出部は、前記テストステップ数と前記テストコード作成工数とに基づいて第１比例定数を、前記テストステップ数と前記手順作成工数とに基づいて第２比例定数を、前記テストステップ数と前記実施工数とに基づいて第３比例定数を算出し、算出した前記第１比例定数ないし前記第３比例定数を用いて前記手動テスト推定工数及び前記自動テスト推定工数を算出することを特徴とする付記３記載の判定装置。
（付記５）
前記判定装置は、ユーザから入力された前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を前記データセットに記録する記録部を備えることを特徴とする付記３又は４記載の判定装置。
前記判定装置は、ユーザから入力された前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を前記データセットに記録する記録部を備えることを特徴とする付記３又は４記載の判定装置。
（付記６）
前記判定装置は、過去の実績に基づいて前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を前記データセットに記録する記録部を備えることを特徴とする付記３又は４記載の判定装置。
前記判定装置は、過去の実績に基づいて前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を前記データセットに記録する記録部を備えることを特徴とする付記３又は４記載の判定装置。
（付記７）
ソフトウェアのテストについて、自動テスト又は手動テストのいずれが有利であるかを判定する判定方法であって、
前記自動テスト用のコードの作成又は修正に要する自動テスト推定工数と、前記手動テストの手順の作成又は修正、及び前記手動テストに要する手動テスト推定工数とを算出し、
前記自動テスト推定工数と前記手動テスト推定工数との比較に基づいて、前記手動テスト又は前記自動テストのいずれか一方を提示する、
ことを特徴とする判定方法。
ソフトウェアのテストについて、自動テスト又は手動テストのいずれが有利であるかを判定する判定方法であって、
前記自動テスト用のコードの作成又は修正に要する自動テスト推定工数と、前記手動テストの手順の作成又は修正、及び前記手動テストに要する手動テスト推定工数とを算出し、
前記自動テスト推定工数と前記手動テスト推定工数との比較に基づいて、前記手動テスト又は前記自動テストのいずれか一方を提示する、
ことを特徴とする判定方法。
（付記８）
前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数をデータセットに記録することを特徴とする付記７記載の判定方法。
（付記９）
前記テストステップ数と前記テストコード作成工数とに基づいて第１比例定数を、前記テストステップ数と前記手順作成工数とに基づいて第２比例定数を、前記テストステップ数と前記実施工数とに基づいて第３比例定数を算出し、算出した前記第１比例定数ないし前記第３比例定数を用いて前記手動テスト推定工数及び前記自動テスト推定工数を算出することを特徴とする付記８記載の判定方法。
前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数をデータセットに記録することを特徴とする付記７記載の判定方法。
（付記９）
前記テストステップ数と前記テストコード作成工数とに基づいて第１比例定数を、前記テストステップ数と前記手順作成工数とに基づいて第２比例定数を、前記テストステップ数と前記実施工数とに基づいて第３比例定数を算出し、算出した前記第１比例定数ないし前記第３比例定数を用いて前記手動テスト推定工数及び前記自動テスト推定工数を算出することを特徴とする付記８記載の判定方法。
（付記１０）
ユーザから入力された前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を前記データセットに記録することを特徴とする付記８又は９記載の判定方法。
（付記１１）
過去の実績に基づいて前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を前記データセットに記録することを特徴とする付記８又は９記載の判定方法。
ユーザから入力された前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を前記データセットに記録することを特徴とする付記８又は９記載の判定方法。
（付記１１）
過去の実績に基づいて前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を前記データセットに記録することを特徴とする付記８又は９記載の判定方法。
（付記１２）
ソフトウェアのテストについて、自動テスト又は手動テストのいずれが有利であるかを判定する判定プログラムであって、コンピュータで実行されたときに、前記コンピュータに、
前記自動テスト用のコードの作成又は修正に要する自動テスト推定工数と、前記手動テストの手順の作成又は修正、及び前記手動テストに要する手動テスト推定工数とを算出させ、
前記自動テスト推定工数と前記手動テスト推定工数との比較に基づいて、前記手動テスト又は前記自動テストのいずれか一方を提示させる、
ことを特徴とする判定プログラム。
ソフトウェアのテストについて、自動テスト又は手動テストのいずれが有利であるかを判定する判定プログラムであって、コンピュータで実行されたときに、前記コンピュータに、
前記自動テスト用のコードの作成又は修正に要する自動テスト推定工数と、前記手動テストの手順の作成又は修正、及び前記手動テストに要する手動テスト推定工数とを算出させ、
前記自動テスト推定工数と前記手動テスト推定工数との比較に基づいて、前記手動テスト又は前記自動テストのいずれか一方を提示させる、
ことを特徴とする判定プログラム。
（付記１３）
前記コンピュータに、前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数をデータセットに記録させることを特徴とする付記１２記載の判定プログラム。
（付記１４）
前記コンピュータに、前記テストステップ数と前記テストコード作成工数とに基づいて第１比例定数を、前記テストステップ数と前記手順作成工数とに基づいて第２比例定数を、前記テストステップ数と前記実施工数とに基づいて第３比例定数を算出し、算出した前記第１比例定数ないし前記第３比例定数を用いて前記手動テスト推定工数及び前記自動テスト推定工数を算出させることを特徴とする付記１３記載の判定プログラム。
前記コンピュータに、前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数をデータセットに記録させることを特徴とする付記１２記載の判定プログラム。
（付記１４）
前記コンピュータに、前記テストステップ数と前記テストコード作成工数とに基づいて第１比例定数を、前記テストステップ数と前記手順作成工数とに基づいて第２比例定数を、前記テストステップ数と前記実施工数とに基づいて第３比例定数を算出し、算出した前記第１比例定数ないし前記第３比例定数を用いて前記手動テスト推定工数及び前記自動テスト推定工数を算出させることを特徴とする付記１３記載の判定プログラム。
（付記１５）
前記コンピュータに、ユーザから入力された前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を前記データセットに記録させることを特徴とする付記１３又は１４記載の判定プログラム。
前記コンピュータに、ユーザから入力された前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を前記データセットに記録させることを特徴とする付記１３又は１４記載の判定プログラム。
（付記１６）
前記コンピュータに、過去の実績に基づいて前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を前記データセットに記録させることを特徴とする付記１３又は１４記載の判定プログラム。
前記コンピュータに、過去の実績に基づいて前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を前記データセットに記録させることを特徴とする付記１３又は１４記載の判定プログラム。
１ テスト判定システム（判定装置）
１０ ソフトウェア開発システム
１１ ＩＣＴシステム
１２ 記録入力部
２ 判定実行部
２０ テストケース管理表
３ 仕様／テスト管理ＤＢ（データセット）
３０ テスト工程レコードエントリ表
４ 記録処理部（記録部）
４０ 仕様変更管理表
５ 判定処理部（算出部）
６ 結果表示部（提示部）
７ テストシステム
８ バージョン管理システム
９ リリース管理システム
１０ ソフトウェア開発システム
１１ ＩＣＴシステム
１２ 記録入力部
２ 判定実行部
２０ テストケース管理表
３ 仕様／テスト管理ＤＢ（データセット）
３０ テスト工程レコードエントリ表
４ 記録処理部（記録部）
４０ 仕様変更管理表
５ 判定処理部（算出部）
６ 結果表示部（提示部）
７ テストシステム
８ バージョン管理システム
９ リリース管理システム
Claims (8)
- ソフトウェアのテストについて、自動テスト又は手動テストのいずれが有利であるかを判定する判定装置であって、
前記自動テスト用のコードの作成又は修正に要する自動テスト推定工数と、前記手動テストの手順の作成又は修正、及び前記手動テストに要する手動テスト推定工数とを算出する算出部と、
前記自動テスト推定工数と前記手動テスト推定工数との比較に基づいて、前記手動テスト又は前記自動テストのいずれか一方を提示する提示部と、
を備えることを特徴とする判定装置。 - 前記判定装置は、前記自動テスト推定工数と前記手動テスト推定工数との算出に用いるデータセットを備えることを特徴とする請求項１記載の判定装置。
- 前記データセットは、前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を記録していることを特徴とする請求項２記載の判定装置。
- 前記算出部は、前記テストステップ数と前記テストコード作成工数とに基づいて第１比例定数を、前記テストステップ数と前記手順作成工数とに基づいて第２比例定数を、前記テストステップ数と前記実施工数とに基づいて第３比例定数を算出し、算出した前記第１比例定数ないし前記第３比例定数を用いて前記手動テスト推定工数及び前記自動テスト推定工数を算出することを特徴とする請求項３記載の判定装置。
- 前記判定装置は、ユーザから入力された前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を前記データセットに記録する記録部を備えることを特徴とする請求項３又は４記載の判定装置。
- 前記判定装置は、過去の実績に基づいて前記テストのステップ数、前記自動テストのテストコード作成工数、前記手動テストの手順作成工数、及び前記手動テストの実施工数を前記データセットに記録する記録部を備えることを特徴とする請求項３又は４記載の判定装置。
- ソフトウェアのテストについて、自動テスト又は手動テストのいずれが有利であるかを判定する判定方法であって、
前記自動テスト用のコードの作成又は修正に要する自動テスト推定工数と、前記手動テストの手順の作成又は修正、及び前記手動テストに要する手動テスト推定工数とを算出し、
前記自動テスト推定工数と前記手動テスト推定工数との比較に基づいて、前記手動テスト又は前記自動テストのいずれか一方を提示する、
ことを特徴とする判定方法。 - ソフトウェアのテストについて、自動テスト又は手動テストのいずれが有利であるかを判定する判定プログラムであって、コンピュータで実行されたときに、前記コンピュータに、
前記自動テスト用のコードの作成又は修正に要する自動テスト推定工数と、前記手動テストの手順の作成又は修正、及び前記手動テストに要する手動テスト推定工数とを算出させ、
前記自動テスト推定工数と前記手動テスト推定工数との比較に基づいて、前記手動テスト又は前記自動テストのいずれか一方を提示させる、
ことを特徴とする判定プログラム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012243700A JP2014092980A (ja) | 2012-11-05 | 2012-11-05 | 判定装置、判定方法及び判定プログラム |
| US14/049,356 US20140129879A1 (en) | 2012-11-05 | 2013-10-09 | Selection apparatus, method of selecting, and computer-readable recording medium |
| GB1317991.6A GB2507874A (en) | 2012-11-05 | 2013-10-11 | Comparing man-hours for manual and automated testing |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012243700A JP2014092980A (ja) | 2012-11-05 | 2012-11-05 | 判定装置、判定方法及び判定プログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2014092980A true JP2014092980A (ja) | 2014-05-19 |
Family
ID=49679903
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2012243700A Pending JP2014092980A (ja) | 2012-11-05 | 2012-11-05 | 判定装置、判定方法及び判定プログラム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20140129879A1 (ja) |
| JP (1) | JP2014092980A (ja) |
| GB (1) | GB2507874A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7487135B2 (ja) | 2021-03-29 | 2024-05-20 | 株式会社日立製作所 | 工数算出支援装置及び工数算出支援方法 |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10146664B2 (en) * | 2016-02-25 | 2018-12-04 | Dell Products, Lp | Virtual test environment for webpages with automation features |
| CN112000587B (zh) * | 2020-10-29 | 2021-11-23 | 四川新网银行股份有限公司 | 一种基于关联对象操作统计的测试工时自动统计方法 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120005055A1 (en) * | 2010-06-30 | 2012-01-05 | International Business Machines Corporation | Dynamic computation of roi for test automation |
| US8661412B2 (en) * | 2010-11-19 | 2014-02-25 | Microsoft Corporation | Managing automated and manual application testing |
| US20120253728A1 (en) * | 2011-04-01 | 2012-10-04 | Verizon Patent And Licensing Inc. | Method and system for intelligent automated testing in a multi-vendor, multi-protocol heterogeneous environment |
| JP5357340B1 (ja) * | 2011-11-04 | 2013-12-04 | 株式会社メディアシーク | アプリケーションソフトウェアを生成するシステム |
-
2012
- 2012-11-05 JP JP2012243700A patent/JP2014092980A/ja active Pending
-
2013
- 2013-10-09 US US14/049,356 patent/US20140129879A1/en not_active Abandoned
- 2013-10-11 GB GB1317991.6A patent/GB2507874A/en not_active Withdrawn
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7487135B2 (ja) | 2021-03-29 | 2024-05-20 | 株式会社日立製作所 | 工数算出支援装置及び工数算出支援方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| GB201317991D0 (en) | 2013-11-27 |
| US20140129879A1 (en) | 2014-05-08 |
| GB2507874A (en) | 2014-05-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9489291B2 (en) | Continuous integration of business intelligence software | |
| US8341617B2 (en) | Scheduling software updates | |
| JP6152675B2 (ja) | ワークフロー制御プログラム、装置および方法 | |
| AU2012202261B2 (en) | Test data supply chain manager for an integrated testing platform | |
| US20070156731A1 (en) | Automatic project management application | |
| US20160055079A1 (en) | Software application lifecycle management | |
| US11500369B2 (en) | Operation/maintenance management method, program, and operation/maintenance management system | |
| JP5614843B2 (ja) | ソフトウェア設計・運用統合管理システム | |
| US11922229B2 (en) | System for determining data center application program interface readiness | |
| US20050172269A1 (en) | Testing practices assessment process | |
| US11619923B2 (en) | Digital twin management system and method | |
| US9621679B2 (en) | Operation task managing apparatus and method | |
| JP4925166B2 (ja) | コール・センタ・トランスフォーメーション・プロセスをモデリングするための方法およびシステム | |
| JP2018147385A (ja) | 保守作業計画システム、保守作業計画方法及びプログラム | |
| JP2018206181A (ja) | 経営管理システム | |
| JP2014092980A (ja) | 判定装置、判定方法及び判定プログラム | |
| JP4309803B2 (ja) | 保守支援プログラム | |
| WO2016205152A1 (en) | Project management with critical path scheduling and releasing of resources | |
| US20050171831A1 (en) | Testing practices assessment toolkit | |
| JP2019175273A (ja) | 品質評価方法および品質評価装置 | |
| US20080294670A1 (en) | Method and system for hierarchical logging | |
| US11924029B2 (en) | System for scoring data center application program interfaces | |
| US20230222510A1 (en) | System for Automatically Generating Customer Specific Data Center Application Program Interface Documentation | |
| JP7438912B2 (ja) | 設備管理システム、設備管理方法、及び設備管理プログラム | |
| JP2020087087A (ja) | 修正候補特定プログラム |