Skip to main content

Improve Communication between Developers and QA

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!






Comments

  1. I am in love with these mind maps!

    ReplyDelete
  2. I 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.

    ReplyDelete
    Replies
    1. Glad it's helped you! Even if it hasn't helped all the time, the times it does help it's invaluable!

      Delete
  3. really nice article .... learnt alot from this :))

    ReplyDelete
  4. 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

Post a Comment

Popular posts from this blog

Treating Test Code as Production Code

It's important when writing automated tests to remember that the code you write should be up to production standards, meaning any conventions that you have in place should be adhered to and that it should follow good design patterns. Too many people often say why does it have to be as good as production code, it's "Only" a test, so long as it passes then that's fine... To answer this we need to look at why we want our tests to be written in such a structured and efficient manner: - Maintainability - by making the test code structured and efficient, it becomes far easier to maintain and in doing so changes in the future can happen quickly as the test isn't linked to anything that it shouldn't be and it's easy to understand for a new set of eyes. - Durability - Again by making the tests structured they should be resistant to changes, if you change a variable name for instance then it shouldn't effect the unit test unless it absolutely has to....

Testers: Be more like a Super-Villain!

Who doesn't love a Super Hero? Talk to my son, and he'll tell you how much he loves them, talk to many adults and they'll say the same! Deep down, we all love to be the Super Hero, we all want to save the day! However, I want to talk about the flip side of Super Heroes, the Super Villains... I often play Imaginext with my son, and I (unfortunately?) am nearly always the Super Villain! Be it Lex Luthor, Joker, Two Face, Mr Freeze or The Riddler! These are all great characters and great Super Villains, but why would I want to write about Super Villains? A while ago where I worked, we had a few Super Heroes, people who would be able to come in and "fix" things that had broken and help deliver projects on time. We then shifted, we decided to do away with the Super Hero culture and try and prevent from being in that position in the first place, whilst we didn't go as far as wanting to hire Super Villains, it's definitely a story that has stuck with me and t...

Using BDD and gherkinising your Acceptance Tests

In my post Testing of Automated tests , I mention about a BDD framework which involves using BDD to drive your acceptance tests. BDD stands for Behaviour Driven Development.  One effective method of writing BDD tests are by using a format known as Gherkin language. These consist of Given, When, Thens. The main advantage of the gherkin language is that it's readable by the business, and in an ideal world forms part of the Conditions of Acceptance around a PBI. Also, using a Visual Studio plugin of SpecFlow , you can integrate your Gherkinised COAs into your solution with feature files, and then drive the automated tests, however, for this post I will focus solely on how to effectively gherkinise your acceptance tests. A Feature file consists of a feature outline, which details what the feature file is testing followed by Scenarios and examples (parameters).  The BDD scenarios are made up of a Given, When, Then... These are effectively an initial state (Given), an action (W...