We all know that every person is different. We all have different personalities, more or less experience, cooler or less cool habits, better or worse days. We must remember to forgive and learn from mistakes. We should all attempt to improve ourselves , while overlooking the weaknesses in others, and at the same time always focus on the positive and appreciate it. The nature of a tester is always the same. His job is to drill, to look for what does not work and what could work better. Regressive tests and one hundred tickets that will never be repaired all belong to him. Programmer, if you do not like the tester you work with, and you would prefer to get rid of him, this manual is for you. Now you can become a tester of the tester himself and see how many of these behaviors your enemy can endure.
No writing test
Surely it works, right? You tried, you spent a few or even dozens of hours working on it, you know the requirements, you do not need anything more. No unit tests or dreaded end-to-end tests. You wrote the integration tests (or not) but that is enough. For the tester, it is a pleasure to work with a well-maintained and tested code, when finding bugs becomes a challenge rather than forced labor. If you hate him, take this pleasure away from him.
Damage more than you fix
If you do not keep testing, you can go all the way. Now every commit can do enough damage by itself. You have done your work, you do not have to check whether you’ve broken any other places in the application. You are a good programmer, and this will not happen to you. Let the testers look for such gems. After all, this is their job, because thanks to your work they actually have a job. Will he have to test fast, until the very last minute before release? Nobody ever said life was fair. You also had to make corrections until the last moment, because of all the mistakes that were reported.
Or do not fix it at all
Get rid of a task. The tester will check it anyway, and it might still work. It doesn’t matter that he has to spend over twice as much time checking the same functionality again and again and returning it with a sad comment. You can make it fun after all! The ticket history is growing, logged time also, everyone should be happy.
Blame the tester for the bugs
Especially for your own, as it will hurt him the most. It’s his fault that he found so many mistakes. He just makes you feel more and more tired. Worst of all, he demands repairs. Or waits to point out the errors that have been found until the last moment. You test poorly, Mr. Tester, since you overlooked such things. Point this out to him and absolutely don’t worry that someone had to write this code, that someone has to carry out a code review, that maybe the requirements should be established better. It is the responsibility of the tester to find all the bugs before implementation.
I do not know how it works, but it works well
I promise that this can make the tester speechless. It is one of the most shocking confessions. It is hard to argue with it. If we do not know how it should work, there is nothing to talk about. Do not accept any criticism, there are no errors. If you did not write this code, assume that others did it well.
It works for me
This is a small but powerful phrase, most effective with a cheeky smile on top. Don’t try to repeat this move too often or perfect its performance. All in all, reading tickets is a waste of time, so obviously everything works and there is no problem to be seen. As long as you do not make the mistake of reproducing on your localhost, do not trust what the tester has to say. There couldn’t possibly be any differences between his and your environments.
Set a trap
Tell the tester that there could be an error somewhere. The tester will search and search, since it is his ambition to find each bug. The perfect plan to take the tester out for a long time and keep him motivated to work harder. It is up to you whether you want to actually leave a surprise somewhere or just mess with him. You might also notice a bug by accident, but you have no idea what could have happened there.
Do not pass requirements
If you create tickets in Jira, do not dwell on them too much. It takes a lot of time and even more effort, so it’s better to write some lines of code instead. The shorter, the better. Especially since documentation does not exist. Thanks to this method you can avoid cumbersome conversations and overcome your opponent. Besides, you cannot by replaced when you have knowledge in the field. Point for you.
Set the build and get out of work
You have made the last change in the code, you have committed, you even ran the jenkins build in the right environment. It will definitely pass. Now you can go home safely, where a warm dinner awaits you. Messed up? Oops, you will fix it as soon as you return the next day. Tester waiting impatiently? Let him wait a little longer. Do you prefer to have a good time at work? Promise that you will give him a new feature in a moment, but put it off for a few hours. At the end of the day, you can tell him that you will give it to him tomorrow.
Let’s be serious now
This really works! But beware, because you can be hated not only by the tester, but also by the whole team. So seriously, we hope you do not use such methods on a daily basis and you understand our sarcastic tone. It’s all in good humor. Programmer, if you notice any similarities in your work, do not follow this route. It is difficult to calculate how much harm you can bring upon yourself and others. Let’s look at your work now, it’s time to examine our consciences. Feel the responsibility that rests on your shoulders.
We could speak about tests written by programmers for a long time. It is the basis of a good software development process. Does the developer need to write integration tests, acceptance tests, and end-to-end tests? Is it his duty to write unit tests and performance tests? It probably depends on the division of responsibilities between the testers and developers. As long as it is effective and efficient, we can be relatively satisfied. In my opinion, a respected developer should at least provide unit tests. The truth is that the more tests the programmer writes, the less the tester will have to report. It seems simple. At the same time, it significantly shortens the time it takes to produce software, reduces the chance of errors in production and reduces the risk of subsequent releases. And what are the benefits of a test be that can be read like a document? Such a test obviously translates into money in the end.
One who makes no mistakes never makes anything. Bugs can be caused by many factors – from wrong assumptions, unknown or bad requirements, poor design, update frameworks, to the negligence or rush of the developer. This may be unfortunate, but ultimately the final result is code written by a programmer which either works properly or not. When the tester starts bombarding you with tickets, remember that you also wrote these bugs. Sad but true. You aren’t the one to blame? OK, we understand, but maybe you can consider improving the thing that has failed, because you can also have an influence on it. Testing and troubleshooting can take up to 50% of the time it takes to write pure code. That’s quite a lot, isn’t it? Aren’t you curious how long it will take your team to fix? Give it a shot. It will be easier to shorten that time if the developer is prepared to understand and fix bugs. The tests you write will help you keep your code stable before you give it to the tester. Do you remember the jokes about testers who love to report bugs? Maybe they have the satisfaction of a job well done, but I assure you that the greatest joy for them is to work on a well-organized team. Tidiness, attention to detail, and conscientiousness are the qualities that testers appreciate in software developers. If this translates into a well-maintained and tested code, and consequently into less corrections, the tester blossoms. Your colleagues will appreciate it too.
Communicate requirements and Jira
Have you ever been on a team where the tasks were not sufficiently documented and a team member ended up leaving? If you have, you have probably noticed how much knowledge the deserter takes with him. You probably already understand how important a good task description is. Imagining what the author meant to say, what changes were made, and what else should be done can take many hours. It can be a sad life of a tester if you do not take care of this aspect of your job. Remember that Jira or any other task / bug tracker is one of a tester’s basic tools. Let’s appreciate the documentation when we have it, and when it’s missing, let’s create it ourselves. If you do not want the tester to interrupt you all the time, remember to make a detailed tickets description. Do you have an analyst on your team and the requirements are only communicated to you? The tester will be grateful to you for sharing your knowledge, passing on the information which has been given to you, and best of all – pointing to areas that require special attention.
Finally, be kind
Respect each other. Each of us performs a hard, responsible job that requires a lot of concentration. Let’s take care of the quality of our communication with the kindness and understanding which we deserve. Let’s make our cooperation pleasant. Be honest, do your best.