Test Engineer

The Role

You own testing across four surfaces: an Angular web app, a .NET REST API, and native iOS and Android apps, each built as several white-labelled variants for different customers.

The work is a mix. Some of it is hands-on manual testing, because a lot of what goes wrong in this product only shows up on a real device with a real map and a patchy connection. The rest is automation you build and maintain: Playwright for the web, Postman for the API, and end-to-end coverage on the mobile apps, which does not exist yet and is yours to establish.

You will not be writing unit tests. Those belong with the engineers who write the code, alongside it. Your job starts where a feature is assembled and has to behave.

The work matters because of who uses the product. Queensland’s Department of Transport and Main Roads uses our apps for post-disaster infrastructure assessment across more than fifty councils, and rangers at the Department of Environment, Tourism, Science and Innovation use them across the state’s national parks. Those crews are often offline, often in bad conditions, and cannot come back and retry later.

Responsibilities

• Test features end to end before they ship. Design the approach, and say what you are not covering as clearly as what you are.
• Test by hand where hands are the only way: real devices, real GPS, a connection that drops halfway through a sync.
• Build and maintain the Playwright suite for the web app, and keep it trustworthy. A suite people learn to ignore is worse than no suite.
• Test the API directly with Postman, including the versioned endpoints older mobile clients still call.
• Stand up automated end-to-end testing for iOS and Android. Nothing is in place today, so the tool choice is a real decision and it is yours to make and justify.
• Write and maintain test cases in Azure DevOps, and keep the pipeline runs meaningful rather than decorative.
• Test the white-label variants, not only the default build. A change that works in one flavour can break another through its own configuration.
• Reproduce, triage and track defects, with a repro a developer can follow without asking you a question first.
• Work customer-reported issues through Jira Service Management, turning a support ticket into something reproducible and, where it is worth it, a regression test.

Requirements

• Two or more years testing software, including automation you built and maintained yourself.
• Playwright, or another browser automation framework you could pick Playwright up from quickly.
• API testing with Postman: collections, environments, and assertions that actually fail when something is wrong.
• Mobile testing on real devices, and an appetite for choosing and standing up the automation for it.
• Azure DevOps: test cases, pipelines and work items.
• You can read the code you are testing well enough to know where the risk sits, even though you are not writing it.
• Comfortable with a multi-tenant product where data is scoped per workspace, so isolation between tenants is itself worth testing.

Useful, not essential: Appium, Maestro or XCUITest, Jira Service Management, Git, offline and sync testing, accessibility testing.

What you will work with

Playwright and Postman day to day. Azure DevOps for test cases, pipelines and work items. Jira Service Management for customer tickets. Real iOS and Android hardware, because the emulator does not tell you what happens when a crew walks out of signal halfway through a job.