About Theresa Neate

Theresa Neate is a quality analyst, test consultant and now developer advocate, who loves lean and agility and advocates for holistic system quality and systems thinking. She is now doing developer advocacy, underpinned by over 2 decades of testing and QA experience; the last decade spent between the ThoughtWorks consultancy stable, Australia Post’s Digital Delivery Centre and has been at REA Group since February 2016. In her spare time Theresa studies a Diploma of Networking (Cloud), freelance blogs for TechTarget DevOpsAgenda, sits on their Advisory Board, and co-organises and contributes at DevOps Girls. She’s a lifelong and eternally curious sceptic and learner. http://theresaneate.com/

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.

Continue reading

Lean QA (aka QA Ops)

 

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

Bug bash – the game

(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