AS400 / IBM iの改修では、正常系だけのテストでは足りません。RPG/CLの小さな変更でも、締め処理、EDI、在庫、請求、権限、ジョブログ、戻し手順に影響することがあります。
Codexを使うと、ソースや修正内容からテスト観点のたたき台を作れます。大事なのは、AIに「正常系だけでなく、異常系と戻しも出す」ように指示することです。
プロンプト例
以下のAS400 RPG/CL改修内容について、テスト観点を作ってください。 観点は以下に分けてください。 1. 正常系 2. 異常系 3. 締め前・締め後 4. EDI送信・再送 5. 権限・ライブラリリスト 6. ジョブログ確認 7. 戻し手順 8. 業務担当者へ確認すること 不明点は質問として出してください。
現場で追加する観点
- テスト環境と本番環境の差
- マスタ、単価、得意先、品番の条件差
- 月末、締め日、休日、夜間バッチのタイミング
- EDI送信先と再送条件
- 戻した時に帳票やPDFも戻るか
テスト観点は、AS400の読み解きにくいRPG/CLソースをCodexで整理する手順とセットで作ると実務で使いやすくなります。
テスト観点は「処理の前後」と「業務の締め」まで広げる
AS400 / IBM i の改修でCodexにテスト観点を作らせる時は、変更したプログラム単体だけでなく、前後の処理まで条件として渡すと精度が上がります。たとえば売上計上、出荷確定、請求締め、EDI送信、在庫更新、帳票出力のどこに影響するかを入れておくと、単なる入力値チェックではなく、現場で確認すべき観点に近づきます。
| 渡す情報 | Codexに期待する観点 | 人が確認すること |
|---|---|---|
| 変更したRPG/CLの役割 | 入力、更新、参照、帳票、外部連携のどれかを分ける | 説明が業務実態と合っているか |
| 前後の処理 | 締め処理、再送、再計算、戻し処理の観点を出す | 実際に再実行してよい範囲か |
| 使うファイルとキー | 重複、未更新、桁あふれ、NULL相当、日付範囲を見る | 本番データを貼らず項目名だけで確認する |
| 業務影響 | 売上、在庫、請求、出荷、EDIの確認順を作る | 担当部署へ確認するタイミングを決める |
| 戻し手順 | リカバリー、再送防止、二重計上防止を入れる | 承認者と作業ログを残す |
AIが出した観点は、そのまま正解として扱わず、抜け漏れ確認のたたき台にします。特にAS400の現場では、夜間バッチや締め後の再実行が絡むと、単体テストだけでは足りません。若手に観点を作らせる時も、Codexの出力を見ながら「なぜその確認が必要か」を説明できるようにすると、研修効果が出やすくなります。こうした使い方を現場で学ぶ場合は、AS400 / IBM i 現場向けCodex実戦研修の対象になります。
まとめ
AS400改修のテスト観点は、正常系だけでなく、締め、EDI、戻し、権限、ジョブログまで含めて作ります。Codexは観点作成のたたき台に向いていますが、最後は業務理解と本番運用に照らして人が確認します。
関連するAS400確認ルート
Codexでテスト観点を作るときは、締め、EDI、在庫、請求、本番戻しのような現場の事故パターンを先に入れます。単なる正常系テストで終わらせないことが重要です。
Codexには「業務の後続処理」まで条件として渡す
AS400改修のテスト観点をCodexで作る時は、変更した画面やプログラム名だけでは足りません。受注、出荷、在庫、売上、請求、EDI、帳票、夜間バッチのどこにつながるかを条件として渡すと、通常ケース以外の観点が出やすくなります。
AS400の販売管理改修です。 変更点: - 受注入力時のチェック条件を追加 - 対象ファイルと項目はマスキング済み 後続処理: - 出荷指示 - 在庫引当 - EDI送信 - 売上計上 - 請求締め テスト観点を、通常・異常・境界値・再実行・戻し手順に分けて出してください。
出てきた観点は、そのまま採用せず、現場の締め時刻やバッチ順序に合わせて削ります。Codexは観点の広げ役、人間は業務影響の絞り込み役、と分けると使いやすくなります。