TCG reads the requirements you already have — BRDs, specs, Jira items — and generates traceable scenarios, steppable test cases and automation suites. Every stage is reviewed, signed off and evidenced, so coverage is a number you can hand to an auditor rather than one you assert in a status meeting.
None of them is a tooling problem in the usual sense. They are all the same problem: the work between a requirement and a defensible test suite is manual, undocumented, and the first thing a deadline eats.
60–70%
of a QE team’s week goes on writing cases by hand
Reading a requirement, deciding what could go wrong with it and writing that out as steps is skilled work — but most of the hours go into the typing rather than the deciding. The judgement is the scarce part, and it is what a deadline squeezes.
TCG does the transcription and puts the judgement in front of a reviewer.
1 in 3
requirements cannot be tested as written
“The system should handle end-of-day quickly” has no timezone, no cutoff and no threshold. Nobody catches it until somebody tries to write a test for it — usually weeks after the requirement was signed off.
Stage 2 grades every requirement and names the sentence, not the document.
“Prove it”
the question a coverage percentage cannot answer
A number on a slide is not traceability. When a regulator, a customer or an internal auditor asks which requirement a test covers and who accepted it, the answer is usually a spreadsheet somebody maintains by hand.
Every run produces the matrix and the sign-off record as artefacts.
TCG is not a test management tool and does not replace one. It produces what a test management tool expects to be given, out of what your analysts have already written.
Point a run at a BRD, a set of Jira items and any context documents that govern them. What comes back is a suite, not a summary of one.
A run is unique per document, context and answer set.
Before generating anything, TCG grades what it was given — and says which sentences will not survive contact with a tester.
Critical findings block generation on purpose.
Generated output nobody accepted is a draft. TCG puts a name against each stage and keeps what they decided.
A run is not closed until the approvers say so.
TCG owns the middle: turning prose into a traceable suite. What feeds it and what consumes it stay exactly where they are.
Requirements come from the tools your analysts already use. Suites, scripts and evidence leave in the formats your test management, automation and audit processes already accept. Nothing in the middle asks anybody to change tools.
A run is a sequence, not a button. Each stage produces something a person can read, argue with and accept — which is the difference between generated output and generated output somebody will sign.
The documents, Jira items and answered clarifications a run is generated from. A run is unique per document, context and answer set — change one and it is a different run.
Every requirement graded against the ISO/IEC/IEEE 29148 characteristics — verifiable, unambiguous, consistent, complete, singular, traceable — and the exact sentences that cannot be tested as written.
Scenarios by design technique — boundary, equivalence, state transition, decision table — each traced back to the requirement it covers.
Steppable cases with data, preconditions and expected results. The suite itself, not a description of one.
Playwright, Selenium or REST Assured suites generated from the cases above. Optional, because plenty of teams stop at the cases.
The traceability matrix, the suite as Excel or CSV, the run written up as Word or PDF — versioned back into the project it came from.
What happened when the cases were actually run, read back against the requirements — so coverage is a measured number rather than a claimed one.
Stage 5 is optional, and stage 7 depends on somebody actually running the suite. The other five happen on every run, and each one can be sent for review before the next begins.
The pattern is the same in each: a lot of requirement text, a release date that does not move, and somebody who will be asked afterwards to justify the coverage.
Long requirement documents, cases in the thousands, and a cutover window measured in hours. Regenerating per release matters more than generating once.
Where a release needs a named reviewer and a named approver, and the record of both has to outlive the release.
Systems documented once, years ago, with a test estate that grew by accident. Grading the documents is often the first honest picture anyone has had.
Requirements are commercially sensitive, and generated output is only useful if somebody trusts where it came from. Both deserve a straight answer before you upload anything.
What you upload is yours: readable by the people you put on the project, exportable whenever you want it, and deletable. Requirements are not used to train anything.
Every generated scenario and case carries the requirement it came from, and every requirement carries the cases that cover it. The matrix is generated from that link rather than maintained beside it.
Reviewers and approvers are set per project and per run. A stage can be sent for review before the next one starts, and what each person decided is kept against the run.
Token consumption is visible per person and per client, with the allowance and what is left of it on the same screen — before a run is started, not after it has finished.
Departments, projects and people are your own structure. Who can generate, who can approve and who can only read is set against that structure rather than a flat list of users.
Suites export as Excel or CSV, runs as Word or PDF, scripts as source, and cases push to Jira. Nothing about the format assumes you will still be here next year.
TCG is built by Adaps Group — a family-owned engineering and managed services firm, not a startup with a demo. Test estates for systems where a failed release has operational consequences are the day job.
Six decades of continuous operation, headquartered in Melbourne with entities in Australia, Singapore, India and the United States — so contracting and data residency can follow the customer.
An engineering centre in Hyderabad under its own head of engineering, built for sustained multi-year delivery. TCG is our own platform work, run by the people who do the testing.
Requirement grading follows the ISO/IEC/IEEE 29148 characteristics as published. Where a standard governs the work we buy it and read it, rather than inferring behaviour from somebody’s documentation.
Monitored operations with playbook-driven triage and a 30-minute critical response commitment, running today for enterprise customers — the discipline behind the platform, not a promise about it.
Shown as direction rather than inventory. Neither is finished, and we would rather have design partners than an announcement.
A requirement moves a version and the affected cases regenerate themselves — everything else carries forward untouched, with the diff shown before anything is accepted.
Partially live today as incremental runs.
Percentage covered treats every requirement as equal, and no release does. The headline number should weight what breaks expensively.
Looking for two design partners.