Monday, October 3, 2016

Programmers Don't Know Anything About Testing

You know what I can’t stand...programmers that don’t know anything about testing. I think it should considered an epidemic. Especially, considering that programmers are now responsible for medical devices, for example, that can be terrible if not tested well. I know there are software testers and the most common thing I hear from programmers is that it’s not their job. Well,to all you programmers out there who think that this is a correct or valid statement you are half right. The part that is right is that software testing is a job in of itself. The part they got wrong is that it's not there job. The accreditation boards should make it mandatory for developers to take a class devoted to testing and testing theories.
Here is a good example of a programmer. I was working as a tester and the developer that I was on the team with was awesome, she actually still is. She would actively think through edge cases to try and cover all the cases possible. Because she would go through this process I believe she was more productive because the time it takes to debug after a tester finds a bug is more costly than if you can do your best to eliminate all of those to start with.
If you ask developers about equivalence class or boundary testing, I bet you you half of the programmers have absolutely no clue what those are and the half that have heard of it cannot use it to save their lives. Here are to top mistakes developers think or do when they first start out,
  1. Your code needs to be thoroughly tested. Not only does the majority of developers not know much about testing but when they start they think that their code is perfect and that testing it would be a waste of time.  Here is the secret no body writes perfect code, no body. Meaning that your code is in absolute need of a look over and more than that a unit test and other testing.
  2. Developers think they are better than tester. I actually have had a lot of luck in this, meaning that developers actually do think of me as an equal. But I know a lot of developers who look down on testers. Testers are nice...We don’t bite...hard. For reals, though testers are really, trying their best to make sure what you write is as close to perfect that can be. There are of course exceptions to all things.
  3. Including the tester in planning. Let me tell you that the tester probably knows more about the product than anyone else in the entire company. It is their job to know. So why would you not utilize their knowledge in planning? Yes you need the UX guy and the developer but what about the problems that could arise? Have you, product manager, thought of everything that the new feature needs and needs checking after written?
  4. Now the other direction, because testers are not perfect either. Nobody hates you and you will be fine. I can’t stand it when tester unite and leave everyone else out to dry. If you want to have a relationship with your developers so that they don’t hate you, you need to talk to them. You don’t necessarily have to be buddy buddies with them but you need to have respect for one another so that together you can reach near perfect code.

What bugs you about developers? Testers? What can both do to help alleviate those issues?


  1. (disclaimer: I'm a developer!)

    Great post, Joseph! I really like your points of view!

    Just wanted to add something from my experience as a developer with my tester colleagues, that adds up to #4: don't strive to be just another button pusher.

    I've got to work with a few testers who just wanted everything to be perfect and all they expected to do was clicking buttons on the UI, without ever leaving their comfort zone. There were times where I would try to explain what was going on, or explain how a tester could have a new version of the system deployed to test environment and they almost ran to the hills out of fear (even though I don't exactly know what did they fear...).

    So, my suggestion would be, besides doing what you do best (knowing the product, identifying edge cases, relating issues between modules), also get to know how it works behind the scenes. Having a rough idea of the architecture already makes discussions with developers a lot easier for everyone. Getting to know your Jenkins and how your deployment pipeline works is awesome, and being able to deploying things yourself without needing to wait for someone else to do it for you is great too!

    I've worked with a very few testers that were awesome professionals. They would always will to walk the extra mile and learn about new things, I'd love to have them onboard of any of my projects.

    I hope my words make sense in the context of this post :)

    Thanks a lot!

    1. Thanks Felipe!! I really appreciate your comments and what you said totally makes sense. I knew, before I wrote this, that testers weren't perfect and this helps because you are a developer and its from your side.