AIでのテストデータ作成で見えた「設計書に書いていないこと」

はじめに

【エンジニア募集中】フルリモート可◎、売上/従業員数9年連続UP、平均残業8時間、有給取得率90％、年休124日以上 etc.　　詳細はこちらから＞

現在、あるシステムの開発で、計算処理のテスト設計を担当しています。テストケースの数が多く、手作業では時間がかかりすぎるため、Claudeに設計書とCREATE TABLE文を渡してテスト仕様書とテストデータ（SQL）を作成してもらいました。最終的には85ケース分、約20テーブル・約800レコードのテストデータになりました。

レビューで見つかった問題

最初の出力をレビューすると、テストケースの不足と期待値の誤りが見つかりました。不足しているケースを伝え、期待値の考え方を説明すると、同様の箇所もまとめて修正してくれました。設計書に書かれている内容なら、説明すれば直してもらえます。

テスト実行で初めて見つかった問題

困ったのは、実際にテストを実行してから見つかった問題です。計算の元となるデータの作成漏れ、データが複数ケースで共用になっていてどのケース用か分かりにくい、キーの重複、画面で確認するための付随データの不足などがありました。

たとえば、ある区分項目には本来「1」「2」のような区分コードが入るはずが、説明用の名前のような文字列が入っていました。CREATE TABLE文で項目や型は伝わっても、区分値の意味までは伝わらなかったためです。これらに共通していたのは「設計書に書いていないこと」でした。

対策

そこで、設計書に書いていない部分を指示として追加しました。実際の指示を一般化すると、次のような内容です。

これにより、1ケースずつ独立して実行でき、画面での確認もしやすいデータになりました。

まとめ

修正は必要でしたが、手作業と比べると手間もかからず、圧倒的に早く作成できました。一方で、設計書やテーブル構造だけでは伝わらない部分は、AIが推測で埋めてしまいます。次にAIでテストデータを作るときは、項目ごとにどんな値が入るか、IDの範囲、どの程度バリエーションを持たせるかといった、設計書に細かい記載がない部分を最初からインプットしておきたいと思います。

【エンジニア募集中】フルリモートも◎(リモート率85.7％)、平均残業8時間、年休124日以上、有給取得率90％ etc.　詳細はこちらから＞