Having recently read the following blog about how to improve communication from a developers perspective, I thought it would be interesting to have a QA perspective on it...
Firstly, communication is key to being a good tester. When someone speaks about the skills of a tester, one thing that I think is one of the top things to look for, is that of a good communicator, someone can have the best technical knowledge and skills in the world, but if they can't communicate what they were doing or how they found a bug, then they would not rank highly in my book.
So how can you improve communication between the QA and the developers, firstly, I don't think you should look at you all as being part of one team, delivering a quality software product, do not have an us vs them attitude, when bugs are raised late on, it's your fault as well as it is the developers fault, you are one team. There is no I in team.
To help in this, it can work in your favour to be careful when raising bugs/defects, do not raise them in an accusatory term, do not degrade their coding skills, people make mistakes, bugs happen, just mention it to them and log it appropriately, and move on. Developers can be sensitive over their code, and rightly so, they will have worked hard on it, so to have it criticised can not hold well for team relationships.
Also, you can improve team relationships by speaking to developers about non work issues, become friendly with them and get to know them on a personal level, this just makes it easier to speak to them about anything, be it work issues or non work issues, when you are talking consistently throughout the day, you can talk to them about anything at anytime without it being uncomfortable.
Whenever you have sprint planning meetings, or any meeting in fact with the team, don't be afraid to speak up, and voice your opinion on anything, if you feel strongly about something say so, the developers will respect you more for doing so. Also, if you don't understand something, ask questions, don't shy away from technical issues, you can guarantee that if you don't understand something then chances are that someone else in the meeting wouldn't have understood it. You will learn far more by asking questions than sitting silent and not doing anything.
Finally, when we talk about communication, I've mainly mentioned face to face communication, and there's a reason for this, I much prefer speaking to people face to face than over email, as it's much more personal and will developer relationships even further than a quick email. Anyone can send an email, if you have an issue speak face to face, it's much hard to misconstrue something that is said face to face than it is over email. If you absolutely have to send an email, don't be afraid to follow it up with a face to face conversation, or even the other way round, speak to them face to face then send an email summarising what was discussed if you want to keep a record of what was said.
You can not underestimate the importance of QA and Developer relationships, you are working together to product something that is much bigger than you individually, so it makes sense to work on the relationship, and make sure it is in as best a shape as possible. Not only will it improve the quality of the product, but it will help improve your work by making it friendlier and more fun place to work.
I've included the mindmap that I created to help with this blog post... stay with me, I will write a blog soon about mindmaps!
Firstly, communication is key to being a good tester. When someone speaks about the skills of a tester, one thing that I think is one of the top things to look for, is that of a good communicator, someone can have the best technical knowledge and skills in the world, but if they can't communicate what they were doing or how they found a bug, then they would not rank highly in my book.
So how can you improve communication between the QA and the developers, firstly, I don't think you should look at you all as being part of one team, delivering a quality software product, do not have an us vs them attitude, when bugs are raised late on, it's your fault as well as it is the developers fault, you are one team. There is no I in team.
To help in this, it can work in your favour to be careful when raising bugs/defects, do not raise them in an accusatory term, do not degrade their coding skills, people make mistakes, bugs happen, just mention it to them and log it appropriately, and move on. Developers can be sensitive over their code, and rightly so, they will have worked hard on it, so to have it criticised can not hold well for team relationships.
Also, you can improve team relationships by speaking to developers about non work issues, become friendly with them and get to know them on a personal level, this just makes it easier to speak to them about anything, be it work issues or non work issues, when you are talking consistently throughout the day, you can talk to them about anything at anytime without it being uncomfortable.
Whenever you have sprint planning meetings, or any meeting in fact with the team, don't be afraid to speak up, and voice your opinion on anything, if you feel strongly about something say so, the developers will respect you more for doing so. Also, if you don't understand something, ask questions, don't shy away from technical issues, you can guarantee that if you don't understand something then chances are that someone else in the meeting wouldn't have understood it. You will learn far more by asking questions than sitting silent and not doing anything.
Finally, when we talk about communication, I've mainly mentioned face to face communication, and there's a reason for this, I much prefer speaking to people face to face than over email, as it's much more personal and will developer relationships even further than a quick email. Anyone can send an email, if you have an issue speak face to face, it's much hard to misconstrue something that is said face to face than it is over email. If you absolutely have to send an email, don't be afraid to follow it up with a face to face conversation, or even the other way round, speak to them face to face then send an email summarising what was discussed if you want to keep a record of what was said.
You can not underestimate the importance of QA and Developer relationships, you are working together to product something that is much bigger than you individually, so it makes sense to work on the relationship, and make sure it is in as best a shape as possible. Not only will it improve the quality of the product, but it will help improve your work by making it friendlier and more fun place to work.
I've included the mindmap that I created to help with this blog post... stay with me, I will write a blog soon about mindmaps!
I am in love with these mind maps!
ReplyDeleteYou'll love my latest blog post then!
DeleteI am so glad I read this. I live by this concept. It doesn't help all the time, but, I am glad to know I have been doing the 'right' thing.
ReplyDeleteGlad it's helped you! Even if it hasn't helped all the time, the times it does help it's invaluable!
Deletereally nice article .... learnt alot from this :))
ReplyDeleteGreat article with unique content, keep sharing your Great blog..
ReplyDeleteBest Embedded System Training in Chennai | Embedded Course in Chennai | Embedded Training in Chennai | Best Embedded Training in Chennai | Embedded Systems Course in Chennai | Matlab Training in Chennai | LabVIEW Training in Chennai | VLSI Training in Chennai
It is of utmost importance not only to communicate but also effectively communicate. Please throw some light on the first instance where Lisa was not suitably promoted.#Davanti
ReplyDelete