テストケースに手順は書くべきか？QAが渡すのは行為ではなく情報

テストケースに、具体的な手順は書くべきなのでしょうか。結論から書くと、書くか書かないかは本質ではありません。手順は事前の指示としては不要で、事後の記録としては必須です。そして本当の問題は書式ではなく、QAが何を成果物として組織に渡しているのかにあります。

ステップを1行ずつ書くか、要点だけ書くか、テンプレートをどうするか。この問いは書式の問題に見えますが、追っていくと、手順の粒度ではなく、その手順書が組織の中で何を担わされているかに行き着きます。

そして、手順書をめぐって現場で起きていることの多くは、テストの技法が未熟だからではなく、責任の単位を取り違えたことから来ているのではないか、というのがこの記事の主張です。

この記事では、テストケースの書き方から出発して、QAが引き受けるべきものは「行為」ではなく「情報」である、という結論まで、途中の反論も含めてすべて書きます。結論だけでなく、この主張がどこで崩れうるか（反証条件）も明示します。

1. はじめに：これは、誰かのやり方を否定する話ではありません

本題に入る前に、この記事の立ち位置をはっきりさせておきます。ここを飛ばすと、以降の内容が「現場のQAへの批判」に読めてしまうからです。

1-1. この記事が問うているのは、人ではなく責任の置き場所です

この記事は、手順書を書いているQAエンジニアや、テストケースを積み上げている現場を批判するものではありません。私自身、手順を1ステップずつ書いたテストケースを大量に作ってきましたし、それが必要な場面があることも知っています。

問題にしているのは、個人の仕事の質ではなく、QAの成果物が組織のどこに置かれているかという構造です。同じ人が同じ精度で仕事をしても、成果物の置き場所が違えば、組織に渡る情報の量はまったく変わります。これは技量の話ではなく、設計の話です。

1-2. これは「QA自身が困らないため」の考え方です

もう一点、誤解されやすいので先に書いておきます。この記事の主張は、QAに新しい負担を課すためのものではありません。むしろ逆です。

「全件パスしました」と報告して、その後に障害が出たとき、いちばん苦しい立場に置かれるのはQAです。報告した内容に嘘はないのに、結果として「テストは何をしていたのか」と問われる。この非対称は、QAが自分の仕事を「実施したこと」で定義してしまったところから生まれます。

QAの価値をどこに置けば、この非対称が解消されるのか。そう考えた結果として出てきた、ひとつの考え方です。誰かのやり方が間違っているという話ではなく、QA自身が守られる形はどれか、という話だと受け取ってください。

2. 出発点：テストケースに、具体的な手順は書くべきか

冒頭に書いた答えを、順に確かめていきます。手順そのものが悪いのではありません。問題は、その手順書が置かれている場所にあります。

2-1. 実際のユーザーは、手順書に書かれた経路だけを通らない

まず前提として、実際のユーザーは、私たちが手順書に書いた経路だけを通るわけではありません。同じゴールに到達するのに、別の画面から入り、別の順番で操作し、途中で戻り、別のデバイスで続けます。

だとすれば、テストが確認すべきなのは、多少手順が違っても期待結果が同じになることのほうです。ここまでは、おそらく多くの人が同意すると思います。

2-2. それでも「手順を書くな」という結論は出てきません

ただし、ここから「だから手順を書くな」は出てきません。ここが最初のつまずきどころです。

期待結果Xに至る経路がA・B・Cとあり、そのすべてでXが成り立つと言いたいなら、それは手順を3本書くということになります。記述量はむしろ増えます。「手順を書かない」という方向に進むと、経路の情報そのものが失われてしまう。

2-3. 手順書が、2つの役割を同時に背負っている

問題は手順の存在ではありません。手順書が「何を確認するか」と「どう操作するか」を同時に背負っていることです。

この2つは、本来別のものが持つべきです。

• 「何を確認するか」は、期待結果が持つ
• 「どう操作したか」は、実行の記録が持つ

そう分けると、指示としての手順は不要になり、記録としての手順は必須になります。言い換えると、手順は事前に書くものではなく、事後に残るものです。

この切り分けをしないまま手順だけを消すと、状況は悪化します。落ちたときにどの経路で落ちたのか分からなくなり、通ったときにリスクの高い経路を実際に通ったのかも保証できなくなる。手順は消すのではなく、置く場所を変える。それが最初の一歩です。

3. 手順を固定して回す運用が持つ、原理的な欠陥

手順を固定した運用には、非効率とは別種の、構造的な欠陥があります。それは「確認していないこと自体が、報告に出てこない」という点です。

3-1. 確認していないこと自体が、報告に出てこない

ABCの3経路を確認する運用を考えます。実際にはDという経路も存在するのですが、設計時に誰も思いつかなかった。このとき何が起きるか。

