テスト計画・分析・設計・実装・実行・レポートまでを通しで自動実行するAI開発&公開
概要
みなさん、いきなりテストケースを作り始めたりしていませんか？
それをやると抜け漏れが発生したり、AI生成だと「このテスト、必要か不要かわからん」が発生します。
そこでテスト計画から実行・レポートまでを中間成果物を作りながら通しで自動実行してくれるAI(正確にはskill群とそれらを束ねるオーケストレーションskill)を開発したので公開します。
- 各段階で中間成果物を作り、それをレビューし問題に優先度をつけ、大きな問題がなくなるまで修正とレビューを繰り返す
- リスク→テストアプローチ→分析結果→設計結果→テスト項目とIDで紐づけ。トレーサビリティの確立。各テスト項目の出所を追いやすくなる、抜け漏れ（途切れ）が発見しやすくなる
- Unit test/Integration/e2e自動テスト/手動テスト等々、どの観点はどのレイヤーで見るべきかの計画実施
- コードベース用テストケース、e2e自動テスト用テストケース、人間用テストケースをわけて出力
- 導出したテストケースとコードベースからUnit test/Integration/e2e自動テストを自動生成、自動実行
repository
- sample_app : サンプル用webアプリ「老後資金シミュレーター」
- spec : サンプル用webアプリの仕様書
- skills : この記事で紹介するskill群
- テスト成果物・tests : 実際に実行した結果。自分で使うときは消していいです。
使い方(run-test-process)
私はcodex派なのでcodex用のスキルとして作っています。
claudeも「claude用にして」と言えばしてくれると思います。
run-test-processが全てのskillを束ねるオーケストレーションskillで、これを実行すると最後までやってくれます。
最低限与えればよい情報は、仕様がわかる何かと、テストコード実装時に使うプロダクションコードの保存場所です。
その他、例えばテスト分析時に過去のバグ情報を与えたいなど、別途与えたい情報があったら与えてください。
(例)
run-test-process を使って、一通りのテストプロセスを実行してください。
テスト成果物はテスト成果物フォルダに入れてください。
仕様は、specフォルダに入っています。
テストコードを書く際のテスト対象のコードはsample_appフォルダに入っています。
これでテスト計画から分析、設計、実装、実行、レポートまですべて行ってくれます。
sample_appでは、全部完了するまで1時間15分でした。
codexのクセなんだか他のAIでもそうなのか、普通にskillの連続実行すると各成果物がとてもいい加減になります。抜け漏れ地獄です。
そこで、run-test-processでは内部的にスレッドをわけて、ひとつひとつじっくり実行させています。
テストプロセスの途中まででいい場合は、run-test-processを使わずに以下のような形です。
このようなシンプルな形でskillをつなげると先ほど言った通り成果物が雑になるので、ほどほどで止めるか１工程ずつ行うかにしたほうが良さそうです。
(例)
テスト計画作成、テスト計画レビュー、テスト分析、テスト分析レビューまでお願いします。
テスト成果物はテスト成果物フォルダに入れてください。
仕様は、specフォルダに入っています。
各テストプロセスskill説明
テスト計画(create-test-plan,review-test-plan)
テスト計画では、プロダクト全体に対して「テストでどう攻めるか」の作戦を決めていきます。
自分がいつもテスト計画を行うときの形で行っていて、リスクをあげ、テストアプローチをあげ、リスクがテストアプローチでカバーされているか見ています。
テストアプローチは、Unit testで行う場所、Integration testで行う場所、e2e自動テストで行う場所、手動で行う場所……のように、プロダクト全体を通してどの段階のテストを行えばいいかの計画を立てています。
その他アクセシビリティだったりユースケースだったりと様々です。
各テストアプローチにはリスクIDが紐づけられており、どのリスクをどのテストアプローチでカバーされているかわかります。
テスト計画作成後は、レビューで大きな問題がなくなるまで繰り返し叩かれます。
テスト分析(create-test-analysis,review-test-analysis)
テスト分析では、仕様やテストアプローチから「どんなことをテストすればいいか」という、いわゆるテスト観点を出します。
仕様書やテストアプローチから導かれるテスト観点の他、汎用的な観点からのテスト観点を追加するように作っています。
各テスト観点はどのリスクや仕様、テストアプローチと紐づいているかわかるようになっています。
ここで例えば「過去バグのリストも使って！」みたいな、PJ独自の観点を加えてあげるのもよさそうです。
ちなみにAI側がテスト分析時によくわからなくて質問したいことが出た場合は「テスト分析_質問票.md」が作られます。
ここでもレビューで大きな問題がなくなるまで繰り返し叩かれます。
テスト設計(create-test-design,review-test-design)
テスト設計では、テスト分析で出したテスト観点それぞれのテストパターンを洗い出します。
テスト設計技法として、同値分割、境界値分析、状態遷移、組み合わせ技法を含めています。(その他にも色々入っている)
テスト設計は、Unit test,Integration test,e2e,パフォーマンス……など、カテゴリにわけて出力されるようにしています。
各テスト設計は、どのテスト観点やテストアプローチ、仕様から出てきたものか紐づけされています。
また、ここでもAIから質問があったら質問票が作られます。
もう書く必要がなさそうですが、レビューで大きな問題がなくなるまで繰り返し叩かれます。
テストケース作成(create-test-cases,review-test-cases)
いきなりテストコードの実装を行うのではなく、まずは表形式のテストケースを作成します。
ここでは、コードベース用テストケース、e2e自動テスト用テストケース、人間用テストケースの3種類のテストケースが作られます。
なお人間用のテストケースはmdの他、csvでも出力させるようにしています。
コードベース用のテストケースはUnit testやIntegration testなど、テストコードで確認するテストです。後ほどAIにより自動生成・自動実行されます。
e2e自動テスト用テストケースは、PlaywrightなどUIを通した自動テスト用のテストケースです。後ほどAIにより自動生成・自動実行されます。
人間用のテストケースは、機械ではできないので人間ががんばる用のテストです。
あと、質問に答えてもらう必要があるテストケースは「質問待ちテストケース」として生成されます。
それぞれのテスト項目はテスト設計のどの項目から出たものか、どのテスト観点かといった紐づけがされています。
あとは、質問があったら質問票が作られ、大きな問題がなくなるまでレビューと修正が繰り返されます。
テストケース_コードベース例
テストケース_E2E自動テスト例
テストケース_人間実行テスト例
テストケース_質問待ち例
コードベースのテスト実装(create-test-code,review-test-code)
ここではコードベースのテストケースを参照し実際のテストコードによるテスト実装が行われます。
このときにプロダクションコードも参照します。（そうしないと作れないし）
何らかの理由で実装できない場合は無理に実装させずに「未実装テストケース_コードベース」として別途保存されます。
コードベースのテスト実行(execute-codebase-tests)
続けてコードベースのテスト実行です。
コードベースのテストケースがコピーされ、その時の結果として日付をつけ、そこにテスト結果が入れられます。
バグを見つけたときはissue一覧が作成されます。
テストケース_コードベース_実行済み例
コードベース_発見issue一覧例
e2e自動テストのテスト実装(create-playwright-e2e-tests,review-playwright-e2e-tests)
e2e自動テストはいったんPlaywright固定で入れています。変更したい場合はskillを編集です。
e2e自動テストを作る際は要素の取得などの関係でプロダクションコードを参照します。
何らかの理由で実装できない場合は無理に実装させずに「未実装テストケース_E2E自動」として別途保存されます。
e2e自動テストのテスト実行(execute-playwright-e2e-tests)
続けてe2e自動テストのテスト実行です。
Playwrightのセットアップもされるはず……と思いますが、自分でセットアップしておくのが良いかもしれません。
e2eのテストケースがコピーされ、その時の結果として日付をつけ、そこにテスト結果が入れられます。
バグを見つけたときはissue一覧が作成されます。
テストケース_E2E自動_実行済み
e2e_発見issue一覧例
テストレポート作成(create-test-report,review-test-report)
AI側で実行できるテストが全て完了した後、テストレポートが作成されます。
見やすいようにhtmlで出力しています。
「人間用テストケース」は人間が行う必要があるため、ここでは実行されていません。
そのほか、質問待ちで実装されていないケースなどがあるので、そこも後ほど補完する必要があります。
最後に
トレーサビリティの確立により「このケースはどういう意図から来た？」「このテスト、必要か不要かわからん」といったことが減り、観点追加時や、仕様変更時も、どの観点や仕様とどのケースが紐づいているかわかるため、どこに手を加えればよいか追いやすくなっています。
これまで人がやってた時はトレーサビリティは良いと思いつつ大変で出来なかったので、AIの登場でやりやすくなった部分と言えるでしょう。
中間成果物も全て残しているので、観点不足やパターン不足など、人による確認もある程度やりやすいです。
sample_appは詳細に仕様も作っていますので、人が一度テストケースを作ってみて、AIが作ったケースと比較してみるのも面白いかもしれません。
Discussion