Testing even before a line of code is written — is it possible?
Testing is often viewed as a necessary evil in software development, in order to ensure the quality of applications. Most commonly, however, testing occurs after the coding process has been completed.
However, according to the Ministry of Testing’s OpsBoss and author of Testing of Web APIs Mark Winteringham, testing should apply across the entire software development lifecycle. In his book, he even wrote that testing should be done “even before a line of code is written.”
How is that possible?
Mark says this comes from a process of questioning the purpose of a piece of code, that is, “sitting down with your team as you are designing your content.. working out what sort of solutions you’re going to come up with… and questioning the problem as well.”
“Understanding what the problem is, trying to make sure everyone’s on the same page, that there’s no misconceptions makes the approach a lot more fluid.” he shares, adding that testing before a line of code is written is about questioning ideas and problems to get everyone on the same page from the start.
He says that this is also inspired by Janet Gregory and Lisa Crispin’s “Whole Team” approach.
Winteringham further shared a good strategy model to bring IT teams and stakeholders together during API development, the idea of exploratory testing and automation during an episode of Coding over Cocktails, a podcast by Toro Cloud. You can view the full interview on YouTube below.
Quality and Risk
During the episode, Winteringham explained how quality and risk are two sides of the same coin when it comes to testing.
“Traditionally, like when we talk about testing, it tends to sort of get stuck in this older thinking of it’s just confirming requirements, it’s confirming expectations. So, it’s taking what has been explicitly stated, whether that’s a big requirement, document or a user story, and turning that into some test cases, test scripts and just running those.” he describes.
However, he says that we need to make sure that “the actual testing that we’re doing is targeted” especially since teams are now being asked to deliver faster.
“That’s where the quality and risk aspects come in within strategy. My focus is thinking about what quality matters and getting everyone else to think about what quality matters to our end users. Like, what do they care about? How do they define quality to themselves? And then use that as the sort of launching point for where I’m gonna focus my testing because I can’t test everything. So, I want to be effective and I want to be laser-focused on the things that matter the most.” says Winteringham.
Thus, we can set the concept of “quality and risk” as the north star of our testing strategy, and plan around them.
But how do we capture or map risks in order to improve the quality of our software?
Capturing risk with Exploratory Testing
This is where exploratory testing comes to mind, and Winteringham explains how the exploratory testing space is basically the use of “charters”.
“Charters are ways of capturing risk, but writing it in a way that’s an invitation to explore…how I track risk is in the testing activities I do and the plans that I set around that. Historically we have risk registers, but they tend to sit separate from strategies. It’d be lovely to see something in the future where we can actually see quite clearly what risks we’re concerned about and what things they are tied to.” he expounds.
You can learn more about testing, and listen to more of the world’s leading experts on architecture, design, and the technologies that facilitate digital transformation on the Coding over Cocktails podcast available on Apple, Google Podcasts, Spotify, Soundcloud, and Stitcher.
