01
Test strategy
What gets tested, at what level, and why. Coverage aimed at the paths that carry consequence rather than spread evenly to satisfy a number.
Capability / Quality engineering
Testing run by people who understand the system.
Test strategy against real risk, manual and automated coverage, release verification that catches faults before your users do, and support for whoever has to sign acceptance off.
Coverage
What the discipline covers.
Quality engineering is not a headcount of testers. It is deciding what is worth testing, proving it, and leaving a record that someone can rely on when they sign.
02
Manual and exploratory
Testers who learn the domain and go looking for what a scripted pass would never find, because they understand what the system is for.
03
Automated regression
Suites that run on every change, written to survive an interface change rather than break on one and get switched off.
04
Release verification
A defined pass before a release lands and a defined pass after it, so a regression is found by us rather than reported by a user.
05
Acceptance testing support
Scripts, environments, data and a person on hand while your business users run acceptance and record what they find.
06
Defect management
Reproducible reports with the evidence attached, triaged by severity, tracked in your tracker through to closure.
Depth
The kinds of quality work we take on.
From standing a function up to verifying a single release on a system somebody else built.
| Type of work | What it involves | How it is engaged |
|---|---|---|
| A QA function you do not have | Strategy, environments, test data and a working suite, then the people to run it week after week. | Managed pod |
| Testers into an existing team | Engineers into your process, your tracker and your definition of done, working alongside your developers. | Dedicated people |
| Automation on a manual estate | The regression paths automated first, measured by how much they take off the manual pass rather than by suite size. | Project delivery |
| Release verification only | A defined pass before and after each release, against the risks you name. | Dedicated people, business as usual |
| Acceptance testing support | Environments, data, scripts and support while your users test and sign the release off. | Project delivery |
Technology and people
What we work with, and who does the work.
Automation is chosen against what your pipeline already runs. A suite nobody on your side can maintain is a liability, not an asset.
Automation
- Playwright
- Cypress
- Selenium
- API test suites
Platform testing
- Salesforce Apex test classes
- Mobile device testing
- Cross-browser testing
- Accessibility checks
Practice
- Test plans and cases
- Risk-based coverage
- Defect triage
- Release checklists
Tooling
- Jira and equivalents
- Test case management
- Continuous integration pipelines
- Evidence capture
Roles and seniority available
QA lead
- Strategy, coverage and release sign-off
- Answers for the quality of the team
- Direct with your stakeholders
Test automation engineer
- Suites that run inside your pipeline
- Senior and mid-level
- Maintains what they write
Manual test engineer
- Functional, exploratory and regression passes
- Senior, mid-level and associate
- Learns the domain, not just the script
Salesforce QA engineer
- Org, CPQ and portal regression
- Senior and mid-level
- Verification across seasonal releases
Inside your team
How the work runs alongside your developers.
Testers sit inside the delivery team rather than at the end of it, which is the only way a defect gets cheaper to fix.
Your tracker, your gates
Defects are raised where your team already works, at the severities you already use, and follow the same path to closure as everything else.
- Your tracker and your fields
- Your severity definitions
- No parallel process to maintain
Evidence, not opinion
Every defect carries the steps, the environment, the build and the evidence needed to reproduce it. A developer should not have to interview the tester.
- Steps and environment recorded
- Build or release identified
- Screens and logs attached
Sign-off you can hold
A release pass produces a record: what was tested, what passed, what is known and open, and what was deliberately not covered.
- Written verification record
- Known issues stated openly
- Scope of the pass made explicit
Proof
Verification on systems where a fault is expensive.
We describe the work, not the client.
What it evidences
Quality held on live and regulated systems
- Changes to a production Salesforce estate proven outside production before release
- Faults traced to their origin across configuration, code, data and integration rather than patched at the symptom
- A quoting and order path kept available through seasonal platform releases set by the vendor
- Approvals and audit logging built into a regulated manufacturing system as part of normal work
Business-as-usual ownership of a CPQ-centred Salesforce estate at a specialty manufacturer
Ongoing ownership of a production Salesforce environment built around CPQ, covering configuration and custom features, ERP and shipping integrations, a customer community and day-to-day org support, held by one team.
Read the case studyMRP system built for a manufacturer operating under FDA compliance requirements
An MRP system in use at a company operating under FDA compliance requirements, covering product lifecycles, orders, workstations and audit trails.
Read the case studyNext step
Tell us what you cannot afford to ship broken.
Send the system, the release cadence and the sign-off you need. You will get named testers, seniorities and a start date.