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!


  1. I am in love with these mind maps!

  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.

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

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

  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


Post a Comment

Popular posts from this blog

Advantages of using Test Management tools

Before I start talking about test management tools, let me clarify what I mean by the term test Management tools...  I am not taking about your office excel program where you store your test cases in. I'm talking about bespoke test Management tools, your quality centers or Microsoft test manager...
In the strict case of the term test Management tool, Microsoft Excel can be used as such, but heck, so could a notepad if used in the right way... For the sake of this blog post I am talking about bespoke test Management tools.
Firstly, what test tools are out there? There are many more out there today than when I first started in QA over 5 years ago. When I started the market was primarily dominated by a tool called Quality Center, this would run in a browser (only Ie unfortunately) and was hosted on a server.. Nowadays it's market share has somewhat dwindled, and there are some new kids on the block. 
One of the more popular tools is that of Microsoft Test Manager, it's big…

What is a PBI?

After my last post, I had the question of what is a PBI... so I thought i'd write a short blog post about what they are and why they are used.

A PBI is an acronym for Product Backlog Item. It is a description of a piece of work that your SCRUM team will develop and deliver. When you have a list of Product Backlog Items, you then refer to that collective list as a Product Backlog.

The product backlog is often prioritised and yourteam will work through each PBI, and release on a regular schedule... I am however going deep into the world of Agile development, which isn't entirely what this post is about, so I will stop myself now.

A Product Backlog Item is made up of the following:

Title - This is often a one liner that gives the team an idea of what the PBI is about, although it can just be an ID for the item and the team work off of that.

Description - Breaks down the PBI in a bit more detail, and can be written in any style, however I prefer it to be written as follows: 

By writin…

Dealing with Selenium WebDriver Driver.Quit crashes (Where chromedriver.exe is left open)

We recently came across a problem with Selenium not quitting the webdriver and this would then lock a file that was needed on the build server to run the builds.

We were using Driver.Quit() but this sometimes failed and would leave chromedriver.exe running. I looked around and found this was a common issue that many people were having. We (I say we, as we came to the solution through paired programming), came up with the following, that would encapsulate the driver.quit inside a task and if this task takes longer than 10 seconds, then it will clean up any processes started by the current process, in the case of the issue on the build server, it would kill any process started by Nunit.

        public static void AfterTestRun()
            var nativeDriverQuit = Task.Factory.StartNew(() => Driver.Quit());
            if (!nativeDriverQuit.Wait(TimeSpan.FromSeconds(10)))

        private s…