Do we need QAs/testers?

 

“Do we (still) need QAs?”

… and flavours thereof, is a question I have been hearing for years now.

The same has been asked of Tech Leads, Operations Engineers, “Front End” devs, “Back End” devs, Security, Iteration Managers/Scrum Masters, Business Analysts, etc. Anything that is not a full-stack dev. The #NoOps conversation is interesting research material.

It seems to me that this question stems from a misinterpretation of agile and lean startup materials.

Idealistic hopes of cutting costs, removing waste (and blindly classifying some roles as such), delivering faster, etc., have caused some to think that role specialisations can all be generalised into being “Engineers” and that we can all self-organise and just do it all.

If you’re a true startup, initially this argument holds water. A techie and product person pair on everything and just #GSD. They hypothesise, they ship, they iterate, they pivot, they MVP, they measure. It works.

But then technical/product and market/customer complexity become a reality and the depth of the problem or technical domain require specialised help:

  • The person who was writing code, cannot keep track of all UX and non-functional metrics in production.
  • The volume of work and the dependencies all of a sudden need a scrum master who can take directional measures and help align vectors.
  • Etc.

The pendulum has swung both ways

And as most extremes go, they have both been destructive. Any cult-like thinking leaves one unquestioning & inflexible.

 One end of the swing is the fully sick enterprise waterfall model, where there are battery hens of QAs, sometimes at a 1:1 QA/Dev ratio. They gate-keep releases, argue about severity of bugs, and act like bullish custodians of quality.

(queue croaky voice) Back in my day… we really did work this way, and sadly some people still do.

Plenty has been said about why this doesn’t work and can be destructive, so I will spare you a dissertation.

The other end of the swing is either “we need to cut costs now!”

OR “we are a wannabe startup” and we don’t need specialists. We aren’t a real startup anymore, there is too much business and technical complexity now; but we want to cut costs/waste, just look cool, or just wish we were still a startup.

We do away with any specialist roles without a deep understanding of the actual (unbiased) value they deliver.

People may wholesale do away with roles that they don’t actually understand, or roles that they are viewing through a bias-lens based of murky information or opinions or idealistic hearsay stories.

I remember a time several years ago, when I was retrenched as tester along will all testers the company employed – to cut costs, and “because the BAs could do the testing”. They rang me 6 months later, offering my job back, with quite a raise!

Not having a QA on hand when you actually need one, can be destructive to not only system quality but also reputation and revenue.

Quality analysis helps address risk & complexity

Quality Analysts (QAs) are not there to assure quality.

They are there to analyse quality and quality practices and advise on approaches to system quality. They are particularly good at helping mitigate quality risks because of their trained ability to question what seems to be there.

They are neither the gatekeepers of the releases, nor meant to be the bottlenecks for testing, nor the owners of quality.

At REA Group, our QA position descriptions clearly state that QAs help the teams own quality.

T-shaped roles

The generalist / specialist argument is a well-known one. For instance, the general practitioner (GP) is a generalist doctor, but sometimes you do need to see a specialist to address specialist ailments.

When to engage a generalist, and when to engage a specialist, depends on the problem at hand.

When problems cannot be predicted, an excellent and sensible compromise is the T-Shaped role (image credit Jason Yip):

Most lean and agile teams, now employ T-shaped roles.

As such, all roles on a delivery team now need QA skills too. These will only be generalist skills, as their role specialisation will still trump other skills. A developer may have generalist operations and QA skills, but remains a specialist on software development and can advise other roles thereupon.

Conversely, QAs too need skills in business analysis, product ownership, UX, development, operations (system engineering), delivery leadership, environment management, etc. – in addition to specialist expertise in risk and complexity analysis and critical thinking and testing approaches.

The more senior the QA, the better the specialist AND the generalist skills.

A team of T-shaped personnel is a balanced team which can flexibly deal with the vicissitudes of the unpredictable life of a software development team and their system maintenance.

When DON’T you likely need (more) QAs?

(examples)

“We have lots of bugs” – rather check your quality processes first (one cannot test in quality – but one can build it in)

“We have UIs to test” – yeah so? (what’s the team doing about that?)

“Someone needs to do cross-browser testing” – same as above

“We have a lot of manual regression testing to do” – automate your repeatable tests! (developers are great at that) or if technically unable to be automated, get the whole team onto this manual activity

“We don’t like testing” – {response cut}

When DO you likely need some QAs?

(examples)

“There are significant integration points” – complexity requires risk analysis & quality analysis

“We are bound by SOX compliance” – again, risk

“This is an absolute deal-breaker for our business” – yes, all-hands on board

“This may affect our share price” – same as above

“We have a team new to this way of working” – a QA can coach developers on testing & quality ownership

“We don’t know how to approach testing this massive system” – a QA may compile a formal or informal test strategy & help the team execute it

“We prefer having someone around who challenges our blinkered thinking” – QAs are just great at questioning, and being curious.

Context-driven thinking

The short answer is yes, we do need QAs. Not all the time, not everywhere, but yes we do. Just like other role specialisations.

Apply context to the decision to appoint a QA, or not.

Sure, cut your waste. Sure, get help with improving quality. But don’t blindly brush all QAs and all QA needs with the same brush.

What can you do?

Train your QAs to be T-shaped and be Lean QAs. 

Train your QAs in updated technologies so they remain engaged & useful, and run at the same pace as the rest of the team.

Train your whole team to own quality and be T-Shaped in generalist QA duties.

Apply context and critical thinking in decisions to hire, or not to hire a QA (and involve fellow critical-thinking QAs in the hiring process!).

Lastly, try not to believe hype and pendulum swings: there IS a time and place for specialised disciplines.

This entry was posted in Culture, devops, Engineering, Our Processes by Theresa Neate. Bookmark the permalink.

About Theresa Neate

Theresa Neate is a career tester and test consultant who loves lean and agility and advocates for holistic system quality and systems thinking. She has 2 decades of IT and non-IT testing and QA experience and since February 2016 has been at digital media icon REA Group. In her spare time Theresa freelance blogs for TechTarget DevOpsAgenda and co-organises and contributes at DevOps Girls. She’s a lifelong and eternally curious sceptic and learner. You can also find her at http://theresaneate.com and https://twitter.com/TheresaNeate.