Software Tester or Lazy Developer?

Most software companies would agree that in order to release quality software in a timely fashion, good test automation is necessary. There’s simply not enough time to wait around for manual testers to do a complete pass of regression tests before releasing new features; progress would slow to a point that the company would not be competitive.

While it’s possible for software developers to write good automated tests, what’s even better is to have a software tester guide the automation projects to make sure that the right things are being tested, and to think of the edge cases that developers might not think of.

But there are many software testers out there who are not actually testers! They can write test automation, but they don’t know how to think like a tester. I call these folks “lazy developers”. They enjoy writing code, and they also enjoy not having to feel responsible for writing good feature code. They can quietly work on their automation projects without worrying about the quality of their code. Unfortunately their poor automation code results in tests that don’t provide the company with the information it needs about the product, which results in poor quality software.

How can you tell if you have a lazy developer rather than a software tester on your team? Here are five key signs:

1. They are not particularly interested in thinking about what to test
   In story grooming sessions, the lazy developer doesn’t have any questions for the team. They don’t participate in the conversation, and they don’t point out any possible problem areas of new features or areas of regression for bug fixes. This can result in many missed opportunities to find bugs.
2. They refuse to do any manual or exploratory testing
   The lazy developer thinks of themselves as an automation engineer and nothing else. They are insulted by suggestions that they do exploratory or manual testing on a new feature. Rather than get to know the product, they’d prefer jumping right in to writing tests. Unfortunately, this means that they really don’t understand how the product works, and they may be automating the wrong things.
3. They are protective of their code and don’t want to share it with others
   Real developers understand that the product code base is a shared code base. No one has exclusive claim to any section of the code. But lazy developers like to have their own little corner of code that no one else looks at. They’ve discovered that by writing automated tests, they can write code that the other developers won’t be interested in, so they won’t interfere with the lazy dev’s pet project. See my post on lone wolves for more information.
4. They have no real interest in the quality of software releases
   The lazy developer doesn’t pay much attention when the team releases software. They are only interested in their automated tests. If the tests run and mostly pass, that’s good enough for them. They don’t make the connection between escaped defects and their tests, because they’re not writing tests to check the quality of the product; they’re writing tests because writing them is fun.
5. They aren’t good at finding bugs
   The lazy developer isn’t good at finding bugs, because they don’t actually care about finding the bugs. If their automation finds a bug, that’s great; they feel like they’ve done their job. But if a bug can’t be found by their automation, they feel it’s probably not that important anyway.

Are YOU a lazy developer?

If any of the above descriptions sound like you, then you might be in the wrong career! Take some time to do the following soul-searching:

• Pay attention to what you enjoy spending time on
  You can definitely be a good software tester and enjoy writing automation code! But if you find yourself sighing inwardly whenever you need to write a test plan, you might really be a developer.
• Notice what kind of stories catch your interest
  When you are reading stories about software online, what gets you excited? Is it the story of an elusive bug that took days of searching to find, or is it a new coding language or an engineering challenge? If development stories excite you more than testing stories, you might be in the wrong role.
• Are you envious of the developers on your team because it seems like they are having more fun?
  Ask your manager if you can do some simple development stories for the team. See if you actually enjoy working on those stories more than you enjoy testing them.
• Is fear holding you back from becoming a developer?
  Perhaps you actually trained to become a software developer, but got stuck in the testing role and never got the courage to leave. Would you be willing to face your fear and take on some additional training? Would you be willing to ask for some coaching from a developer you trust?
• Explore what it would take to become a developer at your company
  If you’ve decided that you are really a developer, talk to your manager. See if there is an established path at your company for making the transition from tester to developer. If there isn’t a path, look for someone at your company who made the transition and ask them how they did it.
• Find a mentor
  Find a developer at your company who has good communication skills, and ask them if they would be willing to mentor you. Let them suggest projects that you can work on that will develop your skills and fill in any technical gaps.

I personally love software testing, and I want to see as many great testers out there as possible! We need people who care about quality so much that they are willing to go the extra mile. But we also need passionate developers. Our software teams will be more effective if everyone is doing a job that they love!