More NoTesting
More NoTesting
My recent post on No Testing met my needs in that it helped start, and sustain, some interesting face to face conversations at Agile Testing Days 2014 in Potsdam, last week.
Of course, face to face, one can explore a subject and clarify confusions rather more easily than via online channels.
I Can’t Believe It’s Not Testing
Some folks have expressed some incredulity that there might exist strategies – other than “testing” – by which software teams might attend to folks’ needs. These needs including: a quality product, confidence in that quality, and so on. Many of the questions about my post seem to have stemmed from reading it through the lens of “there must be tests, and testing, therefore he must mean…”
So, for clarity, my original post suggests that, yes, we don’t necessarily need testing. Not that testing could be done by others, such as developers. Or at other times, such as before code is written, or even as it is being written. Rather, I suggest that folks’ needs can – in some cases – be met by e.g. more capable developers, more humane relationships, an Agile Path to Quality, and letting the team make the difference.
I guess this position is a little closer no “No testing” than some have guessed.
What Happens To The Testers?
Listening at Agile Testing Days, I heard a lot of folks – the majority, testers – expressing frustration, disappointment, etc. about their situations. Specifically, how they felt they could be contributing so much more to their teams and products, if only the opportunity was there.
It strikes me that there are so many “testers” willing and able to do so much more than just “testing”, yet find themselves pigeon-holed into a narrow definition of their role. A number of the conference presentations spoke to this theme, including my own and that of Antony Marcano (links to videos soon).
So, for clarity, I’d suggest that many testers would be fine in a No Testing shop or team, as it affords them opportunities for:
- more autonomy in attending to folks’ need
- more scope for mastering software development
- participating more fully in a broader range of team activities
- addressing the core purpose of their organisations, teams and products.
– Bob
Think Different
Pingback: Five Blogs – 19 November 2014 | 5blogs
Hi Bob,
Now I am even more confused and intrigued at the same time.
“So, for clarity, my original post suggests that, yes, we don’t necessarily need testing.”
Ok…. So how does this fit in with my example of a Chef:
“For example when a Chef is working in his Kitchen and he decides to taste the food to see if it is properly seasoned, isn’t that testing?”
Is my Chef “testing” the food when he tastes it or is he doing something else? Are we just getting caught up over semantics or are you truly talking about something different from the age old “suck it and see”?
Thanks in advance,
Paul.
Hi Paul,
Yes, something different. The chef will, as you say, taste as she goes along. Not too sure the metaphor is useful, but I’ll stick with it. Imagine a pre-packed food line. Boxes of some dish coming off the end of the line. No real time to taste each item, and not much that could be done if they did taste (inspect) and found “defects”. So more emphasis in this case on getting the prep and cooking “right”, maybe with some statistical sampling or whatnot.
– Bob
Ok. I see. Yes. There is a subtle difference here between “apply, then “delay” then “inspect” versus rapid apply, inspect and adapt cycles. It’s the delay that causes problems 🙂 If you remove the delay then the timely application of feedback can be a very effective approach:
http://en.wikipedia.org/wiki/OODA_loop
So for me maintaining a tight OODA loop is one way of getting the cooking right 🙂 Splitting the “apply” and “adapt” activities from the “inspect” inevitably introduces delay and Is best avoided.
Paul.
I like that way of putting it. It’s the distance in time and space that I find interesting. Separation of testing inevitably increases distance. Also see: autonomation (jidoka).
– Bob
Indeed. Jidoka is where it all started 🙂 Toyoda Power and his weaving loom:
http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/origin_of_the_toyota_production_system.html
Automatic stopping on detection of weft-breakage minimised the delay before the loom stopped and hence the waste incurred.
It’s amazing how we always have to relearn the same lessons 🙂
Paul.
“Stopping the line” on discovery of a defect requires the ability to detect defects. Code that checks for defects is testing. And sure, it can be embedded in the code itself — e.g., assertions — but an assembly line is a little different than a software product. You don’t really want to rely on stopping the line on a customer’s PC. You need to use lower environments to make sure the software works before giving software to a customer.
Even things like compiling and running the software locally can be considered forms of testing.
Code reviews do not replace testing either — they are a different form of testing where the code is being executed in your head instead of on a computer.
The Lean approach is to build quality in rather than inspecting it in at the end. Early execution of automated unit and functional tests, especially when leveraging continuous integration / deployment, should be considered the former (building it in) rather than the latter (inspecting at end).
Incidentally. This isn’t a technical problem. As always it is a people problem. If you create an organisational structure where the inspection function is separate, then you have introduced systemic waste. Once that structure is in place however, it isn’t surprising that people resist change.
Indeed. Hence #NoTesting – and its opposers. :}
– Bob