Testing's Contributions to Success

Software testing plays a crucial role in minimizing the likelihood of problematic deliveries by employing suitable test techniques and leveraging expertise at various test levels.

Testing is about knowing who should be involved in ensuring quality. For example, how would you prevent a login flow from being hacked?

It’s not a tester’s job to be an expert in Cyber Security—but it is our responsibility to think of potential issues and risks and act with ownership to mitigate those risks.

There is no “that’s for devs/devops/SREs/DBAs/security to check.” We’re the advocates for quality.

How testing can contribute to the success of a project:

1. Requirements review
2. System Design Understanding
3. Code Implementation Knowledge
4. Verification and Validation

The key is to get in the room with the Designers, BAs, and Developers to head off issues before they’re implemented.

When Developers implement features and then request QA to verify, that’s waterfall, not agile, regardless of the development process.

Certain people will feel threatened by changing the traditional flow, e.g., BA > Design > Dev > Test.

We’re trying to get people into a non-egoic way of working, where we’re all on the same team contributing to developing the best quality product possible.

Teamwork is about putting ego aside, getting people collaborating together, so we can figure out the best and most efficient way to deliver a quality product.

Everyone makes mistakes. No one gets it right all the time. But if we all help each other, we can minimize the mistakes.

• Give me the rules about what will make it pass (devs, security, testers, designers, product, BA). This doesn’t negate bugs and defects, but it will significantly reduce them.

Push back will happen (e.g., too busy)—but the cost of fixing issues later in UAT dwarfs the time spent getting everyone in the room to review in-depth before work starts.

Essentially, we’re just saying, “can we all get together?” We’re setting everyone up for success.

When people push back, just ask, “can we just test this flow on a low-stakes project so we can test the principles in a low-risk environment, e.g., a small standalone project, and then see what works?”

But you’re not trying to prove QA should be in the room or that this is a superior process. You want to push for a scientific approach—you’re setting a hypothesis that you wish to test and measure. That’s all we’re asking.

And this hypothesis process is the same as the testing process. We’re just looking for feedback. You’re not claiming that you “know” the best way. You’re just saying that you’ve been exposed to an interesting idea that you’d like to try out by testing it.

Because even if it is a “best practice,” it won’t work in every team/org because of the people there.

It’s very important to provide feedback that is not interpreted as an “attack.” You’re just trying to gather data to find more efficient ways of doing things that increase quality and make everyone’s lives easier. For example, what are we missing and in what part of the process? It’s not about whose fault it is—it’s about understanding how and why this is happening.

Also, you don’t need to jump into “shift left” as a radical change. Think about what the principle of shifting left is and how you can bring that thinking and mindset into your team and org in a way that’s appropriate.