Category: qa

Quality is NOT perfection

buggylina1 Comment

I’m moving my blog to https://qualitybits.tech – check it out for more content.

There are some words in the Quality Analysis field that I grew to dislike: let me start with perfect. Only learning more and growing with time in my career, I realised that we may need to be a bit more careful about how we talk about our field and what are the exact expectations. If we do not, we may be stagnating in siloed tribes of QA departments full of grudge and pain of not getting the perfect software. 

Perfect software does not exist – bugs do not mean that quality is bad. What matters is how you deal with bugs, mistakes, and proceed to work. 

Even in 2019, at some quality focused (and not only) conferences, I occasionally hear QAs speak how they got into the field because they are perfectionists & they LOVE perfect software. Then I silently cringe, and, actually, feel a bit sad for that – I’ve been there. I was hurt when my reported bugs were not being fixed, that nobody seemed to get me and appreciate my work. However, this often goes hand in hand on how organisation is built, and, what working ways there are implemented.

When all roles collaborate, there is more empathy, more responsibility as well for any kind of an issue that gets noticed. Bugs are not a sign of bad quality, bugs are… inevitable.  When we accept that there is no such thing as perfect software, but only software that has no known bugs, for example, when a bug does pop up – we can treat it as a learning opportunity. Work processes like zero-bug policy can help us with that.

In my team – the backlog has no bugs: not because there are none, but because right now we are not aware of any. Zero bug policy for us does not mean that we have zero bugs at all times, it means that once we do discover the bug – it gains the highest priority and gets tackled as soon as possible. Zero bugs are not tackled. We grab the opportunity to learn immediately. An important part here is that we are saying tackled, not necessarily fixed – some may end up being “fixed” as expected, but the decision is always made (now I just remembered that at the start of my career in my bug reports I’d be asked to add what was the expected result, and, that in my current team we do not have that in the reports – we discuss it using other ceremonies & collaboration instead of me telling what should work how).

And, this leads me to one of my main learnings I had:

Some bugs are really not that important: Value of the product may outweigh the bug-free product. 

We have to make trade-offs. Sometimes a pixel shift of the UI means nothing even if for us it looks ugly (how many times I fought for bugs I thought were disastrous!). However, it all depends on the product – maybe for a UI-focused product it’s a deal-breaker, but for a different product – it’s nothing.

What changed my career was getting exposure to analytics, monitoring, metrics, logs. Understanding what actually is important to the user is eye-opening. We may think that as QAs we represent the customers, but we may be surprised! Also, having the analytics we can quantify the value of bugs (my article on Sticky Minds about monitoring  goes to a bigger depth).

We all do mistakes. High-quality software means that we can recover faster from mistakes, and, are able to handle failure gracefully. 

Netflix has shown a great example of failing on purpose with its idea of a Simian Army. And, to quote Cory Bennett & Ariel Tseitlin who said about that:

“We have found that the best defense against major unexpected failures is to fail often.”

Forget perfection – strive for continuous improvement with learning from mistakes, and consistently working on good ways of working with healthy practices adding up on a high-quality product.

P. S. Two books that popped into my head while doing this write-up and I could definitely recommend reading are Perfect Software: And Other Illusions about Testing by Gerald Weinberg, and Accelerate by Gene Kim, Jez Humble, and Nicole Forsgren. The first one touches on the perfection aspect quite a bit on a high-level, while the second one talks more about high-performing teams and how to measure success better. 

Replacing QA Column in the Work Board

buggylina4 Comments

It was quite a journey. I started as a completely manual tester who could occasionally do exploratory testing. Then, I made a drastic change of transforming my work ethics, learning automation, using monitoring tools and moving my role towards the more generic QA role where testing in production is a part of the quality assessment. And now, with yet again a bigger change in my quality professional’s journey… I promote replacing QA column after development with something like “Desk Check”. 

I recently joined a new project engagement where we can build the product from scratch. This means that we also are creating our work culture from the bottom up. It looks like our favorite phrase nowadays is “adaptable to change”. With all this, we are trying to identify the first version of our work board.

When one of our team members automatically added a column called “QA” after development, I suggested to rename it to “Desk Check”. You may wonder why would I do that when I am still a part of the team with a role of QA?

Quality should be in-built, not tested in

Thinking of quality should start as early as the user story or feature is being created. How will we gain confidence that development was successful? What metrics will we use to measure implementation? Can we recover from the worst case scenarios easily? Questioning is a huge part of quality promoting. This should be done throughout the development process before even the desk check.

Desk check is not assigned to any role specifically

If development was successful can be evaluated not only by testers but also product owners or even other developers. Desk check is more of a concept where developers show their work (and their implemented checks), get asked questions, and sometimes pair test. It can be very useful to get a product owner to give feedback on the feature before it is marked as done.

Quality of the product is a shared responsibility

When I suggested using “Desk Check” instead of “QA”, one of the developers smiled and said “Oh, so you’re not a control freak gatekeeper. We all have to be responsible.”. This is exactly what I aim to promote. However, what matters here a lot is also the fact that your team is engaged in this.

Having the attitude that all the team is responsible for quality is quite a task and I won’t say you can do it on your own and change people overnight. You can’t. They have to be willing to work in these ways and it can be very challenging. Being responsible for quality as a developer has certain benefits: you gain confidence about your work’s reliability, learn to question your own work, get to collaborate and understand better other team members like product team, and, actually help with your developer skills to improve the automated checks. The drawback of this is: you need to put effort. Way more effort than if QA is responsible for quality.

In summary, it is a challenging change to actually shift left and not only talk about it. You may find yourself wondering what QA role does if the quality is inbuilt and developers write their own checks… And that’s normal. I did, too. What is important to understand is that teams still need Quality Evangelists to question, promote quality, investigate CI/CD clutter, analyze requirements, tackle misunderstandings and share their testing knowledge with others.