3 Big Things Organizations Get Wrong About Software Testing

The software development world is all about change. 

What are the latest and greatest technologies, practices, and strategies? What can we develop to answer new challenges and opportunities? What are the latest bugs and threats—and how do we fix them?

These are questions software developers, testers, and leaders must answer every minute of every day. And, it’s one of the reasons why I love my job. Trying to understand and address the newest trends and challenges in engineering, Agile, DevOps, security, and everything in between is what I do. 

But you know the cliche: The more things change, the more they stay the same. 

In my role as a coach, consultant, and trainer, I’ve learned that while software development teams face new challenges all the time, they all too often try to address those challenges by making the same big, and unfortunately common, mistakes. 

Here are three of the most common testing mistakes software organizations make and how they can address them.

1.  Create divides between testers and developers. 

Montagues and Capulets. Yankees and Red Sox. Hatfields and McCoys. Testers and developers?

Sure, it’s funny to joke about the “rivalry” between two very different, and in many ways adversarial, roles in the software development process. Testers and developers have very different jobs and focus on different outcomes. But, in the end, they should have a clear collective goal of producing the highest quality product possible. 

Too often, the makeup of a team or the processes by which that team operates creates silos between testers and developers that stymie the vital collaboration between these roles. 

As veteran software engineer and professor Robert Sabourin told me in a recent conversation:

“The dark side [of development] is siloing. I don’t really understand why it’s there, but it’s there. It even shows up in mature teams, because people get into this rut of ‘this is their job and that’s Joe’s job and this is Phil’s job.’ All of a sudden silos come where there weren’t silos before.”

How do we break these silos? By focusing on collaboration.

No matter what your development approach and testing model is—whether it’s waterfall or Agile or anything else—your goal should be to ensure your team members are working together with one unified purpose. While I’d argue that an Agile approach better promotes such collaboration by encouraging continuous input and improvement, I’ve also seen Agile teams build silos of their own. 

Every team is different. But, there are several strategies that can help to encourage a high level of collaboration on your teams, including:

• Utilizing the “three amigo” model for ensuring the priorities of the business, developers, and testers are aligned and heard. 
• Pairing team members to ensure developers and testers are working closely together.
• Ensuring retrospectives include all key team members.
• Organizing mobbing programs where your entire team works together on the same activity (much like pairing but with your entire team). 

Breaking silos requires that at least some subset of your team is working together in collaboration, not every sprint, not every day, but every hour and every minute. If your organization is not hyper-focused on this level of collaboration, mistakes are bound to happen and your product will suffer. 

2. Make testing a standalone phase of the development cycle.

The traditional approach to testing is a developer creates code and then a tester tests that code. In a way it makes sense—and for a while that approach was helpful.

But in today’s rapidly changing world, when speed, agility, and quality are so important, this strategy simply doesn’t cut it anymore. 

Testing shouldn’t be one part of the software development lifecycle, it should be a part of every phase of the lifecycle. It’s a strategy you may call continuous testing or, as coined by Janet Gregory, one of the authors of THE book on Agile Testing: “holistic testing.” 

As Janet describes it:

“Throw away the ‘then’ in ‘code then test’ – replace with ‘and.’ And maybe, also reverse the order to say, ‘test AND code.’ Put the test first…Testing and coding shouldn’t be separated as stand-alone activities. They are part of the same development process. Code is not complete without testing – at least some kind of testing, although some testing activities can be completed without writing any code. An example of this might be when we do an experiment or a simulation to test an idea and the team decides not to follow-up.”

How does holistic testing differ from continuous testing? How can it be integrated into transformations like DevOps? How does the test AND code approach work in practice?

These are all really important questions that Janet has been working on. We recently discussed her concept of holistic testing in a great conversation. Listen now.

3. Rush into test automation without a plan. 

Automation is revolutionizing nearly every aspect of our lives—from how physical products are manufactured to how we drive our cars and everything in between.

It makes sense that organizations are excited about the prospect of test automation to increase efficiency and output in the software testing process. Unfortunately, I’ve seen far too many organizations rush into implementations without thinking through an effective strategy and architecture for their automation. 

I think my colleague and global testing leader Michael Sowers put it best:

“Unfortunately, with all the pressure to “just automate,” we may not invest enough in planning and architecting our automation. Most of us would not build a house, add on a room, or remodel without first doing some planning and design. Our test automation journey should be treated no differently.”

A first important step in this automation journey is understanding what actually can be automated effectively. While some organizations advocate an “automate everything” methodology, our focus at Coveros is about finding a realistic balance between manual and automated testing, as for some types of testing there is very little ROI in automation. 

Understanding your automation needs and goals starts by developing priorities: “Must have,” “Should have,” “Could have,” and “Won’t have.” Using these priorities, organizations can start to develop realistic automation strategies and then build the necessary architecture for efficient test automation. 

As software developers and testers, we thrive on change. But, we also have to be more willing to change how we approach our work and our strategies. 

If you’d like to have a conversation about addressing these common software testing mistakes or any other software development challenges you may be facing, I’d love to talk. Email me at [email protected] to set up a conversation.