In my 15+ years of professional software development and testing experience, I've seen many teams get into the rhythm of building test suites along with their products. It's a wonderful thing to have in any software development organization, especially since there are plenty of projects out there with zero automation coverage. But teams also need to keep an eye out on the overall health of their test suites as they work.
As a test suite expands, so does the required maintenance the tests need to function correctly. Just like any software development project, automated test suites can accumulate cruft from months or years of commits. Sometimes tests lose their usefulness as the application under test evolves. Sometimes, some tests had no business getting in your code repository in the first place. Whatever the reasons, you and your team have to occasionally take time to "trim the fat" from your test suite.
Unfortunately, development and testing teams rarely spend the necessary time to take a breather from building the test suite and revisit what they already have. Not many teams will voluntarily schedule a few days to perform proper maintenance in their codebase.
You might think that it's due to lack of time. That may be the case sometimes. But often, the actual reason is due to team members who don't want to delete any tests, ever. It doesn't matter if the code they wrote a few years ago has outlived its lifespan, they still want to keep it around for some reason.
Throughout the years, I've noticed a pattern emerge within discussions surrounding test maintenance. I've seen three common types of testers who have the most difficulty in looking back at their work and determine if they should delete older tests or not.
The Hoarder
The Hoarder is the kind of tester who has written plenty of tests for a project. Too many tests, if you ask most of the team. These testers try to automate every single thing they can think of, regardless of whether the tests are useful or necessary to have for the application.
Usually, these are newly-minted testers who have recently discovered the wonders of test automation and think the more tests you have, the better the quality of the product. As the famous saying goes, everything looks like a nail if all you have is a hammer. There's a chance you went through this phase yourself early in your career.
While it's nice to see testers work with such enthusiasm to build a test suite, it can also cause lots of problems in the long run. More tests, especially unnecessary tests, lead to a higher chance of inconsistent test runs and slow build times. It also can affect the morale of these testers later in their careers. If they don't understand why more tests don't always equal better quality, you may cause their motivation and self-esteem to plummet when you point these issues out.
To handle The Hoarder type, you need to step in early and rein them in. You can't allow them to work on whatever they want. Not that you should micromanage them, but make sure they don't stray far away from your team's goals. If you have a test plan for your automated testers, make sure they understand why it's essential to follow the plan instead of trying to reach full coverage of the application.
Keeping these testers aligned with the goals of the project, team, and organization will put them back on track and avoid your test suite from becoming a cluttered, jumbled mess of unnecessary code.
The Proud
The Proud type of tester is someone who's very attached to their work, to the point that anything you say or do to their work feels like a personal attack. You know you work with someone in this category if they instantly get defensive when you bring up the topic of organizing and cleaning up their tests.
For many, the work they do is an extension of their identity, tying their self-worth to their output and what they produce. No one wants to lose part of their identity, so people cling on to what they can. Deleting tests belonging to these kinds of testers almost feels like a literal slap to the face.
Handling The Proud tester requires a balance of early and frequent feedback combined with delivering that feedback tactfully. Usually, these testers hold fast to their tests with good intentions and the desire to make a better product, as all testers do. But most times, the reasons why someone might take offense to criticism and take it personally is by the way it's delivered.
For instance, if you create a pull request deleting someone's tests without discussing it beforehand, they'll probably have an adverse reaction to it. If you talk it over with them before creating any sudden changes to the codebase, they'll be more receptive to what you want to do.
Spend some time with these types of testers, using empathy to see their point of view while offering yours in return. Talking it over before you create the changes can squash any problems before they arise.
The Worrier
The Worrier is the kind of tester who views the work that they've done as highly necessary. The reason why I label these testers as The Worrier and not something like The Self-Important is that they worry that their work is so valuable, removing any of their tests will significantly decrease the overall quality of their project.
These testers come up with different reasons as to why specific tests absolutely need to remain in the test suite. Sometimes, the reasons are valid. For example, if you don't have much familiarity with a particular section of the application you're testing, you'll underestimate the business value it provides, requiring lots of test coverage to avoid financial loss.
However, my experience tells me that's the exception and not the norm. Most of the time, the reasons these testers give are nothing more than excuses to keep their tests in the codebase.
For instance, at a new job, I was tasked with cleaning some areas of the codebase for an application. When I submitted a pull request to remove some tests because most of it was covered elsewhere, I received a swift rebuke. Someone said those tests covered a highly-important feature that changed frequently. Yet when I dug into the code repo's history, no one had touched the code in question for over two years. To top it off, that "highly-important feature" was a deprecated feature, inaccessible to our customers.
Just like The Proud tester, you need to spend some time with The Worrier and discuss these topics in more detail. As mentioned earlier, these testers have credible reasons for keeping a test in the codebase at times. If their intentions aren't real, you'll often catch the excuse when having a dialog with these testers - it all comes out rather quickly.
Summary
Automated tests need frequent maintenance to keep them running smoothly. Part of that maintenance includes revisiting older tests to determine whether they still provide value and lead to your team's goals. Pruning the test suite occasionally helps keep the codebase lean and more comfortable to maintain in the long run.
However, some testers have a hard time letting go of their work. It's understandable since people prefer to avoid as much loss as possible - also known as loss aversion - instead of seeing the potential gains.
In my years working in software development, I've seen the same three patterns crop up when trying to clean up a test suite. You have testers who want to automate all the things (The Hoarder), testers who attach themselves to their work (The Proud), and testers who believe removing what they've done will cause a substantial negative impact (The Worrier).
You may have run into one - or all - of these kinds of testers at your workplace. Each trait has unique characteristics and reasons behind their thought process. If you want to help these types of testers out, you need to handle the conversation differently to come to a conclusion that everybody can agree with.
Just like many other issues in the workplace, the key is honest and open lines of communication. It's up to you and the rest of your team to have an open discussion with them and sort out any potential issues you're facing. It's the best way to have the best version of your test suite possible.
How else have you dealt with testers who find it difficult to let their tests go? Leave a comment below and share your story!
Top comments (0)