Test case review
Test Case Review is the library seen through one question: which of these did an assistant write or change, and has a person read it yet?
:::note Recently changed This screen used to list only test cases an assistant wrote. It now also lists cases a person wrote that an assistant has since changed, and an assistant's edit to an already-approved case withdraws that approval and sends it back here. :::
Why it exists
Sekee lets an AI assistant create and edit test cases through the AI connector. That is useful and it is also exactly the kind of thing that quietly fills a library with plausible, unexamined content. A case written by a model and never read by anybody is not coverage; it is the appearance of coverage, which is worse than a gap because nobody goes looking for it.
An edit is the same problem wearing a disguise. A test somebody wrote, reviewed and trusted can have its steps rewritten by an assistant without changing its name, its folder or anything else a person would notice — so the case goes on looking reviewed while testing something else.
The Review screen is where both get settled.
Using it
The screen lists cases needing review, with the same toolbar and filters as the rest of the app. Open one, read it to the end of its steps, then approve it — or change whatever is wrong first and approve it after. Your name is recorded against it.
Each row says which of the two it is:
| Mark | What happened |
|---|---|
| Written | An assistant created the test case. |
| Modified | A person wrote it; an assistant has since changed it. |
A case is one or the other, never both — a test an assistant wrote is already its work, so editing it again does not make it "modified".
The Waiting since column is when the case arrived in the queue: when it was written, or when it was last changed. A test written two years ago that an assistant edited this morning sorts to the top, where it belongs.
Cases only people have touched are never queued. This is about the ones a model had a hand in.
What counts as a change
Anything an assistant does to the substance of the test: its name, description, prerequisites, state, tags, folder, or its steps — whether it replaces all of them, rewrites one, or appends one.
A save that changes nothing does not count, so an assistant reading a test and writing it back unaltered neither marks it nor disturbs an approval.
Approval, and losing it
Approving records who read the case and when. If an assistant then changes an approved case, the approval is withdrawn and the case returns to this screen as needing review.
That is deliberate: an approval is a person's name against the text they read, and once an assistant has rewritten that text the signature covers something nobody has seen. It also means the rule works more than once — an approval that survived every later edit would send a case here exactly one time in its life.
What to look for
- Does it test what it says it tests? Models write plausible steps for the wrong feature more often than they write nonsense.
- Are the negative cases real? "Enter an invalid email" is a scenario; "enter an email with a leading dot" is a test.
- On a modified case, what actually moved? The Activity log records the edit with the assistant's connector named as the channel, so you can see which fields changed before reading the whole case again.
- Is it linked to a requirement? An unlinked case leaves its requirement reading as uncovered — the traceability page's whole point, reported wrong, by the tool that was supposed to fill it in. The default AI rule asks assistants to link them; this is where you find out whether it did.