Hello my dear Dev friends!
First of all, I would like to thank you for the code you gave us for Testing. Without your code, we wouldn’t have anything to test! I really appreciate the great effort you put in the research and investigation for each of the modules you develop. However, there are some things that I would like you to do “more”; which will make life easier for us, as a team. Here are my suggestions:
Read the Requirements and ask questions.
Pretty obvious, isn’t it? I know you are reading the requirements and I know you are asking technical questions about how to write the code according to the coding standards. But I’m not quite sure whether you are asking questions about how the “feature” you are developing is going to be used by the end user! Unless you don’t know how the feature is going to be used by the end user, your development is not complete. Please don’t say that it is the job of the testers to do that! Yes, we do that; but there is no harm in you doing it either. Now you might ask “Why should we do that?” Because, when you ask that question before you develop something, you are effectively minimizing/avoiding the rework that can happen for something that was developed is not fit for the user! What is the point of wasting your time and effort in writing code that is not fit for purpose? Your one question might save a lot of time and effort for the whole team!
Take responsibility for your code!
Hmm, that is also pretty obvious. It is hard to be 100% perfect, but there is no harm in trying. Try to set a benchmark for your code, set a challenge for yourself “I’m not going to allow any tester to find defects in my code”. Code like your life depends on it. We all are humans, and we make mistakes. Owning our mistakes and taking responsibility to fix it will only make life easier. You can be rest assured that you are not going to make that same mistake in your life again 🙂
Ask your Tester for help!
Alright, do you think we are your enemies? NOO! Understand that I’m trying to help you. You are developing the code, and we are trying to give you information about what didn’t go well with your code! That doesn’t mean that we are giving you more work in terms of fixing bugs and implementing new changes. Imagine what happens if the testers also miss an obvious defect in the code and the customer finds it! Yes, Testers get the blame first, because we didn’t find that bug. But, we didn’t code that bug in the application either! So who is suffering in the long run? We all are! Our Organization’s brand is at stake if we don’t do it properly. When we work together and find defects together, we are working on the same goal and we are working on making something that is good to be better! And don’t you know that when we interact well, the rapport increases and you can be rest assured that your tester pal is there to save your back even when you have made a mistake? Quality is everyone’s responsibility, right?
Read my bug reports to the full!
Yes, you read that right. Read the reports to the full. Because, like the code you develop is your output; the bug reports we write is our output. My personal opinion is that I consider myself a disgrace as a tester if you are not understanding my bug reports on the very first read. You have every right to shout at me if I’m writing poor reports. That being said, if you don’t read the reports to the full, you may not know whether it is written well or not. Just skimming through the bug report may not be enough for some complex issues. This is something similar to the first point we discussed. Not reading a bug report to the full and implementing a partial fix is only going to increase rework for the team!
Ask me questions!
Yes, we like to answer queries and explain scenarios (if you don’t find that boring ;)). There are chances that even a very well written bug report might be complex and you are not able to understand it. Come to us! We are all ears. Also, asking questions might help us realize that the bug reported is a big blunder or a duplicate. 😉
Communicate your changes!
Obviously, we all want to have the information on our finger tips. So, once you make a change and deploy those changes to the Test Environment, please send out an email or ping your tester buddies to stop testing. Otherwise, they won’t be aware of the change and it could result in unintended bug reports, confusion and a whole lot of mess. Yes, the same rework stuff we discussed earlier. Your tester buddies might be investigating some other issues or setting up the test data for an important scenario, and one change in the environment can sabotage all the plans. It is a good thing to keep your team informed about what you are working on and when you are making changes.
So, that’s it. If you could try to accommodate at least a couple of things mentioned above, that will make a difference! I am great fan of Dev-Test collaboration and the points mentioned are NOT intended to start a Dev Vs Tester war. I know that my Dev friends have similar points on “What we want from Testers?”; and I would be really interested to know them! Send in your feedback, comments, mails, tweets…. 🙂