“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.
Developers have – with the advent of DevOps – been working more and more in Operations and Infrastructure. Testers however, have not.
Thus far, the testing personnel have been mostly or wholly assigned to application testing work. As SOFTWARE testers, we have only worked on software – and then mostly only on application software.
I pose the questions: What about infrastructure as code? Should that not be explicitly tested?
And: if Testers are meant to be testing the system, why then have they not explicitly been testing the whole system, infrastructure included?
I am going to make a case here for including QA in Operations and Infrastructure, by clarifying how I see the QA fitting in the DevOps world. Continue reading
(originally written for and published in Testing Trapeze)
Wikipedia defines a bug bash as: “… a procedure where all the developers, testers, program managers, usability researchers, designers, documentation folks, and even sometimes marketing people, put aside their regular day-to-day duties and ‘pound on the product’—that is, each exercises the product in every way they can think of.”
I first learned to do a bug bash after hearing the term about 8 years ago. I taught myself a crash course from a Google search, and then devised my own flavour of bug bash (which continues to evolve every time I run one).
The term “bug bash” seemingly first appears in Ron Patton’s book “Software Testing”1 (first published in 2001). As with many others, it does not surprise me that the term has been around for much longer than I have known it.
In this article I will describe why and how I run a bug bash these days – and hope you too find value in it, as I have since my Google searches years ago. Continue reading