Where we plug in, and what changes after that.
The gate we add to your board, the order the work runs in after the audit, and the machinery that stops you paying twice for the same knowledge.
Inside your SDLCOne column changes who gets to call something done.
We do not sit at the end of the pipeline waiting for a build. A QA engineer joins at refinement, while a ticket is still cheap to change, and again at the pull request, on staging, and at the release gate.
On your board that is one new column. Work stops being done when the person who wrote it says so, and starts being done when somebody else has checked it.
The order of workThree stages, and each one is paid for by the last.
The audit hands us a ranked list. The stages are what we do with it: the dangerous paths first, then the work that repeats every release, then the automation that stops the repeated work costing anything.
We do not date the stages. How long yours take depends on your product. Each one ends in something you can check, and if the outcomes are not there, that is a conversation we start.
Stage 01: Stop the bleeding
The audit's critical findings get coverage first, and every release starts going through the QA column.
- Critical paths covered by cases
- The QA column live on your board
- A written summary every day
Stage 02: Make it repeatable
The regression set grows to cover what you ship each sprint, written so a new person can run it.
- A regression set anyone can run
- Escape rate measured per release
- A go or no-go before you ship
Stage 03: Make it cheap
The cases that run before every release move into your pipeline, where they cost nothing to repeat.
- The repeated cases automated in CI
- Manual effort spent on new features
- Coverage you keep if we leave
Product contextLearning your product is a cost you pay once.
Any engineer is expensive while they are still learning a product, and that price is paid again every time somebody leaves. We pay it once and write down what we learn.
- Product map
- Every flow that makes you money, and what stops working when it fails.
- Environment notes
- Which host behaves like production, and which one does not.
- Defect history
- Every bug we filed, and the pattern it turned out to belong to.
- Release history
- What shipped, what it broke, and what we run before you ship again.
Kept per engagement, never in one person's head. Yours at handover.
LLMs in productionModels do the typing. Engineers do the deciding.
We use language models in day-to-day QA work, and we are specific about where. What they buy you is speed on the mechanical half of the job, never a shortcut past the judgement you are paying for.
A model drafts
Test cases from a ticket, the repetitive half of an automated test, defect summaries, and bulk edits across a suite when a flow changes shape.
An engineer decides
Which of it matters, what the ticket forgot, and what gets deleted before anybody runs it.
A person signs
Every line that reaches your repository is read and signed by somebody you can name.
Ownership
The cases, the automation code, the reports and the context notes are yours. We claim no licence over any of it.
Access
Your code reaches a model only where you allow it, with the provider named in the contract. Where the answer is no, the work is done without one.
The board above is drawn the way a tracker draws one, from a representative sprint rather than a client's project. GitLab is a trademark of its respective owner; it is not affiliated with GetQA, and we work in whichever tracker you already run.
See this run against your own product.
Thirty minutes with a QA engineer: how you release today, which column is missing, and what the first stage would have to cover.