Dは確認されないだけではありません。確認されていないこと自体が、報告に出てこないのです。結果は「全件パス」と表示されます。報告書を読んだ人には、Dという経路が存在することも、それが未確認であることも伝わりません。

3-2. 設計時の想像力が上限になり、その上限が動かない

固定ケースが持っている性質は、「同じ経路を繰り返し確認できる」ことだけです。そしてこれは、過去に一度でも誰かが思いついた範囲の再確認でしかありません。

つまり、設計時の想像力が上限になっていて、その上限が時間とともに動かない。リグレッションを何度回しても、Dはそこから出てきません。

ここで、経路を固定しないことの意味がはっきりします。それは網羅率が上がることではなく、上限が動くことです。実行のたびに違う経路を通るなら、設計時に存在を知らなかった経路が、時間の経過とともに拾われます。ただし拾えるのは通った経路までで、そこで起きた異常に気づけるかどうかは、期待結果をどこまで書いてあるかによります。

• 固定ケース ＝ 既知の経路を守る仕組み
• 経路を振る ＝ 未知の経路を既知に変える仕組み

そして前者は、後者の副産物として得られます。重大な経路が見つかったら固定すればいい。ですが逆はできません。固定ケースをいくら積んでも、未知の経路は出てきません。

3-3. 固定ケースの役割は「網」ではなく「留め具」

ここで、固定ケースの役割が変わります。事前に用意する網ではなく、見つかったものを掴んで離さないための留め具になります。設計工程の成果物ではなく、実行の副産物として増えていくものです。

これは私だけの見立てではありません。不具合分析について書かれた記事の中に、次のような指摘があります。

本番障害の再発防止策が「テストが漏れたテストケースをリグレッションテストに追加して毎回確認します」となる場面を何度か見かけます。しかしながら、上記の再発防止策では欠陥流出原因（テスト漏れ）の根本原因を解決していないため、別の機能における改修で同じ原因によるテスト漏れが発生する可能性が高いです。
（かわちーばーのブログ「不具合分析（テスト漏れ・欠陥流出原因の分析）のやり方、私の場合」2021年8月10日）

ここで指摘されている現象は、まさに「留め具を増やしているだけ」の状態です。見つかったDを固定ケースに追加しても、まだ見つかっていないE・F・Gについては何も変わらない。留め具として使う分には正しいのですが、それを再発防止策と呼んでしまうと、上限が動かないままになります。

4. リグレッションが確認しているのは、経路ではなく期待結果

「経路を固定しないと、前回と比較できなくなるのではないか」という懸念は当然出ます。ですがこれは、リグレッションの目的を取り違えています。

4-1. 前回と比較できなくなるのではないか

今週はA・B・CでOK、来週はA・B・DでOK。これでは、Cが壊れていても分からないのではないか。もっともな指摘です。

ですが、リグレッションが確認しているのは期待結果の同一性であって、経路の同一性ではありません。前回成り立っていた期待結果が、今も成り立つか。問われているのはそこです。

それが確認できるなら、経路は同じである必要はありません。むしろ違う経路で成り立つほうが、確認できたことの範囲は広い。「Aという経路でXが成り立つ」より「A・B・DのいずれでもXが成り立つ」のほうが、強い主張です。

経路の固定は、実装上の都合でしかありませんでした。手動で回すなら手順を固定したほうが安い、というだけの理由です。工数の制約が外れれば、固定する理由そのものが消えます。

4-2. 切り分けの問題も、経路の固定とは無関係です

同じことは切り分けにも言えます。「Dで落ちた。これは環境要因か、バグか」という問いは、経路が固定かどうかと無関係です。

環境要因ならABCでも同じことが起きますし、環境要因でないなら「Aが今まで通っていたのに急に落ちた」と同じ現象になります。落ちた後の処理として、新規経路を特別扱いする理由はありません。

5. 手順書を成果物にしたのは、制約ではなく選択でした

前章で、経路の固定は工数制約による実装上の都合だと書きました。ただし制約で説明できるのは、そこまでです。

5-1. 「工数の制約があったから」では説明しきれない

期待結果が主で経路が従なのは元からそうで、手動実行という制約がそれを覆い隠していただけだ。この説明は、一見きれいに収まります。

ですが成立しません。制約は、手順を固定するという選択肢が採用可能だった理由にはなります。しかし、なぜそれを外に出す成果物にしたのかを説明していません。

制約下でも、手順は内部の作業資料に留めて、組織に渡す成果物は「何が成り立っていて、何が分からないか」にしておくことはできたはずです。工数が足りないことと、何を外に出すと決めるかは、別の判断です。そして実際に外へ出されたのは、手順書のほうでした。

5-2. 成果物を決めることは、責任範囲を宣言することです

