Investigating the need for software testing process changes

Investigating the need for software testing process changes

How do you avoid having to do a complete overhaul of your test processes? If you realize that how the test team should work and interact with the rest of the company is not working, how do you avoid scrapping it and replacing it with something else?

    Requires Free Membership to View

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Generally, I try and avoid doing a massive, complete re-vamp of test processes unless absolutely needed.  It seems to me the disruption from changing a full set of related processes or procedures can cause more damage than simply allowing them to continue as they are. Examine the cost to morale of your team before leaping in to a complete replacement and recognize this will only be a part of the cost of making a large-scale change.

Instead, I recommend people examine the causes that result in the need for changing processes. Start with small changes and make incremental improvements. Too often I have seen huge sweeping campaigns that falter and drop away, to be followed by another equally unsuccessful attempt six months or a year later. 

I’m a strong advocate of teams evaluating themselves, defining their strengths and weaknesses based on their own abilities. Then examine the weaknesses and consider ideas on how to mitigate them. Training may be an option as well as bringing in experts to work alongside the team so the team can learn the techniques by actually doing them. 

It may be that as the weaknesses are being addressed, the processes themselves can be reviewed. It may be that the improvements to testing itself may well correct the issues that gave the perception of a need for change. 

If it does not, look to see what it is that the processes are intended to do. If the information, the story, you are giving as a result of your testing and test processes is not of interest to the various stakeholders, look to see why that is. If their needs have changed, meet with them and talk over what it is that they need to do their jobs. Too often I hear test leads and testers say “Our users just want us to make sure it is right.” In that case, perhaps the questions are too granular. I suggest they look for more of a meta discussion. 

Gaining a better appreciation of how the customers and users actually use the system, and what difficulties they encounter in doing so, can enlighten the test group and help them target their efforts to be more closely aligned with what their customers need. These can often be fairly minor changes in process itself, even when it is a sea-change in perspective. 

This was first published in May 2011