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

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 follow...

Coding something simple.... or not! Taking a screenshot on error using Selenium WebDriver

I recently wrote a little function that takes a screenshot at the end of a test if it has errored. What sounded very simple at the start turned out to be quite a bit of work, and quite a few lines of code to handle certain scenarios! It's now over 50 lines of code! I'll start with what I had at the beginning, this was to simply take a screenshot in the working directory, we are using SpecFlow and Selenium to run the tests, so we are going to check if the ScenarioContext.Current.TestError isn't null, if it is, then using Selenium, take a screenshot (note the below code is a simplified version of what I had at the beginning). [AfterScenario]         public static void TakeScreenShotOnError()         {             if (ScenarioContext.Current.TestError == null) return;             var screenshotDriver = Driver as ITakesScreenshot;             if (screenshotD...

The Stickman Tester... The full version complete with deleted "scenes"!

As some of you may have seen, a little while ago I performed a 99 second talk on the Stickman Tester for the Ministry of Testing. Owing to the fact that it had to be 99 seconds, this unfortunately meant that a verse was left out in order to keep it within the time frame! It's only now that I have found the time to put the deleted verse/scene back in, and re-record it and upload it! (It's now a 120 second talk!) It talks about a testers journey in an Agile team, about how not everybody has it as good as others, and basically talks about not giving up, keep searching, or trying to change your role to make it what you want it to be. Anyway, here it is, in all it's glory. Hope you enjoy it!