Software Testing & QA
Two ways to get your product tested: a trained manual testing team that runs cycles on demand, or an automated testing system you own that runs on every release. Take either one, or both together.
Two ways to get your product tested
Pick one, or run both Apex Automation Team offers manual testing by a trained QA team and automated testing you own as two separate options. Some clients take only the team, some take only the suite, and most end up with both because they solve different problems. If you are weighing them up, the rule we use to decide what gets automated is written out in full.
Option 1 : A trained manual testing team
A test team without the hiring Vetted testers who are briefed on your product run cycles on demand, on real phones, tablets and desktop browsers. A cycle mixes a smoke pass, scripted test cases, guided exploratory sessions and a regression pass. Every finding is reproduced and triaged by a lead before it reaches you, so what lands in your tracker is a fixable report rather than noise. Cycles are scheduled around your release, and how the team is briefed and run is no secret.
Option 2 : An automated testing system
Regression that runs itself We build a suite in Playwright, Puppeteer or Cypress, wire it into GitHub, GitLab or your CI, and run it on every pull request and nightly. You own the repository and the documentation, and we maintain it as your UI changes. It never gets bored, never skips a step and catches the things you fixed three months ago. Keeping a suite believable matters more than its size, which is why we follow strict rules about tests that pass and fail at random.
Both together
The team finds it, the suite guards it The usual path is a manual cycle first on your critical journeys, then automation of whatever has settled, so the testers move on to new features while the suite protects everything behind them. You can start with either option and add the other whenever you want.
What we test
- Functional & user-story testing: every flow behaves exactly as the ticket says it should.
- Exploratory testing: guided sessions where a tester hunts for the bugs a checklist never finds.
- Regression testing: a manual regression pass, an automated suite in Playwright, Puppeteer or Cypress, or both.
- Cross-browser & cross-device: Chrome, Firefox, Safari and Edge; real Android and iOS devices and viewports.
- Checkout & payment flows: carts, coupons, taxes, subscriptions and refunds, in sandbox or with controlled live transactions.
- Accessibility (WCAG 2.2): keyboard, contrast, labels and screen-reader behaviour, with the exact failing rule.
- Localisation & translation: layout breaks, truncation, currencies, dates and right-to-left text.
- Load & performance: how many users the app survives, where it slows and what breaks first.
- API testing: contracts, status codes, auth, rate limits and edge-case payloads.
- AI feature testing: prompts, guardrails, hallucination and cost checks for LLM-powered features.
What you receive
- Bug reports a developer can act on: steps to reproduce, screen recording, console log, network trace, environment and severity, triaged before they reach you.
- A test plan and coverage matrix you approve before the cycle starts, so you can see what is tested and what is not.
- With the manual option: cycle summaries by severity and a plain recommendation on whether the build is safe to release.
- With the automated option: a reusable regression suite you own, with documentation and maintenance.
- Scheduled runs (nightly, pre-release or on every push) with pass/fail alerts.
- Retesting of every fix, so a closed ticket is verified closed.
How it fits your workflow
- 1. Scope (free): you send the app or URL and the critical flows; we map coverage and risks and tell you which option fits.
- 2. Manual cycle: the trained team runs a pass over the critical journeys and reports triaged findings.
- 3. Automate (optional): the stable flows become an automated suite wired into GitHub, GitLab or your CI.
- 4. Report: results land in Jira, ClickUp, Slack, Google Sheets or e-mail through n8n, Zapier or Make.
- 5. Run forever: scheduled regression, with maintenance when your UI changes.
Frequently asked
Which option should we start with, the manual team or the automation?
Start with the trained manual testing team if the product is changing fast or has never been tested properly, because people find the problems a script was never told to look for. Start with the automated testing system if the flows are stable and the same checks are repeated on every release. Most clients end up running both.
Who are the manual testers and how are they briefed?
A small, named team assigned to your product, not a rotating crowd. Each tester gets a written charter covering the journeys in scope, the devices, browsers, countries and accounts to use, and the data to work with. A lead reviews and de-duplicates every report before it reaches you, so you read findings rather than noise.
What does a manual test cycle deliver?
A cycle covers smoke checks, scripted cases, guided exploratory charters and a regression pass on what was fixed last time. Every bug arrives with the steps to reproduce it, a video or screenshot, console and network detail, the exact device and build, and a severity. Fixes are retested in the next pass and the report says what closed.
How quickly do we get results?
That depends on the size of the product and how many journeys are in scope, so the schedule is agreed after we have seen the build rather than guessed before it. Critical bugs are never held back for the final report: they are sent as soon as they are confirmed. An automated suite follows the same rule, with the timeline set by the number of flows being covered.
Do we own the automated tests?
Yes. The suite is written in Playwright, Puppeteer or Cypress, documented, and handed over in your repository so it runs in your CI without us. We can keep maintaining it or step back once your team is comfortable.
Which devices and browsers do you test on?
The ones your own analytics show, not a generic top-ten list. We tier them: the top platform versions crossed with the top vendors run on real devices and block a release, a second tier covers the tail where emulators are acceptable for layout and logic, and a third covers form factors such as a tablet, a foldable and a low-memory phone. Real Safari on a real iPhone is always included if you have iOS traffic.
How are bugs reported and ranked?
Every finding carries numbered steps from a clean state, expected against actual, a screen recording, console errors and the failing network request, the exact device, build and account, and how reproducible it is. Severity runs from critical (no workaround, data or money affected) to trivial (cosmetic). Severity is ours to assign from evidence; priority stays yours, because that is a scheduling decision.
What happens to a bug after you report it?
It lands in the tracker your developers already use, and critical findings are pushed to Slack or e-mail as soon as they are confirmed. On the next build every fix is retested and the area around it is checked for damage, and a ticket is only closed on a build where the fix was seen working.