Why are you waiting?

Continuing the recent theme of freedom and autonomy, let’s talk about the realities—and opportunities—of testing with third parties (or even just between departments within your own organization). Over the last two decades, the landscape has changed dramatically. Today’s systems are more integrated than ever, driven by business needs, the rise of SaaS and APIs, and the constant pressure to deliver value quickly.

Back before Y2K (yes, I twitched a bit typing that), most organizations built everything in-house. The time-to-market was slow, Agile wasn’t mainstream, and cross-departmental involvement was rare. But as the internet exploded, so did the demand for information and online transactions. Suddenly, companies had to innovate fast or risk being left behind.

This led to a major shift: the “Buy vs. Build” debate. Why spend months building something from scratch when you can buy a proven solution, save money, and let someone else handle support? The banking industry is a perfect example. Online banking now lets you move money, pay bills, and check balances from your kitchen table. However, behind that convenience lie countless teams and third-party vendors collaborating to make it all seamless.

With all these moving pieces, integration is critical. But here’s the real question: do you have to wait for another team or vendor to test your code? My answer is no—and if you’ve ever worked with service-oriented architecture or transaction testing, you probably agree.

As long as the format, content, and layout of your data are defined, your team can and should test your components independently before full integration.

The system only cares about getting the right data in the right place, not where it came from. Simulating data and posting transactions isn’t just possible—it’s essential for quality and speed.

Taking control of your own testing means you’re less dependent on other teams’ timelines, which reduces delays, finger-pointing, and frustration. Yes, it can be hard to get started, but once you do, the quality of your releases will improve, and integration will go more smoothly. Developers can run quick integration checks, QA can validate against simulated data, and certification processes become much more manageable.

If you’re already doing this, great! If not, I hope this sparks new conversations on your team about how to take more ownership of your testing process and reduce your reliance on outside factors. Want to discuss or see if we can help in any way? Reach out to us at jberriault@berriaultandassociates.com

Want more practical QA insights?
Listen to my segments and other great discussions on SPaMcast.