Skip to main content

A day in the life of a QA Lead!

I thought it might be interesting to some people to start doing some posts about my day to day job as a QA Lead! I often get asked what it is that I do, how do I do it, what skills are important and just what is difficult about the job, so what better way than to just start a diary documenting all of this!?

In writing this, I've figured it would be a good idea to get others to do the same across the different levels and teams, as we very often get asked in interviews "What will my day to day role be?" So hopefully this will serve as a useful piece of information.

So lets begin (on a Friday as this idea came to me on a Friday!)

Friday June 17:

8AM : It's Friday, and it's Summer, so you know what that means (or maybe you don't, but you will now)... It's Summer hours here! So a 3PM finish today! I got in early today to make up for the England game yesterday where no work was completed for obvious reasons (what a result!), I have to catch up on emails as well as trying to get a solution to build and run some automation before an Automation Deep Dive that I've booked in with one of the Senior QAs here to see what they're working on and to see if there can be any improvements.

He's already taken the team through what he's done at a high level, but I want to go deeper and see what improvements can be made. Already after the last session I feel it would be beneficial to go over BDD & SpecFlow as well as taking the entire team through a Test Planning workshop to get everyone talking and communicating. Right now it seems like the Automation that he's worked on is just worked on by him, I want to change that and get the whole team on board. Hopefully the workshops I've arranged will help with that.

11AM: left my desk to go to another meeting, but got grabbed en route and ended up participating in some swarming on some failing automation by one of the 10 teams that I help which was pretty cool to see and be a part of! (So the meeting had to happen without me, but it was worth it!)


Midday: We also had a review of some End to End tests for a major project that's going on, it's being done by a single team, so it's important that we as Leads have overview as the project touches a number of areas that we all look after. It's good to see progress being made and whilst I disagree with the reasons why we're doing it, it's important that it's done right and is easy to maintain going forward by everyone involved.

We also discussed about having checks for the API & UI as part of one test suite, which I'm not a big fan of, it will increase the feedback loop of the API checks, as well as making the overall suite flaky. I'd rather have them as 2 seperate packs, and if the API fails we don't run the UI... So watch this space in that regard as we are going to discuss it next week.

1PM: Time for lunch so I went out for a quick walk in glorious sunshine, sometimes I'll take a packed lunch, but either way it's lovely to get out of the office! Had a catch up with someone about Test Data and how we can manage that for teams Integration Testing for one of the big releases that is coming up soon.

2PM: Final meeting of the day, but it's a celebratory one and one that is in good spirit for a team that's been working hard and met some really tight deadlines, so the update is good, and it's more of an update for the other teams on what's going on and what's happening. It's nice to see such a big group of people come together and pull all in the same direction in achieving something for the greater good.

3PM: Home Time! Whilst on the way home I send out meetings for the workshops that I want to do, so hopefully people can make them!


So today has been largely been spent in meetings, working with people to help them improve and just facilitating conversations between people and ensuring that we're following a good path when it comes to Testing & Engineering, which can be difficult when I have so many teams, but it's important to have strong Seniors within the teams and platforms who can help with the load.




Comments

  1. This is a good idea but I am just wondering how if we each day, write down what we do, we'd notice how monotonous our lives are. Most of the times at least

    ReplyDelete

Post a Comment

Popular posts from this blog

Treating Test Code as Production Code

It's important when writing automated tests to remember that the code you write should be up to production standards, meaning any conventions that you have in place should be adhered to and that it should follow good design patterns. Too many people often say why does it have to be as good as production code, it's "Only" a test, so long as it passes then that's fine... To answer this we need to look at why we want our tests to be written in such a structured and efficient manner: - Maintainability - by making the test code structured and efficient, it becomes far easier to maintain and in doing so changes in the future can happen quickly as the test isn't linked to anything that it shouldn't be and it's easy to understand for a new set of eyes. - Durability - Again by making the tests structured they should be resistant to changes, if you change a variable name for instance then it shouldn't effect the unit test unless it absolutely has to....

Testers: Be more like a Super-Villain!

Who doesn't love a Super Hero? Talk to my son, and he'll tell you how much he loves them, talk to many adults and they'll say the same! Deep down, we all love to be the Super Hero, we all want to save the day! However, I want to talk about the flip side of Super Heroes, the Super Villains... I often play Imaginext with my son, and I (unfortunately?) am nearly always the Super Villain! Be it Lex Luthor, Joker, Two Face, Mr Freeze or The Riddler! These are all great characters and great Super Villains, but why would I want to write about Super Villains? A while ago where I worked, we had a few Super Heroes, people who would be able to come in and "fix" things that had broken and help deliver projects on time. We then shifted, we decided to do away with the Super Hero culture and try and prevent from being in that position in the first place, whilst we didn't go as far as wanting to hire Super Villains, it's definitely a story that has stuck with me and t...

Using BDD and gherkinising your Acceptance Tests

In my post Testing of Automated tests , I mention about a BDD framework which involves using BDD to drive your acceptance tests. BDD stands for Behaviour Driven Development.  One effective method of writing BDD tests are by using a format known as Gherkin language. These consist of Given, When, Thens. The main advantage of the gherkin language is that it's readable by the business, and in an ideal world forms part of the Conditions of Acceptance around a PBI. Also, using a Visual Studio plugin of SpecFlow , you can integrate your Gherkinised COAs into your solution with feature files, and then drive the automated tests, however, for this post I will focus solely on how to effectively gherkinise your acceptance tests. A Feature file consists of a feature outline, which details what the feature file is testing followed by Scenarios and examples (parameters).  The BDD scenarios are made up of a Given, When, Then... These are effectively an initial state (Given), an action (W...