そして成果物を決めることは、責任範囲を宣言することと同じです。手順書を渡した時点で、「私が引き受けるのはこれです」と言っていることになります。

だから評価指標が件数と消化率になりました。順序が逆だと私は見ています。指標が先にあって手順書ができたのではなく、手順書が先にあって、指標がそれに従った。手順書を成果物にした以上、そこから測れるものは「何本書いたか」「何本消化したか」しかありません。

5-3. 「全件パス」が、品質の報告として通ってしまう

決定的なのは、「全件パス」が品質の報告として通用してしまうという事実です。

私は、テストが全件パスと報告された後に本番で障害が出る場面を、実際に見てきました。そのとき報告に嘘はありませんでした。書かれたケースはすべて通っていた。それでも障害は出た。理由は単純で、障害が起きた経路は、そもそもテストケースに書かれていなかったからです。

このとき「全件パス」という報告は、何も間違っていないのに、何の役にも立ちませんでした。読んだ人は、そこから何ひとつ判断できなかったからです。

そしてこれが成立するのは、手順が責任の単位になっているときだけです。成果物が最初から「確認できていない範囲」だったなら、手順を固定していてもこの報告は書けません。「全件パス」という報告のおかしさは、工数制約の副作用ではなく、責任定義から直接出ています。

5-4. 手順書は、免責の装置としても機能してしまう

さらに、手順書には免責の装置としての機能もあります。書いた手順を実行して報告した以上、書かなかった経路で障害が出ても、QAの不履行にはならない。

私はこの構図が実際に使われる場面も見ています。障害の振り返りで「テストケースには無かったので」という一言が、そこで議論を終わらせてしまう。誰かが悪意でそうしているわけではありません。成果物が手順書である以上、それは論理的に正しい応答なのです。手順書を渡すと決めた時点で、書かなかった範囲は責任の外に出ます。

だから成果物を期待結果と未確認範囲に移すことは、単に軸を移す話ではありません。「やったことに対する責任」から「見ないと決めたことに対する責任」への移行になります。何を確認しないと判断したのか、なぜそう判断したのかを、自分の名前で出すことになる。負担は増えます。増えますが、そのぶん「テストは何をしていたのか」と問われたときに答えられるようになります。

6. QAが引き受けるのは、行為ではなく情報です

ここまでを1文にまとめると、こうなります。QAが引き受けるのは、行為ではなく情報である。

6-1. ここでいう「行為」と「情報」の定義

語の定義を正確にしておきます。報告を書くこと自体も行為ですから、雑に使うと何も言っていないことになってしまいます。

• 行為＝実施したという事実。「200件実施した」「全経路を通した」がこれにあたります
• 情報＝判断を変えうる内容。それを読んだ人の意思決定が変わりうるもの

つまり対比は、実施したという事実を成果物にするか、判断を変えうる内容を成果物にするかにあります。

6-2. 報告に載せるべき3つ

以上から、QAが渡すべきものは3つになります。

• 守りたかったこと（期待結果）
• それが成り立つと確認できた経路
• 確認できていない範囲と、その理由

実際の報告にすると、たとえばこうなります。

守りたかったこと：決済が完了したとき、注文と在庫が必ず一致する
確認できた経路：カード決済（Web／アプリ）、クーポン併用、決済後のキャンセル
確認できていない範囲：コンビニ後払い（検証環境の入金通知が未接続のため。前回も同じ理由で未確認）／同一アカウントからの同時購入（再現手段がないため。今回から新たに未確認）

この3つに実施件数は含まれません。「200件実施、全件パス」が意味を持たないのは、数が少ないからではなく、確認できていない範囲が報告に出てこないからです。残っているリスクについて、何も言っていない。

6-3. ただし、件数が情報になる場合もあります

件数という形式そのものが禁じられるわけではありません。前回180件通っていたものが、今回150件しか通らなければ、そこには「何かが悪化した」という情報が入っています。「実施したという事実」か「判断を変えうる内容」かは二択ではなく、程度の問題です。

6-4. 判定基準は「前回と比べて何が変わったかが分かるか」

では、どこで線を引くのか。判定の基準はひとつです。

その報告を読んで、前回と比べて何が変わったかが分かるか。

分かるなら、形が件数であっても情報として働いています。分からないなら、どれだけ詳細に書かれていても、実施の証明でしかありません。

この方向への移動は、私だけが言っていることではありません。NTTデータは、バグ密度・テスト密度といった従来の量的指標について、開発技術が多様化した現在では「バグ密度・テスト密度を計算する際の規模としてソースコード行数（SLOC）を用いるのは適切でないと考えられます」と述べ、代替として「観点カバレッジ」と「DDPモニタリング」を挙げています。DDPは、ある工程で検出すべきバグをその工程でどれだけ検出できたかを測る指標で、すり抜けバグが増えると値が下がるという性質を持ちます。

