Selenium test automation
Selenium is the suite most teams already have and fewest teams still trust. Three things bring people here. A list of browsers somebody else decided you must support. An inherited suite where a red build means nothing to anyone. And a plan to add more browser tests, which is usually the wrong plan.
01Capabilities
Where a red build stopped meaning anything
Selenium drives real browsers through the W3C WebDriver protocol, which the browser vendors implement themselves. That is why it survives wherever the browser list is wide or set by somebody outside engineering. We take it on inside our QA and test automation practice rather than as a pile of scripts, and our QA engineers are ISTQB certified and sit in every sprint.
- Breadth
Checks that pass on every browser you support
The set that has to be green on every build, running on Chrome, Firefox, Safari and Edge rather than on one engine and a hope. Genuine breadth is the thing this tool still gives you that lighter ones only partly match.
- Estate
Back offices older than the current framework fashion
Admin screens, resource planning systems and internal portals of the kind behind our logistics work, where the front end predates everything modern and the supported browser list comes from a policy document.
- Rescue
A suite that trained the team to ignore it
An inherited suite failing at random is worse than no suite, because it teaches people that red means nothing. We find what is actually unstable, fix the causes instead of hiding them behind retries, and where you want an outside verdict we run a quality audit first.
- Parallel
Running the whole thing unattended on every change
Parallel execution on a containerized grid, wired in so nobody has to remember to start it. That is usually a Docker and pipeline problem rather than a test problem, and it overlaps with our DevOps work.
02Fit
Breadth of browsers against the cost of determinism
Selenium is the safe answer more often than it is the best answer, and the difference costs money every sprint. It wins on browser breadth, language choice and an ecosystem two decades deep. It loses on developer experience, and on how much work it takes to make a test give the same result twice. Five of the six rows below send you somewhere other than a new Selenium build with us, and two of them name a tool we do not sell.
| Your situation | What we recommend |
|---|---|
| A wide real-browser list including Safari and Edge, mandated rather than chosen | Use SeleniumVendor-implemented driver support across every major browser is the reason it is still here, and no lighter tool substitutes for it. |
| An existing Java or C# suite that runs green in your build today | Keep itPair it with TestNG on the Java side, and spend the budget on the paths nobody tests rather than on a runner migration. |
| A new suite, a JavaScript team, and a product that only has to work in two engines | Not SeleniumPlaywright gives you automatic waiting, isolated browser contexts and trace-based debugging as defaults. We do not sell it and have no page for it. |
| The real complaint is that nobody trusts the suite | Not a new toolA rewrite carries every unstable test into the new framework and throws away coverage you already paid for. Waits, selectors and test data first. |
| Thin unit and API coverage, and the plan is to add more UI tests | Fewer testsThe answer here is fewer browser tests, not a different runner. Push coverage down to the service layer and keep what is left small and meaningful. |
| You need browsers, operating systems and devices you do not own | Different problemNot a framework decision at all. That is BrowserStack or an equivalent device cloud, running whichever suite you end up with. |
Scope
We own the suite as an asset, not the number of tests in it. That means which layer each check belongs in, and how it keeps giving the same answer while the product changes underneath it. It also means whether your own people can maintain it once we step back. Our QA engineers are ISTQB certified and sit in every sprint. unicrew has built and tested software since 2012. We have 100+ senior in-house engineers across six countries. We work under an ISO 27001:2022 certified information-security management system. Where the honest answer is fewer browser tests and better ones, we write that down.
The reason test suites get abandoned is almost never the tool. It is that they became slow and occasionally wrong, and a suite people do not trust is worse than no suite, because it teaches everyone to ignore a red build. We would rather run a small number of tests that always mean something than a large number somebody reruns until they pass.
Ihor PrudyvusDelivery Director, unicrew03Delivery
Making an inherited suite trustworthy again
This is the order we run on a suite somebody else wrote, and step one is not optional.
- Measure how often it disagrees with itselfRun the suite repeatedly against an unchanged build and record which tests give different answers. Until that record exists, every conversation about quality is opinion, and it also tells you which tests are worth fixing and which to delete outright.
- Remove the fixed sleeps and the global waitsWaiting for a fixed duration, and a blanket wait applied to everything, are the two largest sources of instability in real suites, and they interact badly with each other. Waiting on a condition fixes more red builds than any change of tooling.
- Give every test its own dataTests that share accounts and fixtures pass alone and fail together. Isolated setup per test is what makes running them at the same time safe, and running them at the same time is what keeps the build inside a duration people tolerate.
- Put a quarantine lane in the pipelineA known-unstable test that blocks everybody gets ignored, and then the whole suite does. Quarantined with a named owner and a deadline, it gets fixed. The suite has value only while a red build still means something. Every sprint runs through the same testing and QA practice we use on our own builds.
04Stack
What drives the browsers and what runs them
The four neighbours of a browser-suite decision, each with its own page if that is the call you are really making.
05Questions
Questions about a suite people stopped reading
The six that come up before anyone rewrites or deletes anything. If yours is not here, it is a good first message.
Yes, and that is a normal way to start. What we will not do is supply hands and leave the suite design to chance, because a badly layered suite is the most expensive kind of test debt there is. The architecture gets reviewed by an engineer outside the delivery team, and the work runs through the same testing and QA practice as our own projects. Capacity is managed teams.
For a new suite on a modern web application, usually Playwright. It was designed after the industry had learned what makes browser tests unstable, so automatic waiting, isolation and trace-based debugging are defaults rather than things you build. Selenium still wins on two counts: the browser list, because vendors implement the driver themselves, and the weight of what already exists inside a Java or C# build.
Fix it, at least far enough to know what you have. The cause is rarely the framework. It is waiting on durations instead of conditions, selectors tied to markup that changes weekly, and tests sharing data. A rewrite carries all three into the new tool and discards coverage you already paid for. Once it is stable, changing frameworks becomes an optional decision rather than a rescue.
Java, C#, Python and JavaScript are all real options, and the right one is the language your engineers already read rather than the one with the nicest documentation. If the product is a Java system, the suite belongs beside it in Java, usually with TestNG underneath. If your team is TypeScript throughout, adding a JVM purely to run tests is a cost with no return.
A scoping call with a QA engineer rather than a salesperson. If a suite exists, we ask for read access to it and to the last few weeks of build results, because the pattern of failures tells us more than any description of it. What comes back is written: what to fix first, what to delete, and what to leave alone. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we offer it once the first read is done, because a fixed number on a suite nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Red builds nobody reads any more?
Send us the suite and the last few weeks of build history. If there is nothing yet, tell us what has to be covered. You get an engineer's read on it, including the version where you write fewer browser tests than you planned.