Our Continuous Testing odyssey - part III

This blog post is all about the difference between operational & aspirational work, how does the waste disguise itself, why QA is so prone to over-doing, that QA is much...

20 days ago

Latest Post How does Dunning–Kruger effect impact collaboration in tech teams by Sebastian Gebski
This blog post is all about the difference between operational & aspirational work, how does the waste disguise itself, why QA is so prone to over-doing, that QA is much more similar to other disciplines of engineering than one may think, how making things visual helped us a lot with stopping starting :)

Part II of the series can be found here.

So, how far did we go in the last part? Not that far to be honest, we've identified some ways to "free the mandays" & started implementing them - but this was just the beginning of our journey ...

Increasing the capacity is awesome, but if not governed properly, the only thing it brings by default is ... chaos.

Why so? Let me clarify.

In many jobs (and QA in particular) the everyday activities can be split into 3 categories:

In other words ...

  1. ... operational work is trivially measured, the most easily defined, always a first priority; if it doesn't happen, shit hits the fan & some important people get unpleasant - in case of QAs operational work is usually about pushing next release through - executives rarely care whether it's done manually or automatically, they just want new functionality delivered to the end users.
  2. ... aspirational work is much harder - it's about experimentation, introducing change (with a clear, beneficial purpose in mind!), "selling out" the effects of your work, assessing the outcomes, staying focused, taking ownership for proposed solutions; and all of that will make any sense ONLY if operational work is done properly (so you wonder: "maybe I'll do another round of regression tests just to be sure ...")
  3. ... waste is less obvious than you think, because ... usually no-one calls it a "waste" - people just look for non-committing activities they find a justification for, that either help in low (or near-to-zero) priority annoyances or even worse: just keep them busy but objectively speaking ... don't bring any value

Over-doing the QA

Understanding this split is EXTREMELY important in case of QA. Why so? Because in the Quality Assurance is the land of no clear border-lines. It's very easy to "over-do" things. Sensing the proper threshold when something is tested well enough is not easy for beginners or people who don't feel confident enough.

And what happens? Waste happens:

This sucks big-time & ... it's no-one else but ourselves (QA engineers) who are to be blamed!

It's convenient to be stuck in operational work, because it's always the highest priority & a baseline, ain't it? Perfect justification, but time passes by & we never have time to do any automation (or any other improvement at all). But we've worked hard, so we've managed to convince ourselves that we did our best, right?

Stop starting

Solution (to get out of this madness ...) is freaking simple:

  1. empirically set the criteria for "good enough" (even if you have to guess - as the last resort)
  2. based on these criteria, split work in a way that will leave people X time for aspirational work (& set the cut-off dates, so it doesn't last forever)
  3. sanctify the prioritization - there's no bug-less software, so stick to the highest priority stuff first, many things can be dealt with non-immediately - keeping the healthy, fluent release cycle is more important than some minor annoyances
  4. distribute the goals for aspirational work among your crew, but everyone should explicitly commit to a particular goal (this works far better than having them imposed)
  5. start short-term planning of work - both operational & aspirational (and make sure it's measurable to track progress!) - continuous progression (even if not exceptional on daily basis) will sum up & make the difference in time
  6. sync, sync, sync! - make everyone's work fully transparent so any trace of waste can be insta-spotted!

In our cases it meant:

There were stills some questions unanswered, people unhappy with some conventions, missing specifications, a chance that some low quality features may slip, ... BUT perfectionism is a disease, that has to be ruled out if you want ANY progress at all. It may be against your habits, but QA is also an engineering discipline & things can always get some improvement here - so it's better to apply it continuously, instead of fulling yourself that you can make it perfect if you get just one more week.

In our case it was a perfect moment to STOP STARTING & actually TAKE OFF finally.

To be continued ...

Sebastian Gebski

Published 20 days ago

Comments?

Leave us your opinion.

Subscribe our newsletter

Recieve news directly to your email.

No Kill Switch © 2018.