Grassroots Testing: A Campaign for Improvement

Posted on January 31, 2007
Filed Under Computers, Politics, Programming

With the votes cast, the polls closed, and the candidates elected, we say farewell to another political season that captivated everyone in a way that we thought only the Super Bowl could. Of all the soap opera-esque drama that occurred during the general election, Dion Johnson found grassroots campaigns to be the most interesting because they generated the greatest level of success from the bottom up, as opposed to from the top down. He believes the world of software testing can learn a lot from this grassroots approach. In this week’s column, Dion embarks on a grassroots campaign trail that he hopes will get any process improvement initiative elected.

Grassroots movements are among the most powerful for getting things accomplished because they are driven by the people. Too often solo attempts at instituting improvements to testing processes fail because we don’t connect with the people that will ultimately be electing and driving these improvements. We become mavericks that pull out our best practices and formal test process improvement models and use them to let everyone know how poorly they are currently conducting business. The recipients of our condescension view mavericks as “testing elitists”–a.k.a. “The Establishment,” “The Man,” or “The Machine”–trying to keep them down. This creates a disconnect between us, the mavericks, and the people, which ultimately results in our failure to institute improvements.

To succeed in implementing positive improvements on a project–specifically improvements that are not driven by and strongly supported by upper-level management–it often becomes necessary to organize a grassroots testing process improvement campaign. The key elements of this campaign are as follows:

·Talk with and understand the constituents
·Become one of the people
·Become the people’s champion
·Accept the people’s call for improvement

Talk With and Understand the Constituents
We can view our projects as the community, where managers and peers represent the constituents of the project. Talking with constituents is important for getting a clear picture of the needs and issues of the people. The project constituents often are unreceptive to implementing process improvement initiatives, but as much as we’d like to dismiss them as being shortsighted or having no vision, it is not always their fault. Part of the problem is that we start our campaign by attempting to impose traditional power structures, known as best practices, that instill in us many preconceived notions without truly conveying what is going on around us. If we start with open minds and truly listen to people instead of just waiting for our turn to talk, we’ll get a lot farther.

As you’re listening to and gathering information from your constituents, you may want to takes notes regarding the following topics:

·Stated goals and objectives
·Systems and environments
·Roles and responsibilities (including your boss’s management style)
·Processes (defined and undefined)
·Current tools that support processes (automated and manual)
·Historical data

Become One of the People
As you begin to learn about the people, you have to become one of them. Test process improvements are often rejected simply because the constituents believe the improvements are nothing more than a self-serving attempt by someone to make a name for himself. They don’t believe that the improvements really are meant for the good of the project.

It takes sincerity and hard work to become one of the people. Keep a low profile, and let your work speak for itself. Exercise the current processes to the maximum extent of proficiency and productivity to a point that is far above and beyond what is expected. Producing positive results will always be more beneficial than focusing on improvements because it will eliminate the belief that you’re offering a new process simply because you don’t understand the existing one.

Read full article at http://www.softwaredevelopmentblog.com/2007/01/grassroots_test.html on
http://www.softwaredevelopmentblog.com