AI時代の短期的な第三者検証を考察する
AIの台頭で、一定のテストはAIが代用できるようになってきています。
単純なテストケースの作成までは、すでに実用段階とも言えるでしょう。
そんな中で、第三者検証が出せる価値を考察してみます。
テスターはファーストユーザー
「知りすぎていない」
- リリース前にフィードバックを得るサイクルを作れる
- ユーザーに近いので、率直な意見が出やすい
- “知りすぎているがゆえの盲点”を意図的に遮断できる
- 開発者の「わかるはず」を疑える（初見での迷い・誤解を拾える）
- この「初見の違和感」自体が、テストアスペクトの種（concerns）になる
- これを早期に回収できる
ブラックボックスアプローチのメリット
「仕様の曖昧さ・抜けを炙り出しやすい」
- 内部を見ないので、仕様の穴がそのまま「テスト不能」や「テスト観点」として現れる
- 例外系・境界条件・前提条件の抜けを見つけやすい
- “仕様に書かれていない動作”が発生したときに、議論の起点を作れる
- 仕様の不足は「観点（テストアスペクト）」として明示化して残せる
「UX不備を見つけやすい」
- 正しい/間違いだけでなく、「迷う」「不安」「誤解」を拾える
- これらは「バグ」ではなくても、ユーザー離脱の原因になりうる
- 具体例
- ボタンが押せるが、押してよい確信が持てない
- 戻れない／やり直しが効かない
- エラーが出るが、次に何をすればいいかわからない
- 表示文言が強すぎる（確定・絶対など）／誤認を誘発する
- こうした“嫌な気持ち”は、UX系のテストアスペクトとして体系化できる
テストアスペクトを活用できる
（ここで言うテストアスペクト＝テスターの concerns を観点として明示化したもの）
- 画面や機能で追うより、観点（アスペクト）で横串にする方が漏れにくい
- 「何を見たか／何を見ていないか」を観点で説明できる
- 属人化しがちな“勘”を、チェック可能な形に落とせる
- アスペクトはプロダクト横断で再利用できる（カタログ化できる）
例
- 入力（Input）
- 必須、桁、文字種、境界値、コピペ、全角半角、絵文字
- 状態（State / Context）
- 未ログイン、権限違い、初回、復帰、セッション切れ
- 例外（Failure / Exception）
- 通信失敗、タイムアウト、二重送信、戻る操作
- 表示（Presentation）
- 文言、単位、丸め、並び順、初期値、保持
- 期待（Guidance / Next action）
- ユーザーが次に取るべき行動が明確か
ロールと期待役割を整理しよう
第三者検証に期待できるのは、テストだけではない
- テスターの指摘を、製品作りに生かす
- 観測ログや観点（テストアスペクト）が残ると、議論を進めやすくなる
- 結果として、判断が属人化しにくい
これらは、ユーザビリティテスト等で別コストをかけて取得されることもあります。
また、リリース後のユーザー反応を知見化するサイクルだと、遅い場合もあります。
場合によっては致命的なこともあります。
「QAは福利厚生」「QAは健康診断」「QAは保険」「QAは投資」「QAは最後の砦」…いろいろあるけど
QAは「気づきを共有可能にする仕事」でもある、と捉えています。
- QAは「必要な時に効く安全装置」でもある
- テストだけなら第三者スタイルじゃなくても成立する場面はある
- ただ、モノづくりにおいては、貴重な意見を拾える機能を持つ
これは、活かさないと、もったいないと思うのですよ。
参考：Designing Fulfilling Test Cases with Test Aspect Model（InSTA 2019）
https://www.aster.or.jp/workshops/insta2019/img/InSTA2019_Designing_Fulfilling_Test_Cases_with_Test_Aspect_Model.pdf