これは、指標の側から見た同じ移動です。「どれだけ実施したか」ではなく「取りこぼしがどれだけあったか」を測ろうとしている。見えていない範囲を測りにいくという点で、この記事の主張と方向が一致します。

現場の感覚としても同じことが語られています。テスト進捗の集計についてMIXIのQAが書いた記事には、不具合件数が過去平均から「下振れが過ぎるとちゃんと不具合検出できてるかなと心配にもなってくる」という記述があります。件数そのものではなく、前回との差分を読もうとしている。実務では、すでにそう扱われているわけです。

7. 「未確認範囲を書く」形式は、なぜ空洞化しにくいのか

「未確認範囲を明示しました」も、いずれ「全件パス」と同じように儀式化するのではないか。当然の疑いです。結論から言うと、儀式化は起こりえますが、空洞化の起きる条件が違います。

7-1. 空洞化が起きる条件が違う

「全件パス」が空洞なのは、その報告を受けても判断が一つも変わらないからです。合格という情報しか入っていないので、受け手は何も選べません。

対して未確認範囲が書かれていれば、「確認させるか」「そのまま出すか」という選択が受け手の側に現れます。

ただし、選択が現れることと、実際に選択が行われることは別です。 受け手が未確認範囲を読み飛ばして承認する運用は、十分にありえます。ここは確かめられていません。

儀式化はもちろん起きえます。ですがそれは形式の欠陥ではなく実装の劣化で、しかも毎回同じ文言が並ぶなら、再評価していないという事実が目に見える形で残ります。「全件パス」は、劣化しても劣化が見えません。ここが決定的に違います。

7-2. 未確認範囲だって、全部は書けません

もうひとつ、強い反論があります。未確認範囲はDひとつではなく、E、F、Gと無限にある。全部書けば報告は無限に長くなり、絞れば絞った基準が新たな不可視領域を作る。結局、選んでいることに変わりはない。

これは成立します。未確認範囲を書く側も、選んでいます。

7-3. 違うのは、選び損ねたときの挙動です

違うのは、選び損ねたときの挙動です。

手順書は、選ばなかった経路について「合格」と報告します。選び損ねが、肯定的な情報に化ける。

未確認範囲の報告は、選ばなかったものについて何も言いません。「Aは確認、Bは未確認、それ以外は言及なし」となり、受け手は言及されていない領域があることを構造的に知っています。選び損ねが、沈黙のまま残る。

7-4. 沈黙は誤情報ではありません

ここが分かれ目です。沈黙は誤情報ではありません。合格は誤情報です。

書けないことと、嘘をつくことは違います。すべてを書けないという制約は両者に等しくかかりますが、書けなかった部分がどう扱われるかがまったく違う。

8. 読まれなかったら意味がないのではないか

未確認範囲が書かれていても、リリース判断者はそれを読まずに承認できます。それどころか、書かれた瞬間にQAが免責され判断者が不利益を引き受けることになるので、政治的には「そんなに書くな」という圧力が返ってくるはずです。

いや、実際に返ってくるのは圧力ですらなく、無関心かもしれません。抵抗にはコストがかかりますが、無視のコストはゼロだからです。

これは、この主張に対するもっとも実務的で、もっとも痛い反論です。応答は2つあります。

8-1. 圧力が返るなら、責任は移動しています

1つは、圧力が返るということは、未確認範囲の明示が実際に判断者へ責任を移動させているということです。何も動いていないなら、誰も文句を言いません。抵抗の発生は、それまで宙に浮いていた責任が誰かの手元に着地した証拠になります。

8-2. 無視されても、無視されたことが記録に残ります

もう1つは、無視されても、無視されたという事実自体が記録に残ることです。渡されていたのに読まなかった、という状態になります。「知らなかった」と言えなくなる。

ただし、この2つも確かめられていない予測です。 圧力が返ってこず、記録も参照されないまま定着する可能性は残ります。

8-3. 「読まれないなら意味がない」という基準自体の問題

その上で、「読まれないなら意味がない」という基準の立て方自体に、私は問題があると考えています。それはQAの責任を、受け手の行動で測っているからです。

QAの仕事は判断させることではなく、判断が行われた条件を確定させることです。読まれるかどうかは受け手の責任範囲であって、QAの責任の成否を決めません。

そして、読まれやすくするために正確さを削れば、受け手の判断材料を意図的に劣化させることになります。それは「全件パス」に戻る道です。

8-4. リスクの総量は変わりません。見えているかどうかだけが違います

未確認範囲が200件積み上がって誰も読まない、という状態が起きたとします。それでも、それはリスクが200件あるという事実が可視化されているということです。

固定ケース運用でも、同じ200件のリスクは存在しています。ただ「全件パス」に吸収されて消えているだけです。リスクの総量は変わらず、見えているか見えていないかだけが違います。

