Testing remains a critical yet often misunderstood and undervalued component of software development. What’s more, as artificial intelligence threatens to reshape the role of testers, questions of job security and demonstrating value become increasingly pressing. From the struggle for recognition and early involvement in the development process to the delicate balance between automation and human insight, testers navigate a minefield of technical and organizational hurdles. Michael Larsen, a veteran with over three decades of experience in the field, sheds light on the complex challenges facing the software testing industry today.
Edited transcription
Michael Larsen’s experience using computers was mostly limited to music production when he started working at Cisco in the early 1990s as an engineer. Soon enough, his aptitude and interest moved him to work as a tester.
After a decade at Cisco, Michael sought to broaden his horizons and transitioned to independent consulting, a path he continues to embrace today, even with the realities of an unstable job market. “After a 30-year career,” Michael jokes, “I tell people that I am an independent software testing consultant because it sounds better than saying that I’m basically unemployed, which is the truth.”
Software Testing Strategies: Skills and ethics for testers
To share his vast experience in the software industry and testing practice, Michael recently co-authored with Matthew Heuser Software Testing Strategies. Published by Packt Publishing, the book delves into various aspects of testing, making it a valuable tool for testers of all levels.
Software Testing Strategies consists of 16 chapters divided into three parts. The first part consists of testing knowledge and skills for testers; “things you should know as a tester,” says Michael. While experienced testers might find this section familiar, it includes a valuable chapter on specialized testing in in-demand areas like modern web applications, SaaS, microservices, and APIs. Michael clarifies that the book does not attempt to turn readers into experts on these technologies. Instead, it provides a solid base for understanding how testing applies to them: “You fired up a tool, you know how to use it superficially. That’s great. There’s a whole lot more you need to learn before you can say that you’re proficient at it.” Hence, he encourages exploration and further learning beyond the book’s introductory guidance.
The book’s second part dives into software delivery processes and the testing strategies that work best within those frameworks. Michael stresses the importance of flexibility and adaptation, rejecting a “one-size-fits-all” approach to testing. He uses a recipe analogy to illustrate this point. Testing, like a recipe, has core principles that remain constant. A deep understanding of these core principles allows testers to improvise and test software in various contexts, coming back to them when needed.
Besides, once you have a grip on how this recipe works, you can tweak it to match your requirements: “You can change the flavor profile a little bit or the development environment has changed and what used to work with the team that you were with before may not work here,” Michael affirms. A deep knowledge of what underlines the “recipes” makes it possible to adjust it to suit your space problem. Michael believes it is necessary to understand the core principles of testing (“recipes”) to adapt and improvise in different environments.
The final section of Michael’s book ventures into the often-overlooked territory of the “political landscape” of software testing. Here, he tackles the undervaluing of testers, the ethical dilemmas they face, and strategies for navigating challenging situations. This last section, Michael admits, has garnered the most interesting feedback, as it addresses crucial issues rarely explored: “Let’s talk about the difficult people you’re going to have to deal with, the difficult conversations you’re going to have, the fact that you may be asked to compromise your ethical standards or somebody might term something in a way where you’re doing what you think is the right thing and somebody else is misrepresenting your work and you’re getting thrown under the bus when something goes wrong.”
Empowering testers for quality, usability, and inclusivity
From his experience in the industry, Michael doesn’t hide that testers can be “very highly valued or can be denigrated, treated like a second class citizen.” Yet Michael defends the tester role as irreplaceable for achieving quality, provided certain conditions are met. “If you’re not willing to give the testers autonomy and they don’t get the chance to make the decisions or they don’t get a chance to be part of early conversations, then no, we can’t really assure quality; we can’t even really provide you with good testing,” says Michael.
Quality hinges on empowering testers with autonomy and authority over decisions, and also, on their involvement in early project discussions. According to Michael, testers are most valuable at the beginning of the development process, “before line one of a feature is even written.” Their role is to ask critical testing questions from the outset, acting as a voice of caution that can ultimately prevent future problems. Testers should be involved in defining how features will be tested, including considerations for APIs and potential user scenarios, and proactively examining “what if” questions, which significantly contribute to a well-rounded product.
The involvement of testers in development isn’t limited to identifying potential problems but also to anticipating a wider range of user experiences. In this regard, Michael challenges the common perception of accessibility features being solely for people with disabilities. While accessibility features like screen readers or closed captions are typically seen as aids for those with visual or hearing impairments, “everybody can benefit from accessibility enhancement because every one of us can find ourselves in a disadvantageous situation and we don’t have to be disabled to be in it,” Michael points out. Even a well-designed, accessible product can become unusable due to external factors. For instance, bright sunlight can make it difficult to see a screen, or a noisy environment can render audio features useless. In these scenarios, accessibility features act as a safety net for every user, ensuring usability even in less-than-ideal conditions.
However, Michael also cautions that a highly compliant product can still fail if it’s simply unpleasant to use: “You can have the most compliant software product…but if it’s terrible to use, if people don’t like interacting with it, then you’ve won the battles but you’ve lost the war.”
Is test automation overhyped?
Technology hype cycles end up in two ways, they either don’t stick around or “they work with the way you do things.” In the case of test automation, by itself it has been around for a long time, still, Michael argues it has limitations: ” Automation can do a lot of neat things. It can’t do everything.”
Automation is great for repetitive tasks and following established paths, as it ensures reliable and consistent testing of programmed functionalities. However, once an automated test is written and integrated, the “interesting work” of discovery is mostly done, as automation is incapable of uncovering new issues. Test failures often indicate code changes or library updates, not necessarily new product issues.
Fixing these failures becomes change management, not an active exploration of the product. Hence, Michael understands that at this point automated tests become maintenance tools that check if things work the same after code changes. Besides, in this stage automated tests are also subject to diminishing returns. All they can do is manage known test cases, however, automating every possible test case might not be necessary or efficient. Sooner or later will come a time where the time and effort invested in automation doesn’t yield significant benefits.
In this way, Michael believes it is necessary to implement automated testing specifically where it is more critical. For example to prioritize critical tests that ensure core functionalities work as expected. What’s more, Michael believes these critical tests should be integrated into the development pipeline to catch regressions early. Staging environments can’t perfectly replicate real-world conditions. Production testing helps identify user behavior and the adoption of new features. Besides, users and unexpected situations can reveal issues missed in controlled environments.
The place of AI in testing
“If a technology can come along that can do a lot of what they feel you can do and save a lot of money, any logical organization is going to do that,” says Michael on the rise of AI in test case generation. Still, he sees AI as freeing testers from repetitive and manual labor and forward to more challenging issues. Being responsible for more complex issues can be intimidating, however, there’s no alternative: “I’m going to have to think about what value I bring now that say chat GPT or copilot can’t do exactly what I’m doing. If the answer is nothing, you’re in a dangerous position,” says Michael.
Since testers need to showcase their unique value proposition beyond what AI can do, another way to look at complexity in testing, and that can make testers value their work properly in the face of becoming obsolete, is seeing testing as risk management. Regarded as such, testing is not about “going through the motions and hammering on the product”, but, as Michael puts it, about “understanding what are the risks that we face.”
The bottom line
You can follow Michael on Linkedin. To learn more about his work, you can read his testing blog TESTHEAD and listen to his podcast, The Testing Show.
Grab a copy of his co-authored book, Software Testing Strategies, published by Packt Publishing. Discussion groups about the book are also available on Facebook and LinkedIn.
If you are a hard rock fan, check out Michael Larsen’s band, Ensign Red, on Spotify, Apple Music, and Amazon for a taste of his musical side.
Originally published at https://semaphoreci.com on July 2, 2024.
