PR 테스트의 어려운 부분은 종종 테스트 전에 발생합니다.

One thing I keep running into when reviewing a PR is this: before writing a test, I first have to work out what the change is actually supposed to prove.

My first instinct was to generate E2E test drafts from diffs. It looked useful on paper. In practice, a lot of the output was obvious: click something, then check the success screen.

So I am trying to start one step earlier.

I have been building QAMap, a small local CLI that reads commits and diffs, tries to describe the behavior a change touches, and points out QA questions that may be missing around failures, boundaries, and state changes.

It runs locally. It does not upload source code or make LLM calls.

It is still early, and it definitely gets things wrong. Right now, I am more interested in finding those weak spots than pretending it can understand every product domain.

https://github.com/IvoryCanvas/qamap
https://github.com/ivory-code