QA tools and test automation technologies
None of the four tools here is really a purchase decision. A team whose tests fail at random still has tests that fail at random after buying a bigger licence. This page is about what makes an automated suite worth trusting, and where testing by hand is still right.
01Capabilities
Four kinds of testing work, and none of them is a tool purchase
The tools sit underneath the work rather than being the work. All four run inside our QA and test automation practice.
Regression suites, built from written cases
The checks you re-run before each release exist as something a person can read before they exist as code. A suite that starts as code covers whatever was easy to automate.
Coverage pushed down a layer
Checks against the services under the screen, doing work people ask browser tests to do on the long-lived systems behind our fintech work. Seconds to run, one reason to fail.
Browser and device breadth, sized to your traffic
A target list built from your own visitor numbers, not a vendor catalogue, run against rented real phones and browsers on a service like BrowserStack. On e-commerce front ends one broken mobile browser is lost revenue.
Rescuing a suite nobody trusts
An inherited suite that fails at random is worse than none: it teaches the team that red means nothing. We fix the causes rather than hide them behind retries, and an outside verdict first is a quality audit.
02Stack
What each of these four is still the right answer for
One row per tool page, with the honest reason to reach for it or leave it alone. Every row has one destination, so the whole row is the link.
| Tool | What that means in practice |
|---|---|
| Selenium | Widest browser listIt drives real browsers through a standard the browser makers implement themselves, which is why it survives a browser list set outside engineering.Selenium automationOr book a meeting |
| BrowserStack | Devices you lackRented real phones, tablets and browsers, under whichever suite you already have. For a few desktop browsers, running your own containers is cheaper.Device and browser coverageOr book a meeting |
| TestCafe | Keep, do not startRight to keep where a working suite already exists in it: the value is the coverage, not the framework. We would not choose it for a new suite today.TestCafe automationOr book a meeting |
| TestNG | Legacy Java packsEarns its place on large existing Java suites that declare grouping and ordering outside the code. On a new Java project we would reach for JUnit 5.TestNG for Java suitesOr book a meeting |
03Fit
When a different tool is the answer, and when no tool is
Tool choice matters less than almost anyone selling tools will admit. In three of the six situations below, the answer is Playwright, JUnit 5 or the suite you already have. Worth settling before you spend a quarter on a migration that adds no coverage.
| Your situation | What we recommend |
|---|---|
| A new browser suite, a JavaScript team, and a product that only needs Chrome and Safari | PlaywrightThe default we recommend for a new JavaScript suite. It was built after the industry learned what makes browser tests fail at random, so waiting and isolation are defaults. |
| A wide real-browser list including Safari and Edge, set by IT policy rather than chosen | SeleniumSelenium drives browsers through a standard the browser makers implement themselves, and that breadth is what lighter tools only partly match. |
| A Java product, a Java build and Java engineers | Stay in JavaSelenium with TestNG under it. A second toolchain purely to run tests is a permanent cost with no return, and the suite belongs in the language the team maintains. |
| A new Java project, nothing chosen yet | JUnit 5JUnit 5 rather than TestNG. Grouping, parameters and running tests together are all there now, and more Java engineers read it. TestNG earns its place on large legacy packs. |
| You need devices, system versions or browsers you do not own | Rented devicesThat is BrowserStack or an equivalent, under whichever suite you have. For a few desktop browser versions, running your own containers is cheaper. |
| A suite that exists, and that everybody has stopped trusting | Fix the suite firstNot a new tool. A rewrite inherits the same unreliable tests and throws away coverage you have paid for. Waits, selectors and test data first; the tool decision then becomes optional. |
Scope
What we own is the suite as an asset, not the number of tests in it. That means which layer each check belongs in, how it keeps giving the same answer while the product changes underneath it, and what is deliberately not covered. Where the right answer is fewer browser tests and better ones, that goes in writing. Our QA engineers are ISTQB certified, the international testing qualification, and sit in every sprint. We work to ISO 27001:2022 and ISO 9001:2015, audited by Quay Audit UK.
04Delivery
What separates a suite people trust from one they ignore
Four properties, in the order we establish them on a suite somebody else wrote. None is a feature of any tool here.
- A measured rate of random failure, not an impressionRun the suite repeatedly against a build that has not changed and record which tests disagree with themselves. Until that number exists, every conversation about quality is opinion.
- Tests that depend neither on timing nor on each otherMost random failures come from waiting a fixed number of seconds instead of waiting for something to happen, and from tests sharing accounts or records. Each test makes its own data and removes it afterwards.
- A shape that is wide at the bottomMost inherited suites are top-heavy: slow browser tests doing work a check one layer down could do in a tenth of the time. Deciding which layer each check belongs in is the highest-leverage change available.
- A red build that still means somethingA test known to fail at random, left blocking the pipeline, gets ignored. Then the suite does, then the gate does. Set aside with a named owner and a deadline, it gets fixed instead.
05Case studies
Independent QA on somebody else's product
We match the tool to your browser list, your devices and the language your team writes. Trust in the results comes from a layered suite, repeatable tests and a named owner. We put those three in place, whichever tool runs the suite.
Ihor PrudyvusDelivery Director, unicrew06Questions
What teams ask before changing how they test
You can bring our QA engineers onto your team, and that is normal. They own the suite design as well as the tests, because layering decides how much test debt a suite carries. Team extension is managed teams; handing over the outcome is QA and test automation.
Playwright, in most cases we see, and none of the pages under this cluster will tell you otherwise. Selenium still wins when the browser list is wide and set outside engineering, because the browser makers implement its driving standard themselves. TestCafe stays right where a working suite already exists in it.
Automate the checks that are stable, repeated and expensive by hand, starting with the release regression path and the services under the screen. Leave screens still changing every sprint until they settle, and keep anything where the verdict is a judgement in human hands permanently. That is a full-cycle testing position rather than automate-everything.
Fix it, at least far enough to know what you have. Random failure is rarely the framework: it comes from waiting a fixed number of seconds instead of waiting for something to happen, selectors tied to markup that changes weekly, and tests sharing data. A rewrite carries all three into the new tool.
A scoping call with a QA engineer, not a salesperson. If a suite exists we ask for read access to it and to the last few weeks of build results: the pattern of failures tells us more than any description. What comes back is written: what we would fix first, what we would delete, what stays manual. Work starts two to four weeks after scope is agreed.
Services we deliver in QA Tools & Technologies
All servicesA suite nobody trusts, or nothing to trust yet?
Send us the suite and the last few weeks of build history, or tell us what has to be covered if there is nothing yet. You get an engineer's read, including a suite sized to what actually needs covering.