Warning: This article needs to be read carefully!
you are in software testing or software development, you may know a few
things about the relationship between “tester and coder”.
I don’t know who started the previous war or how their relationship got
worse, but it is clear that the tester and coder often don’t like each
other. Coder basically doesn’t like tester, but what if I tell you that you can make them hate you more?
In this article, I will share with you 10 easy ways for coder to hate you more.
Wait a minute … I’ve had enough problems with my coder, do you want
to share tips that will destroy that relationship forever ???????
I don’t know, that’s what you understand what I try to convey through this article. No problem, let’s go.
1: Submit a bad error report
Want to make the coder hate you right away? Report an important problem but vague or incomplete information so they have no idea about the problem. Like this:
Summary: System crashes
Description: The crashes system on my several times PC. Fix it like that
Steps to reproduce: None
Observed result: None
Expected result: None
A report like this will make your coder frustrate immediately.
Why can this make them hate you? We all know that the coder depends a lot on the error report of the tester to understand the error and correct it. If you are sending them a bad report, they will be difficult or take a long time to re-create and fix bugs.
2: Critics of developers about errors encountered
Coder always feels bad when you find a problem in their code. You may have made them feel worse when pointing out exactly who wrote the code that caused the error. Sayings like:
- I think you should work better after handling this bug.
- I think this is a stupid design that you did.
- The programmer did not correctly handle this exception?
- Why does this function not work?
Constructive feedback only makes the coder more like you, so give up destructive feedback like above.
3: … Public criticism
You want things worse? Don’t just criticize them but do it publicly.
You can point out the responsibility for a specific programmer in the
bug tracking system (such as Redmine, Jira …) where people can read
your comments and reviews. You can also do this in group meetings and especially with the relevant management team. Why should I do this? That’s because you are touching one of the sensitive parts of the coder. That is their instinct.
4: Incorrect test environment
It requires the tester to check the system and report the problem in the appropriate environment. Do you want to surprise the developer, try this:
- The Coder build gives you a new test environment
- You mark the old test environment and start working on it.
- The next morning, you rush to meet the coder and notice that you found an error on the build yesterday.
- Then you re-show him the error on your computer.
- The coder then takes all day to analyze, re-create the bug you pointed out. Until the end of the day he found out that you had tested the build wrongly.
Hura hura you did that, and now the developer will remember your name for the rest of his life.
5: Report the error, tell the coder how to fix it and specify the deadline
You know that even though you are just a tester, you have good technical skills. You can show by not only reporting the problem but also providing step-by-step instructions for the coder to troubleshoot. You not only propose a solution, you make the coder understand that this is the only way to fix the problem. Oh, and by the way, don’t forget to set a deadline to fix the problem because this error is affecting your test schedule. For example:
- To fix this bug, you only need to fix step 1, step 2 … I think this way the bug will be fixed quickly.
- By the way, can you finish fixing bugs on Friday? Because I want to finish the test next Monday.
Why does this make the coder hate you?
This way, you are showing that you are smarter than the coder and you know better than them. You also show that you can control and set the deadline for them.
Great, now you look like the boss of the coder.
6. Request other coder to recover any errors you find.
You feel bad when your error is denied or marked as Will not be corrected. Your manager will doubt the capacity as your tester.
To prevent this, you ask, you encourage, you ask the coder to fix any
errors you find regardless of how serious or priority it is.
If the coder refuses to troubleshoot your problem, you write a long
email to discuss and present back and forth to give them the reason why
they should correct your mistake (although from the bottom of your
heart, you know The problem is not worth fixing. You can also escalate to management if you can’t convince developers to fix their errors.
Why is this a great idea to try?
Well, you think the coder is there and has all the time in the world to fix every error you find.
You can ask: “Hey, what’s the problem with this? It is a coder error. They wrote bad code and now they have to clean up the mess they created. ”
In fact, troubleshooting is the job of the coder, but don’t forget that
they also have their own development schedule and they also have time
7. Save the best to the last
You check a build and you find many bugs? What will normal testers do?
They report errors immediately and as soon as possible because the cost of late repairs is high.
That’s what normal testers do, you might want to do differently. You do not report them at the same time, you can also report some, but you spend the best to the end.
You only report this serious issue the day before the system works with
the hope that you can stop the program and receive your credit.
Why does coder hate this? The coder hated the last minute surprise. This will cause a lot of problems and risks when troubleshooting last minute things like that.
A quick fix will cause more risks, a more thorough fix will take two or
three days, this is not possible because the release schedule has been
The coder will scratch your head and curse you why you didn’t report the problem sooner.
8. You act as the gatekeeper (gatekeeper).
This is what a tester is doing as a gatekeeper:
If the coder does not receive your “Pass” word, the build is not released.
Not all testers have that power and authority to do that, but if you’re
lucky and you can act as the gatekeeper and take advantage of that. This is one thing you can do:
You refuse to release the build from the coder if you find any errors
in that build and if the coder insists on releasing it, tell them that
they will be responsible for the product quality or any complaints. from
customers. Why does the coder hate this?
Because they hate to compromise with testers, but you have no choice because they now have friends as gatekeepers.
9. You create a ton of duplicate errors
Needless to say, this is one of the most famous frustrations of the coder.
When you find an error, don’t take your effort to search the bug
tracking system or check it closely with your colleagues to see if the
same problem has been reported before. If you are going this way, you are on the right track to make developers hate you.
Duplicate errors mean that the coder will waste their time reading
errors, analyzing errors and eventually finding that the same problem
has been reported earlier. If you can repeat day in and day out, the coder can call your name in their dreams.
10. You interrupt the thought flow when the coder is programming.
While the coder is programming, try ping them just to say that you have just found a great error in their code. Five minutes later, you write another email to request documentation about a feature they are not responsible for. Sometimes, you come across and describe the problem you find in the system and ask their ideas to see if it is at fault. Why can this make your coder crazy?
While programming, the coder needs to completely focus on their work.
That makes them really frustrated when their thoughts flow like a river and then you interrupt them.
I have just shared with you 10 easy ways to make coder hate you. Of course, the intention of the article is not to tell you the literal ways to make someone hate you. The goal is to help you look back and see if you have a bad relationship with the coder and whether you are making these mistakes. As a tester, you are not responsible for creating coder like you, but you are responsible for working effectively with the parties as a group to build great products. That is the ultimate goal of testing.