1 ポイント 投稿者 kyo3553 7 시간 전 | 1件のコメント | WhatsAppで共有

こんにちは。PRの変更コンテキストを読み取り、必要なQAを設計するローカルCLI、QAMapを作っています。

私がプロダクトチームで感じたボトルネックは、テストコードを書くことよりも、PRごとに「今回の変更で何を証明すべきか」を改めて判断するプロセスでした。最初はdiffとプロジェクト構造を分析して、Playwright・MaestroとE2Eの下書きを推薦していましたが、実際には開発者がすでに知っている内容や、単純な成功画面テストにとどまっていました。

そこで目標を変えました。すべてのドメインを完璧に理解する代わりに、コミットとdiffを根拠として変更意図と機能フローを整理し、正常・失敗・境界・状態遷移のうち抜けている可能性が高いQAを提案します。確信しにくい判断には、根拠と信頼度もあわせて表示します。

最終的には、PRが登録されると影響を受ける機能を見つけ、必要なE2Eとmock・fixtureを構成して安全に実行したうえで、検証の根拠まで残すローカルQAツールを目指しています。現在はv0.4.0で、実際のリポジトリで誤るケースを一つずつ検証しながら、その目標に近づくためにアップデートを続けています。

まだ初期段階のため、誤って解釈したり重要なシナリオを見落としたりする可能性があります。今いちばん必要なのは、実際の失敗事例です。QAMapが的外れな判断をしたり、使えないテストを提案したりしたら、気軽に教えてください。

1件のコメント

 
jeongjin0 1 시간 전

ローカルでdiffベースに境界や状態遷移まで提案する方向性は良いですね。各シナリオごとに、どのdiff hunkやファイルから根拠を抽出したのかがもっとよく見えると、レビュー時にfalse positiveを除外しやすくなりそうです。