単体テスト済みと言われたら何を見る？点検申込の結果報告を確かめる方法

単体テストは、申込全体のどの部品を確かめるのか

単体テストは、システムの中の小さな処理や部品を、周囲から分けて確かめる試験です。通常は開発者が、部品の仕様やコードを基に実施します。発注担当がすべてのコードを代わりに調べることと、受け取る報告の対象・根拠・結果を読めるようにすることは、仕事が違います。

この架空例では、希望日文字列を暦上の日付として読む小さな処理だけを取り上げます。実システムにこの処理が存在するかは未確認です。実コードを掲載したり、Web画面で動かしたりする教材ではありません。

Web申込全体のうち、どの小さな処理を確かめる話でしょうか。

「暦上の日付として読める」という部品の期待と、その日に点検予約を受けられるという業務の条件は違います。予約を受け付ける業務規則は未確認です。暦にある日というだけで、休日の扱い、予約できる期間、契約上の対象などを決定しません。

ISTQBの基礎シラバスも、部品、部品間の連携、システム全体、業務上の受入を、対象と目的などで区別しています。工程の名前が同じでも自社で何を指すかを説明してもらい、一つの部品の結果を申込全体の合格へ広げないようにします。

報告の版・仕様・入力・期待・実結果を結び付ける

「テスト済み」という一言から、誰がどの版の何を確かめたかは読み取れません。IT発注担当は、一つの部品の報告を選び、仕様の根拠と対象の版、入力、実行前に期待していた状態、実際に見た出力を対応させます。資料が大量にあっても、同じ対象の話かを追えなければ質問が必要です。

「テスト済み」という報告で、どの欄を同じ対象へ結び付けるのでしょうか。

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

まず、仕様・コード・試験場所の対応を見る

承認された部品仕様の版は未確認、試験したコードの版も未確認です。開発会社へ、報告の対象となった版と、その処理の期待を定めた資料を聞きます。「最新版です」だけでは、報告後の修正や版の違いを追えないためです。

単体テストを実行する環境は未確認です。どの環境で、周囲の処理をどう置き換えて実施したか、報告を読むのに必要な範囲で説明を求めます。開発環境で部品だけを試したことを、本番と同じ環境で全体を確認したことへ置き換えません。

期待と実結果を、同じ入力に結び付ける

期待結果は、実行前に仕様などの根拠から定める状態です。実結果は、実際に実行して得た出力や記録です。期待どおりと書かれた欄だけを見るのでなく、何を入れ、何を見て、どの根拠と比べたかを読めるかを確かめます。期待自体が不明なら、出力が得られても正しさを判定する根拠が不足します。

この案件の実際の結果報告は未確認です。以下の三例は、報告を読む場所を説明する架空の確認予定です。実際に開発会社がこの入力を試した、結果を提出したという記録にはしません。

実施しなかった項目は、結果と理由を分けて読む

準備した確認を実行できなかった場合は、何を行わず、なぜ行えず、次に何をそろえるかを説明してもらいます。別の方法で確かめた場合も、置き換えた範囲と理由が必要です。未実施を不合格と混同せず、未実施を黙って合格に含めないために区別します。

IPAの組込みソフトウェア向けの工程例では、出力の記録、代替した方法や未実施の理由、修正後の版の確認を扱っています。報告を読む考え方の参考です。Web開発のすべてに同じ書式や資料の提出義務があるとするものではなく、受け取る範囲と粒度は対象と合意した条件に合わせて確認します。

暦にある日・暦にない日・空欄を、別の入力で読む

ここでは、暦にある日、暦にない日、空欄という別々の入力を、同じ日付処理の案で読みます。修正前と修正後の比較ではありません。三例とも説明用の架空例です。実行して得た出力や合否を示す表ではなく、期待と実結果をどこで区別するかを見る例として読んでください。

暦にある日、暦にない日、空欄では、何の期待と結果を分けて読むのでしょうか。

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

暦にある日

確認予定の入力は「2027-04-30」です。暦を読む処理で予定する期待は「暦上の日付として読める」です。

暦の日付として読めるか、という処理の期待です。その日を点検予約として受ける、申込を保存する、受付担当へ届くという期待は別に確認します。実際の処理がどの形式を扱うかも、仕様の根拠と照合してください。

暦にない日

確認予定の入力は「2027-02-30」です。暦を読む処理で予定する期待は「暦上の日付として読めない」です。

この入力は暦に存在しない日付です。架空の処理の期待は、そのまま暦上の日付として読めないという点までです。エラーコード、利用者への文言、画面の色や入力の残し方は、この例から決めません。

空欄

確認予定の入力は「空欄（空の文字列）」です。暦を読む処理で想定する期待は、仕様未決のため、未確認です。