だからトレードオフは、正確さと到達性の間にあるのではありません。見えないまま抱えるか、見えた上で処理しきれないかの間にあります。

なお、ここで踏み越えてはいけない線があります。「未確認が200件あり、直近3回の判断で参照された形跡がない」と述べることと、「この組織は処理能力を超えている」と述べることは違います。前者は観測、後者は評価です。QAが渡すのは前者までで、是非は判断者が決めます。

9. 帰責が明確になることは、品質を上げるのか

この形式の機能が「事後に誰の判断だったかを確定させること」なら、障害の発生率は変わらず、変わるのは帰責先だけではないか。ユーザーは誰の責任かを知りたいのではなく、壊れていない製品が欲しいはずだ。これも強い問いです。

9-1. 帰責の明確化は目的ではなく、経路です

帰責の明確化は目的ではなく経路だ、というのが私の答えです。

未確認範囲が可視化されると、判断者は「確認を追加するか」「リスクを取るか」を選びます。選ぶという行為が発生した時点で、リスクが管理下に入ります。

管理下に入ったリスクは、次の判断材料になります。「前回Dを見送って障害が出た」という履歴が積み上がれば、次からDは確認範囲に入る。これは漏れたケースを固定ケースに足すのとは違います。残るのは経路そのものではなく、見送ると判断した記録のほうだからです。

未確認範囲が見えなければ、Dは存在しないものとして扱われ、障害が起きても「想定外」で処理され、次も同じことが起きます。学習が発生しません。

9-2. 障害の事後検証が、そこで止まらなくなります

これは、障害の事後検証でもっともはっきり出ます。

報告が「全件パス」だった場合、「なぜ防げなかったか」への答えは「想定していなかった」になります。そこで検証は止まります。想定していなかったものについて、それ以上言えることがないからです。

報告に「Dは未確認」と書かれていれば、答えは「想定はしていたが、確認せずに出した」になります。ここで問いが次に進みます。 なぜ確認しなかったのか。誰がそう判断したのか。その判断基準は妥当だったのか。

この「事後検証が止まらない」という効果が、この主張の中心にあります。そして、これも確かめられていません。

関連して、日本のソフトウェア品質の文脈では、バグの流出原因分析が長く議論されてきました。日科技連SQiPのソフトウェア品質管理研究会では2011年に「バグの流出防止を考える ―どんなテストをすればバグを見つけられたのか？―」というテーマが扱われています（SQiPソフトウェア品質ライブラリ）。タイトルそのものが事後検証の問いの形をしている点に注目しています。この問いに答えられるかどうかは、リリース前の報告に何が書かれていたかに強く依存します。

9-3. 「記録は参照されない」という反論

現実の障害対応で読まれるのはログとコードであって、リリース前の報告ではない。この反論は成立します。記録は残るが参照されない、という状態は十分にありえます。

ただしこれには、こういう言い方も可能です。読むべき材料がなかったから読まれなかったのではないか。 「全件パス」しか書かれていない報告には、読む価値がありません。読まれないから書かない、書かないから読まれない、という循環が起きていた可能性があります。

10. この定義が排除するもの、そしてこの定義の弱さ

「何を書いても情報だと言えるなら、この定義は何も排除していないのではないか」という疑いは正当です。CIへの検査の組み込みも、レビューでの指摘も、報告書も、すべて情報を渡す行為だと言えてしまいます。

10-1. 排除できているのは、1つだけです

排除されているものは1つあります。実施したという事実だけを成果物とすることです。

「200件実施した」「全経路を通した」は、前回と比べて何が変わったかを含まない限り、判断を変えません。この1点だけが、この定義によって明確に外に出ます。

そして排除するものが1つしかないというのは、この定義の弱さです。 職能の定義としては、輪郭が緩い。これは認めた上で維持します。緩いことと、間違っていることは違うからです。そしてこの1つが排除できていないことが、現場で起きている問題の中心にあります。

10-2. CIが緑であることも、同じ構造を持ちえます

CIに検査を組み込むことも、この枠の中にあります。何を検査対象にするかは誰かが決めていて、それは「何を守るか」の定義そのものです。

そして組み込まれなかったものについては何も分からないままで、CIが緑であることは「組み込まれた検査は通った」という情報でしかありません。構造は「全件パス」と同じです。

だから、CIに何が入っていて何が入っていないかを述べることが、依然として必要になります。自動化されているかどうかは、この問題と独立しています。

11. この考え方の反証条件

主張を出す以上、それがどこで崩れるかも書いておきます。この定義には、確かめられる条件があります。

未確認範囲を明示した報告と、しなかった報告で、事後検証の到達点が変わらない。 これが観察されれば、この主張の中心は空になります。

