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.


Labels:

Comments

Post a Comment

Popular posts from this blog

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...
15 comments
Read more

How to manage resources within new teams?

Working where I work we are constantly spinning up new teams to take on new workloads as business come up with new demands and new features they want developed and tested. The problem with this is how do we ensure the work of the newly spun up team is of sufficient quality. One method is by taking people from other established teams and placing them on the new team. This works great for the new team, but unfortunately it will oftenl eave the established team lacking in a resource whilst they try and fill the gap left by the person who has left. We are seeing this often with our offshore teams, it can be damaging to the team structure and the teams velocity, but try as I might, I can't think of another way around it. It's far easier to take 1 person from a team that is established than it is to build a whole new team from scratch. At least by leaving the core of a team in place, you should be guaranteeing that the new team are aware of any coding standards or any QA standard...
Post a Comment
Read more

Considerations when creating automated tests

We recently released to a number of teams our automated regression pack that has been worked on over the past few months. This regression pack tests legacy code, but contains a large number of tests.  As a bit of background, a number of teams are working on new solutions whilst some are still working on legacy code. With this in mind we constructed an email with a list of guidelines when creating new tests that need to be added to this regression pack.  I figured that these can be quite broad so should apply for any organisation, so thought it would make an interesting blog post...  So here goes,  when creating automated tests, it's important to consider and adhere to the following: - Think about data . The tests need to retrieve or set the data they need without any manual intervention - This should help them be more robust and easier to run without manual intervention. - The tests need to be idempotent - By making it so that each test is standalone and does...
Post a Comment
Read more