柳田國男と聞くと、私は「日常の小さな事例を集め、その違いを見ていくこと」を連想します。あくまで私の解釈で、特定の著作や歴史的な方法論をまとめたものではありません。この連想から、AIにテストデータの候補を出してもらうとき、人は何を確認すればよいかを考えてみます。
この記事のポイント
AIには、入力例などの候補を増やす作業を手伝ってもらいます。使う理由と期待結果を確かめるのはテスターの仕事です。まだ試していない候補と、確認済みの事実は分けて記録しておきます。
よくある入力以外に何を確かめるか
データドリブンテストは、共通の手順やロジックと、入力値・期待結果を分けて扱う方法です。同じ手順で入力を変えて確かめる場合、入力値と期待結果を表にすると、どの条件を確認するかを比べやすくなります。
候補になるのは、よくある入力だけではありません。境界値、例外的な操作、言語や環境の違い、過去に不具合が起きた条件も使えます。ケースを増やす前に、その違いによって利用者が何に困りそうかを考えておきます。
AIに入力例の候補を出してもらう
住所の入力なら、全角と半角、長い建物名、ハイフン、改行、コピペで入る不可視文字などが候補になります。こうした表記や入力の仕方について、ほかにどんな違いがありそうかをAIに聞いてみます。
ただし、AIが出した住所が実在するとは限りません。対象サービスが扱わない形式も混ざります。生成した例なのか、実際に確認したユーザー入力なのかは分けておきます。候補を残すときも、何を根拠に挙げたかが分かるようにします。
住所フォームの候補を表にしてみる
次の表は、架空の住所フォームを想定した候補です。まだ具体的な入力値を決める前の段階です。全角数字を正規化するか、不可視文字を取り除くかは、サービスごとの仕様を確認します。期待結果が分からない欄を、AIの推測で埋めないようにします。
実際にテストするときは、決定した入力値、期待結果、その根拠を表に加えます。業務への影響を見て優先順位をつけ、自動テストに追加するものと、探索的テストで確かめるものを選びます。
| ケース | 観点 | 入力候補 | 期待結果の確認先 |
|---|---|---|---|
| address_001 | 基本入力 | 仕様に沿った架空の住所 | 登録可能な項目と条件 |
| address_002 | 表記ゆれ | 番地の数字を全角にする | 保持・正規化の仕様 |
| address_003 | 文字数 | 建物名を上限前後の長さにする | 上限値と超過時の挙動 |
| address_004 | コピペ | 途中へ不可視文字を入れる | 許容・除去・エラーの条件 |
| address_005 | 郵便番号 | 形式は合うが対応先を確認できない値 | 実在確認の有無と検証範囲 |
不具合や気づきを「野帳」に残す
ここでは、事例をためておく記録を「野帳」と呼んでみます。これも私の比喩です。過去の不具合や問い合わせ、レビューで出た懸念、QA中に気になったことを書き留めて、次のテスト設計で参照できるようにします。
見つけた場面、再現する条件、確認できた結果、まだ分からないことを書いておきます。ログや入力例を使うときは、使ってよい範囲を確認します。個人情報をそのままテストデータにしたり、AIに渡したりしないように整えます。
候補と確認済みの事例を分けて記録する
AIが出した候補だけでは、実際に何が起きたかは分かりません。対象の仕様に関係するか、期待結果は何か、どんなリスクを確かめたいかを、資料や調査結果と照らして判断します。
確認した事例を残し、次の候補を考えるときに参照します。これを繰り返すと、そのプロダクトで起きやすい問題や確認が必要な条件もたまっていきます。AIを使ってよかったかも、候補の数だけでなく、自分では見落としていた違いを検討できたかで振り返りたいです。