Senior QA Engineer
at Impact.com
- Seniority
- Senior
- Location
- Cape Town, SA
- Posted
- 5d ago
at Impact.com
<p><strong>The Company</strong></p> <p><a href="http://impact.com/">mpact.com</a> is the world’s leading commerce partnership marketing platform, transforming the way businesses grow by enabling them to discover, manage, and scale partnerships across the entire customer journey. From affiliates and influencers to content publishers, brand ambassadors, and customer advocates,<a href="http://impact.com/"> impact.com</a> empowers brands to drive trusted, performance-based growth through authentic relationships. Its award-winning products—<strong>Performance</strong> (affiliate), <strong>Creator</strong> (influencer), and <strong>Advocate</strong> (customer referral)—unify every type of partner into one integrated platform. As consumers increasingly rely on recommendations from people and communities they trust,<a href="http://impact.com/"> impact.com</a> helps brands show up where it matters most. Today, over 5,000 global brands, including Walmart, Uber, Shopify, Lenovo, L’Oréal, and Fanatics, rely on<a href="http://impact.com/"> impact.com</a> to power more than 225,000 partnerships that deliver measurable business results.</p> <h2><strong>Your Role at</strong><a href="http://impact.com"><strong> </strong><strong>impact.com</strong></a><strong>:</strong></h2> <p>The Senior QA Engineer for <strong>Programmatic XP</strong> owns the quality strategy for our programmatic publishing capability, the systems that let publishers monetise their inventory and let advertisers buy placements across our network. This is a <strong>hands-on senior individual contributor role inside a single squad</strong>, not a management position. You are the quality authority for the squad: you design and build the automation, you decide what "release-ready" means, and you raise the engineering bar of the developers around you through review, pairing and example rather than through headcount. The work is <strong>backend- and data-heavy</strong>. This is a high-throughput, real-time decisioning path plus a configuration surface. Most of your day is APIs, contracts, SQL and production signals with a real but secondary frontend surface.</p> <h2><strong>What You'll Do:</strong></h2> <h3>1. <strong>API & Contract Testing </strong></h3> <ul> <li>Own automated coverage of the squad's REST/JSON surfaces APIs, and the high-throughput serving path.</li> <li>Build and maintain <strong>consumer-driven contract tests</strong> across service boundaries, so a breaking change in an upstream or downstream dependency is caught at build time rather than in production.</li> <li>Test the decisioning logic itself, not just the HTTP envelope</li> <li>Cover the unglamorous half properly: authentication and authorisation, negative and malformed input, boundary and idempotency behaviour, versioning and backwards compatibility, and performance and latency under representative load.</li> </ul> <h3>2. <strong>Data & Report Validation </strong><strong><em>(SQL)</em></strong></h3> <ul> <li>Prove the numbers. Trace an event from the point of capture through the pipelines into the reporting surfaces, and validate that customer-facing reports agree with the source of truth.</li> <li>Write and own non-trivial <strong>SQL </strong>to interrogate reporting datasets independently, reconciliation checks, aggregation and attribution correctness</li> <li>Validate persistence in the operational stores, writing via UI or API, then proving the resulting state is correct and consistent across stores.</li> <li>Build the test-data strategy for a domain where realistic data is the hard part: representative data that make the interesting cases reachable.</li> </ul> <h3>3. <strong>Event & Edge Processing </strong><strong><em>(Kafka)</em></strong></h3> <ul> <li>Test the event-driven seams at the edges of the squad's systems, the messages published and consumed for downstream monetisation events.</li> <li>Assert on message contracts and schema evolution, and cover the failure modes that green functional suites miss</li> </ul> <h3>4. <strong>Frontend & UI Quality</strong></h3> <ul> <li>Own automated coverage of the squad's user-facing journeys — multi-step configuration and setup wizards where state carries across several screens and a partial save is as important to test as a happy path.</li> <li>Work effectively across <strong>two generations of frontend</strong>: legacy server-rendered screens that predate modern tooling and are unforgiving to naive automation, and modern component-based frontends built in TypeScript.</li> <li>Test at the right level for each: end-to-end journeys where the risk is cross-screen state, component-level tests where the risk is rendering and behaviour, and visual or layout assertions where presentation itself is the product.</li> <li>Validate the behaviour revenue depends on: form and validation correctness, permission-dependent rendering, and the tracking and click-through wiring behind user-facing elements.</li> </ul> <h3>5. <strong>Logs, Monitoring & Production Quality</strong></h3> <ul> <li><strong>Read and interpret logs as a primary diagnostic skill.</strong> You can take a vague report — "this customer's numbers look wrong", "requests are failing intermittently" — and work backwards through application logs across services to a specific cause, correlating a single request or transaction across service boundaries rather than guessing from symptoms.</li> <li>Use log and metric evidence to reproduce defects precisely, to distinguish a genuine product bug from a data, configuration or environment problem, and to write the regression test that closes it.</li> <li>Work with dashboards and monitoring tooling (<strong>Grafana</strong> or equivalent) to read the health of the squad's systems — request volume and error rates, latency distributions, drop-off through the processing funnel, and dependency failure and cache behaviour </li> <li>Define the quality signals and thresholds that gate a