システムのテスト計画は何から決める？点検申込をWeb化する前の確認

テスト計画で、何を誰が確かめるかをそろえる

テスト計画は、何のために、何を、誰が、どんな条件で確かめるかを関係者でそろえるものです。個々の操作を詳しく書くテストケースや、実際に見た結果の記録と役割が違います。計画には、必要な準備、進める順序、結果の返し先、始める・終える・保留する条件を結びます。

紙の点検申込をWebへ移すと、どの仕事を誰が確かめるのでしょうか。

試す対象と、今回は含めない範囲を対応させる

紙の申込にある情報を、Webでどのように伝え、受付側で何を確認するかを業務側に説明してもらいます。紙に書かれていたことをそのまま画面へ写す前に、使う人の仕事と対象条件を読みます。画面の見た目だけを確かめるのか、受付側の記録や利用者への案内まで追うのかでも、必要な準備は変わります。

対象外にする確認があれば、その理由と後の扱いも残します。「今回は画面を中心に見る」という予定を、受付側の記録が不要という判断へ変えません。全体の性能、権限、他システムとの連携などが必要な場合は、それぞれの目的と担当を別に相談し、この一件の確認で全部が済むとは扱わないようにします。

通常の申込・対象条件に合わない申込・途中停止を分ける

通常の入力だけを一度たどっても、対象条件に合わない申込や、入力途中で止まった申込の扱いまでは分かりません。業務側が困る場面を分け、その場面で何を期待するかを、根拠の資料と結び付けます。下の三つは、関係者に確認するための予定です。

同じ申込でも、通常・対象条件・途中停止で何を分けて相談するのでしょうか。

この節の解説図を原寸で見る

通常の申込

想定する仕事は、点検申込をWebで入力し受付担当が受け取ることです。確認の観点は、入力した同じ申込が、受付担当にどう見えるかを相談する予定です。

業務責任者へ、申込者が伝える内容と、受付担当が同じ一件を確認するために必要な内容を聞きます。開発側には、その対応をどこで見られるかを説明してもらいます。表示された情報、保存された情報、受付担当が使う情報のどれを今回見るかを分け、画面表示だけで全部が成立したと判断しないためです。

対象条件に合わない申込

想定する仕事は、対象外の申込条件を適用することです。確認の観点は、対象条件に合わない場合の案内と、受付側でどう扱うかを相談する予定です。

誰が申込の対象になるか、条件に合わない場合に何を伝えるかは、業務側の規則を確認して決める内容です。この例に年齢、地域、契約の種類などの具体的な資格規則はありません。確認の観点として受付側の「未承認」を考えていますが、それを確定した拒否規則や、実際の受付結果として使いません。案内と受付側の状態をどうそろえるかを、業務責任者へ聞きます。

途中停止・再開

想定する仕事は、入力途中で処理が中断した申込を扱うことです。確認の観点は、入力途中で止まった内容と、二重受付をどう確かめるかを相談する予定です。

入力途中で止まった場合に、何を残し、どこからやり直し、二重の申込をどう避けるかを相談します。入力した内容が自動保存される、再開すれば前の状態へ戻る、と推測しません。開発側へ現在の案と制約を聞き、受付担当が同じ申込を重複と読む条件も、業務側と合わせます。

三場面で使う申込対象条件の合意・承認の状況は未確認で、最終的な期待結果も未確認です。上の予定を書いたことを、業務規則が確定した証拠にしません。関係者の回答から、何を入れたらどの状態を期待するかを具体化してから、実行用の操作へ落とします。

個々の入力・保存・参照の操作を作る段階は、発注者の受入テストで、通常・入力違い・やり直しを確かめる方法で扱っています。本稿は、その操作をどの範囲・担当・準備・開始条件で進めるかを決める段階です。

業務側・開発側・受付側の役割と返し先を結ぶ

開発会社が試験を進められることと、発注側が自社の業務として受け取れるかを確かめることは、同じ役割ではありません。IT発注担当は、技術的な確認を引き受ける人、業務上の期待を説明する人、受付側で同じ申込を読む人を結びます。一人が兼ねる場合も、何を確認したかを分けます。

業務上の判断と技術的な確認を、誰へどう相談するのでしょうか。

この節の解説図を原寸で見る

業務上の期待と判断を説明する人

申込の対象条件、受付が進められる状態、例外時の業務への影響を説明します。今回、業務側で判断する実際の人は未確認です。役割の候補を説明しただけで、その人が担当を了承したとはしません。

技術的な確認と、試す場所を説明する人

対象の版や試験環境、入力と受付側の記録を見る方法、制約、技術的な不具合の返し先を説明します。実際の技術テスト担当は未確認です。技術側が一部を確認した結果を、業務側の全確認の結果へ広げません。

受付側の仕事を確かめる人

同じ申込を受付担当が見つけ、日々の仕事を進められるかを確かめる役割です。実際の受付側の担当も未確認です。画面を説明する人と、受付の仕事を判断する人が違う場合は、その違いを残します。

三場面とも、担当を確認した状態にはなっていません。これは、担当者が存在しないと確認したことや、依頼を断られたという意味ではありません。IT発注担当から業務責任者と開発窓口へ、誰がどの範囲を見て、質問へ答えられるかを聞きます。

結果を返す相手と、説明する内容をそろえる

