Managed QA
Crux owns the testing function month to month: coverage, execution, maintenance, triage and reporting. Your engineers stop writing tests and start reading results.
Fits teams where QA is absorbing developer time and no one owns the suite.
AI software testing · Saudi Arabia
Your test suite passes. That isn’t the same as working.
Crux rebuilds QA around what AI is genuinely good at — generating coverage at volume — and keeps engineers doing what it cannot: deciding what actually matters.
01 — The problem
How suites quietly stop testing anything
Test suites decay in a predictable sequence. They start deliberate. Then a deadline arrives and a failing test gets skipped rather than fixed, because skipping takes a minute and fixing takes an afternoon. Nobody logs the decision.
A year later the suite runs for forty minutes, fails intermittently for reasons no one has traced, and developers have learned to re-run it until it goes green. At that point it has stopped being a safety net and become a toll booth — and defects it would once have caught start reaching production.
The root cause is economic, not technical. Writing and maintaining tests competes against shipping features, and features win every sprint, in every company, forever. Anything that makes coverage cheaper to produce and cheaper to keep alive changes that arithmetic. That is the whole argument for putting generation into QA.
- A suite that passes but tests little, because assertions were weakened to stop failures
- Flaky tests nobody owns, quarantined years ago and never revisited
- Coverage concentrated on easy paths, with risky integration seams untested
- Manual regression cycles that grow by a day with every release
- No measured defect escape rate, so QA value is argued rather than evidenced
- Arabic and right-to-left behaviour tested by hand, or not at all
A model reading your app assumes current behaviour is correct behaviour.
Which means it will confidently write a passing test for your bug. That single limitation determines the whole design of this service: generation proposes, engineers decide, and nothing enters a suite unreviewed.
02 — How it works
Generate, review, run, maintain
Step 01
900
We read the repository, the existing suite and the last few months of defect history. The output is a picture of reality: what is covered, what is flaky, where defects actually escaped, and how long a release currently takes to verify.
- Coverage and flakiness audit
- Defect escape analysis
- Risk map of untested seams
Step 02
900
Against a code change or an API contract, the model proposes cases: happy path, boundaries, negative inputs, error handling, and the permutations a person writes last and least carefully. These are candidates, not tests.
- Cases proposed from diffs and contracts
- Input and boundary variation
- Draft scripts in your existing framework
Step 03
900
A QA engineer accepts, rewrites or discards every candidate. This is where the value is actually created: weak assertions get strengthened, tests that merely restate current behaviour get cut, and the gaps generation missed get written by hand.
- Every generated test reviewed before merge
- Assertions strengthened, not just present
- Exploratory and usability testing by people
Step 04
900
Merged tests execute in your CI on your triggers. Failures are clustered so one underlying issue reports once instead of forty times, and results land in the channels your team already watches rather than another dashboard nobody opens.
- GitHub Actions, GitLab, Jenkins, Azure DevOps
- Failure clustering and triage
- Results into Jira, Slack or Teams
03 — Engagement models
Three ways to work with us
Capacity when needed
Testers and generation capacity added for a release peak, a migration or a compliance deadline, then scaled back down. No permanent headcount, no long commitment.
Fits teams with QA in place who hit periodic surges.Automation build
A fixed-scope engagement that builds the suite, wires it into your pipeline, documents it and hands it over with training and a maintenance runbook.
Fits teams who will run QA internally and need the foundation built properly.
04 — What we test
Scope set by risk, not by category
Functional and regression
Core flows verified on every change, with the regression pack held inside a runtime budget so nobody is tempted to skip it.
API and contract
Endpoint behaviour, schema conformance, error handling and versioning, tested independently of any interface.
Web and mobile UI
Cross-browser and cross-device behaviour, responsive breakpoints, and native mobile flows on real devices.
Arabic and RTL
Right-to-left layout, bidirectional text, Hijri dates, Arabic input validation and sorting order — a distinct defect class in Saudi applications.
Performance and load
Response times under realistic concurrency, against thresholds agreed in advance rather than judged afterwards.
Security
OWASP-aligned checks in the pipeline: dependency scanning, common injection classes, authentication boundary testing.
Accessibility
WCAG-aligned checks, increasingly required for Saudi government and public-facing platforms.
Data and integration
The seams between systems, where defects concentrate and unit tests never look.
Release verification
A defined gate before production, so go or no-go is decided against evidence rather than instinct.
05 — Your stack
We work in your tools, not ours
Test frameworks
Playwright/Cypress/Selenium/Appium/pytest/JUnit/TestNG/RestAssured/Jest/k6/JMeter
Pipelines and platforms
GitHub Actions/GitLab CI/Jenkins/Azure DevOps/Bitbucket Pipelines/Docker/Kubernetes/AWS Saudi/Azure KSA/Jira/Slack/Microsoft Teams
Existing tests that work are kept. Migration happens only where there is a reason for it.
06 — Questions
Answered plainly
What does AI actually do here?
The volume work: reading a code change and proposing cases, drafting scripts against an existing page or API contract, generating input variations for boundary and negative testing, and clustering repeated failures so a reviewer sees one issue instead of forty. Deciding what matters stays with engineers.
Does this replace our QA engineers?
No, and any vendor claiming otherwise is selling something. Generated tests need review because a model infers that current behaviour is correct behaviour — including your bugs. Generation removes repetitive scripting so engineers spend their time on exploratory testing, edge cases and judgement.
How do you integrate with our CI/CD?
Tests run inside your pipeline, not a separate system. We work with GitHub Actions, GitLab CI, Jenkins, Azure DevOps and Bitbucket Pipelines, and with existing suites in Playwright, Cypress, Selenium, Appium, pytest, JUnit and RestAssured.
Can you test Arabic interfaces?
Yes, and it needs deliberate attention. Right-to-left layout, bidirectional text mixing Arabic with Latin identifiers, Hijri dates, Arabic input validation and sorting order are a recurring defect class in Saudi applications. We cover them explicitly rather than assuming the framework handles it.
How is our source code protected?
Access is scoped to what testing requires, under a written agreement covering confidentiality, data handling and retention. Where policy prevents code leaving your environment, testing runs inside your infrastructure. Test data is synthesised or masked rather than copied from production, per PDPL.
How do we know it is working?
Two numbers, measured from the baseline onward: defect escape rate — bugs reaching production that testing should have caught — and release verification time. Coverage percentage is reported but is a weak proxy, since a suite can cover most lines and assert almost nothing.
Related services
Cloud & DevOps transformation
The delivery pipeline testing runs inside — CI/CD, environments and release automation.
Explore →
Intelligent application engineering
Applications built with coverage from the first sprint rather than retrofitted later.
Explore →
Enterprise application modernization
Legacy systems where the absence of tests is what makes every change expensive.
Explore →
Start here
Find out what your suite is actually testing
A two-week assessment reports your real coverage, your flaky tests, where defects escaped last quarter, and what it would take to fix each — whether or not you engage us afterwards.