Skip to main content

Become a team player....

We've all worked as part of a team as a tester before, whether that be in an Agile team where you work directly with developers or in a QA team in a more waterfall environment, but have we ever looked at how we can improve our relationships within the team? I'm not necessarily talking about nights out, although that undoubtedly helps, I'm talking about team relationships and enhancing them as you see fit.

It's been a long time since I worked in a Waterfall environment, however, I think the same principles apply to waterfall as they do for agile when it comes to team relationships.

When working in a team, the following are key principles that I think you should follow:

  • Team first - Put the team first before any personal gain, if you are up for a promotion for instance, then don't just think about yourself, don't put your personal objectives above that of the team, this will be noticeable.
  • Communicate freely with the team - Often I've been in teams where they've been deemed a bit loud, that to me isn't a bad thing, a team that plays well and laughs together undoubtedly works well together.
  • Be honest with your team members - If you're having trouble doing some work, be honest and open about why, don't try and shy away from it, tackle the problem head on, and you never know people in the team might be able to help you overcome that team.
  • Talk about personal life - Talking about your personal life builds the trust within the team, and with trust comes respect, which will undoubtedly help the team work together.
  • Don't blame individuals - It's not any individuals fault as to why a product was released with a bug in it, people will ask the QA what was tested, and if it wasn't tested, then questions will be asked as to why, which is definitely a team question, was it a lack of communication? or was it a last minute change? It doesn't matter for the blame game, but it does matter so that you can learn from it and avoid it next time.
I read a blog recently here where she discusses the value in retrospectives, these are often invaluable in building team relationships, what is said in a retrospective should stay in a retrospective, and it's a platform for honest and constructive criticism as well as patting people on the back and saying they did a good job. Retrospectives aren't completely about actions, so long as people are honest with each other and relationships are developed, then that in my opinion is another positive for retrospectives.

So whilst that last point was agile specific, there's no reason why you can't have similar meetings in waterfall after a release, discuss (either with just QA or developers as well) what went badly, what went well etc. 

I think if an individual... no sorry, team, were to follow the above, then they would certainly all feel a part of something bigger than themselves, and it wouldhelp make work more fun, and help them work better together.


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…