確かめ方は2つあります。同じ組織が運用を切り替えた前後の比較と、複数組織の横比較です。

厳密な統制実験はできません。同じ障害について両方の状態を観察することはできないからです。ですがこれは経営や工学と同じ制約であって、確かめられないことを意味しません。同じ基準を適用すれば、対抗する案も同様に反証不能になってしまいます。

12. AIが実行を担うと、何が変わるのか

ここまでは、道具を問わない話でした。ここからは、AIが実行を担ったときに何が変わり、何が変わらないかを書きます。

前提を明確にしておきます。ここでいうのは「AIに任せれば勝手にサービスを探ってくれる」という話ではありません。期待結果を固定して、そこに至る経路をAIに振らせるという運用です。

人間が渡すのは、守りたい期待結果（決済後に注文と在庫が一致する、など）と、その期待結果が定義する範囲（対象の画面、入力できる値、前提データの条件）です。AIが決めるのは、その範囲の中でどの順に、どの経路を通るかだけです。

探索空間の外縁は人間が引き、中の道順をAIが変える。AIが振るのは、この道順の部分だけです。

手動で1経路しか回せなかったものが3経路回せるなら、報告できる内容が変わります。同じ期待結果が3経路で成り立つと言えるのと、1経路でしか言えないのとでは、情報の質が違う。

これは、経路を固定しない運用を実行可能にする手段です。それまで「経路を複数書くべきだが工数が」で止まっていた問題を外します。

12-1. AIがスケールさせる部分

異常の検出、分類、重複の統合、影響範囲の推定、そして処理量。ここは実務的に効きます。

経路を振る運用では実行が安くなるため回数が増え、異常の総量も増えます。処理側が人間の手作業のままなら、「大量に実行して、異常は溜め、期待結果の定義は初期のまま」という状態に収束します。AIはこの詰まりを解消します。

なお、異常が溜まって詰まるという事態は、固定ケースでは起きません。起きないのは健全だからではなく、拾っていないからです。固定ケースは期待結果に書かれた事象しか見ないので、想定外は最初から観測されません。詰まりの発生は、観測が発生している証拠になります。

12-2. 人間が持ち続ける部分

「この事象は仕様違反か、仕様通りか」の判定は、仕様の外側の情報を要求します。業務上どうあるべきか、契約上どうか、この機能で何を実現したかったのか。AIに渡せるのは、渡された分だけです。

これは未解決ではなく、分担です。AIの検出能力は、渡した期待結果の粒度で決まります。経路Bを通ったときだけ起きる副作用は、期待結果に書かれていなければ素通りします。だから、経路依存で壊れやすいものを期待結果側に足しておく作業が残ります。

そして判定できない異常は、未確認範囲に入ります。不具合か仕様か分からないというのは、確認できていないということだからです。沈黙ではなく、明示される側に落ちます。

AIが期待結果そのものを生成した場合も同じ扱いです。「この項目の期待結果は推定であり、事業側の確認を得ていない」と記録すれば、それは未確認範囲の一種になります。AIが空欄を埋めてしまう危険は、埋めたことを記録しない場合にのみ発生します。

AIの実行記録が信用できるか、という問題もあります。ですがこれはAI固有ではありません。テスターが「実行した」と書いたが実際にはやっていない、というのは手順書運用の最大の空洞化パターンでした。人間の実行は記録が本人の申告に依存していましたが、AIの実行には機械的なログが残ります。検証可能性はむしろ上がっています。 疑わしい記録は、その経路を固定して再実行すれば確かめられます。

12-3. 道具では動かない部分

未確認範囲を明示したことが、実際に組織の行動を変えるかどうか。ここは道具では動きません。

AIは報告を正確にでき、未確認範囲を漏れなく列挙でき、事後検証で過去の報告を照合することもできます。材料の側は全部できます。 ですが、材料があることと、その材料に基づいて組織が動くことは別です。

むしろ、AIが精度の高い未確認範囲を出せば出すほど、読んだ後に引き受けるものが増えるため、読まない側の理由は強まります。

そしてこれは、技術で解くべきものではないと私は考えています。読ませることを目的にすれば、読まれやすい報告を書くことになり、「全件パス」に戻ります。これは未解決の課題ではなく、QAの責任範囲の境界線です。

13. 外部の系統との照合

ここまで書いてきたことが、既存の議論とどう関係しているかを整理します。先に言っておくと、これは新しい主張ではありません。

13-1. 構造まで一致するもの：Session-Based Test Management

James BachとJonathan Bachが2000年に形式化したSession-Based Test Management（SBTM）は、ここで述べたことと同じ構造を持っています。ヒューレット・パッカードでの実践から生まれた手法です。

