Verdicts follow the text
A verdict given on text that later changed no longer counts, so nothing is accepted on wording that is gone.
For testers
Accept behaviours, not tickets.
A feature is finished when the behaviours are there, not when a status says done. In KiwiPow you judge each behaviour of the approved spec against the tests the developer wrote to prove it, and the accepted spec becomes the record of what the product does.
Sound familiar?
- You write your own acceptance criteria for a ticket someone else interpreted.
- You accept against the requirement's own behaviours and edge cases, the same ones the product owner approved and the developer built.
- Test cases live in a separate tool, disconnected from the requirement text.
- Each behaviour shows the tests that prove it, the repository it was built in and the spec revision it was proven against.
- A reopened ticket comes back and you test everything again.
- Accepted carries over. Only the reopened and changed behaviours wait for a new verdict, and a reopened one needs a new proof before you see it again.
- Work reaches you half done, with open questions still in the air.
- A feature reaches you only when every task is done and proven and every decision between spec and code is ruled.
Your part in the loop
Judged one behaviour at a time, decided as a whole
-
See the behaviour
Each behaviour with its edge cases, the tests that prove it and the repository it lives in.
-
Accept or reopen
Accept it, or reopen it with a comment saying what is missing.
-
Decide the feature
All accepted accepts the feature. One reopened behaviour sends it back to the developer with every comment at once.
-
Accepted is final
An accepted spec is what the product does. A change comes as a new feature, so the record is never rewritten.
What you get
Proofs from real tests
A behaviour counts as built only when a named test proves it. No hand-linked test cases.
One authoritative test
Each behaviour has exactly one authoritative test. Overlapping tests at several levels are reported, because they hide which test matters.
Premise breaks come to you
A run that falsifies what approval rested on, such as a size budget or an architecture rule, returns to the architect and test leader.
Edge cases are requirements
The empty list, the expired session and the second click are written out under each behaviour, not discovered at acceptance.
Evidence for the auditor
Each behaviour carries its citation, revision history, proving tests and your verdict.
No dedicated tester? The product owner accepts.
Roles follow the work. In a small team one person holds several, and acceptance stays with the person who asked.