テストケースが完成したら、テストの実行フェーズに入る。ただテストを進めればよいわけではない。ここでも作業を効率化して品質を高める小ワザがある。

テストケースのできた順にテスト実行してはいけない

 テスト実行フェーズで最も困るのは、終盤に差し掛かったころに影響範囲の大きい不具合が見つかることだ。例えば、テストデータの作成元として、あるデータ登録機能を使っていたとする。そのデータ登録機能に不具合が見つかり、それまでのテストがすべてやり直しになる、といった状況だ。大掛かりなやり直し作業が発生する原因は、テストの実行順序がよく考えられていなかった場合が多い。

 テストケースは、できた順に実行すればよいものではない。実はテストの実行順序については軽視されていることが多い。

 本来は、テストの目的や不具合が判明したときのリスク、テストの実行効率などを考慮して実行順序を組み立てることが重要である。

 実行順序の優先順位を決めるための小ワザはこうだ。「他機能への影響度」と「改修規模」を基準に設定する(図1)。他機能への影響度が大きく、不具合が判明したときの改修規模が大きいものほど、優先してテストを実施するのである。

図1●テストの実行順序は「他機能への影響度」と「改修規模」を基に算出する
[画像のクリックで拡大表示]

 実際には両者の項目を点数付けして、掛け算したうえで評価点を算出する。例えば、他機能への影響度の場合、数多くの機能で参照されるデータ(マスターデータなど)を登録・更新・参照している機能は、影響度が「大」。トランザクションデータを登録・更新・削除している機能は「中」。参照のみの機能は「小」とする。定量的に大が3点、中が2点、小が1点などと点数付けする。

 同様に、改修規模もランク分けする。不具合が見つかったら新規に作成し直さなければならないほどの改修規模ならば「大(3点)」、通常レベルの修正であれば「中(2点)」、軽微な修正であれば「小(1点)」などとする。

 両者の点数を掛け合わせた評価点の大きい順にテストを実行する。こうすれば、テストをやり直すリスクを軽減できる。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら