Developers and Testers: Nemeses or Soulmates

My husband and I have been married for a little over two years now. In that time, we have heard all kinds of marriage advice; some of it is good and some not so good. Most of that advice could be applied to just about any relationship, for instance, that of a developer and a tester. This particular relationship hits home for us since my husband is a developer, and I am a tester at the same software company. Around the dinner table, we often talk about our work. He tells me the things testers do that drive him up the wall. I also talk to him about how I wish developers would do things a little (maybe a lot) differently. With that in mind, I have worked with my husband to compile some advice for both developers and testers. While I focus on the developer-tester relationship, a lot of this can apply to many struggling work relationships.

The Perfect Developer

Just admit it, we all have made that list in our head of what makes our own Mr./Mrs. Right. Along those lines, I made a list for what makes the perfect developer.

1. Listens

   Listening is the hallmark of any great relationship. I can often tell the difference between when a developer listens to my concerns and takes them seriously instead of just brushing them off. For instance, if I have to repeat myself constantly or explain the importance of an issue, it feels like I am put in the role of the nagging wife asking her husband to do his chores. Fortunately, it doesn’t have to be that way. As long as a developer listens to why a tester thinks an issue is important and takes it seriously, then it is amazing how much quicker work can be accomplished.

2. Takes Ownership Not Blame

   It may be taboo to categorize people so much, but there really are two kinds of developers. There are developers who take ownership and those who give blame. Those who take ownership are the ones who, when presented with a bug, step up and fix it. At the very least, they look into what caused it and re-assign it if need be. They don’t complain when issues arise. Those who give blame often say things like “I didn’t break it. It wasn’t me”. They are frustrated any time an issue arises instead of accepting it as part of the development process. Simply put, ownership is a “we” attitude. Blame is a “me” attitude.

3. Realistic

   Developers are probably the most optimistic people when it comes to getting features done. Planning with developers kind of makes me feel like Oscar the Grouch trying to tell Cookie Monster that he can’t have a cookie. I feel this way the most when I believe that a feature is much more complicated than they do. While having the optimistic developer can be a good balance with a pessimistic tester, it is helpful to have a developer be realistic about what can be done.

The Perfect Tester

For the sake of fairness, my husband also compiled a list of what makes the perfect tester.

1. Communicates Clearly

   Developers really don’t want to ask for clarification about what a tester means when they report an issue. Any time a bug is found, it is important to describe it as clearly as possible. Two tips for this one:
   • ALWAYS include steps to reproduce the bug. There is no reason not to do this. If you don’t have a clear-cut way to reproduce an issue, there is no way a developer can figure out what your issue is to resolve it.
   • Attach a visual aid like a screenshot or even better a GIF. There is plenty of free software out there that makes it easy to record GIFs. I started attaching one to my more complicated issues recently, and I can’t tell you how much time it has saved developers from asking me for more details.

2. Prioritizes Well

   Testers frequently have multiple things on their plate at once. It is essential for them to test what is most important first. There are three main factors to consider when deciding what is top priority. One, how complicated is the feature? If something touches multiple areas of the product or is a massive code change, it is more likely to have issues than a single line code change. Two, how long has the feature been sitting there? No developer should have to find out right before a release that there is an issue with something they finished a week or two ago which is eternity on an agile cycle. Three, how many users will see it? Something that impacts all users versus something impacting a few users should be tested first in most cases. It can be tough as a tester to balance your priorities, but it is critical for a sprint to run smoothly.

3. Realistic

   Remember how I said I feel like Oscar the Grouch around developers? It’s because even I as a tester am not realistic about what can be done. In fact, most testers are pessimistic and a little apprehensive when it comes to features. We are trained to find the bugs and the problems, but not so much to see all the good that can come out of it. It is crucial for testers to recognize both the good and the bad in each thing they test in order to be realistic.

Developer Oh No No’s

Parks and Rec is one of my husband and I’s favorite shows in the world. One of the characters compiles a list of “Oh No No’s” that if a girlfriend commits could end the relationship. (Check out the clip.) On a similar note, I have a list of “Oh no no’s” that I have seen or heard developers committing.

1. Treats QA like a gatekeeper

   Picture a giant castle with a huge wall around it, and a single gate near the front to get in. Standing at that gate is a guard who decides whether or not you are allowed through. Sometimes testers are put in this position when it comes to code going out to production. We are standing there in front of the gate inspecting anything that wants to get through to production and saying yes or no.

   

   QA being a figurative gatekeeper usually is a result of an organization’s processes and not an individual developer. For instance, if a feature is not seen a single time by QA until it is “done” with development, then of course, QA is going to be treated like the bottleneck at the end of a process every time a bug is found. This leads to the mindset in a company among all employees, even the testers, that QA is a painful process and that testers are only good for keeping the bad stuff from getting through the gate. Testers can do so much more than that though. The cure is involving testers in the development process from start to finish. I help our team plan around what QA sees as potential issues with new features. We can also be useful in adding things that would be of benefit to users. Testers shouldn’t only be thinking about what is wrong with a product, but instead they should think of how to improve it. Developers can also prevent the “gatekeeper mindset” by never thinking of a feature as done until it has been tested. You shouldn’t turn in a rough draft as a final paper to an English teacher and untested code should not be given to users.

2. Says testers break things

   I am a clutz and I break a lot of things. However, I don’t break our product. I test it. I find where it can be improved, and I find where it has issues. Saying testers break the product places blame on us that is undeserved. If there are issues with the product, testers are there to find them. Sometimes, I find strange outliers and use cases, but let me repeat for emphasis, TESTERS DO NOT BREAK THE PRODUCT. Testers are there to find what is already broken.

3. Uses too much technical jargon

   Believe it or not, I was new to the software industry once, and there is a ridiculous amount of jargon. At one point, I would keep a notepad of all the words that people used that I did not understand and look them up. After doing this for a little while, I realized that there are people who use jargon just to show off. You can tell because those who use jargon in this way usually can’t explain what they mean in a simpler way or are using a word incorrectly. If you can’t explain a concept to someone, you don’t understand it and need to learn more about it yourself.

QA Oh No No’s

While it is hard to admit, testers aren’t perfect either. My husband also created a list of Oh No No’s, and I have probably committed a few.

1. Throws a developer under the bus

   Throwing a developer under the bus is probably the worst of the worst that a tester can do. I don’t mean that it is wrong for a tester to say that they believe a certain developer caused an issue. That’s just a part of your job. However, calling out a developer in a public setting about an issue or disagreement to the point where they are completely embarrassed is unnecessary and downright wrong. Any time an issue arises, whether it is a bug in the software or a personal grievance, it should be handled with civility and some kindness, only involving those who need to know about it.

2. Creates bug reports without understanding the feature

   At Lucid, we have teams for many different areas of the product. For each team, there is an assigned tester. When another team changes an area of the product that you test, it can cause a little confusion. Instead of instantly reporting a bug, it may be best to go to the other team’s product manager or developer to get a full idea of the feature.

3. Lets things sit for a long time

   This is a throwback to being able to prioritize. If a feature sits forever without getting tested, the entire development cycle can just be thrown downhill. It is critical for each member of a team to do their individual parts in a timely manner.

Following the advice previously mentioned will improve many of the problems developers and testers face. In addition to these, my biggest tip is to always remember that you actually have the same goal. You want to release the best possible product as quickly as possible. When each of you work together towards that goal, petty differences will not seem that big. You will be able to work together to solve problems and may even realize that developers and testers aren’t nemeses after all. Feel free to share your thoughts on other issues you have seen arise between developers and testers in your workplace and ways you have overcome them.