システムテストが間に合わないとき 優先順位を決める4つの基準

システムテストは、予定どおりに始まるとは限りません。 実装が後ろへずれ、環境準備にも時間がかかり、テスト開始時には残り日数だけが減っていることがよくあります。

このとき、全項目を同じ順番で消化すると、締め日までに重要な処理が残ります。 画面の文言確認を何件も終えたのに、受注登録から請求連携までの流れをまだ通していない、という状態は避けたいところです。

ここでは、受注管理システムの改修を例に、優先度表の作り方とリリース判断に残す情報を整理します。 対象は、項目追加や表示変更だけでなく、CSV連携や承認処理にも影響する改修です。

残り時間とテスト対象の棚卸し

先に並べるのはテストケースではなく変更内容

テスト項目が多いと、一覧の上から順に消化したくなります。 ただ、並び順が作成順や担当者別のままだと、優先順位にはなりません。

最初に集めるのは、今回変えたものです。 画面、DB更新、帳票、CSV、外部連携、権限、バッチを1枚に並べます。修正した画面だけを見ていると、同じ登録処理を呼ぶ別画面や、夜間連携が後から残ります。

この棚卸しは、細かいテストケースを書く前に行います。 変更内容から周辺処理を辿る方が、優先順位を付けるための材料を集めやすいからです。

未実施を隠すとリリース判断が難しくなる

時間が足りない場面で、完了率だけを見ても判断しにくいです。 全体の90%が終わっていても、残り10%が請求確定や外部連携なら、安心できません。

逆に、残っているのが使用頻度の低い検索条件の組み合わせや、将来利用予定の帳票レイアウトだけなら、業務への影響は別です。 大事なのは、完了件数ではなく、何が未実施なのかを分けて見えるようにすることです。

tomo

テストの消化率だけを見ていると、残っている項目の重さが消えます。リリース直前ほど、件数より中身を見た方がよいです。

未実施項目を「時間不足」とだけ残すと、誰もリスクを判断できません 対象処理、未実施理由、想定影響、代替確認をセットで残します。

優先順位を決める4つの基準

基準1 変更が入った箇所

まず優先するのは、修正した箇所と、その修正が通る経路です。 受注入力に項目を追加したなら、登録だけでは足りません。修正登録、取消、承認、検索、CSV出力まで、追加した値が途中で欠けないかを見ます。

変更が小さく見えても、共通の更新処理を触っている場合があります。 たとえば配送区分を受注明細へ保存する処理を変えたなら、Web画面だけでなく、CSV取込やバッチ更新が同じ明細を更新していないか確認します。

基準2 業務への影響

次は、不具合が出たときに何が止まるかを見ます。 登録できない、承認できない、請求額がずれる、連携ファイルが受け取られない、といった処理は上位に置きます。

表示の余白や文言のずれも直すべきですが、受注確定後に金額を戻せない処理と同じ順番にはしません。 不具合の見た目ではなく、誤った結果がどこまで広がるかで判断します。

業務影響が大きい処理は、利用頻度が低くても後回しにしません 月末だけ使う請求確定や締め処理は、頻度が低いからといって軽く扱えません。

基準3 利用頻度

利用頻度は、同じ不具合が何人に何回当たるかを見るための基準です。 受注検索や受注登録のように毎日使う機能は、小さな操作ミスでも問い合わせが増えます。

一方で、管理者だけが年に数回使う設定画面は、同じ表示不具合でも影響範囲が狭いことがあります。 ここで見るのは、利用者数だけではありません。朝一番に必ず使うのか、締め日だけ使うのか、他の手段で回避できるのかも確認します。

tomo

利用頻度は「毎日か月1回か」だけで決めません。締め日にしか使えない処理は、月1回でも確認を残します。

基準4 過去の障害と不具合履歴

過去に崩れた箇所は、今回の変更と直接関係が薄くても確認対象に残します。 特に、NULLの扱い、取消後の再登録、権限別の表示、CSVの列順は、修正量のわりに再発しやすい場所です。

テスト表に過去障害の列を作り、障害票や問い合わせ番号を残します。 理由が分かれば、「前回CSVの空欄で連携先が止まったため」のように、確認する根拠をチームへ説明できます。

過去障害の再確認は、念のための作業ではありません。再発したときに業務へ影響が出ると分かっている処理を、意識して残す作業です。

受注管理改修の優先度表

A B Cに分けるための記入例

ここでは、残り2営業日でテストを終える状況を想定します。 優先度は点数の合計だけで決めず、4基準の理由を書いたうえでA、B、Cに分けます。点数だけだと、なぜAにしたのかを後で説明しにくいからです。

この表では、CSV出力をAにしています。 画面で配送区分が見えていても、連携ファイルに列が出ていなければ、業務全体としては完了していません。

