developers

Every tester is probably aware of the stereotype that developers hate testers. But does that statement have any ground underneath? Is that the bitter truth every tester will have to deal with every single day at the job place? We were curios and did a little research. The simplest way would be to just ask developers and so we did. Here are our results: There was this time back at the day when I first met and worked with a tester on a project. We were developing some kind of a news website then and the firm hired several testers to try things out. It was quite some time ago, when testers were as rare as unicorns in IT companies. So I was going through the very first report I got from a software tester in my life and all I could see is that the person clearly does not understand the product. He just found so many defects, most of them so small that it seemed they were nothing but irrelevant. But there were several real bugs he found that mattered a lot. It took some time before I realized that the size of the issue does not matter. I want my code to be perfect. Until this day I am grateful to that tester for planting the seeds of this thought inside my brain. Sam Nichols, Senior Architect Actually the parts testers are not understanding in the product are the most valuable ones. That’s the view of the end user in its purest form. Software’s just not entirely about code, logic and algorithms.  We are looking to deliver people something they will be using with ease. Something of value to users. If it wasn’t for testers then software today would be something only real geeks may use. Michael Schetkin, Team Lead I always want to get feedback and reports from testers first. I am aware how painful it is when somebody is saying bad things about the code you have loved, cherished, spent hours on but that is a necessity today. After all we all have a thirst for perfection. And I, today, wish to find out about all the nasty things first. Then only I will share all the updates with the team. Servey Vachlov, Team Lead All names have been changed in this article because of a request from our developers. Their pride can’t take the punch of admitting they all need and love software testers.

Recently I got a chance to mete Peter, an old friend of mine, a tester of the good ones. And as we were chatting he told me of his first experience with an agile team. Peter kindly allowed me to write about it in one of my ‘software testing articles’ as he calls them. He was astonished from the first group meeting they were holding to work on some issues. The thing is that the developers were discussing how they should test the new feature. Not how he, the tester, would, but how they will do all as a team. The question “how are we going to build that stuff in order for it to work properly” almost made him loose consciousness. He is one of the old-school guys, that probably is the reason of his reaction. How’d the process go? So he told me how all was going. As the features were built developers were writing all tests from unit to browser level. And a special developer was even doing manual tests. Then only was all passed to him and a fully integrated environment. So it was a rare occasion for him to find a bug that was caused by inaccuracy. Most were crawling in all kinds of user scenarios that were not pre-discussed. Thus the process turned around a bit. Software testing was done before, rather than after it was getting to my fellow tester. Yet that is a positive side. He was still needed and could do his job even better due to the fact he had more time. Although he had to put more effort in the processes beginning. There his experience was of tremendous value. But where is all this head? The general idea is that the new hybrid of developers and testers is the future, as my friend said. And these exact words he asked me to write in one of my ‘articles’.

It is believed that testers should have good relationships with developers. How much do software developers differ from testers and QA engineers? They are often considered to be totally opposite units in the tech world, but if to take a closer look you will see that they are more alike than you have ever imagined. They have lots of similar features. You should keep in mind that it is always good to keep a developer in your QA team. Testers and developers may be the most frightening rivals or have a mutual understanding between each other and cooperate that will bring up good benefits for testers. Because it is quite good to have an ally on your side who is as dedicated as they are. Let’s take a look at the features most appreciated by the developers while cooperation with testers: The following are the traits most valued by developers: Detailed explanation Developers always rush to meet the deadline and often they have little time and if testers are not clear in their explanations while reporting the bugs it can lead into awful results. Testers should have a good understanding of software to be able to elude the needed information and leave the flood behind their story. Understanding the developers’ slang If you want to get along with the developer and understand what he is talking about you need to know the technical slang. Knowing their lingo will allow testers to speak freely and give some respect from the developer during important discussions with the team. Quality is in priority You may be super qualified as a tester and be best in your stuff but what developer wants is to see significant bugs, issues that involve core functionality and the analysis of a root cause. Be open-minded and cooperative Developers want testers to be open-minded and willing to talk to testers in order to work out the problem or working issue. Testers might be astonished that developer would be grateful if they give them an advice or give an expert opinion. It makes their job easier the next time around when coding!

There are a lot of testers complaining that though they catch an enormous number of bugs a developer quite often doesn't take them into considerations. One can probably say it's not tester's job to get the bugs fixed. But agree that it is anyway frustrating when somebody does not take seriously your efforts. So the better you will sell your bug the more attention the developers will pay to it. One of the ways to get hold of developers' time and attention is to write an enticing bug report working as your bug's advertisement. If you follow the tips below your bug report will definitely stand out in the crowd. Tips for Efficient Bug Report Your bug report should be as simple and straightforward as possible. If a 12-year-old child can repeat your bug in accordance with your report then you can consider your report well-written. Write realistic reports. If the bug has nothing to do with real life then the developer will most likely ignore it. The more required set ups needed the bug report contains, the easier it will be for a developer to reproduce it. This is all the more important when the detected bug proves to be configuration dependent. Your main task is to get to the root of the bug. Sometimes a bug has more than one symptom of the problem. In this case you should mention the most serious one for example data corruption and include its description in your report. You should always make your bug report inviting enough to capture the developer’s attention. The tip “You should make it inviting” does not actually mean “You should make it exaggerated” if you don’t want to risk your tester’s credibility. In other words your bug report must describe well the importance and possible consequences of the bug. Well-written report also includes the description of how it affects users, what distress a similar software bug had run to before and how the competitors had suffered because of it.   A properly written report is a successful sales ad for your bug. Consider that you are selling your bugs to developers. Once you become a good marketer for your bugs you will watch them being fixed quicker and quicker.

Is it true that testers are those awful troublemakers as developers suggest? Of course, nobody wants to be criticized, especially when it’s his/her work. But what testers really do is delivering qualitative product to a client. That’s why at some point of the game developers feel themselves kind of offended. Want to know why? It’s the character and responsibility of these two roles. Sometimes severe bugs occur, sometimes bug invasion occur and developers feel irritated of the number and sometimes even at the person. These two roles lack the understanding between each other in many areas. Creating a good and understanding relationship between testers and developers Friendship and teamwork are the best keys to solve this issue. Being a good friend to a developer, means that you can talk to him and he will understand the issue and therefore you two combining your efforts, can improve the work. Both of you should understand that the better and the more coordinated your work the greater result you achieve. The developers, on their side, should guarantee that their work is free of bugs. However the testers, on their side, should ensure that if there are bugs, they should be dealt with in time and appropriately before it’s time to release the project. Being a QA and having spent time with a team makes the relationship between every member, including you and developers, friendlier. While working together you can find faults beforehand. And it’s always better to fix them right away, rather than get complaints from clients. From cooperating, i.e. discussing design and solutions, everyone can benefit, for example developers can become aware of various issues and areas, so that they can improve the quality of their work, hence implanting the quality into their minds. Testers always find bugs but they can also share some tactics with developers on how to test their work. It could help the developers to test their projects better, before handing them to clients. Note that such scheme can be true only when everyone is working together and share the same final target, i.e. “to deliver a high-quality product” and to satisfy the client. Thoughts sharing: So what is the best way to make the relationships between developer and QA friendlier? Here are some thoughts concerning this issue: Sharing. Share your thoughts, strategies with developers. Don’t leave it till it’s become a screw. Be friendly and open-minded with developers so that they don’t feel wounded. Give ...