Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Blogs Banner

Becoming a QA Leftie - Team Quality Indicator?

During delivery of a product, there are times when I check the board and think "Ok, all is in hand with the stories in play. Great, I can start to focus more to the left". By 'left', I mean the Analysis area of the story wall, the right-hand side traditionally being Development and Done.

This comes after I've gained the confidence that the devs understand what to build and that the automated test framework and stack is in a good shape. It takes time to reach this phase and relies on a lot of groundwork and discipline by the team in setting up pipelines, environments and workstations, and in me gaining confidence that the team is generally following all the good dev practices that TW believes in. Basically, a mature team.
 
To me, this is a natural goal of the QA, to spend the majority of their time at the genesis of stories, learning about what the work is, the scope and how it fits with the product built to date. Being ahead of the development engine. I believe it is also an indicator of the team's practices and processes - dare I say it, the quality of the team?
 
Imagine the other end of the spectrum, i.e. to the right-hand side of the story wall. The QA spends most of their time working on exploratory testing, finding defects and looking at automated tests. They'll obviously be involved in story kick-offs and have input in acceptance criteria, but the majority of their day is spent

  1. making sure that the functionality being built right now is working as expected
  2. ensuring the story has the appropriate automated test coverage,
  3. ensuring defects found are resolved and further test coverage is subsequently put in place

rather than

  1. discussing new stories with the BA and XD
  2. questioning the product owner (and, if possible, end users) about the optimum user experience and goal of each part of the product
  3. assisting the product owner and BA with any technical understandings e.g. defining the expected number of concurrent users, explaining how to define highest transaction volumes, providing access to environments and insight into how the team is currently building the product.

 
I believe there's a natural ebb and flow that occurs during projects where the QA finds themselves spending most time on one section of the wall. Multiple factors affect this (team size, maturity, external project influences, infrastructure etc), however I believe that if a QA can comfortably spend most time in the Analysis part of delivery, it's an indicator that the team is motoring along nicely and exercising good practices for software delivery.
 
It's certainly been a personal indicator of how well the team is doing. Have you encountered this?

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Keep up to date with our latest insights