Qualification and Experience
Required Technical Skills
- Hands-on experience with mobile test automation (Appium, Detox, XCUITest, Espresso, or
Flutter Driver)
- Solid API test automation experience (REST-assured, Postman/Newman, Karate, Playwright
API, or equivalent)
- Practical experience with performance testing tools (k6, JMeter, Locust, or Gatling)
- Ability to read and interpret API contracts (OpenAPI/Swagger) and identify coverage gaps
- Comfortable writing automation code in at least one language (Python, TypeScript, Dart,
Java, or Kotlin)
- Understanding of mobile performance metrics: app launch time, frame rate, memoryand
battery usage
Required Leadership Skills
- Ability to identify and communicate quality risks proactively — not just after a bug is found
- Strong enough technical depth to have credibility with mobile and backend engineers
- Comfort working directly with Product and Engineering during sprint planning to flag
testability concerns early
- Self-directed: able to assess what needs testing most and prioritise without being told
- Clear written communication —yourdefectreports andtest reports should require minimal
follow-up
Experience Requirements
- 4‒7+ years in QA engineering with a mobile or API automation focus
- Demonstrated experience building or owning an API or mobile test suite (not just
contributing to one)
- Experience with performance testing in a product environment (not just synthetic
benchmarks)
- Familiarity with both iOS and Android platforms.
Nice to Have
- Flutter or Dart experience
- Experience testing GraphQL APIs or event-driven / async systems
- Exposure to observability tooling (Datadog, Grafana, or similar) for correlating performance
test results
- Experience in F&B, delivery, or high-transaction consumer applications
- Understanding of backend architecture sufficient to design meaningful load scenarios
Who Will Succeed in This Role
You will thrive here if you:- Think about edge cases that weren't in the spec and test them anyway
- Care about performance not as a benchmark exercise but as a real user experience concern
- Are comfortable going deep on a failing test to understand why it fails, not just that it does
- Build test coverage that reflects actual user risk, not just line coverage or case counts
- Want your work to make engineers more confident, not create more gates and friction
a Necessity, not a Luxury