01 · Software testing & QA
Test engineering that proves software behaves under real conditions.
1722 designs and builds the test engineering behind software that ships with confidence: a test strategy set against your risk, automated test frameworks wired into CI, regression and end-to-end coverage that runs on every build, performance and load testing under realistic traffic, and focused manual and exploratory testing where judgement matters more than a script.
Applied directly by a senior engineer, on a written statement of work.
What we do
Five disciplines, engineered as one practice.
Each stands on its own or as part of one programme — the strategy decides the mix, not a default toolchain.
- 01
Test strategy
A test plan set against actual risk: what needs automated coverage, what needs manual eyes, what a release can and cannot ship without.
- 02
Test automation frameworks
Automated suites built for your stack — unit, integration and end-to-end — maintainable by your team after handover, not a black box.
- 03
CI & pipeline integration
Suites wired into GitHub Actions, GitLab CI, Jenkins or your existing pipeline, gating merges and reporting where your team looks.
- 04
Regression & end-to-end
Coverage that runs on every build, catching what a change breaks elsewhere before a release does.
- 05
Performance & load testing
Load, stress and soak testing under realistic traffic and data, with the bottleneck identified and evidenced.
When you need it
The moments that bring us in.
| Before a launch | A release date is set and there is no confidence the software holds up under real use. |
|---|---|
| A flaky or missing suite | Tests exist but are not trusted, run too slowly, or do not exist at all. |
| A release you cannot trust | Regressions keep reaching production and nobody can say why the suite missed them. |
| Performance that falls over under load | The system works in the demo and buckles at real traffic or data volume. |
What you get
Deliverables you own.
Every engagement ships concrete artefacts your team keeps and can act on — never advice alone.
- Test plan — strategy, scope and risk-based prioritisation, documented
- Automated suites — unit, integration and end-to-end tests, version-controlled and yours to extend
- CI configuration — pipeline set-up so suites run and gate merges automatically
- Defect reports — found issues, reproduction steps and severity, tracked to closure
- Coverage reporting — what is covered, what is not, and why
- Performance results — load-test evidence with bottlenecks identified, where in scope
How we engage — starts with a short review of the codebase, existing coverage and current pain points, then a scoped test plan before any suite is built. Engagements run as a fixed-scope build-out, an ongoing T&M arrangement matched to a release cadence, or a bounded engagement to stabilise and extend a suite you already have.
Ship the next release with confidence.
Tell us what is shipping and what is at risk. A short discovery call, then a scoped plan.
FAQ
Software testing & QA, answered.
Do you do manual testing, or only automation?
Both, applied where each earns its place. Automation carries regression, integration and end-to-end coverage that has to run every build. Manual and exploratory testing is used where judgement beats a script — new features, edge cases, usability and anything automation would not catch on its own. The strategy sets which is which; it is not automation for its own sake.
Which test frameworks and tools do you use?
Chosen to fit your stack and CI rather than a fixed toolchain — Playwright, Cypress, Selenium and native language frameworks (pytest, JUnit, xUnit and similar) for functional and end-to-end work; k6, JMeter or Locust for performance and load. The framework is picked and justified during test strategy, not assumed up front.
Do you set up CI, or just write the tests?
Both. Test suites are wired into your pipeline — GitHub Actions, GitLab CI, Jenkins or whatever you already run — so they execute automatically on every commit or pull request, gate merges on the criteria you set, and report results somewhere your team actually looks.
Can you test software you did not build?
Yes — most engagements start on an existing codebase. Testing is engineered against the behaviour and requirements of the system as it stands, not against knowledge of how it was written. Onboarding starts with a short review of the codebase, existing coverage and current pain points before any test is written.
Do you do performance and load testing?
Yes. Load, stress and soak testing against realistic traffic and data profiles, with the bottleneck — database, application tier, network or a specific endpoint — identified and evidenced, not just a pass/fail number. Useful ahead of a launch, a peak-traffic event or after a change that touches throughput.
How is this scoped and priced?
Day-rate, time-and-materials, retainer or fixed-scope against a written statement of work, matched to what the engagement needs — a fixed-scope test strategy and automation build-out, or an ongoing T&M arrangement covering a release cadence. Discussed and agreed on the discovery call before any work starts.
What if we already have a test suite, just not a good one?
Common starting point. The existing suite is reviewed for coverage, reliability and speed — flaky tests, missing coverage and slow-running suites are diagnosed first, then stabilised and extended rather than thrown out and rewritten from nothing, unless a rewrite is genuinely the faster path.