Use cases / Before a release ships
640 regression cases, two testers. What does this release change?
Running the whole regression sheet takes a week, so testers guess what to skip, and nobody records what went untested or who accepted it.
Jigward reads what the release changed, tests the changed areas and returns a scoped plan in which every untested area has a named owner. The QA lead sets the scope, and the product manager decides which risks to accept.
The film
Chapters
Read the narration
0:00 Run everything, or guess
Tom's team releases on Thursday. A complete regression pass takes a week, so testers guess what to skip. Nobody records what went untested. I'm Jigward. Tom's mention became my task. The team connected the storefront repo and a staging profile beforehand.
0:19 What release 5.2 changed
Ten pull requests merged since the previous release. Half are low-risk. Two change what customers pay: plan changes, and coupons. The plan-change PR rewrites how a mid-cycle credit is rounded and adds a path for annual plans. No test changed with it.
0:40 Targeted tests and a staging check
There's history here. A plan-change credit once reached customers wrong. Now, every release touching that code gets a mid-cycle check. I run only the tests covering what changed. They pass, but nothing exercises the new credit calculation, so I record that gap. Following that rule, I upgrade a synthetic account halfway through its billing period. The preview credit matches what the invoice charges.
1:15 The path staging cannot reach
That change also added a path for annual plans. Staging refuses annual billing, so I mark it untested, instead of skipping it.
1:30 A scope with named owners
Next, I map every change onto the regression sheet's area labels. Testers get about a tenth. Every gap gets an owner. I reply where Tom asked. Every claim links to its evidence, so the people deciding can verify it.
1:48 The QA lead sets the scope
Tom sets the scope. The product manager won't accept the annual gap untested. The release decision stays with them.
What changes
Today. Testers either run the whole sheet, which takes a week, or skim the release notes and skip what feels safe. The cases live in a spreadsheet or a test-management tool and the automated tests run in CI, but someone still has to read the merged changes and map them onto the sheet's areas by hand. Effort goes where nothing changed, a risky change can slip through, and nobody can say afterwards what went untested or who agreed to it.
-
Before: Running all 640 cases for a week, or skipping what feels safe.
With Jigward: 71 cases chosen from the ten pull requests the release merged.
-
Before: A rewritten credit calculation shipped with no test that covers it.
With Jigward: The missing test named, and the new credit checked on staging against the invoice.
-
Before: Areas left untested that nobody wrote down.
With Jigward: Every area left out listed with an owner, so the people who decide can accept or reject it.
What Jigward does
@Jigward what does 5.2 change since 5.1, and what must we test before Thursday?
Connected beforehand
- The QA channel is named for the storefront's Context.
- The storefront repository is connected through GitHub. Its regression sheet is a CSV file in the repository, with an area label on every case.
- An admin set up a browser profile for staging, with a synthetic test account.
-
Lists what merged
Ten pull requests merged since the previous release. Their titles show two that change what customers pay, plan changes and coupons.
-
Reads the risky changes
The plan-change pull request rewrites how a mid-cycle credit is calculated and adds a path for annual plans. No test changed with it.
-
Recalls the team's rule
Jigward recalls a rule the team agreed after an earlier release. A plan-change credit once reached customers wrong, so every release that touches it gets a mid-cycle check against the invoice.
-
Runs the tests for what changed
Only the 64 tests that cover the changed areas run, and they pass. Nothing covers the new credit, so Jigward records the missing test as an initiative.
-
Checks staging
Through the browser profile, it upgrades a synthetic account halfway through its billing period, and the preview credit matches the invoice. Staging refuses annual billing, so that path is marked untested, not skipped.
-
Maps the changes, then replies
It maps every change onto the sheet's area labels, attaches the scope file to the Task and replies in the thread, with every claim linked to its evidence.
Jigward in this case
-
Slack
The question arrives as a mention in the QA channel, and the scope goes back to its thread as one reply.
-
Tasks
The mention becomes a Task that keeps the test runs, the staging session and the scope file.
-
GitHub
Jigward reads the pull requests merged since the last release and the diffs of the two that change what customers pay. It opens no pull request.
-
Memory
The rule the QA lead and the product manager agreed after an earlier release comes back with who agreed it and when.
-
Workspace
Only the tests that cover the changed areas run, on Jigward's own copy of the repository.
-
Browser
Jigward signs in to staging through the browser profile, with a synthetic account. The recording and the network log stay on the Task.
What comes back, and what stays with the team
What comes back
- The Task A scope file with 71 of 640 cases to run, the 569 cases in unchanged areas listed as not run, and annual plan changes listed as untested, each with an owner.
- The QA thread in Slack One reply with the scope, the missing test, how it was checked and what was not, linking the Task, the scope file and the plan-change pull request.
What the team decides
- The regression scope. The QA lead sets it.
- Whether to accept each untested risk. The product manager decides, and here rejects the annual gap and asks for a test case.
- The go or no-go for the release. Jigward opens no pull request and changes no code.
What Jigward did not check
- Annual plan changes. No staging account has annual billing.
- The 569 cases in areas the release did not change.
- Other browsers, mobile, tax regions and concurrent changes.
- Plan changes beyond one monthly upgrade on one synthetic account.
Meet your next engineering coworker
Bring a question
from your own project.
See how Jigward can help your team understand the system and move the next task forward.
Jigward is in closed testing. Accounts are created by hand; sending a request does not create one.