今日の最短ルート（15分しかない日）：① 「読み手プロファイル」（30秒） → ② 「4段階で見る（日本語）」の Bad と Good を見比べてから Better を読む（5分。森田さんは「正しい」を判定できない。Good は型が完璧だが、観測点と入力の値が無い。Better は「どの欄に何と出れば○か」を値で書いた） → ③ 「今日の演習 → 15分版」（10分）。残りは余裕がある日に。
今日の文書 — テスト仕様書 / テストケース
テスト仕様書 / テストケース — 機能要件（Day032: システムが何をするか）を受けて、「どの状態で、何を入力し、どこを見て、何と出れば合格か」 を、実施する人が迷わず○×を付けられる形で書く文書。機能要件が「建物名まで比べて、違えば贈り物とする」なら、テストケースは「ハイツ青葉101とハイツ青葉102を取り込んだら、出荷指示一覧の同梱欄に何と出るか」まで下りる。
| 比べる文書 | 何を決めるか | 読み手 |
|---|---|---|
| テスト計画書（Day016） | 何を・どこまで試すか。試さないものと理由、合格の基準、人員 | 承認者・QA |
| テスト仕様書（今日） | 1件ずつの入力・手順・期待値。実施者が○×を付けられる粒度 | テスター |
| テスト報告書（次の回の候補） | 実施した結果と、リリース可否の判断材料 | 発注者・判定者 |
| バグ票（4本目） | ×が付いたものの再現手順 | 開発者 |
この文書の勝負どころ: 期待値が一意に判定できるか。
今日はこれを実務の言葉に言い換える。期待値が一意とは、「同じ画面を見た2人のテスターが、同じ○×を付ける」ことである。 付かないとき、足りないのは多くの場合、観測点（どこを見るか）・入力の値・前提の状態・期待値の出どころのどれかである。
| 考え方 | 中身 | 今日の題材に当てはめると |
|---|---|---|
| テストケース仕様の項目（ISO/IEC/IEEE 29119-3 の 8.3: 識別子・目的・優先度・トレーサビリティ・事前条件・入力・期待結果） | 7つの項目がそろって、はじめて他人が実施できる | 今日の Good は7項目のうち「入力」が値でなく、「期待結果」が観測できない形で抜けている |
| テストオラクル（期待値を何で決めるか）の問い | 期待値の出どころが「システムの出力そのもの」だと、バグを正解として写す | 4月分の再判定で、システムが出した件数を期待値にしてはいけない。人が先に決めた件数と突き合わせる |
| 片側だけの合格条件の罪 | 「対象外になること」だけを見る試験は、全部を対象外にする誤りも合格させる | Day032 の受入れは「720件が対象外」の片側だけ。入れるべき注文が入ることも期待値にする |
期待値が一意にならない4つの形（この回の道具）
| よく出る形 | 何が抜けているか | 置き換えの形 |
|---|---|---|
| 「正しく動作すること」 | 正しいの中身 | 「欄Aに値X、欄Bに値Y」と値で書く |
| 「エラーになること」 | エラーの出る場所と、その後 | 画面名・欄名・値。止まるのか流れるのかも |
| 「カードが入らないこと」 | 画面では見えない結果 | 見える代理（同梱欄・理由欄）で書く。実物は別ケースで少数だけ |
| 「適当なデータで」 | 入力の値 | 取込ファイル名と、各項目の文字そのもの（全角半角まで） |
シナリオ
あなたは株式会社ノヴァストア EC事業本部・販促システム部の MOpsチームマネージャー・宮田（Day004〜Day032 の続き）。
2028年8月9日（水）。6/9 に出した機能要件定義書（Day032）の改修が、ミナトソフトの浅野さんの手で単体テストまで進んだ。受入テスト環境が 8/18（金） に渡される。受入テストは 8/21（月）〜22（火）の2日間、柏物流センターで実施する〔仮定: MOps計画〕。結果は 8/23（水）16:00 に今井課長へ、稼働可否の判定は 8/24（木）10:00、稼働は 8/28（月）、次の同梱物は 9/4（月）。
受入れ側のテスターは、梱包ライン早番リーダーの 森田さん（新登場）。梱包のことは8年分知っているが、システムの言葉（正規化・理由コード）は読まず、テストをするのは初めて。この表以外に頼れるものはない。宮田さんは2日間とも同席できない（別会議）〔仮定〕。
宮田さんが付録A（Day032 の住所12例）を土台に仕様書を書いている8/8（火）、2つのことが分かった〔いずれもシナリオ内の設定〕。
| 発見 | 中身 |
|---|---|
| ① 6/6 の「書き方の違い60件」は、そろえ前の数だった | 宮田さんが60件に N-1〜N-4 を1件ずつ手で当てはめると、38件は「一致」になり、22件だけが不一致のまま（カタカナと漢字の違いなど）。Day032 の「Q の代償は60件/月」は、実際には22件/月になる見込み |
| ② Day032 の受入れ「720件がすべて対象外」は、もう成り立たない | 720件のうち38件は一致になり、カードが入るのが正しい。期待値は 682件（520＋別室140＋22）が対象外、38件が対象。しかも「対象外になること」しか見ない試験は、全部を対象外にする誤りも合格させる |
- 4月の初回購入27,720件の内訳（期待値の元）〔仮定: この回の設定。Day032 の720・18に包装・のしの件数1,980を足した〕: 包装・のしあり1,980／番地から別520／別室140／書き方の違い22／住所の項目欠け18（重ならないと仮定）。対象外の合計 2,680件、対象（カードが入る）25,040件〔導出: 27,720−2,680〕
- 面倒な事情:
- 受入れ環境の画面では、カードが入ったかどうかは見えない（カードは梱包ラインで物理的に入る）。見えるのは出荷指示一覧の「同梱」欄と「理由」欄
- 4月分の再判定にはお客様の住所が要る。ただし住所を伏せると判定の対象そのものが壊れる。複製してよいかは宮田さんが決められない（情報システム部と社内規程）
- 森田さんが「同じマンションなのに入らないのはおかしい」と思うケース（書き方の違い）は、仕様どおりの動きである。×を付けるべきでない
読み手プロファイル
| 項目 | 内容 |
|---|---|
| 誰が読むか | 森田さん（柏物流センター 早番リーダー。梱包ライン8年。テストは初。受入れ環境の管理画面は研修で1回触った）。結果の判定は今井課長。浅野さんは写し |
| 何を判断するために読むか | 森田さん: ①何を入れて ②どこを見て ③何と出れば○か ④違ったらどう書くか。今井課長: ⑤2日間で何が確かめられ、何が確かめられないか ⑥自分が事前に決めることは何か |
| 何を知っているか | 森田さん: 梱包ラインの実際、4月に受取人へカードが入った困りごと。今井課長: 案B・Q を選んだ経緯 |
| 何を知らないか | 森田さん: 「一致」の定義、N-1〜N-4、理由コード、なぜ書き方の違いが「入れない」で○なのか。今井課長: 受入れ環境でカードが見えないこと、4月分の再判定にお客様の住所が要ること |
| 何を気にしているか | 森田さん: 自分の○×で稼働が止まるかもしれない責任、変な操作をして壊すこと、2日で終わるか。今井課長: 稼働日（8/28）が動かないこと |
| 読む時間と場面 | 森田さん: 前々日に20分、紙に印刷して通し読み（付箋を貼る）。実施日は紙を横に置いて操作。今井課長: 前日に1ページ目だけ10分 |
この読み手が変わると何が変わるか: 読み手が 同じ会社の浅野さん自身（Lv1: 味方・開発者）なら、「正規化の4規則を当てた後の文字列を期待値にする」と書いてよく、自動化した突合表で足りる。読み手が 成果を認めたくないベンダー（Lv3: 利害が対立）なら、期待値の出どころ（誰がいつ決めたか）を各ケースに書き、×の判定を誰がするかを契約に近い形で固定する。読み手が システムを知らない経営層（Lv4）なら、ケースの一覧より先に「何を試し、何を試さないか」の2行を置く。今回は システムの言葉を読まない現場のテスター なので、画面名・欄名・値だけで書き、1ページ目には「迷ったときの3つの決まり」を置く。期待値の根拠（なぜ入れないのが○か）は、1行の理由で添える。
4段階で見る — 受入テスト仕様書「TC-05・TC-07・TC-11」
以下は同じ受入テスト仕様書の テストケース表のうち、TC-05（部屋番号が違う）・TC-07（建物名の書き方が違う）・TC-11（郵便番号が空）を4段階で書き分けたもの。差が出るのはケースの数ではなく、期待値が値で書かれていて、2人が同じ○×を付けられるかである。
タブで精読、「横に並べる」で差を一望できる（横並びは各段階の要点3行だけ）。
行数 10・9・13・16、字数 Bad201 → Good243 → Better548 → Best802字（空白を除く・実測）。Best が最長（行・字数とも。Good は表にして1行に詰めたため Bad より1行短い）。期待値の欄・出どころ・選択肢の表が Best で初めてそろう。
Bad
期待が「カードが入らないこと」「エラーになること」。見えない・仕様と違う。
入力は「各自適当に」。合格基準も「問題ないこと」で循環。
疑問の窓口は「随時」で、宮田は2日間不在。Good
ID・対応要件・前提・手順・期待の型は完璧。QAには通じる。
ただし入力が値でなく、「対象外」をどの欄で見るか不明。初回購入の前提も隠れている。
TC-07 が森田さんにはバグに見える。4月分の再判定が抜けた。Better
入力を取込ファイルと住所の文字そのもの、期待を「同梱欄＝対象外／理由欄＝G-02」の値に。
TC-07 に「これで○」の理由を1行。共通の前提を1か所に。
ただし4月分の再判定のデータ（住所の複製）を、黙って決めた。Best
冒頭に「決めていただくこと」。再判定のデータ P/Q/R を、見えること・代償で。
合格は人が数えた内訳（2,680／25,040）。入れる側も数える。
期待値を疑ったときは判定会で振り分け。決まらなければ 8/16 に R。Bad
Expected = "card is not inserted", "an error occurs": not observable, contradicts the spec.
Input: "as appropriate". Pass criterion is circular.
Questions: "as needed" while Miyata is away.Good
IDs, trace, precondition, steps, expected: the standard form, fine for QA.
But input is not a value, "Excluded" has no observation point, first-purchase precondition hidden.
TC-07 looks like a bug; April re-run missing.Better
Input = file + exact address text; expected = field = value (Insert = Excluded, Reason = G-02).
TC-07 gets one line saying why it is a Pass. Common preconditions in one place.
But the data for the April re-run (copying addresses) was chosen silently.Best
Decisions first: data for re-run as P/Q/R with what it shows and cost.
Pass = hand-counted breakdown (2,680 / 25,040): count the insert side too.
Doubts sorted at the Aug 23 review; if undecided, R on Aug 16.Bad — 妥協して雑に作った状態 ／ 10行・201字
受入テスト項目書（同梱物の対象判定）
No. 項目 確認内容 期待結果 結果
5 住所比較 部屋番号が違う場合 カードが入らないこと
7 住所比較 表記が違う場合 正しく判定されること
11 判定不能 郵便番号が空の場合 エラーになること
12 全体 4月分のデータで確認 問題なく動作すること
備考: テストデータは各自適当に用意すること。
不具合があれば宮田まで連絡。
仕様について疑問があれば随時確認のこと。
合格基準: すべての項目が問題ないこと。Bad
Subject: UAT checklist - gift determination
No. Item What to check Expected result Result
5 Address compare When the room number differs Card is not inserted
7 Address compare When notation differs Judged correctly
11 Undeterminable When postal code is empty An error occurs
12 Overall Check with April data Works without problems
Notes: Prepare test data as appropriate.
Report any defects to Miyata. Confirm any questions as needed.
Pass criteria: All items work without problems."Judged correctly / works without problems / as appropriate" は期待結果の欄に入れてはいけない語。英文のテストでは "Verify that..." の後に観測できる値が来ない文は、レビューで "Verify what, where?" と返る。
Good — 型は満たしている ／ 9行・243字
ID 対応 前提 手順 期待結果 結果
TC-05 F-3 受入れ環境で ①注文者と送り先の部屋番号が 同梱対象外となること
付録#5 注文作成可 異なる注文を作成する
②出荷指示を生成する
TC-07 F-3 同上 ①建物名の表記が異なる注文を作成 同梱対象外となること（G-02）
付録#7 ②出荷指示を生成する
TC-11 F-3 同上 ①郵便番号が空の注文を作成 同梱対象外となり、
付録#11 ②出荷指示を生成する 出荷は止まらないこと（G-07）
合格基準: 全TCの結果が期待結果と一致すること。×は宮田へ報告し、修正後に再実施する。Badから何が変わったか:
- ③事実と解釈の分離が動いた。「正しく」が「同梱対象外」「G-07」「出荷は止まらない」という仕様の言葉に置き換わった。ID・対応する機能要件・付録Aの番号が付き、どの要件のどの例を試すかが追える（29119-3 のトレーサビリティ）
- ④次の行動が少し動いた。×が付いたときは、宮田さんへ報告し再実施、と書いた
- ①結論の位置・⑤想定反論は動いていない
まだ足りないもの（ここが今日の本題）:
- 入力が値になっていない。 「建物名の表記が異なる注文」とは、何と何か。森田さんが「ハイツ青葉101」と「ハイツあおば101」で作れば、付録Aの #7 でない別のケースを試している
- 観測点がない。 「同梱対象外となること」を、どの画面のどの欄で見るか。森田さんはカードの有無で判断するしかなく、それは受入れ環境では見えない
- 前提が隠れている。 付録Aの「入れる」は F-1 の条件（初回購入など）に合う場合に限る。森田さんが購入履歴のある顧客で注文を作ると、TC-01 は「入らない」になり、×を付ける。同じ「入らない」の見え方に、2つの原因（住所／初回でない）が混ざる
- TC-07 は、森田さんから見ると「バグ」に見える。 同じ建物に見えるのに入らない。期待どおり（仕様上の既知の見逃し）だと、どこにも書いてない
- 4月分の再判定がない。 全体の確認が12例だけで、Day032 の受入れ（27,720件）が抜けた
Good
ID Trace Precondition Steps Expected result Result
TC-05 F-3 UAT environment 1. Create an order whose room Order is excluded from
App.#5 available number differs. the insert.
2. Generate shipping instructions.
TC-07 F-3 Same 1. Create an order whose building Excluded (G-02).
App.#7 notation differs.
2. Generate shipping instructions.
TC-11 F-3 Same 1. Create an order with an empty Excluded; shipment is not
App.#11 postal code. 2. Generate. held (G-07).
Pass criteria: All results match the expected results. Report failures to Miyata; retest after the fix.ID・Trace・Precondition・Steps・Expected の列は 29119-3 の項目に沿った標準形。ただし "differs" "notation" がデータでなく、"Excluded" をどこで観測するかが無い。英文では "Where would I see that?" と必ず返る。
Better — 読み手に最適化されている ／ 13行・548字
共通の前提（全ケース）: C-1 顧客 T-001〜T-012 は購入履歴0件（初回購入） C-2 同梱物 CP-TEST は
「初回購入のみ・贈り物を除く」で登録済み C-3 取込ファイルは「注文取込」画面から取り込む
TC-05 部屋番号が違う（付録A #5）
入力: TC05.csv 注文者 柏市柏1-2-3 ハイツ青葉101 送り先 柏市柏1-2-3 ハイツ青葉102 包装 なし
手順: ①「注文取込」で TC05.csv を取り込む ②「出荷指示生成」を押す ③「出荷指示一覧」で注文番号 T0005 の行を開く
期待: 「同梱」欄＝対象外 「理由」欄＝G-02 （2つとも合えば○。1つでも違えば×）
TC-07 建物名の書き方が違う（付録A #7）
入力: TC07.csv 送り先 柏市柏1-2-3 ハイツアオバ101（カタカナ）。ほかは TC-05 と同じ。注文番号 T0007
期待: 同梱＝対象外 理由＝G-02 ※同じ建物に見えるが、これで○（そろえ方の対象外。仕様上の既知の見逃し）
TC-11 郵便番号が空（付録A #11）
入力: TC11.csv 送り先の郵便番号を空にする。注文番号 T0011
期待: 同梱＝対象外 理由＝G-07 「出荷指示」欄＝生成済（「保留」でない） （3つとも合えば○）
結果欄: ○ / × / 未実施（時間切れ）。×のときは、実際に出た値を「実際の値」欄に書き写す。Goodから何が変わったか（★ここが今日の学習の中心）: 読み手プロファイルの各項目に、変更を1対1で対応させている。
| 読み手プロファイルの項目 | Betterで行った変更 |
|---|---|
| 何を判断するために読むか（森田）「何を入れて、どこを見て、何と出れば○か」 | 入力を取込ファイル名と住所の文字そのものにした。期待を画面の欄名と値（同梱＝対象外、理由＝G-02） にした。「カードが入らないこと」は、見えるものに置き換えた。複数の欄があるときは「全部合えば○」と書いた |
| 何を知らないか（森田）「なぜ書き方の違いが入らないで○なのか」 | TC-07 に1行の理由を添えた（そろえ方の対象外・仕様上の既知の見逃し）。「バグに見えるが○」を、そのケースの中で伝える |
| 何を気にしているか（森田）「変な操作をして壊すこと」 | 手順に画面名とボタン名を書き、注文番号まで指定した。共通の前提（C-1〜C-3）を1か所にまとめ、初回購入でない顧客で試す事故を消した |
| 何を気にしているか（森田）「自分の○×が稼働を止めるかもしれない」 | 結果欄に「未実施」を足し、×のときは実際の値を書き写すだけにした。原因の判断は森田さんの仕事ではない、と読める |
| 何を判断するために読むか（今井課長）「何が確かめられ、何が確かめられないか」 | まだ足りない。 12例のあとの4月分再判定、試せないこと（物理的なカード）、結果が×のときの扱いは、1ページ目にない |
まだ足りないもの:
- 4月分27,720件の再判定の期待値が、Better では決められていない。 件数の期待値（対象外2,680／対象25,040）は書けるが、再判定にはお客様の住所の複製が要る。宮田さんは複製してよいかを決められない。黙って本番データを複製すれば、規程違反の可能性がある。黙って省けば、Day032 の受入れ条件が消える
- 期待値を疑ったときの扱いが書かれていない。 森田さんが「期待が変だ」と思ったとき、○×を変えるのか、手を止めるのか。8/21〜22は宮田さんが不在
- 決まらなかったらどうなるかがない。 受入環境の渡しは 8/18、稼働は 8/28 で、途中の遅れを吸収する余白は 8/24 の判定会の1日しかない
Better
Common preconditions: C-1 Customers T-001..T-012 have no purchase history C-2 Insert CP-TEST is registered
("first purchase only, excluding gifts") C-3 Files are loaded on the "Order Import" screen
TC-05 Room number differs (App. A #5)
Input: TC05.csv. Orderer: Kashiwa 1-2-3 Heights Aoba 101. Ship-to: Kashiwa 1-2-3 Heights Aoba 102. Wrapping: none.
Steps: 1. Load TC05.csv on "Order Import". 2. Press "Generate Shipping Instructions".
3. Open the row for order no. T0005 in "Shipping Instruction List".
Expected: Insert = "Excluded" AND Reason = "G-02" (pass only if both match)
TC-07 Building spelled differently (App. A #7)
Input: TC07.csv. Ship-to building written in katakana ("ハイツアオバ101"). Order no. T0007.
Expected: Insert = "Excluded", Reason = "G-02". Looks like the same building, but this is a PASS
(outside the normalization rules; a known and accepted miss).
TC-11 Postal code empty (App. A #11)
Input: TC11.csv. Ship-to postal code empty. Order no. T0011.
Expected: Insert = "Excluded", Reason = "G-07", Instruction status = "Generated" (not "Held").
Result: Pass / Fail / Not run. On Fail, copy the actual values into "Actual".AND と pass only if both match で、複数の欄の合否を閉じている。"Pass / Fail / Not run" の3値は英文テスト記録の標準形で、Blocked（前提が整わず実施不能）を足す職場もある。今回は Not run に統合した。
Best — 読み手が意思決定できる ／ 16行・802字
8/21（月）〜22（火）の受入テストの前に、決めていただくこと（2点）と、お願い（1点）
① 長谷川さん・今井課長: 4月分27,720件の再判定に使うデータ（8/16（水）までに）
案 使うデータ 再判定で見えること 代償
P 本番4月分から判定に使う列だけ複製 実際の書き方のばらつき。想定外の書き方も お客様の住所を本番の外へ複製（規程の確認が要る）。8/25に廃棄
Q 住所を別の住所に置き換えて複製 件数と一致関係。書き方は置換が再現した分だけ 置換の検証 +2人日〔仮定〕。置換が一致関係を壊すと偽の合格
R 作り物200件＋付録12例 個人情報なし。実際の書き方は見えない 想定外の書き方を稼働後に初めて見る
推奨は P（規程上できるなら）。できなければ R で進め、再判定は稼働前日に回す。規程の確認は長谷川さん
合格: 入れない2,680（包装1,980／番地から別520／別室140／書き方22／欠け18）かつ入れる25,040
※「対象外になること」だけを見ると、全部を対象外にする誤りも合格する。入れる側も数える
② 今井課長: 期待値が変だと感じたとき（案: 承認のお願い）
実施中は○×だけ付け、期待値は変えない。変だと思ったことは「気づき」欄に。8/23（水）16:00 に今井課長・宮田・浅野さんで
「実装を直す／期待値を直す／そのまま」を決める。TC-07 のような既知の見逃しは「○」（×にしない）
③ 森田さん: 8/18（金）までに、付録の12例を紙で通し読みし、画面の名前や欄が違うところに付箋を
決まらなかったら: 8/16（水）12:00 に R で進め、4月分の再判定は 8/25（金）に回す（稼働は 8/28 のまま）
試すこと: 付録12例（TC-01〜12）／実物の箱3つ（TC-13: 梱包ラインで #1・#5・#10 のカード有無）／4月分の件数（TC-14）
試さないこと: 処理時間、法人の複数配送先、注文後の送り先変更（機能要件の対象外と同じ）Betterから何が変わったか:
- ①結論の位置 → 冒頭が「決めていただくこと」になった。 今井課長と長谷川さんは前日に最初の10行だけ読む。TC-01〜14 の表は、森田さんが読む2ページ目以降に下げた
- ②読み手適合 → データの複製を、宮田さんが黙って決めるのをやめ、情報システム部が選ぶ表にした。 列を「再判定で見えること」と「代償」にして、判断者が起きることで比べられるようにした。「複製してよいか」は技術の問いに見えるが、実際は規程と、想定外の書き方を稼働前に見つけるか、後に見つけるかの問いである
- ③事実と解釈の分離 → 合格の条件を件数の内訳で書いた。 2,680 の内訳（1,980／520／140／22／18）が合って初めて、システムの出力が期待値と言える。期待値はシステムの出力でなく、人が先に数えたもの
- ④次の行動 → 誰が・いつまでに・何をを3点で確定し、決まらなかった場合の既定を日付で決めた。 8/16 12:00 に R。再判定は 8/25 に回すが、稼働は動かさない
- ⑤想定反論 → 「P で十分では」「全部対象外にすれば合格では」に、①の表と合格の1行で先回りした。 後者は、片側しか数えない試験は、片側を壊す誤りに気づけないことを、そのまま見える形にした
- 削ったもの: TC-01〜12 の入力・手順・期待の詳細、共通の前提、画面の見方は2ページ目以降へ下げた。Better のケース3件の説明は、表の行に圧縮した
なぜ黙って決めず、決めさせたのか — 宮田さんが迷った点: 宮田さんは最初、P で出すつもりだった。「現場データで見るのが一番確かだ」と思ったからである。しかし、お客様の住所を本番の外へ複製するのは、MOps の権限でできることではない。黙って P で進めて後で規程違反と分かれば、再判定の結果ごと使えなくなる。 逆に R を黙って選べば、Day032 の受入れ条件（4月分の再判定）が、誰にも知られず消える。宮田さんが決めたのは、どちらを選んでも結果が出る形に、期待値を内訳つきで書いておくことである。
反証条件（この文書の形が変わる場合）:
- 8/8 の手計算（38件が一致になる）が、実システムで再現しなかったら、期待値の内訳は変わる。6/6 の抽出から数え直し、TC-14 の期待値を作り直す。だから TC-14 の期待値は、実施の前日（8/18）に、実装後のシステムではなく人が当てはめた結果で確定する
- 森田さんが TC-01〜12 の途中で「画面が違う」と言ったら、仕様書の側を直す。 手順は、実施者が迷う箇所の記録を最優先とする
今回はBestまで作るべきか: Best必要。 期待値の出どころがお客様の住所で、複製の可否が書き手の権限を超え、さらに合格の条件が片側だけだった。逆に、ラベルの文言を変えるだけの画面の改修なら Better で十分。選択肢の表と、決まらなかったときの動きは、書き手が決められない前提があるときにだけ効く。
Best
Decisions requested before the UAT on Aug 21-22 (Mon-Tue): two, plus one request
1. Mr. Hasegawa / Mr. Imai: data for the April re-run of 27,720 orders (by Aug 16)
Option Data What the re-run shows Cost
P Copy only judgment columns from April Real-world notation variety, incl. cases Customer addresses leave production
production data we did not predict (policy check needed); delete Aug 25
Q Copy with addresses replaced Counts and match relations; notation +2 person-days [assumption]; a wrong
only as far as the replacement keeps it replacement gives a false pass
R 200 synthetic orders + the 12 examples No personal data; no real-world variety Unpredicted notations are first seen after go-live
We recommend P if policy allows (Mr. Hasegawa to confirm); otherwise R, with the re-run moved to Aug 25.
Pass: "no insert" = 2,680 (wrapped 1,980 / street 520 / other room 140 / notation 22 / missing 18)
AND "insert" = 25,040. Counting only "excluded" would also pass a bug that excludes everything.
2. Mr. Imai: if the tester doubts an expected value (approval requested)
Testers mark Pass/Fail only and never change expected values. Doubts go in "Observations".
On Aug 23 (Wed) 16:00, Imai, Miyata and Asano decide: fix the code / fix the expected value / leave.
Known accepted misses such as TC-07 are marked Pass, never Fail.
3. Ms. Morita: by Aug 18 (Fri), read the 12 examples on paper and flag screen or field names that differ.
If undecided: on Aug 16 (Wed) noon we proceed with R and move the re-run to Aug 25. Go-live stays Aug 28.
In scope: 12 examples (TC-01..12); 3 physical boxes (TC-13: #1, #5, #10); April counts (TC-14).
Out of scope: processing time, corporate multi-address, ship-to changes after ordering."Decisions requested" から始め、案の表に "We recommend P if policy allows" と条件つきの推奨を添えるのが、英文の意思決定文書の型。"Pass:" の行で期待値の内訳を示し、"Counting only..." で片側試験の欠点を理由として書いている。
日英差分ノート
1. 「確認すること」と "Expected result" — 動詞か、値か
日本語のテスト項目書は「〜を確認する」「〜であること」と動詞や状態で終わることが多く、確認する中身が書き手の頭にだけある。英語の表は Expected result の列が独立し、"Verify that..." と書くと、値が来ないことがレビューで必ず指摘される。日本語でも「欄A＝値X」の形に直すと、英語に訳したとき欄が埋まるかで確かめられる。
2. ○×と Pass / Fail / Blocked
日本語の○×は2値で、「実施できなかった」が書けず、空欄になる。英語は Pass / Fail / Blocked / Not run のように、実施できなかった理由も記録の対象にする。今回は森田さん向けに3値（○・×・未実施）にとどめ、△は作らなかった。△があると判定会で「△は合格か」の議論になる。
3. 「既知の見逃し」と "known limitation / accepted miss"
日本語では「仕様どおり」「既知」と口頭で済ませやすく、誰が受け入れたかが残らない。英語の受入れ文書は accepted by (who, when) を添える。TC-07 の理由は、本来 Day032 で今井課長が Q を選んだ記録に結びつく。
4. 「気づき」と "observation" / "defect"
日本語の「不具合」は、期待値との違いも仕様への疑問も1語にまとめる。英語は defect（コードの誤り）・observation（気づき）・change request（変更要望） を分ける。今回の「気づき欄」はこの observation で、判定会で3つに振り分ける。
頻出表現
| 日本語 | English | トーンの強さ |
|---|---|---|
| 期待結果 | Expected result | 中立・合否の基準 |
| 事前条件／前提 | Precondition | 中立・29119-3 の項目名 |
| 合格／不合格 | Pass / Fail | 中立・2値 |
| 実施できず | Blocked / Not run | 中立・理由を残す |
| 〜であること（確認） | Verify that <欄> = <値> | 強い・観測できる形にして使う |
| 既知の見逃し | Known and accepted limitation | 中立・誰が受け入れたかを添える |
| 気づき | Observation | 弱い・判定会で振り分ける |
| 決まらなければ〜で進める | If undecided, we will proceed with ... | 中立・既定動作 |
差分5軸まとめ
| 軸 | Bad | Good | Better | Best |
|---|---|---|---|---|
| ① 結論の位置 | ない（「問題ないこと」が合格基準） | 表の最後の「合格基準」 | 共通の前提とケースが先頭 | 「決めていただくこと」が冒頭。ケース表は後ろ |
| ② 読み手適合 | 想定していない（各自適当に） | ID・前提・手順・期待の型（QAには通じる） | 森田さん向け（画面名・欄名・値・注文番号） | 森田さんはケース表を、今井課長・長谷川さんは冒頭の表を。期待値の内訳は両方が使う |
| ③ 事実と解釈の分離 | 「正しく」「問題なく」（解釈が期待値に混じる） | 期待値は仕様の言葉。観測点と入力が無い | 欄＝値で書く。既知の見逃しに理由を1行 | 期待値は人が先に数えた内訳（2,680／25,040）。システムの出力を正解にしない。〔仮定〕に印 |
| ④ 次の行動 | 「随時確認」 | ×は宮田へ報告 | ×は実際の値を書き写す | 誰が・いつまでに（8/16・8/18・8/23）。決まらなければ既定（R、再判定は8/25） |
| ⑤ 想定反論 | 無視 | 触れない（観測点・前提・既知の見逃し） | 既知の見逃しを理由つきで。データの複製には黙っている | 「P で十分」「対象外だけ数えれば」に表と1行で先回り。反証条件を書く |
Best版・全文
日本語版 全文を見る
倉庫システム改修 受入テスト仕様書（第1版）— 同梱物の対象判定
2028年8月9日 ノヴァストア EC事業本部 販促システム部 MOps 宮田
宛先: 柏物流センター 森田様（実施）／今井課長（判定） 写し: ミナトソフト 浅野様、情報システム部 長谷川
対応する文書: 機能要件定義書 第1版（6/9）、テスト計画書（Day016 の考え方）
━━ 1ページ目 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
8/21（月）〜22（火）の受入テストの前に、決めていただくこと（2点）と、お願い（1点）
① 長谷川さん・今井課長: 4月分27,720件の再判定に使うデータ（8/16（水）までに）
案 使うデータ 再判定で見えること 代償
P 本番の4月分から、判定に使う列だけ 実際の書き方のばらつき。 お客様の住所を本番の外へ複製する
（注文番号・住所6項目×2・包装のし） 想定外の書き方も見つかる （規程の確認が要る）。8/25に廃棄
を複製
Q 住所を、別の住所に置き換えて複製 件数と、住所が同じ／違うの関係。 置換の検証 +2人日〔仮定〕。
書き方は、置換が再現した分だけ 置換が一致関係を壊すと「偽の合格」
R 作り物の200件＋付録の12例 個人情報を使わない。 想定外の書き方を、稼働後に初めて見る
実際の書き方は見えない
推奨は P（規程上できるなら。規程の確認は長谷川さん）。できなければ R で進め、再判定を8/25に回す。
合格: 「入れない」2,680件（包装・のし1,980／番地から別520／別の部屋140／書き方の違い22／項目欠け18）
かつ「入れる」25,040件。内訳が合うこと
※「対象外になること」だけを見ると、全部を対象外にする誤りも合格してしまう。入れる側も数える
※期待値の内訳は、宮田が6/6の抽出と付録の規則を人手で当てはめて作った（システムの出力ではない）。
書き方の違い60件のうち38件はそろえ方で「一致」になり、22件が不一致のまま〔仮定: 8/8 手計算〕
② 今井課長: 期待値が変だと感じたときの扱い（承認のお願い）
実施中は ○×だけ付け、期待値は変えない。変だと思ったことは「気づき」欄に書く。
8/23（水）16:00 に今井課長・宮田・浅野さんで、気づきを 「実装を直す／期待値を直す／そのまま」に振り分ける。
TC-07 のような「既知の見逃し」は ○（×にしない）。実施中に宮田は不在のため、迷ったら ○×を付けず「未実施」にして先へ
③ 森田さん: 8/18（金）までに、付録の12例を紙で通し読みして、画面の名前や欄が違う所に付箋を貼ってください
（8/18 の環境引き渡しの際に、画面と見比べます）
決まらなかったら: 8/16（水）12:00 に R で進め、4月分の再判定は 8/25（金）に回します。稼働（8/28）は動かしません。
試すこと: 付録の12例（TC-01〜12）／実物の箱3つ（TC-13: 梱包ラインで #1・#5・#10 のカード有無）／4月分の件数（TC-14）
試さないこと: 処理時間、法人の複数配送先、注文後の送り先変更（機能要件の対象外と同じ）
━━ 2ページ目: 森田さんへ（実施の決まり）━━━━━━━━━━━━━━━━
迷ったときの3つの決まり
1. ○か×かは、「期待」の欄の値と、画面の値が同じかどうかだけで決める。「おかしい」と思っても、値が同じなら ○
2. 期待と違う値が出たら ×。「実際の値」欄に、画面の値をそのまま書き写す（原因を考えなくてよい）
3. 画面が違う、ボタンがない、進めない → 「未実施」にして、理由を1行書き、次へ
共通の前提（全ケース）
C-1 顧客 T-001〜T-012 は購入履歴0件（初回購入）。C-2 同梱物 CP-TEST は「初回購入のみ・贈り物を除く」で登録済み
C-3 取込ファイル（TC01.csv〜TC12.csv）は、「注文取込」画面から取り込む（別の住所を自分で入力しない）
手順（TC-01〜12 共通）: ①「注文取込」で TCxx.csv を取り込む ②「出荷指示生成」を押す
③「出荷指示一覧」で注文番号 T00xx の行を開き、「同梱」欄と「理由」欄を見る（2つとも合って ○）
━━ 3ページ目: テストケース ━━━━━━━━━━━━━━━━━━━━━━━━━━━
ID 付録A 内容 期待（同梱 / 理由） 備考
TC-01 #1 送り先が全く同じ文字 対象 / -
TC-02 #2 全角の数字とハイフン 対象 / -
TC-03 #3 「1丁目2番3号」の書き方 対象 / -
TC-04 #4 部屋が「101号室」 対象 / -
TC-05 #5 部屋番号が違う（101と102） 対象外 / G-02
TC-06 #6 番地が違う（1-2-3と1-2-4） 対象外 / G-01
TC-07 #7 建物名がカタカナ（ハイツアオバ） 対象外 / G-02 同じ建物に見えるが ○（既知の見逃し・今井課長が Q で受入れ）
TC-08 #8 戸建て（建物・部屋とも空） 対象 / -
TC-09 #9 送り先の建物・部屋が空 対象外 / G-02
TC-10 #10 包装あり 対象外 / G-03
TC-11 #11 郵便番号が空 対象外 / G-07 「出荷指示」欄＝生成済（保留でない）
TC-12 #12 郵便番号277-0005と都道府県が大阪府 対象外 / G-07
TC-13 実物 #1・#5・#10 の3件を、梱包ラインに流し、箱にカードが入るか見る
#1 → 入る／#5 → 入らない／#10 → 入らない（森田さんが箱を開けて見る）
TC-14 件数 4月分の再判定（①の案で用意）。結果の画面の件数が、
「入れない」2,680（1,980／520／140／22／18）かつ「入れる」25,040と同じ → ○
内訳が1つでも違えば × にして、画面の数字をそのまま書き写す（原因は後で宮田・浅野さんが調べる）
結果欄（1ケースごと）: ○ / × / 未実施 実際の値: 気づき: 実施日・時刻: 実施者:
━━ 付録: 期待値の元 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
付録A（住所の12例）と そろえ方 N-1〜N-4・理由コードは 機能要件定義書（6/9）と同じ。
TC-14 の内訳の出所: 6/6 長谷川さん抽出（720・18）、包装・のし1,980（宮田が4月の受注から数えた〔仮定〕）、
書き方の違いの38/22 は 宮田が8/8に N-1〜N-4 を1件ずつ当てはめた結果。8/18 に、実装後の確認とは別に人が再確認して確定する
扱わないこと
・処理時間、法人の複数配送先、注文後の送り先変更の再判定（機能要件と同じ）
・カタカナと漢字の同一視（見逃しとして受け入れる。22件/月の見込み。稼働後の実績で見直す）English 全文を見る
Warehouse system change - Acceptance Test Specification v1: eligibility for inserts
August 9, 2028 MOps (Miyata), Marketing Systems, Nova Store
To: Ms. Morita, Kashiwa Logistics Center (tester) / Mr. Imai (decision) Cc: Mr. Asano (Minato Soft), Mr. Hasegawa (IS)
Based on: Functional Requirements v1 (June 9)
== Page 1 ==
Decisions requested before the UAT on Aug 21-22 (Mon-Tue): two, plus one request
1. Mr. Hasegawa / Mr. Imai: data for the April re-run of 27,720 orders (by Aug 16, Wed)
Option Data What the re-run shows Cost
P Copy only judgment columns (order no., Real-world notation variety, including Customer addresses leave production
6 address fields x2, wrapping) from cases we did not predict (policy check needed); delete Aug 25
April production data
Q Copy with addresses replaced Counts and same/different relations; +2 person-days [assumption]; a wrong
notation only as far as the replacement replacement produces a false pass
preserves it
R 200 synthetic orders + the 12 examples No personal data; no real-world variety Unpredicted notations are first seen after go-live
We recommend P if policy allows (Mr. Hasegawa to confirm); otherwise R, with the re-run moved to Aug 25.
Pass: "no insert" = 2,680 (wrapped 1,980 / street number 520 / other room 140 / notation 22 / missing 18)
AND "insert" = 25,040. Counting only "excluded" would also pass a bug that excludes everything.
Note: expected counts were derived by hand by Miyata (June 6 extract + Appendix rules), not from system output.
Of the 60 notation-only cases, 38 become "match" after normalization and 22 stay "mismatch" [assumption: Aug 8 manual check].
2. Mr. Imai: if the tester doubts an expected value (approval requested)
Testers mark Pass/Fail only and never change expected values. Doubts go in "Observations".
On Aug 23 (Wed) 16:00, Imai, Miyata and Asano sort each observation: fix the code / fix the expected value / leave as is.
Known accepted misses such as TC-07 are marked Pass, not Fail. Miyata is absent during the UAT:
if in doubt, leave the case "Not run" and move on.
3. Ms. Morita: by Aug 18 (Fri), please read the 12 examples on paper and put a sticky note wherever a screen or field name
differs. We will compare against the screen at the Aug 18 handover.
If undecided: on Aug 16 (Wed) noon we proceed with R and move the re-run to Aug 25 (Fri). Go-live stays Aug 28.
In scope: 12 examples (TC-01..12); 3 physical boxes (TC-13: #1, #5, #10); April counts (TC-14).
Out of scope: processing time, corporate multi-address, re-evaluation after ship-to change (same as the functional requirements).
== Page 2: for Ms. Morita ==
Three rules when in doubt
1. Mark Pass or Fail only by whether the screen value equals the "Expected" value. If it looks wrong but the values match, it is a Pass.
2. If the value differs: Fail. Copy the screen value into "Actual". You do not need to find the cause.
3. If a screen is different, a button is missing, or you cannot proceed: mark "Not run", write one line why, and go on.
Common preconditions: C-1 Customers T-001..T-012 have no purchase history. C-2 Insert CP-TEST is registered
("first purchase only, excluding gifts"). C-3 Load TC01.csv..TC12.csv on "Order Import"; do not type other addresses.
Steps (TC-01..12): 1. Load TCxx.csv on "Order Import". 2. Press "Generate Shipping Instructions".
3. Open the row for order no. T00xx in "Shipping Instruction List" and read "Insert" and "Reason" (Pass only if both match).
== Page 3: test cases ==
ID App.A Content Expected (Insert / Reason) Note
TC-01 #1 Identical ship-to Insert / -
TC-02 #2 Full-width digits and hyphens Insert / -
TC-03 #3 "1-chome 2-ban 3-go" notation Insert / -
TC-04 #4 Room written "101-goshitsu" Insert / -
TC-05 #5 Room differs (101 vs 102) Excluded / G-02
TC-06 #6 Street number differs (1-2-3 vs 1-2-4) Excluded / G-01
TC-07 #7 Building in katakana Excluded / G-02 Looks like the same building, but Pass (known and accepted miss; Mr. Imai chose Q)
TC-08 #8 House (building and room both empty) Insert / -
TC-09 #9 Ship-to building/room empty Excluded / G-02
TC-10 #10 Wrapping selected Excluded / G-03
TC-11 #11 Postal code empty Excluded / G-07 Instruction status = "Generated" (not "Held")
TC-12 #12 Postal 277-0005 with prefecture Osaka Excluded / G-07
TC-13 Box Send #1, #5 and #10 through the packing line; open the boxes. #1 card in / #5 no card / #10 no card
TC-14 Counts April re-run (data per decision 1). Pass if the screen shows "no insert" 2,680 (1,980 / 520 / 140 / 22 / 18)
AND "insert" 25,040. Fail if any figure differs; copy the screen figures (Miyata and Asano investigate later).
Result per case: Pass / Fail / Not run. Actual: Observation: Date/time: Tester:
== Basis of the expected values ==
Appendix A (12 examples), N-1..N-4 and reason codes: same as Functional Requirements v1 (June 9).
TC-14 breakdown: Hasegawa's June 6 extract (720, 18); wrapped 1,980 counted by Miyata from April orders [assumption];
38/22 from Miyata's hand application of N-1..N-4 on Aug 8. To be re-confirmed by a person on Aug 18, separately
from the post-implementation check.
Out of scope: processing time; corporate multi-address; re-evaluation after ship-to change; katakana/kanji equivalence
(accepted as a miss; about 22/month expected; to be reviewed with post-launch actuals).完成の定義チェックリスト
テスト仕様書を出す前に必ず確認する。「雑・妥協」を防ぐための外部基準。1つでも未チェックがあれば、まだ出さない。
今日の演習
15分版（まずこれだけでもやる）
Bad の「No.3 判定不能: 郵便番号が空の場合 → エラーになること」の1行だけを、3〜4行のテストケースに書き直す。
手順:
- 曖昧語に線を引く: 「空の場合」（どの項目が、どう空か）、「エラーになること」（どこに、何と出るのか）
- 入力を値にする: 取込ファイル名と、郵便番号以外の項目に入れる文字
- 期待を「欄名＝値」の形で、観測できるものだけ書く。Day032 の F-3 を見て、エラー画面が出ないことに気づく。出荷は止まるのか流れるのかも値で書く
欄名＝値の形で書けたら、今日の目的は達成。書けたら Best の TC-11 と見比べる。余裕があれば、書いたケースに「バグに見えるが仕様どおり」の例を1つ足してみる。
60分版
同じ受入テスト仕様書を、「森田さん」でなく、3か月後にこの機能を稼働後に変更する担当者（情報システム部の新人）向けの回帰テスト一覧に書き直す。 読むのは、次の同梱物の追加や住所の規則の変更のとき。
設定（自分の題材がない場合）: 稼働後に、カナと漢字の同一視（22件/月の見逃しの対処）を追加することになった。変更が他に影響しないかを、毎回同じ手順で確かめたい。
守る条件:
- 追加する規則の影響を受けるケース（TC-07 は期待が変わる）と、変わってはいけないケース（TC-05, 06 など）を、仕様書の中で分ける
- 期待値の変更の記録欄を作る（誰が・いつ・なぜ変えたか）。TC-07 の期待値が「対象外」から「対象」に変わるとき、旧い期待値を消さずに残す
- 実施の自動化を前提にして、期待値をファイルにできる形（欄名＝値）にする。ただし、自動化の方法はこの回では決めない
- 手順は、森田さん向けの画面操作を省く。代わりに、入力ファイルの置き場所だけを書く
取り組む前のヒント
考える順序
- 同じケースでも、実施する人（森田さん）と変更を守る人（新人）では要る粒度が違う。森田さんには「どの画面のどのボタン」、新人には「どの規則を変えたら、どのケースが影響を受けるか」。まず、Best のどの行が新人に要らないかに線を引く
- 期待値の出どころを、ケースごとに1語で付ける（仕様 §F-3／今井課長の判断／手計算）。出どころが分かれば、規則を変えたときどの期待値を見直すかが決まる
- 「変更で期待が変わるケース」を先に列挙すると、残りが「変わってはいけない」になる
陥りやすい罠
- 回帰テストを「全ケースをもう一度」と書く。影響範囲を決めないと、毎回全件か、毎回ゼロかのどちらかになる
- 期待値を上書きして、旧い値を消す。なぜ変わったかが、次の変更で分からなくなる
チェックすべき観点 書き上げたら「規則を1つ追加したとき、どのケースを見直すかが、仕様書を見ただけで3分以内に決められるか」を確かめる。
実務での使いどころ
テスト仕様書は、機能要件（何をするか）と、テスト報告書（結果が何を意味するか）のあいだにある文書である。受託開発では受入れの合否そのものを決める根拠になり、ここの曖昧さはそのまま「合格した／していない」の争いになる。2026年現在、LLM はテストケースの案を大量に出すことを速くした。だからこそ、期待値の出どころがシステム自身の出力になっていないか、片側しか見ていないかが最も危うい。自動で出ないのは、今日の Good→Best の部分 —— 実施者が見える場所で期待値を書き直し、書き手に決められない前提（データの複製）を判断者の表にし、人が先に数えた内訳で合否を決めることである。
隣接する文書との関係:
- 前: 機能要件定義書（Day032: 付録Aの12例が入口）、テスト計画書（Day016: 何を試し、何を試さないか）
- 後: テスト報告書（カテゴリ16の3本目: 今日のTC-01〜14の結果を、8/24の判定材料にする）、バグ票（4本目: ×の再現手順）、リリース計画書（5本目: 8/28の稼働と切り戻し）
- 横: 非機能要件定義書（処理時間は今日の対象外）、ADR（住所の正規化を自作するか既製か。22件の見逃しの対処）
この回の設計メモ（迷った他案・扱わなかった範囲・出所）
題材の選び方で迷ったこと
- Day032 の付録A（住所12例）を入口にして、同じ題材の続きにした。Day016（テスト計画書）が「試すこと」を決め、今日は「1件ずつの入力と期待値」に下ろす関係。他案の「画面の文言変更のテスト仕様」は期待値が自明で、観測点や期待値の出どころを学ぶ素材にならないため見送った
- 読み手を「QA の石井さん（Day010）」にする案もあったが、石井さんは Day016 の場にいて仕様書の型に慣れている。カタログの主な読み手（テスター）と Lv2 が一致するように、システムの言葉を読まない現場のテスター（森田さん）にした。ルール5は要らない
- Day032 の数字との食い違い（60件→22件、「720件すべて対象外」）をあえて取り上げた。テスト仕様を書く作業が仕様のレビューになる、という実務の性質を見せるため。ただし 38/22、1,980 はこの回の設定で、Day032 の本文は直していない
Best の形で迷ったこと
- 「複製のデータ」を宮田さんが黙って選ぶ案（Better のまま）と、情報システム部が選ぶ表にする案で迷い、後者にした。複製の可否は MOps の権限を超え、後から取り消せないため。法的な判断はしていない（この回は書き方の練習であり、法的助言ではない）。規程の確認は長谷川さんの仕事として本文に残した
- 期待値を疑ったときの扱いは、①のような表にせず、1行の承認のお願いにした。選択肢が実質1つ（実施中は変えず、判定会で決める）で、△を作る案は判定会で「△は合格か」の議論になるため採らなかった
- 推奨を「P（規程上できるなら）」と条件つきにした。無条件の推奨は、確認できていない規程を前提にすることになる
- TC は14件にした。付録12例を1対1で対応させる、実物の確認は3件にとどめる（受入環境でカードが見えない代理として）、件数は1件。最適な件数を測ってはいない
数字の出所
- 〔実測〕とした値（4月初回購入27,720件、720件、18件）は、Day032 と同じシナリオ内の設定で、現実のデータではない
- 〔仮定〕: 包装・のし1,980件、38件／22件（8/8の手計算）、Q の検証 +2人日、各ステップの日付（受入環境の引き渡し8/18、受入テスト8/21〜22、判定会8/24）、5つの内訳が重ならないこと
- 〔導出〕: 2,680 = 1,980+520+140+22+18、25,040 = 27,720−2,680（実際に計算して確認）、682 = 720−38、520+140+22 = 682、22 = 60−38。曜日（8/9水・8/16水・8/18金・8/21月・8/23水・8/25金・8/28月）は暦で確認
出典の深さ
- ISO/IEC/IEEE 29119-3 の 8.3.3（識別子・目的・優先度・トレーサビリティ・事前条件・入力・期待結果）: AS/NZS 版の目次を見た検索結果の要約で確認（2026-10-18。規格本文は有償で未読）。https://store.standards.org.au/product/as-nzs-iso-iec-ieee-29119-3-2022
- テストオラクルと期待結果の関係を規格が何と書くかは確認できなかった（検索結果に出なかった）。「システムの出力を期待値にしてはいけない」は、一般に知られたテストオラクルの考え方（記憶による）で、規格の引用ではない。ISTQB 用語集は未取得
- 「Blocked / Not run」の状態名、defect / observation の区別、個人情報の複製・マスキングの実務は記憶による。出典ページは確認していない
- 分量（実測、スクリプトで数えた）: JA Bad10・Good9・Better13・Best16行、字数（空白除く）Bad201・Good243・Better548・Best802字（EN 10・10・15・19行）。Best が最長（行・字数とも）で、逆転ではない。 Good が Bad より1行短いのは、表にして1行に詰めたため。期待値の欄・出どころ・選択肢の表が Best で初めてそろう。次の逆転候補: Runbook（itops#2）
扱わなかった範囲
- 自動テスト化（突合のスクリプト、CI での回帰）。60分版で期待値の形だけ触れ、方法は扱わない
- テストデータ管理・マスキングの技術と、個人情報の取扱いの法的な論点。今日は「判断者の表にする」までで、規程の中身は扱わない
- 負荷・性能・探索的テスト。機能要件が処理時間を持たないため
- 12例以外の住所の書き方の網羅。今日扱ったのは、付録Aの範囲と、再判定で見つかる想定外の書き方への備え。網羅度は測っていない
AI臭さ検査（努力の痕跡4軸）: ①トレードオフ=P/Q/R案と代償、期待値を疑ったときの△案を採らなかった理由、黙って P を選ぶ Better の問題 ②ドメインへの接地=29119-3 の項目（目次まで確認、本文とテストオラクルは未読と明記）③測った証拠=〔実測〕〔仮定〕〔導出〕ラベルと、件数の計算を実際に確かめた記録 ④止め方=扱わなかった範囲。「同じ指示を AI に出せば数時間で出るか」→ ケース表の型は出る。出ないのは、前の回の受入れ条件が片側だけで、書き直した数字（60→22、720→682）が成り立たないと気づくこと、書き手に決められない前提（データの複製）を判断者の表にすること。世界の実物との比較: テスト仕様の中核概念（識別子・目的・優先度・トレーサビリティ・事前条件・入力・期待結果・事後条件・環境）のうち、今日扱ったのは識別子・トレーサビリティ・事前条件・入力・期待結果の5つ。優先度・目的・事後条件・環境・同値分割/境界値などの設計技法は扱っていない。
何が起きているか:
これは怠慢ではなく、「テストは現場が一番よく分かっている。細かい操作は任せよう」という信頼から生まれる形である。しかし現場が知っているのは梱包であり、この機能の期待値ではない。任せた結果、森田さんは「迷ったら×」か「迷ったら○」のどちらかに倒れ、判定会で数字が信用されなくなる。