どうもTORAです。
仕事で実装と単体テストが進んで、内部結合テストの準備に入ったときの話です。テストケースを作るのにAIを使いました。今回書きたいのは、そのケースを考えてもらうために、何をどの順番で渡したかという話です。
対象はバッチです。バッチというのは、まとめて実行する処理のことです。それを実行順にいくつか組んだものを、ジョブネットと呼んでいます。
この現場では、結合テストの中に「バッチ単位テスト」と「ジョブネット単位テスト」という区分を置いていました。単体テストのときは、あるモジュールから別のモジュールを呼ぶ部分をモックにしています。モックは、呼び出し先を代わりの処理に置き換えたものです。バッチ単位テストでは、そのモックにしていたところを本物でつないで確認します。ジョブネット単位テストのほうは、前のバッチが出したものを次のバッチが入力として受け取る、そのつながりを見るためのものです。計画上は性能や業務シナリオのテストもあったんですが、今回はこの二つの話をします。
共通機能の設計書は、AIのほうから求めてもらう
使ったのはMicrosoft 365 Copilotです。最初に渡すのは、対象のバッチ本体の機能設計書と、共通機能の定義の二つにしました。
バッチは中でいくつかの共通機能を呼んでいます。どれを呼んでいるかは本体の設計書を読めば分かりますが、共通機能の詳しい中身は、それぞれの設計書のほうにあります。
そこで、呼んでいる共通機能を探すところからAIにやってもらうことにしました。プロンプトには、本体の設計書から呼び出している共通機能を特定して、その設計書を添付するよう開発者に求める、という手順を書いています。共通機能がさらに別の共通機能を呼んでいる場合も、必要な範囲でたどって、下の設計書を追加で求めてもらいます。
なので資料は一度に渡していなくて、求められた資料を開発者が何回かに分けて添付する流れにしました。呼び出しをたどりながら、テストを考えられるところまで情報を積み上げていくイメージです。
DDLは、AIが出したテーブル名で集める
設計書がそろってきたら、次はDDLです。DDLは、テーブルやカラム、データの型や桁数、NULLを許すかどうか、キーなどを定めた定義情報のことです。
機能設計書は、バッチがどう動くべきかの根拠になります。一方で、そのデータがテーブルに実際に入る形なのかは、DDLを見ないと分かりません。なので、DDLもAIに渡す資料に入れています。
ただ、DDLはテーブルごとに別のファイルになっていて、必要なテーブルの分を人が一つずつ探すのは結構手間でした。それでPowerShellで収集ツールを作っています。必要なテーブル名を渡すと、該当する定義を集めて1ファイルにまとめてくれるもので、このツール自体もMicrosoft 365 Copilotを使って作りました。
AIには、設計書から必要なテーブルを特定して、テーブル名をツールの引数にそのまま使える形で出してもらうようにしました。それをツールに渡して、まとまったDDLをまたAIに渡します。
ケースを書く前に、合わないところを聞いてもらう
設計書やDDLに食い違いがあれば、先に質問するよう指定しています。
質問が来たら、開発者が中身を見て対応を分けます。設計書の書き漏れなら設計書のほうを直し、設計書には書かれていないけど暗黙の前提になっていることなら、それを回答として返します。前提をはっきりさせるのは、人の側の役目にしてあります。
あわせて、単体テストでどこまで確認したかと、モジュール間の呼び出しをモックにしていたことも前提として渡しました。結合テスト側の見方はブラックボックスで、DBやファイルなどからの入力に対して、DB・ファイル・ログなどに何が出るかを確認します。
正常系は、結合テストのケース同士で単純に同じことを確認しているだけのものを整理したうえで、データのバリエーションと合わせて考えてもらいます。異常系は、設計書に書かれている業務エラーとシステムエラーが対象です。
ケースを書く直前には、既存のExcelのひな形を渡して、その列構成に合わせたCSVで出力してもらいます。
テストデータは、ケースを作ったのと同じチャットのまま続けて作る形にしています。設計書や、そこまでに確かめた前提をそのまま引き継げるので。データそのものに加えて、投入用のSQL、どのタイミングで入れるか、環境をクリアするためのSQLを用意してもらい、根拠がはっきりしないところには確認用の印を付けてもらうようにしました。
バッチ単位のテストケースを、ジョブネット側へ渡す
ジョブネット単位テストのほうも、渡す順番を決めています。まず全体のジョブフロー図を渡して、対象のジョブネットを指定します。次に、そのジョブネットに関係するバッチの設計書を、これも何回かに分けて渡します。そのあとで各バッチのバッチ単位テストケースを渡して、最後にジョブネット側のケースを作ってもらう流れです。
前の工程のテストケースまで渡しているのは、バッチ単位でどの観点をケースにしたかをAIが分かるようにするためです。そのうえで、前のバッチが出したデータを次のバッチがちゃんと受け取れるかを中心に、ジョブネット側の観点を整理してもらっています。
そうなると、ジョブネットのケースを作る時点で、バッチ単位のテストケースができあがっている必要があります。なので作業の順番も、バッチ単位のケースが先に完成するように計画の段階で組み込みました。
