Skip to main content

How a QA/Test Lead works in an Agile environment

So I recently had a discussion at work to define how my role works and the responsibilities and what it entails. I thought it would be good to open that up to the wider audience here, as I often hear that there is no need for a Test Manager/Test Lead in an Agile environment.

Whilst there is no need for what we would see as an old school test manager, being one that manages test resources and allocates testers to projects, there is still a need for a test manager/test lead, and I'll explain my thinking here.

In the past my role has been around fighting fires and helping teams out when testing resource is needed, which don't get me wrong I have enjoyed as it's meant getting my hands dirty and improving things from the ground level.

However, I wanted my role to be clearly defined as we have gone through structural changes since it was last defined, and some of the responsibilities aren't necessarily valid still.

  1. Drive testing within teams
     Directly or by working closely with Testers in the team
     Define how Seniors and Mid Level Engineers work together in a team
  2. Create a Testing Community
    Help develop and mentor testers
  3. Recruit good testers
  4. Put on classes/programs for people to learn and develop
  5. Forecast Test Resources
  6. Oversee any cross cutting concerns of projects across the organisation
  7. Improve the perception of testing

The first thing that I wanted to work on was working closely with the teams that I look after, work with the testers within the team so I can help see what the weaknesses/strengths are and help them develop accordingly. It is also important to define how seniors and mid level engineers worked within teams to ensure that testers across teams were working at comparable levels. I also want to be able to mentor people and help testers grow and be there in case they need help/advice in any testing conundrums that they may come across.

Next I'm really eager to get a sense of community going, I've had  few meetings with people who are also interested to define what we see a community as, what they want from a community, so it looks like things are going to start picking up hopefully on that front. I read an interesting blog here that defines what a community is and how it should work and I agree wholeheartedly with that approach. The next step is obviously implementing it... More updates will obviously occur on this front.

Another important factor of my role and in all honesty is probably one of the most challenging and time consuming aspects is recruiting good testers for the teams, but it's something that I want to look after and help achieve as this will ultimately make my job easier and help me achieve another goal in improving the perception of testing in the company.

I want to also work with the testers that we have and provide classes and help people put on classes to improve their skill-set to help them become better testers, as it's all very well recruiting good testers, but it's important to ensure that current testers who we have aren't left behind. This is something that unfortunately I've not had time to do yet, but it is something that I plan on doing going forward.

Also, whilst I don't manage resources I do have a say on estimating what resources will be needed for up coming projects, which I enjoy looking at and learning about new technologies etc.

Finally, I think it's important to have a view of  multiple projects that are going on to see any cross cutting concerns and ensure that testing covers all aspects of any integration that may occur.

This is a high level overview of what I think a test lead/manager role should be in an agile organisation, sure it will vary from place to place, but

Comments

  1. Two things jump out at me. The first is, at least in my head, a lead is someone in charge of the 'technical' aspects of a project while a manager is someone who is more involved in the 'people' aspects. Obviously these two categories intermix, so another way of looking at it is to say a lead is the person dealing with how the work is organized and completed in a testing team and a manager is concerned with a larger picture. The lead would be an expert in the system(s) under test and would have a solid idea of the testing workflow. The lead might know a great deal about the automation and/or documentation being developed and likely wrote a large portion of it. The manager would be more concerned with the bigger picture. They might be talking with the CTO about QA needs, about how the ratio of Dev-to-Ops or QA-to-Dev is wrong in their context. This gets me to the second thing that jumped out at me.

    Where is the improvement of the process outside of testing? Assisting the developers in improving their code and teaching them to do basic 'bench' testing. Helping design who does what types of testing (unit testing, integration testing, functional testing, etc.). I recall James Whittaker wrote something to the effect of how he judged a QA engineer by how well the development team did and/or improved. While this might fall under your cross-cutting concerns, I didn't get that out of your writing.

    I could go on, but there is some food for thought.

    - JCD

    ReplyDelete
  2. I think #2, #4, and #7 address some of the most important problems with the broader testing "community" today. Everywhere you look in software development today, there are coding "celebrities". Household names, rock stars, evangelists (Matsumoto & DHH, for example, are two among dozens of others), who have gathered large development communities full of really passionate young programmers by the thousands.

    Quite frankly, I think the testing craft is desperately starving for this kind of passion, and leadership. I scan blogs, twitter accounts, and videos constantly, and as far as I can see, there are really only two people who are even marginally successful at inspiring the same kind of self-identification with testing, and the same sense of community, as the celebrity coders: James Bach, and Markus Gärtner.

    The blog you linked to is essentially restating a presentation by James Bach (as pictured). We need a lot more James Bachs, and a lot more passionate young testers following people like James Bach (and others), if testing, as a craft, as a discipline, and as a role within organizations that rely upon software development, is going to survive into the future.

    Many people are terrified of the notion of "celebrity testers" (see Karen Johnson's chat at CAST 2014, here for example: https://www.youtube.com/watch?v=rUijs3KifxU). But the point Karen is missing, is that "celebrity testers" *are leaders*, and leaders inspire, and inspired people form communities, and communities will rally around leaders when the need is there.

    What you are doing at your organization by promoting community, active learning, and open communication, is precisely that. And as such, you are providing value to much more than just your organization. You are adding real bricks-and-mortar to the larger testing community, and in doing so, helping to make sure that the craft not only survives, but *thrives* in the coming decades.

    ReplyDelete
  3. Lead Abatement and Lead Hazard Standards. There are numerous state, federal and industrial standards for lead exposure, lead abatement, testing for lead and removing it. This article addresses the most commonly cited standards on lead. An Introduction to Lead testing

    ReplyDelete

Post a Comment

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.

[AfterTestRun]
        public static void AfterTestRun()
        {
            var nativeDriverQuit = Task.Factory.StartNew(() => Driver.Quit());
            if (!nativeDriverQuit.Wait(TimeSpan.FromSeconds(10)))
            {
                CleanUpProcessByInheritance();
            }
       }

        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.