See exactly what you get.
Every artifact below is a representative example of our engineers' output, in the format your team receives it.
01 / QA auditWhere is quality actually leaking today?
Before anyone writes a test, we spend a week inside your product and your pipeline. What comes out is one document: what we found, how we know, and what each gap is putting at risk.
Findings are ranked by what they endanger, not by how easy they are to fix. The report is yours whether you continue with us or not.
- Scope
- Web app, 3 environments, 6 weeks of releases
- On site
- 5 working days
- Delivered
- Report + walkthrough call
Every release is tested by the engineers who wrote it, so the same assumptions guard the code twice. Coverage follows where the team feels risk, and stops where the product actually breaks: money paths, permissions, and data export.
The refund path has never been tested end to end
No test case, no ticket and no release note mentions a refund since v3.0. The path crosses three services and one provider webhook, and each part is tested alone.
Cover it first. It is the shortest route to money leaving an account by mistake, and it is the one failure a customer reports to their bank rather than to you.
Staging cannot reproduce a payment failure
The staging host's outbound IP is not on the payment provider's allowlist, so every callback is rejected before it arrives. Three of the last five bugs closed as staging only were this.
Fix the allowlist before adding coverage. Until staging can fail the way production fails, a green run there tells you nothing.
Most defects never reach the tracker
In the last sprint, 14 of 19 defects were reported in a Slack thread and closed there. Two were fixed twice by different engineers, and none of them are countable today.
One tracker, one format, no exceptions. The ticket shape in section 03 is what we file, and it is what makes an escape rate a number instead of a feeling.
02 / Test resultsHow do I know a test was actually run?
Every case we execute closes with a comment like this one: the steps exactly as they were performed, and what happened in plain language.
A pass tells you the behaviour held. A fail tells you what broke and hands you the recording, so your engineer does not have to reproduce it before starting.
Settings > Team: invite a member with the Viewer role
Passed- Sign in as an admin on the test environment.
- Open Settings > Team and invite [email protected] with the Viewer role.
- Accept the invitation from a second browser profile.
- Confirm the new member appears in the team list with Viewer permissions.
The invitation arrived in eight seconds and the member appears in the team list with the Viewer role. Viewer restrictions hold: billing and team settings are hidden, and the two admin-only endpoints return 403 rather than rendering an empty page.
Reports > Export: row count of a 12-month CSV export
Failed- Navigate to Reports > Export.
- Select a date range covering 12 months and click "Generate CSV".
- Wait for the export to finish and download the file.
- Compare the row count against the on-screen report total.
The export completes and downloads without an error, but the CSV contains only 1,000 rows while the on-screen report shows 4,382 records for the same range. No truncation warning is shown, so the file silently omits the rest.
filed as QA-1156 within the hour
03 / Bug ticketsWill bugs arrive in a form my team can act on?
We file directly in your tracker, in your format. Expected against actual, numbered steps that reproduce on a stated host, and a screen recording attached to every report.
Each ticket also records which versions it affects and links back to the test case it came from, so nothing turns into a conversation about whether it is real.
Dashboard > Widgets
Chart legend disappears after switching between date ranges QA-1142
Ahmet Sevinc- Navigate to Dashboard.
- Locate the "Monthly Activity" chart.
- Select "Last 30 Days" from the date range dropdown.
- Select "Last 90 Days" from the same dropdown.
- Observe the legend is no longer displayed.
The legend stays visible and updates every time a new date range is selected.
The legend disappears after the second date range change and does not reappear until a full page reload.
- Affected
- 2.4.0, 2.3.9
- Browser
- Chrome
- Replicated on
- 192.168.1.50
Reports > Export
CSV export silently truncates at 1,000 rows QA-1156
Ahmet Sevinc- Navigate to Reports > Export.
- Select a date range covering 12 months and click "Generate CSV".
- Wait for the export to finish and download the file.
- Compare the row count against the on-screen report total.
The export contains every record in the selected range, or the export warns clearly when it cannot.
The CSV contains 1,000 rows while the report shows 4,382 records for the same range, with no truncation warning.
- Affected
- 3.2.0 test release
- Browser
- Firefox 128
- Replicated on
- 192.168.10.42
04 / Investigation notesDo you stop at “it’s broken”?
When a bug has a pattern behind it, our engineer keeps going and writes down what they found. Sometimes that is a root cause in your code; sometimes it is proof the code is fine and the environment is not.
This is the part that saves your team the most time, and the part you cannot buy from a click-through vendor.
Spent an hour narrowing this before filing. The legend is not being unmounted, it is being re-keyed. Every date range change re-issues the session token, and SessionTokenCache_v2 keys entries by user ID alone.
So on the second lookup the entry written for the previous region_scope comes back, and the widget renders against a scope it has no series data for. That is why the legend is empty rather than stale, and why a reload hides it again. Worth checking anywhere else that reads region_scope off the cached token.
Reproduced on 2.3.9 as well, so this is not new in 2.4.0. I have left the branch running on 192.168.1.50 if anyone wants to watch it happen live.
This one turned out to be environment, not code. The failed webhook deliveries only happen on the staging host, whose outbound IP is not on the payment provider's allowlist, so every callback is rejected before it reaches /hooks/payments.
The same build on 192.168.10.42 delivers all 40 test events. Nothing to fix in the application. I have closed the ticket and written the allowlist gap into the environment notes so it does not get re-filed next sprint.
05 / Test casesWhat happens to this coverage if your engineer leaves?
Nothing. The coverage lives in a test management suite you own, written so a new person can run it on day one: pre-conditions, action, data, expected result.
It also gives your team something to point automation at later, instead of starting the specification from scratch.
Storefront / Checkout / Payment
Checkout > Payment: apply a discount code and complete an order using a saved card
Verifies that a returning customer can apply an active percentage discount code and complete checkout with a saved card, and that the discount is reflected in both the order total and the order history.
- App version 4.2.0 deployed to the test environment.
- A logged-in customer with a saved card and a default shipping address.
- An active 15% discount code with no minimum spend.
Add items to the cart.
Input dataStandard Notebook x2, Desk Lamp x1
Expected resultBoth items are added and the cart icon shows 3.
Open the cart and apply the discount code.
Input dataSAVE15
Expected resultA discount line appears and the subtotal drops from $78.00 to $66.30.
Proceed to checkout and confirm the saved payment method.
Input dataVisa ending 4242
Expected resultThe saved card is preselected and the default shipping address is prefilled.
Place the order.
Expected resultThe confirmation screen shows a total of $66.30 and an order number.
Open Orders in the account area.
Expected resultThe order is listed as Paid with the discount shown as a separate line.
- Last run
- Apr 12, v4.2.0
- Result
- Passed
06 / Reporting cadenceHow often will I hear from you?
Daily in writing, so you never have to ask what QA did today. Then a fuller picture at the two moments you make decisions: end of sprint and before a release goes out.
You get one named engineer, in your Slack, on your standup if you want them there.
A short written summary in Slack: what was tested, what broke, what is blocked. Plus the nightly regression run.
$ npm test -- --suite=regression PASS checkout/payment.spec.ts (24) PASS dashboard/widgets.spec.ts (11) FAIL reports/export.spec.ts (1) Tests: 118 passed, 1 failed, 119 total Time: 4m 12s · env 192.168.10.42
A sprint report: cases added, bugs filed by severity, regression pass rate, and the areas we think are getting risky.
A release sign-off: full regression run, an explicit go or no-go, and a list of the open issues you are shipping with.
The panels above show our output inside the tools teams already use. GitLab and Qase are trademarks of their respective owners; neither is affiliated with GetQA, and we work in whichever tracker and test management suite you already run.
See these artifacts against your own product.
Thirty minutes is enough to tell whether this fits. We look at how you release today, and show you a full week of work from a team about your size.