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

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…

Famous Movie Quotes applied to Software Engineering - Jaws

You're gonna need a bigger boat? How can that relate to Engineering?

Firstly, let me ashamedly admit, that I've never seen the whole of Jaws all the way through. It's on my list of films to watch, but whether I get round to it, is another matter!

Anyway, to apply this to engineering, it's almost like "you're gonna need more testers/developers"...

We hear this all too often when trying to push releases out the door, let's throw men at it... However, as we all know, a bigger boat/more men... isn't always the answer, it's not a guarantee of quality, or even a guarantee of getting things done quicker.

If you have a task that will take 2 hours, simply having 2 people work on it doesn't mean that it is halved, in fact often, the time taken to do the task remains at 2 hours, but the maintainability and the knowledge around that area is increased, so it's a price, in my opinion that is often worth paying.