Have you hugged your software tester today? These brave souls are the unsung heroes of the software development process. Because their job is sometimes viewed as finding fault with perfectly good code, they may tend to get the stink eye from the rest of the team. Even when they receive a grudging nod of approval for preventing a wide-scale deployment failure, the full scope of their contribution is unacknowledged.
A testing expert who really knows his stuff adds enormous value to the project for the customer—and for the whole team by making their job easier rather than harder. Sadly, too many companies still view testing as more of a necessary evil than an opportunity. That's an attitude that Jim Holmes, Director of Engineering for Test Studio at Telerik, is doing everything he can to change.
Some people just don't do testing
In today's software development world, it might seem unbelievable that a shop with any measure of commercial success could get by without a formal testing process. Yet Holmes says he's actually seen it happen. It's an interesting study in how testing gets overlooked when things come too easily at first. The startup company in question had experienced massive expansion in a short period of time, and its testing procedures simply hadn't kept up. Instead of implementing a full-fledged testing process, this firm had its program manager do quick and dirty acceptance tests just prior to releasing products and upgrades to customers. As you can imagine, despite their continued viability, they were paying a steep price.
Cultural change starts with admitting the truth
Jim didn't realize he was destined to help pave the path to greater productivity when he was hired as a PM for this firm. Little did he know that he would one day be made the Director of Quality, helping the company streamline development and deployment while minimizing their pain with better testing practices. How did the transformation begin?
It doesn't matter if an idea seems like common sense to you. If you want to convince a bunch of stakeholders to alter their course, you need a mountain of data. Like a famous fictional detective of the same name, this Holmes had some investigating to do before he could move to change the testing landscape within the organization. He started by finding answers to key questions.
What happened when the software was rolled out on the company's own internal network?
How many release candidates were they going through before they were ready to deploy to customers?
What was the support impact 30 days after dropping the software to customers?
What were the company's regression rates and what kind of rework was involved?
The information Jim collected told a convincing story. Incorporating testing into the entire development process was the obvious solution to increase speed, reduce risk, and boost customer satisfaction. However, it still took three grueling years to get the company to support better testing practices. Even then, there were still areas that weren't fixed. All it takes is a handful of people who are too entrenched in their own way of doing things to bring progress to a halt.
Tools can't force cultural change
Even though he works for a tool vendor, Holmes says this is never where he starts the conversation with the client. Instead, he brings it down to the level of day-to-day team and business basics:
Where do you want to be?
Where are you feeling pain?
What do you want to do better?
Where is your communication not working?
"If we can't solve these problems first, it doesn't matter if the client spends a million dollars on a commercial tool or hires people to show them the latest open source awesomeness. All of that is doomed to failure."
According to Holmes, tools only come into play after you have buy in. "Frankly, I don't even want to talk tools. It is much more important, before you ever consider anything about the technology or the tools, to begin by forming the appropriate culture." He points out that success doesn't hinge on the language or the platform. "You have to foster an environment that there is no Quality Assurance team because no one can assure quality. Instead, you have testers who get involved in the entire process, letting the whole team know that they need to be having a much broader conversation about delivering value." In effect, everyone becomes responsible for quality. When a let's test this together mindset pervades the entire team, you know you are doing it right.
Are you wasting money and time on outside solutions, or are you ready to make a change on the inside? Tell your stories of cultural shifts that support better testing processes.
Fnd out how mindsets can impact software quality