Every integration is a promise made by someone else's engineering team. My job was to find out where those promises broke, before a customer did.
SalesRabbit is a field sales SaaS platform used by outside sales teams to manage territories, track leads, and log customer visits across web, iOS, and Android. Like most modern B2B products, a meaningful share of its functionality doesn't live inside the product at all. It depends on third-party APIs for scheduling, mapping and geolocation, CRM sync, and solar financing.
That dependency creates a specific and under-tested class of risk. Internal code changes get caught by a regression suite. Integration failures behave differently: the partner ships a change, your code is untouched, your tests still pass, and a customer's calendar sync quietly stops working. The failure surfaces first as a support ticket, not as a build error.
As the QA analyst serving multiple engineering squads, I owned the validation layer for that surface.
Of everything I tested, the Solar Proposals feature carried the most risk. A proposal is a priced quote a rep hands to a homeowner at the kitchen table. It pulls hardware selections, quantities, and pricing together, then runs financing through a third-party lender API to return loan rates, approvals, and denials.
The failure mode here isn't a broken screen. It's a rep confidently quoting a number that turns out to be wrong. Every input to that quote crosses a boundary between systems, and any one of them can drift without anyone noticing.
Proposal accuracy depends on several moving pieces staying in sync at once: hardware quantities, current pricing, and live financing terms from an external lender. Validating that by hand, per release, means clicking through a full proposal build every time and trusting that you'd notice if a number looked slightly off. That doesn't scale, and quiet numerical drift is exactly the kind of thing manual testing misses.
I built reusable Postman collections that exercise the Solar Proposals endpoints directly, and set them to run as automated regression checks in the pipeline rather than as a manual pre-release pass. Testing at the API layer instead of through the UI decouples validation from front-end state, so a proposal's underlying numbers get verified on every run regardless of what the interface is doing.
The collections were shared with the QA team, which moved the knowledge of how to validate the feature out of one person's head and into something anyone could run.
The suite surfaced a category of defect that is genuinely hard to catch by eye:
Both are silent failures. Nothing errors, nothing crashes, and the proposal renders cleanly. The only signal is a number being wrong, which is why an automated assertion catches it and a human clicking through usually will not.
The solar financing integration meant validating loan rates, approvals, and denials returning correctly from the lender. Denials mattered as much as approvals: a financing path that mishandles a rejected application creates a bad moment in front of a customer and a support ticket immediately after.
Alongside the happy path, I tested auth and token expiry behavior, and how the product handled malformed or missing data coming back from partner APIs.
SalesRabbit's scheduling functionality is built on the Nylas API, calendar and communications infrastructure delivered as a third-party service. I validated it from the customer's point of view rather than the endpoint's, testing that the two directions of sync stayed honest with each other:
Bidirectional sync is where calendar integrations tend to fail, and the failure is asymmetric. A rep who deletes an event and still sees it on the lead loses trust in the data. A rep whose lead record silently disagrees with their calendar misses an appointment.
Beyond the integration layer, I authored and maintained automated regression scripts in JavaScript within the CI/CD pipeline, enabling continuous quality checks and rapid detection of UI and functional regressions across web, iOS, and Android. Written with WebdriverIO and version-controlled in Git, these ran as part of the build rather than as a pre-release scramble.
The testing work sat inside a broader program I built and led: a cross-functional bug escalation process that validated 100% of incoming support tickets before they reached engineering. Every escalation arrived reproduced, documented, and confirmed as a genuine product issue.
The distinction I'd draw is between finding bugs and shaping decisions. Most of what I did in this role was the second thing wearing the first thing's job title.
Testing the integration surface tells you where it breaks. It doesn't tell you which breakages matter most to revenue, which partners are worth deepening versus replacing, or which integration requests in the support queue represent a real market rather than one loud account. That prioritization layer is the work I'm moving toward, and the reason the evidence habits from QA transfer directly rather than needing to be unlearned.