チャーターは開かれた形で書かれ、何をすべきかの網羅的記述ではありません。実行後にセッションシートという報告が作られ、第三者が何が起きたかを確認できます。報告には情報の欠落や未解決の疑問が記録され、デブリーフでは「何が妨げになったか」「まだ何が残っているか」が問われます。

手順を事前に固定せず、実行後に記録として残し、報告に確認できていない範囲を含める。 構造が一致しています。

さらに、Bach & Hodderが2014年に発表した論文のタイトルは、そのまま “Test Cases Are Not Testing” です（Testing Trapeze創刊号、2014年4月）。テストケースを作って実行することはテストと同じではない、テストケースはテストプロセスを組み立てる基盤として不適切であり、テストの進捗を測る基盤にはまったくならない、という内容です。

つまりこれは、2000年に形式化され、少数派のまま今日に至っている考え方です。AIによる実行が変えたのは、この構造のコストであって、構造そのものではありません。

主流にならなかった理由も、ここまでの内容の中にあります。読み手には読まない方が得だという構造がある以上、組織は正確な報告を積極的に選びません。「テストケースなし、期待結果なし、合否の指標なし」という形は、進捗を線グラフで見たい管理者には採用しにくい。構造の欠陥ではなく、組織の選好の問題だと私は見ています。

13-2. 方向が同じもの：ISTQBとGoogle

ISTQB Foundation Level シラバス v4.0 のテストの原則は、テストは欠陥の存在を示せるが不在は証明できないこと、全組み合わせを尽くすことは現実的でないのでリスク分析と優先順位で絞るべきことを明記しています。テストケースが一例でしかないことは、公式見解でもあります。

ただし注意が必要です。ISTQBの用語では、QAはプロセス指向・予防的なものと定義され、テストは品質管理（QC）の一形態とされます。この定義に照らすと、ここで論じてきたのはQCの話になります。

ただしISTQBは、QAは全員の責任だとも明記しています。予防の主体はQA部門ではない。だとすればQA担当者が予防のために出せるものは、「このプロセスではここが防げていない」という情報しかありません。ISTQBは予防を目的として書いていますが、手段を書いていない。ここで述べたのは、その手段を埋めるものだと位置づけられます。

Googleは『How Google Tests Software』の中で、品質はテストと等しくない、専任テスターが少なくても回るのは開発者が品質を所有しているから、テストが肩書きに入るエンジニアは他のエンジニアが良いテストをできるようにする裏方だ、と述べています。行為の実施が品質を保証しないという点で方向が同じですが、これは組織構造についての記述であって、成果物の置き方についてのものではありません。

この2つは、同じ方向を向いているというだけで、同じことを言っているわけではありません。 構造まで一致しているのはSBTMだけです。

13-3. 主流が実際に選んだ別解：CI/CDと本番計測

もっとも強い反論はここです。主流が実際に選んだのは、CI/CDと本番計測という別解でした。

デプロイ頻度を上げ、段階的に出し、本番の異常を検知する。事前に情報を出して判断させるのではなく、判断の粒度を小さくして、間違えても戻せるようにする方向です。これは実際に機能し、普及しました。

ただし2つの限界があります。

戻せる範囲が限られています。 ロールバックできるのはデプロイであって、実行された処理ではありません。誤った請求、失われたデータ、送信された通知は戻りません。カナリアリリースで影響を1%に抑えても、その1%は実在するユーザーです。

本番計測は期待結果を知りません。 拾えるのはエラー率やレイテンシの変化で、「金額が業務ルール上おかしい」は正常応答として返るので拾えません。

そして、ダッシュボードが緑であることは「監視項目は正常」という情報です。何を監視項目にするかは事前に決めているので、決めなかったものについては分かりません。事前に決めた範囲の外が見えないという点で、「全件パス」と同じ構造を持ちます。別解は、同じ問題を別の場所に作り直しているように私には見えます。

13-4. 反例として残るもの：規制産業

もうひとつ、この主張が通らない領域があります。医療機器、航空、自動車の機能安全領域では、手順書が法的な成果物になります。事前承認と再現可能性が要求され、「経路を振って事後に記録した」は証拠として通りません。

ここで要求されているものの目的自体は、情報の側にあります。何を守るべきかが要求として定義され、それに対して何が確認されたかが辿れること。残存リスクの文書化は義務であり、「全部確認しました」という報告は受理されません。手順の固定は、再現による検証を証拠形式として採用しているために指定されています。

ただし、手順を固定せよという要求そのものは残ります。 目的が情報の側にあることは、この領域で「経路を固定しない」が採用できることを意味しません。ここは反例として扱うべきだと考えています。

14. 日本の現場から出ている、同じ方向の指摘

この記事の内容が現場の実感から遠いかというと、そうでもありません。国内で公開されている記述の中にも、同じ方向を向いた指摘が見つかります。

14-1. 指標の側から起きている移動

