テスト設計の標準が、いま効いている話

最近、テスト設計をAIに頼むこともだいぶ増えてきました。

ただ、最初の頃にやってみて気づいたんですけど、なんとなく「このシステムのテストケース出して」と頼むだけだと、返ってくるのはハッピーパス中心の、なんとも当たり障りのない一覧なんですよね。

それが「JSTQB準拠で、同値分割と境界値分析を使って」と一言添えるだけで、ぐっと網羅性が立ち上がる。境界の漏れが減って、デシジョンテーブルでお願いすれば条件の組み合わせが整理された形で返ってくる。状態遷移ならそれっぽく状態とイベントを分けて出してくれる。

最初は「やっぱりAIって賢いんだな〜」と素直に感心していたんです。

でも最近、ちょっと違う気がしてきました。

賢いのは、たぶんAIじゃない

「同値分割」「境界値分析」「デシジョンテーブル」「状態遷移テスト」っていう語彙そのものが、もうすでに テスト設計の観点を圧縮した結晶 なんだよな、と。

AIはその語彙を知っている。それだけで、観点に沿った設計を組み立ててしまえる。逆に、語彙がまだ整っていない領域でAIに設計を頼んでみると、「なんとなくそれっぽいけど抜けがある」出力しか出てこなかったりします（経験談）。

JSTQBが完璧だとは思っていません。「もう古い」という声も聞くし、実務との乖離もある。

ただ、共通語として機能している という一点では、いまむしろ強く効いている気がするんですよね。AIにも人間にも、等しく通じる土俵を作ってくれているという意味で。

人間同士のレビューでも同じで、「この同値クラスの境界、抜けてない？」が言える現場と、言葉がないからふんわり「網羅性が…」としか言えない現場では、品質の積み上がり方がぜんぜん違う。

語彙があるって、ほんま強い。

「次の品質を作る人」って、こういうことかも

同値分割を最初に定義した人は、たぶん「次の品質を作った人」だったんだよな、と最近よく考えます。

それまで暗黙だったテスト設計の観点を、誰でも使える言葉に削り出してくれた。だからいま、その言葉を使うだけで、後発の自分たちもAIも、それなりに網羅された設計まで辿り着ける。

ふと足元を見ると、いまも未定義のまま残っている領域はけっこうある気がします。AIエージェントの品質をどう測るのか、agenticなワークフローにどんなテスト観点を当てればいいのか、そういう話はまだ言葉が揃っていない（と思います、たぶん）。

そこを言語化して、共通語として浸透させていく仕事こそ、自分が前から夢として持っている「次の品質を作る人になる」の、現実的な一歩なのかもしれないな、と。

JSTQBが効いているという体感から、ここまで連想してしまったわけですけど、こういうことを考えながら日々のテスト設計に向き合うのも、悪くないかなと思っています。