tomo

Aに入れる根拠を1行で書けると、テストの順番を相談しやすくなります。「重要だから」だけでは、途中で優先度がぶれます。

Aランクは業務の流れで通す

Aランクは、項目を単発で確認して終わりにしません。 配送区分を指定して受注登録し、承認し、出荷CSVを出力するところまで通します。途中で一度差戻し、値を修正して再承認する操作も入れます。

この順番にすると、画面ごとの単体確認では見えない受け渡し漏れが出ます。 入力画面では値が保存されているのに、承認画面で空欄になる。承認画面には出るのに、CSVには列がない。こうした不具合は、業務の流れで通して初めて見つかります。

1. 配送区分を指定して受注を登録する
2. 受注詳細と検索一覧で配送区分を確認する
3. 承認者が内容を確認して承認する
4. 出荷連携CSVを出力し、列順と値を確認する
5. 差戻し後に配送区分を変更し、再承認する

1. 配送区分を指定して受注を登録する
2. 受注詳細と検索一覧で配送区分を確認する
3. 承認者が内容を確認して承認する
4. 出荷連携CSVを出力し、列順と値を確認する
5. 差戻し後に配送区分を変更し、再承認する

この5操作が通ったあとで、Bランクの検索条件や表示確認へ進みます。 Aランクは、業務で値が渡っていく順番で確認すると、限られた時間でも検証の密度が上がります。

未実施項目とリリース可否

未実施の理由を表に残す

Cランクを後回しにした場合も、テスト項目を空欄のままにしません。 未実施理由と、業務上の影響を確認した人を残します。

代替確認は、未実施を実施済みに見せるためのものではありません。 どこまで確認できていて、どこから先が未確認なのかを区切るための記録です。

リリース判断で見るべき状態

リリース可否は、テスト担当者だけで決めるものではありません。 少なくとも、Aランクの完了状況、未解決不具合、未実施項目、代替確認、業務側が受け入れるリスクを同じ表で確認します。

次の状態なら、リリースを止める判断が必要です。

ここで重要なのは、BやCなら必ず出してよい、という意味ではないことです。 対象業務、リリース日、回避策の有無で判断は変わります。表には、判断に必要な事実を残します。

テスト表に残す判断記録

優先度だけでなく根拠を書く

テスト表の優先度列にA、B、Cだけを入れると、翌週には理由が消えます。 変更内容、業務影響、利用頻度、過去障害、未実施理由を列として残すと、次の改修でも使えます。

この表は、立派なテスト管理ツールを導入しないと作れないものではありません。 Excelやスプレッドシートで十分です。大事なのは、項目の完了・未完了だけでなく、順番を決めた理由を残すことです。

次の改修で使える形にする

今回Cにした項目は、ずっとCのままとは限りません。 次回の改修で検索条件や旧年度データに触れるなら、その項目はAやBへ上がります。

リリース後に問い合わせが出たら、該当するテスト項目へ障害番号と再発条件を追記します。 すると次回は、過去障害の基準から優先度を上げられます。

残り時間が少ないときの進め方

変更内容からAランクを決める

テストが間に合わないとき、一覧の上から均等に進めると、最後に判断が必要な処理だけが残ります。 まず、変更内容を画面、データ、連携、権限、帳票に分けて並べます。そのうえで、業務を止める処理と、後続処理へ値を渡す処理をAランクにします。

受注登録、承認、請求確定、出荷連携のような処理は、画面単位ではなく業務の流れで確認します。 表示項目の確認を先に何十件終えても、Aランクが残っていればリリース判断の材料にはなりません。

Aランクを通したあとでBランクへ進む

Bランクは、日常的に使う検索や表示の確認です。 検索条件を保持できるか、一覧から詳細へ戻ったときの表示が崩れないか、権限ごとに余計な列が見えないかを確認します。

ただし、Aランクに不具合が残ったときは、Bランクの消化を優先しません。 登録したデータが連携先へ正しく渡るか、取消後に再登録できるかといった確認を先に終えます。ここは、見た目よりデータの整合性を優先する場面です。

Cランクは未実施理由と次の確認日を残す

Cランクを後回しにする場合は、対象を消さずに残します。 未実施の理由、想定される影響、代替として見た範囲、追加確認する日をテスト表へ記録します。リリース後に問い合わせが出れば、その項目を次回のAまたはBランクへ上げる判断材料になります。

たとえば旧年度データの複合検索を後回しにするなら、単一条件検索まで確認済みであること、旧年度データを使う担当者、次の月次確認日を残します。 これなら、未実施をなかったことにせず、誰がどのリスクを受け入れたかを後から追えます。

参考になりますと幸いです。