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!

8 thoughts on “Software Tester or Lazy Developer?

  1. Anwar Alam

    Hi,
    Kristin
    Read your blog Software Tester or Lazy Developer?, After a Long time
    It was an amazing Experience to read your blogs. The blog was fantastic, Superb got the exact information which was required.!
    I have a question for you.?
    Can a Manual Test Engineer becomes a Automation Test Engineer..?
    If Yes.!
    What are the things which he/she needs to do..?
    what books to read,what are the website visit, What programming language to choose etc…?

    Reply
    1. kristinjackvony Post author

      Hi Anwar- Yes! A manual tester can definitely become an Automation Test Engineer! I did it nine years ago, and you can too! I recommend learning JavaScript, because it’s so versatile. Go to the Test Automation University website, and take the “Web UI JavaScript Path” and the “API JavaScript Path”. These courses are completely free! You can also read “The Way of the Web Tester” by Jonathan Rasmusson. It’s a really helpful introduction to thinking about automated testing. Good luck and have fun!

      Reply
  2. David

    Good post. It got me thinking of a particular situation. I’ve come across situations where the test automation developer doesn’t write ideally good automated tests or test design. For example, the automated test and the automation framework code around the test is designed to test a fixed option in the test case workflow, such that testing a different variation of the option requires more work than if it was abstracted properly to minimize the amount of automation code or # of specific test cases if made data driven. For example, a different quantity, a different color, etc. But supporting such requires a level of expertise in UI locator strategy and programming skill. The automation author also does manual testing in these cases. It makes me think under these conditions, is it a lack of technical expertise to code it the optimal way or a lack of test case design foresight to handle variations of a test, or overall lazy approach to take the simplest path for testing and automation and not seek out excellence in test coverage as well as automation quality.

    Reply
    1. kristinjackvony Post author

      Great points, David! In cases where the test automation engineer isn’t writing reusable test code, it could either be because they don’t know any better, or because they are lazy. Hopefully it’s the former. In either case, this is why it’s so important to get developers involved in test automation. The tester can communicate the different types of tests that will be needed, and the developers can suggest the best ways to set up automation that will be reusable in the future.

      Reply
  3. Andie Johnson

    Exploratory testing can be somewhat intimidating. For a newer resource that probably relates directly to how successful onboarding on their project was. For older resources, maybe it’s more related to not having a solid conception for how to perform exploratory testing – how to document, plan, or what stage to perform it in. Do you have any good resources for how to approach exploratory testing?

    Reply
    1. kristinjackvony Post author

      Hi Andie- Yes, I have a great resource for exploratory testing! It’s the book “Explore It!” by Elizabeth Hendrickson. This book is absolutely a must-read for every tester, and it would be great if developers read it too. Not only will it give testers plenty of ideas for what to test, it will also help them think about exploratory testing in an organized fashion.

      Reply
  4. Pingback: Five Blogs – 8 June 2021 – 5blogs

  5. Pingback: Testing Bits: 395 – May 30th – June 5th, 2021 | Testing Curator Blog

Leave a Reply

Your email address will not be published. Required fields are marked *