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

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

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

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