入力は何も入っていない空の文字列です。日付を必須にするか、省略を認めるかを先に決めた例ではありません。空欄の扱いは仕様が未決なので、業務側へ必要な仕事を、開発側へ現在の案と確認方法を聞きます。期待が決まらないまま、空欄を拒否した・受け付けたという実結果を作りません。

三例の業務上の受付の期待は未確認です。三例とも試験はまだ実行していません。実際の出力は未取得、合否は未判定、実施の証拠は未取得です。予定の入力と期待を書いたことを、試験を終えた証拠にしないようにします。

版違い・期待未決・未実施を、答えられる相手へ返す

報告がそろわないときは、どの欄が不足し、何を判断できないかを具体的な質問へ変えます。コードの細部を発注担当が代わりに直すのでなく、技術的な説明が必要なことと、業務側の条件を決めることを分けて返します。

版や実施の記録への質問と、申込条件への質問を、誰へ返すのでしょうか。

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

対象の版が分からない場合

開発窓口へ「この結果はどの部品・コードの版に対するものか」「期待を定めた仕様のどの版と対応するか」を聞きます。報告と納品対象の版が違うなら、違いと影響、必要な再確認を説明してもらいます。別の版の結果を、そのまま現在の結果として採用することは保留します。

期待結果や空欄の扱いが分からない場合

業務責任者には、点検申込で希望日を省略できる仕事か、利用者や受付担当が何に困るかを聞きます。開発側には、その回答をどの仕様と期待へ反映するかを説明してもらいます。空欄の条件が決まるまでは、その条件に対する合否の判断を保留し、回答を得た後に実行用の期待をそろえます。

未実施の理由や証拠が分からない場合

開発会社へ「何を行えなかったか」「不足する条件や資料は何か」「どの記録が得られれば結果を読めるか」を聞きます。理由のない空欄を、問題がなかったという結果へ変えません。必要な実行をできる範囲と、前提がそろうまで保留する範囲を分けて説明してもらいます。

誰が回答し、誰が業務側の確認を担うか

実際の開発側のテスト担当は未確認で、発注側の報告確認担当も未確認です。IT発注担当から開発窓口と業務責任者へ、対象の説明や仕様の判断に答えられる人、回答後の確認を行う人を相談します。役割を挙げただけで実担当の了承が取れたとは扱いません。

回答・修正後の結果を、同じ対象と版へ結び直す

実際の報告で期待と違う結果が見つかったら、その入力、期待の根拠、実出力、対象の版を対応させて開発側へ返します。ただし、実出力が期待と違う原因はコードだけとは限りません。期待の根拠となる仕様や、用意した入力・条件の誤りの可能性も、担当と確かめます。

この三例の不具合の状況は未確認で、次の対応担当も未確認です。以下は不具合や回答が得られた場合の進め方で、この架空例に実際の失敗や修正が発生した記録ではありません。

回答や修正の結果は、元のどの報告へ結び直すのでしょうか。

不具合が直ったかを確かめる確認と、変更によって別の部分へ悪影響が出ていないかを確かめる回帰テストは、目的が違います。必要な範囲は変更の影響から考えます。修正後の業務上の優先順位は、回帰テストの確認範囲と計画を決める方法へつなげてください。この三入力を修正前後の結果として並べ替えません。

部品の報告と、申込全体・業務受入の確認を分ける

単体テストの報告を読めても、画面から入力して保存し、受付担当が同じ申込を使えるかは別の確認です。申込処理との接続状況は未確認で、実際の利用者による受入の結果も未確認です。部品の報告を、受付全体の実施結果や業務の受入結果へ広げないようにします。

小さな処理の報告から、次に何の確認を残すのでしょうか。

全体のテスト計画では、何を誰がどの条件で確かめるか、開始・終了・保留の条件をそろえます。発注者が通常の操作や入力違いを試す段階は、業務の流れから受入テストを組み立てる方法で確認できます。単体報告を読む段階と、利用者として実際に操作する段階を混ぜないための案内です。

試す入力や開始状態を用意する考え方は、架空の試験データを一組にそろえる方法へつなげます。また、どの報告を納品物として受け取るか、何を契約上の受入条件にするかは、発注前に納品物と確かめ方をそろえる方法と分けて相談してください。

まとめ：一つの報告で、期待と実結果を照合する

最初からすべてのテストを発注担当が代わりに調べる必要はありません。今回の仕事へ関係する一つの部品の報告を選び、対象・仕様の版・入力・期待・実結果・未実施を対応させます。読めない欄があれば、そのため何を判断できないかを質問にして返します。

今日、一つの報告を使って何を相談すればよいでしょうか。