How often have you heard:

“Our quality is poor, we need more testing (or testers).”

When you hear this, know that this indicates not only a spurious correlation but also a fundamental misunderstanding of what testing is or does.

Come on this journey with me where I explore the above claim, walking you through 1. Testing, 2. Quality, and 3. Building in Quality.

1. Testing

Testing is feedback

Testing does not ASSURE or bring about quality, it only reflects quality. It shines a light on the current state of quality.

2018: For reference, here’s what I concluded in 2018, including some of my commitments for the new year of 2019.

This story begins at the beginning of 2019, takes a few detours back and forth and stops at some pitstops along the way, and ends with my trip overseas at the end of the year.

2019 started on a low

I started the year of 2019 in despair. My role of Senior Developer Advocate was not working out. I was not sleeping well. I was dreading going to work. …

(Continued from Part 1.)

Things went sour, very quickly.

This part covers July 2018 to Feb 2019.

(A lot of detail not shared, out of respect to those who really tried to help)

As the months progressed, nearing 4 and 5 months now, I continued to struggle with the lack of clear direction, multiple priorities, conflicting messages and extreme busyness of my team. There was also an obvious power struggle between some leaders in our space was noticeable and also destabilising.

I found the prevalence of indecision and disorganisation no help in resolving my own unsettled state.

We are all so afraid of uncertainty that we want a guarantee before we even try.

— Mel Robbins

I tried a thing. And it somewhat backfired on me. But as I actually TRIED, I am still the winner because I learned something.

Part 1 covers the background to the risk, and the risk starting June 2018.

I’ve always been a fairly “gutsy” risk-taking individual, at 12 I won the national judo championship, at 14 I was racing & showjumping horses, at 16 I was playing ice hockey, in my early 20s I moved country without a concrete plan, then with no visa got kicked out of that country, then immigrated again and started all over again in my 30s. …

I saw a few reflections by others on their 2018 year and I loved reading what they’d learned and reflected on. Not all good, not all bad, but so insightful to me.

This inspired me to write my own, more as a record for myself but hopefully insightful to others too.

Background, 2017:

• For the first half of 2017 I felt quite defeated about my future in my personal and career lives. My long term relationship had just ended, I gained weight and became quite pudgy and hated the sight of myself in mirrors, and I felt trapped in a career rut.
• Imagine my delight when I was contacted by a Spotify recruiter and after several Skype/Google Hangouts interviews with her in London and the team in New York, in May 2017 was flown out to New York for final interviews and offered the job! …

… 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., …

Developers have — with the advent of DevOps — been working more and more in Operations and Infrastructure. Testers however, haven’t.

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. …

(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. …