GetQA
How we test

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.

Start at the board

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.

webBoards
Development
To Do4
4 further issues, drawn without their titles.
In progress3
3 further issues, drawn without their titles.
In QA2
Done5
5 further issues, drawn without their titles.

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.

Nothing repeatable can be built before the dangerous paths are covered, and nothing is worth automating before it is repeatable. We do not date the stages — how long yours take depends on your product, and a number here would be a guess about a codebase we have not opened.

Every stage ends in something you can check rather than a status update. If a stage's outcomes are not there, that is a conversation we start.

  1. Stop the bleeding

    01

    The audit's critical findings get coverage first, and every release from then on goes through the QA column. The daily written summary starts immediately, so the first thing that changes is that you can see what is happening.

    • Critical paths covered by cases
    • The QA column live on your board
    • A written summary every day

  2. Make it repeatable

    02

    The regression set grows to cover what you ship every sprint, written so a new person can run it without asking anyone. Escapes become a number instead of a feeling, which is the point at which quality can be argued about with evidence.

    • A regression set anyone can run
    • Escape rate measured per release
    • A go or no-go before you ship

  3. Make it cheap

    03

    The cases that run before every release move into automation and into your pipeline, where they cost nothing to repeat. Human hours go back to the new work, which is where a person still finds what a script never will.

    • 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.

The notes travel with the engagement rather than with the person, and they are yours: handed over at the end, not kept as leverage.

Product map

Every flow that makes you money, who owns it, and what stops working when it fails.

Environment notes

Which host behaves like production and which does not, with the reason, so nobody debugs the same environment twice.

Defect history

Every bug we filed, where it was found and what it turned out to be. The pattern is what tells us where to look next.

Release history

What shipped, what it broke, and what we run before you ship again.

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. They draft; they never decide. A named engineer reads and signs everything that reaches you, exactly as before.

What that buys you is speed and coverage on the mechanical half of the job. What it does not buy is a shortcut past the judgement you are paying for.

The model drafts
The engineer decides
  • A first pass of test cases from a ticket and its acceptance criteria.
    Which of them matter, what the ticket forgot, and which to delete before anyone runs them.
  • The repetitive half of an automated test: selectors, fixtures, the setup.
    Whether the assertion tests the behaviour or only tests itself.
  • A summary of a long defect thread, and the same defect written in your format.
    The root cause, and whether the pattern is your code or your environment.
  • Bulk edits across a suite when one flow changes shape.
    Every line that reaches your repository, read and signed by a named person.
Ownership
Everything an engagement produces is yours: the cases, the automation code, the reports, and the context notes above. A model helping to draft a line does not change that. We claim no licence over any of it, and the notes are handed over at the end rather than kept as leverage.
Access
Your code and your data reach a model only where you allow it, with the provider and the retention terms named in the contract before we start. Where the answer is no, the answer is no, and 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 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 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.

Chat on WhatsApp