Software QA and testing
Manual and automated testing from Ho Chi Minh City for teams in the UK, US and Australia. We test what ships, including the parts that touch hardware, migrations and regulated data.
Ask for a test plan See where we have tested
First engagement is usually one release. If we find nothing worth the money, you stop there.
| Automated regression Selenium suite, 412 cases | Passed |
|---|---|
| Device matrix Android and iOS, 9 devices | Passed |
| Migration check Row counts and checksums, both systems | Matched |
| Instrument reading Bluetooth torque value versus device display | 3 defects |
| Security pass Access control and data handling | Passed |
The honest question first
Bringing testers in from outside works in some situations and fails in others. Here is how we read it before quoting.
Keep QA in house when
Outsourced QA needs onboarding like any hire. Without it you get bug reports nobody can act on.
Bring us in when
This is our work. Both of our largest engagements involved recovering quality on a codebase another vendor had left behind.
What we test
No capability listed here is theoretical. Each comes from a project already delivered.
Our work
Case study, Norway
A Norwegian EdTech company had to move years of sensitive student data onto a rebuilt platform while schools kept using the old one. A previous vendor had already missed the delivery date, and the deadline with schools was contractual. A separate team worked on migration alone, with security work covering SPT, SSAT and NVA, and we stayed on for 60 days of warranty after go-live.
Case study, Germany
A German cloud-native software firm came to us after another vendor left a project with poor code quality and missed dates. QA engineers were part of the core team from the start, running manual and Selenium coverage alongside the developers rather than as a separate gate at the end. The engagement grew into a dedicated core team plus an on-call group for urgent work.
Plain definitions
These come up on almost every first call, and getting them clear saves a wasted procurement round.
Paying an external team to test your software instead of hiring testers. It comes in three shapes: a one-off engagement on a single release, testers embedded in your sprints, or a managed function where the supplier owns test strategy and sign-off.
The word outsourcing hides the important variable, which is who decides what good enough means. On a one-off that stays with you. On a managed arrangement it moves, and that has to be deliberate.
Automation pays where a test runs many times without changing: regression before every release, checks across a device matrix, reconciliation during a migration. The suite costs money to build and keeps earning.
Manual pays where judgement is needed: a new feature nobody has used, an interface being assessed for whether it makes sense, hardware behaviour in the real world. Automating an unstable feature produces a suite you rewrite every sprint.
Where we have done this
We list four because we have shipped in four. A longer list would be a list of industries we would like to work in.
How the work runs
We would rather prove the value on a single release than ask you to sign a year of testing up front.
Week 1
We work through your product with someone from your team, read what test coverage exists, and write down what is currently untested.
Week 2
Scope, priorities, device matrix, what we will automate and what stays manual. You approve it before we test anything.
One release
Full pass on a real release, with defects logged the way your developers want them. You see whether it was worth the money.
Ongoing
Either our testers join your cadence permanently, or we hand over the suites and documentation and step back.
Tools and coverage
Every item here comes from something already shipped, not from a list of things we could learn.
Who does the work
Small for an offshore QA supplier, and deliberately so. The testers who write your test plan are the testers who run it, and you meet them before you sign anything.
Three ways to work with us
A trial that produces real work
QA inside your team
We own the whole function
How we work
The models differ in one thing: how much of the management you hand over. Everything else, including who owns the code, is the same in all five.
Changing model later is normal. Augmentation into a dedicated team is the common direction, and the people stay.
Engineers join your team and work inside your process, your board and your code review.
A team that works only on your product, with a lead on our side running delivery.
A long-term engineering site under your standards, where we carry recruitment, HR, payroll and equipment.
04
One price for a scope that is genuinely settled, with the overrun carried by us.
Everything in the centre model, with the whole team moving into your own Vietnamese entity on an agreed date.
FAQs
Yes, and we prefer it. One release gives you a defect report you can judge on its merits. If it was not worth the money, you stop there and keep the test plan.
Both. We build Selenium suites and hand them over with documentation so your own team can run and extend them. Automation that only we can maintain is not much use to you.
Yes. We have tested apps that read live values from measuring instruments over Bluetooth, where the check is whether the number in the record matches the number on the device.
We test them as their own workstream: row counts, checksums and spot checks across both systems. On the Norwegian platform this ran alongside the build and nothing was lost.
In your tracker, in your format, with steps to reproduce, environment and severity. A screenshot with the word broken under it is not a defect report.
Ho Chi Minh City, working the overlap hours you need. Vietnam is 6 to 7 hours ahead of the UK, so we usually cover your morning and hand over results before your afternoon.
Paying an external team to test your software instead of hiring testers. It comes in three shapes: one engagement on a single release, testers embedded in your sprints, or a managed function where we own test strategy and sign-off.
A first engagement on one release is priced as a small fixed project. Ongoing embedded testers are priced per person per month. The first call ends with a number for your release cadence rather than a range.
Yes. Test plans, cases and automation suites are handed over with documentation and belong to you, so you are never locked into us to run your own regression.
Several hold ISTQB. We would rather you judge the first release than the certificates, but they are there if your procurement process asks.
Send us the product and how you ship it. You get a test plan, then a full pass on a real release, and a report you can judge on its own.
