In testing, as in life, it’s easy to get stuck in an old, outdated process that no longer works for you and your team. To avoid this trap, you have to be flexible enough to change and adopt the mantra “Change is good.” But that’s rarely easy.
We all have our morning routines. We commute the same route to work each day. Our days follow predictable patterns, with little variation—and we like it that way. It’s comfortable. And that’s exactly why we find it so difficult to make a change.
However, when a routine becomes a rut, problems arise. When we get into a testing rut, we can miss defects, deadlines, or both. The workload grows or the team dynamic changes, but we don’t adapt, because comfort and familiarity have blinded us to better ways of doing things.
Recognize the Rut
Not long after starting as QA manager, my new boss asked me about the documentation our team created for test planning and scheduling. One question in particular opened my eyes.
“Why does the team create external test plan documents that are not linked to our current test case management application?”
“That’s the way we’ve always done it,” I replied.
As a valuable member of the testing team, you should always be able to answer the question “Why do you do it that way?” with a solid reason. For example, “I run functional tests this way because it’s the most accurate way to document each step I take and provide adequate testing evidence to stakeholders or auditors.”
When I heard myself say, “That’s the way we’ve always done it,” it was a big red flag. I knew we had gotten into a rut.
If the only answer you can come up with is that you’ve always done it that way, it’s time to take a hard look at your process and see if there’s a better way. Change is good.
Be Open to Change
This is where many of us fall short. We’re so afraid of change, we don’t even want to be open to the possibility that there’s a better way. We make excuses, or find clunky workarounds, or simply put up with the pain of the old, familiar process.
The willingness to make changes can have an enormous impact on the effectiveness of your team. Conversely, if you’re unwilling to change, the team may feel frustrated and trapped in a broken process.
My team definitely felt frustrated and was eager to make a change. We switched from the legacy system to integrating our test plans into the test case management (TCM) application, which has powerful linking and traceability features. After a brief breaking-in period, our process improved drastically. The TCM application made it much easier for the team to track project status and progress.
After that experience, I implemented a new policy of assessing our processes annually. It’s a great way to avoid falling into a rut, and I highly recommend it. Meet with your team regularly to discuss what’s working, what’s not working, and what can be done to make the process better. Listen closely to the feedback you get, and be open to the possibility that your process can be improved. Change is good.
Implement Change Carefully
Once you’ve identified changes you believe will improve your process, consider the team dynamic before you implement them. Do a trial run before rolling out the changes to the entire team. Ask for volunteers to be in the trial group; some team members are more comfortable with change than others.
Additionally, a trial run allows you to measure the old process against the changed process. Is the trial group finding more defects? Are they testing faster? Are they happier? How much has the change improved the process? The answers to these questions will tell you if the change is worth making full scale. Documenting these metrics may also help convince any remaining skeptics.
Beware of changing too frequently, however. Adjustments come with learning curves, and your team’s productivity may drop while it adjusts to the changes. If you make changes too frequently—even good ones—your team will always be in a constant state of adjustment, which will negatively affect your ability to meet deadlines and maintain quality.
Change Is Good
Yes, I’ve said that a few times now; mantras are meant to be repeated. I say it to myself every time I’m faced with a change that makes me nervous. And I’m going to keep reviewing our processes annually and making changes when they’re warranted, because—say it with me—change is good.
User Comments
Good article, thanks for writing it. On a similar lines, when I ask folks why we don't do some practice, the answer is often "they don't require it" or "they aren't asking for it". I like to remind folks that "we are the they". We can drive the adoption of a new practice and become the "they" that are insisting on the change.
Normal
0
false
false
false
EN-US
X-NONE
X-NONE
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman","serif";}
Good read about Testing. As Testing has always been an important function in the software development cycle as Testing drives quality software. The increasing importance of quality has brought the thought deliveing Speed@Quality software. It needs lot of brainstroming of eminent testers to arrive at new ideas of testing. One idea is to put "Test" in "DevOps" to have a truely Agile software. You can attend LiQE. LiQE is an event where software evangelists meet and talk about trends in quality engineering. Agile and Devops teams also get to know about the new buzzword "DevTestOps".
Testing is done explicitly to generate change, either as a bug fix or a design change. So change is a desired thing. The resistance to change lies in the failure of giving reasons. Many changes are made solely because something has to change hoping that changing something yields a better outcome. Finding the causes and reasons for a suboptimal process is about as important as making a change.
Very rightly said - Change is good. But most of the veterans Managers are not comfortable with the changes suggested by their juniors. Those guys want to follow the same pattern that they were following in last so many years of their professional tenure.
And if changes apply on the process / system, everybody wants to see the better results asap. In that point of time, it is very difficult to continue with the changed process.
But yes, change is required and is always very fruitful, if done with a correct manner and attitude.
Good article. Really continous testing improves the quality of software.
Really helpful for Software testing companies.
Change is always needed in the domain of software testing as many new techniques replaces the old one. Kepp up the good work. Nice article.