Manual release checks
Manual testing for features, tickets, and releases
You tell us what to test: a set of tickets, a page, a release, or a whole process. Our QA team checks it on the browsers and devices your customers use and tells you what works, what broke, and what is still open.
Included in the Growth and Scale plans. One-off checks and extra sessions are scoped and priced with you.
RELEASE CHECKLIST
3 of 4 checked · 1 finding
You set the scope
Point us at what needs testing.
In your dashboard you link the tickets, pages, or flows you want checked, or bring our team into your process for every release. We test the unhappy paths too, not just the green one: wrong input, interruptions, going back, edge cases. You get the result for every path we checked.
What do you need tested?
Curious? Tick a few. On the demo we go through everything anyway.
How we work
From the first call to a clear result.
- 01
You set the scope
Link the tickets, page, or release in your dashboard, and agree browsers, devices, and test data with us.
- 02
We run the checks
Our QA team works through the scope on the agreed browsers and devices: the happy path, the wrong turns, and the regression around it.
- 03
You get the results
Everything lands in your dashboard: the checklist as a PDF and every bug with steps, expected vs. actual, and screenshots. Send bugs to Jira or Linear in one click, or export them to any tracker.
Results, evidence, and QA requests live in your Release Shield dashboard. Bugs go to Jira or Linear, updates to Slack, Teams, or email. See the dashboard
Example release check
Validating a new account flow
Three tickets linked in the dashboard, checked together with the account area around them. Hand them to the team and see how the results come back.
Try the checklist
- 01Create and verify an account
- 02Recover access after a failed sign-in
- 03Repeat on the agreed mobile and desktop browsers
Hand the checklist to the team and see how the results come back.
What you receive
- The completed checklist as a PDF, in your dashboard
- Every bug with steps, expected vs. actual, and screenshots
- Bugs sent to Jira, Linear, or any tracker, and a Slack, Teams, or email message when we finish
What we need to start
- Release scope and acceptance criteria
- Test environment, accounts, and test data
- Agreed browsers and devices
Common questions
How is this different from bug hunting?
Manual testing checks a scope you define: tickets, a page, a release. Bug hunting is exploratory: we go looking for problems nobody wrote a ticket for. Many teams use both before a bigger release.
Is manual testing included in the monthly plans?
Growth includes two focused manual QA or bug-hunting sessions a month, Scale covers manual QA for critical releases. Extra sessions and one-off checks are priced separately.
Do you do regression testing before releases?
Yes. Most manual testing requests are a release check: the new or changed behaviour plus a regression pass around it, on the browsers and devices your customers use. Recurring release checks can become a standing arrangement.
Where do I get the results?
In your Release Shield dashboard. Each session shows the checklist PDF, the environment we tested, and every bug with steps and screenshots. Connect Jira or Linear and every bug becomes a ticket in one click, screenshots included. Without a connection, copy a bug as a ready-made draft or export the whole session to Jira, Linear, or any tracker that imports CSV. Slack, Microsoft Teams, or email tells your team when the session is done.

Book a demo. After setup, you request manual testing straight from your dashboard.
30 minutes on Google Meet. Pick a time directly in our calendar.