先に触れたNTTデータの「バグ密度・テスト密度に依存しない品質保証への挑戦」は、量的指標を捨てて、すり抜けたバグの割合を測る指標（DDP）へ移ろうとしています。「どれだけやったか」から「何を取りこぼしたか」への移動です。

不具合分析の現場からも、再発防止策として漏れたケースをリグレッションに追加することへの批判が出ています（前掲・かわちーばーのブログ）。これは、固定ケースを積み増しても上限が動かないという、この記事の3章と同じ指摘です。

14-2. 探索的テストへの評価が、そのまま論点になっています

興味深いのは、探索的テストのデメリットとして挙げられる項目です。SHIFTの解説記事は、探索的テストには「実施されるテストの全量が把握できないというデメリットがあります」と述べています。

これはまさに、この記事が扱ってきた論点そのものです。全量が把握できないのは、探索的テストの欠点ではなく、テストという営みの実態だというのが私の立場です。固定ケース運用は全量を把握しているのではなく、「把握できる範囲だけを全量と呼んでいる」。だから「全件パス」という報告が成立してしまう。

同じ記事は、あらゆる例外を考慮しようとすると「運用上発生し得ないパターンも加味しなければならず、設計的にもデータ準備的にも労力が大きすぎることが想像できるかと思います」とも書いています。事前設計には現実的な限界がある、という認識は共有されているわけです。

だとすれば、残る問いは1つです。設計しきれなかった範囲を、報告に書くのか、書かないのか。

15. まとめ：渡すべきものは、渡されているか

結論を書きます。QAが引き受けるのは、行為ではなく情報です。

QAの責任は、何を守るかを定義し、それが成り立っているかどうかについて、成り立っていない部分と分からない部分を含めて、正確に述べることにあります。ここに手順は含まれません。

15-1. 最初の問いへの答え

手順書運用が誤っていたのは、非効率だからでも、網羅性が低いからでもありません。実行という行為を、責任の単位に据えたことです。

行為は誰かの判断材料を作るための手段でしかなく、手段を成果物にした瞬間に判断材料が失われ、「全件パス」という中身のない報告が成立するようになりました。

経路を固定しないことは、この誤りの是正の一部にすぎません。中心にあるのは、引き受けるべきものが行為ではなく情報だという一点です。道具が何であっても、経路が固定であってもなくても、報告に未確認範囲が含まれていなければ、QAは責任を果たしていない。逆にそれが含まれているなら、経路の扱いは技術的選択の問題に落ちます。

最初の問いに戻ります。テストケースに具体的な手順を書くべきか。答えは、書くか書かないかは問題ではない、になります。手順の有無を議論している限り、行為を責任の単位に据えたままだからです。

問うべきは、その手順書が誰かの判断材料になっているか、それとも実施の証明になっているか。後者なら、手順を書いても書かなくても、渡すべきものは渡されていません。

15-2. この主張の限界を、3つ

ここを書かずに終わると、この記事自体が「全件パス」になってしまいます。

定義としての輪郭は緩い。 排除しているのは「実施したという事実だけを成果物とすること」の1つだけです。職能の定義としては弱い。ただしその1つが排除できていないことが、現場で起きている問題の中心にあります。

新しい主張ではない。 SBTMが2000年に同じ構造に到達しています。独立に同じ場所にたどり着くことは思考の妥当性を示しますが、業界に対する新規の貢献ではありません。変わったのは構造ではなくコストで、AIによる実行がそれを外しました。

中心部分は確かめられていない。 未確認範囲を明示した報告が、実際に事後検証の到達点を変えるかどうか。これは運用にしか答えがありません。変わらなかったなら、この主張が誤っているか、組織の側に別の問題があるかのどちらかが分かります。それも重要な情報になります。

15-3. この考え方は、QA自身を守るためのものです

冒頭に書いたことを、もう一度書きます。

この記事は、手順書を書いている人を否定するものではありません。手順書は、限られた工数の中で確認範囲を確保するための、合理的な発明でした。問題は手順書そのものではなく、それが組織に渡る唯一の成果物になったことです。

そして、その構造でいちばん損をしているのはQAだと私は考えています。正確に仕事をしても、報告できる内容が「実施しました」に限定される。障害が出れば「テストは何をしていたのか」と問われる。免責はされるが、価値は伝わらない。

未確認範囲を書くことは、負担が増えるように見えて、実際にはQAの立場を強くします。「何を見て、何を見なかったか」を自分の名前で述べられる職能は、実施の証明を積み上げる職能より、はるかに置き換えにくいからです。判断材料を持っている人間は、判断の場に呼ばれます。

テストケースに手順を書くかどうかは、そのあとの話です。まず問うべきは、あなたの報告書を読んだ人が、前回と比べて何が変わったかを言えるか。ここが出発点になります。