試験を行う人が、期待と違う結果をどの窓口へ知らせ、誰が業務への影響を判断するかを合わせます。返す情報は、対象の版・場面・使った資料や入力・期待した状態・実際に見た状態を対応させます。不足資料への質問と、実行した不具合の報告を混ぜないようにします。

日程は未確認です。業務側が確認できる時間、開発側が用意できる版と場所、質問へ回答する予定を相談します。記事から一律の試験日数を置かず、準備を確認できない期間を、実施できる期間へ読み替えないようにします。

資料の版・試す場所・使えるデータを準備へ結ぶ

同じ申込を試すつもりでも、資料や対象の版、使うデータ、試験場所が違えば、結果を比べられなくなります。計画では、実行する前に何をそろえ、誰へ確認するかを示します。分からない欄は想像で埋めず、準備の質問として残します。

試験を始める人は、同じ版・場所・申込の例を使えるでしょうか。

紙の資料と、Webの対象版を区別する

紙の申込資料の版は未確認で、対象とするWebの版も未確認です。業務側が説明する資料と開発側が示す候補が、同じ申込条件を対象としているかを合わせます。「最新版」という一語だけで、途中で変わった条件を追えるとは限りません。

試せる場所と、使う人の条件をそろえる

試験環境は未確認です。三場面とも、試す環境を確認した状態にはなっていません。開発窓口へ、どの環境で、どの役割の利用者として、何を実行してよいかを聞きます。環境をまだ確認できないことを、環境がないという断定や、本番を代わりに使う許可へ変えません。

端末とブラウザの確認の組合せは未確認、アクセシビリティの確認範囲も未確認です。アクセシビリティは、操作を行いにくい人なども情報を読み、手続きを進められるかという観点です。自社で使う条件を相談し、携帯端末で一度画面が見えたことや、担当部署があることだけを、必要な確認の完了としません。

試験用のデータと、情報を扱う条件を確かめる

この三場面では、試験データが承認されたとは確認できていません。個人情報などを扱うための社内の確認・許可も未確認です。データの準備方法と利用してよい範囲を管理担当へ聞き、承認の状況が不明なまま本番の申込を持ち込みません。

三場面とも実顧客のデータは使っていません。架空の申込の例をどのように用意し、毎回どの状態から始めるかを開発側と合わせます。データの組を作る具体的な考え方は、架空の顧客・商品と開始状態をそろえる方法で確認できます。

試験を始める・終える・保留する条件を分ける

開始条件は、その確認を始める前に何をそろえるかです。終了条件は、何を行い、どの状態や残る問題をどう判断したら、その確認を終えたと扱うかです。合意した試験の目的に応じて、業務側と開発側で具体化します。計画の作成、試験の実施、システムを受け入れる判断は、それぞれ区別して記録します。

何がそろえば始められ、実施後に何を読めば終える判断ができるのでしょうか。

この節の解説図を原寸で見る

始める条件：実行できる準備を確かめる

対象の版と仕様、試験場所、担当、使えるデータ、期待する状態とその確認先をそろえます。例えば、対象条件の説明を読む人が必要なのに、その説明資料や回答を得ていなければ、何を正しい結果として比べるかを具体化できません。準備の一覧に名前を書いたことと、その条件で実施できることを分けます。

この三場面の開始条件を満たすかは未判定です。担当や環境の確認状況も前述のとおりです。条件を確認できない試験は実行を保留し、足りない材料を誰が示すか、回答後に誰が開始可否を判断するかを相談します。

終える条件：実施した範囲と残る問題を読めるようにする

どの場面をどの版・条件で行い、結果を何と比べ、未実施や未解決があれば誰がどう判断するかを合わせます。終了の目安に件数や網羅の指標を使う場合も、その仕事の目的とリスクに照らして決めます。記事に一般的な数値を埋めて、すべての会社の合格基準にする進め方ではありません。

この三場面の終了条件を満たすかも未判定です。計画した試験はまだ実施していませんし、実際の操作も行っていません。三場面の観測した結果は未確認、合否は未判定、実施の証拠も未取得です。予定の表を作った状態を、試験を終えた記録へ変えません。

個別の契約上の受入条件は未確認です。試験の終了条件を整理しただけで、契約上の検収や支払いの条件が決まるわけではありません。発注前の納品物と確かめ方をそろえる段階は、納品物と検収条件を発注前に確認する方法につなげてください。

回答・変更を、同じ対象と担当の計画へ戻す

関係者から回答を得たら、計画の欄だけを埋めるのでなく、その回答がどの場面の何を変えるかを読みます。対象条件、対象の版、利用できる場所、担当や期待結果が変われば、実行する操作や確認の順序も見直します。以下は回答が届いた場合の進め方で、この架空例に実際の回答が届いた記録ではありません。

回答や仕様の変更は、どの場面と確認条件へ戻すのでしょうか。

公的な仕様の書き方も参考にできます。IPAの2020年の一つの調達仕様は、テスト計画の項目と、IPA側の受入試験・請負者の支援を具体的に分けています。個別案件の例として役割を考える参考になりますが、民間のすべての案件でIPAの承認や同じ分担が必要という規則ではありません。

まとめ：一件の仕事と、実行前に聞く条件を並べる

最初に、どの一件を見せ、何を相談すればよいでしょうか。

三場面で次に確認する相手は、共通して「業務責任者と開発窓口」です。IT発注担当は、誰がどの質問へ答えられるかを相談し、回答と元資料を結びます。確認先の役割が書かれていることを、実際の担当が確定・了承したことへ読み替えません。