Testsigma
Low-code test automation for web, mobile, and APIs. Write tests in plain English and run them across browsers and devices.
Overview
Testsigma is a cloud-based, low-code test automation platform founded in 2018. It enables testers to write automated tests in plain English using NLP (Natural Language Processing), with the platform translating those instructions into executable automation code. Testsigma supports web, mobile (iOS/Android), and API testing in a single platform.
Testsigma is positioned as a more affordable and accessible alternative to enterprise low-code tools like ACCELQ and Tosca. It targets mid-market teams that want codeless automation without enterprise pricing.
What it's used for
Testsigma is ideal when:
- Low-code automation needed: Write tests in plain English without programming.
- Cross-platform testing: Web, mobile, and API tests in one platform.
- AI-powered maintenance: Self-healing tests that adapt to UI changes.
- Mid-market budget: More affordable than enterprise tools like ACCELQ.
Pros & Cons
Pros
- Plain English test authoring
- Cross-platform: web, mobile, and API
- AI-powered self-healing and maintenance
- Affordable pricing for small-to-medium teams
- Cloud-based with local agent option
Cons
- Less mature than enterprise tools
- Limited customisation for complex scenarios
- Smaller community and fewer resources
- Some advanced features require higher tiers
- Performance can be slower than code-based tools
Platforms & Integrations
Testsigma is a cloud-based SaaS with optional local test agents. It supports web browsers, iOS/Android devices, and REST APIs.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Free | Free | Limited tests, basic features, community support |
| Pro | $249/mo | Unlimited tests, parallel execution, advanced features |
| Enterprise | Custom | SSO, dedicated support, custom integrations, on-premise agents |
NZ Context
Testsigma is gaining traction in NZ as an affordable low-code alternative. It is popular with NZ bootcamps and training programmes teaching codeless automation. For NZ teams transitioning from manual testing to automation, Testsigma provides a gentle learning curve.
Alternatives
- ACCELQ — More powerful for enterprise applications but more expensive.
- testRigor — Similar plain-English approach with different pricing model.
- Mabl — AI-powered with stronger visual testing and analytics.
When to choose Testsigma
A quick decision guide for NZ teams evaluating cloud-based test automation options.
| Choose Testsigma when… | Choose something else when… | Combine with… |
|---|---|---|
| Your testers write manual test cases in plain English and you want automation without hiring a developer. | Your team already codes fluently in Python or TypeScript — use Playwright or Selenium directly and keep full control. | Jira for defect tracking and GitHub Actions for CI — Testsigma connects to both natively. |
| You need web, mobile (iOS/Android), and API tests under a single licence and one reporting dashboard. | You need pixel-perfect visual regression — Mabl or Percy integrated with Playwright will give you far stronger visual diff tooling. | Postman for exploratory API testing — Testsigma handles the automated regression layer while Postman stays your dev-facing sandbox. |
| Your budget is mid-market (under NZ$500/mo) and you can't justify Tosca or ACCELQ enterprise licensing. | Your application has heavy custom UI components or complex canvas/WebGL surfaces — codeless NLP struggles here; go code-based. | Xray or Zephyr Scale for structured test management — Testsigma handles execution, Xray keeps your traceability matrix in Jira. |
| Your UI changes frequently and your team spends more time fixing locators than writing new tests — the self-healing engine pays for itself. | You need open-source auditability or must run tests fully air-gapped on-premise — Selenium Grid or Playwright in Docker fits better. | BrowserStack or Sauce Labs for real-device cloud coverage if Testsigma's built-in device lab doesn't cover the exact device/OS mix you need. |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
If…
I were leading QA at a mid-sized NZ fintech like CloudBooks and had a team of three testers — two manual, one automation — with a backlog of 400 regression test cases that nobody has time to automate in Selenium.
I would…
Start a Testsigma Pro trial and assign each manual tester a batch of 50 high-priority regression cases to convert. The plain-English authoring means they're writing automation, not just watching someone else do it. I'd give it 6 weeks: if the self-healing holds up across two sprint cycles and test maintenance time drops by at least 30%, I'd commit to the annual licence. If maintenance is still painful, that's a signal your UI architecture needs fixing first — Testsigma can't paper over constantly-changing locators that aren't the tool's fault.
If…
I were the test lead at TechServNZ delivering a mobile banking app for a major NZ bank client, and the client required cross-platform regression across both iOS and Android on every release.
I would…
Evaluate Testsigma specifically because it covers web, iOS, and Android under one licence — running three separate tool stacks (e.g. Playwright for web, Appium for mobile, Postman for API) triples your maintenance burden on a delivery contract. I'd pair Testsigma with BrowserStack's real-device cloud rather than relying solely on Testsigma's built-in device lab, because client-facing delivery needs exact device/OS combinations documented. Set up the Azure DevOps integration on day one so test results feed directly into the pipeline — don't leave it as a manual step.
If…
I were a lone QA analyst at a government agency like Revenue NZ, inheriting a legacy web portal with no automated tests, a risk-averse procurement process, and no budget approval for enterprise tooling until next financial year.
I would…
Use the Testsigma free tier immediately — no procurement, no sign-off needed to prove value. Automate your 10 most-critical smoke tests first: login, key form submission, and any citizen-facing transaction flows. Document time saved and defects caught, then take that data to the procurement conversation. If the free tier feels too constrained, that's actually a useful discovery: it tells you whether you need a $249/mo Pro licence or whether the constraint is really that you need a developer involved. Don't upgrade to Pro speculatively — earn it with evidence.
The bottom line: Testsigma earns its place when your manual testers become the automation authors — the moment you hand it to a developer who'd rather write Playwright, you've spent money to slow someone down.
Interview questions
Questions you are likely to get if you list Testsigma on your CV — with what interviewers are really testing for.
Why would you choose Testsigma over Playwright or Selenium for a regression suite?
What they’re really testing: Whether you understand the trade-offs between low-code accessibility and code-based control, not just which tools you’ve heard of.
Strong answer covers: Plain-English authoring empowers manual testers to write automation without developer support; self-healing locators reduce maintenance overhead on fast-moving UIs; Playwright or Selenium wins when the team already codes fluently or needs deep framework customisation not available in codeless tools.
When would you use Testsigma over Mabl for a cross-platform test programme?
What they’re really testing: Whether you can compare tools on concrete criteria rather than brand recognition or marketing claims.
Strong answer covers: Testsigma covers web, mobile (iOS/Android), and API under one licence where Mabl focuses primarily on web; Mabl has stronger visual regression and analytics; if budget is mid-market (under NZ$500/mo) and the scope includes native mobile apps, Testsigma is the more practical choice; Mabl edges ahead when pixel-perfect visual diff is the primary requirement.
You’re joining TeleNZ as a QA analyst on a customer self-service web portal. The existing regression suite is 300 manual test cases in Jira, no automation at all, and the team has two testers with no coding background. How would you approach introducing Testsigma?
What they’re really testing: Whether you can build a practical adoption plan rather than just describing what the tool does in theory.
Strong answer covers: Start with the free tier to prove value before procurement sign-off; identify the 10–15 highest-risk smoke tests (login, billing flows, account changes) as the first automation batch; have both testers author tests in plain English so they own the suite from day one; connect Testsigma to Jira from the outset so results feed back into existing test management; measure maintenance time over two sprint cycles before committing to Pro licence.
Your Testsigma tests pass consistently on your local agent but fail intermittently in CI on GitHub Actions. How do you investigate?
What they’re really testing: Whether you can diagnose environment-specific failures systematically rather than blaming the tool or ignoring flakiness.
Strong answer covers: Check if failures correlate with specific steps (timing, data state, network latency) by reviewing Testsigma’s step-level execution screenshots and logs; compare environment differences — browser version, viewport size, test data, and base URL between local agent and CI runner; increase wait thresholds or add explicit waits for slow-loading elements in CI; if self-healing triggered a locator change, review the AI suggestion before accepting it blindly; add a retry count to flaky tests as a short-term measure while fixing root cause.
How would you structure a Testsigma test suite to scale from 50 to 500 test cases without it becoming unmaintainable?
What they’re really testing: Whether you think about long-term suite architecture or just add tests ad hoc until the suite collapses under its own weight.
Strong answer covers: Group tests into logical modules by feature area (not by tester or sprint) so ownership is clear; extract reusable step groups for repeated flows like login, checkout, and form submission rather than duplicating steps across tests; use Testsigma’s data-driven testing to parameterise boundary values instead of creating separate tests per data variant; tag tests by risk level (smoke, regression, full) so CI runs the smoke suite on every PR and full regression only on release; review and retire stale tests on a quarterly cadence — a 500-test suite with 100 obsolete tests is harder to trust than 400 well-maintained ones.