What’s the difference between testing and quality management? 

Over the past few years, I’ve been thinking about quality and what it means. I’ve done a few talks on it and engaged in several conversations with different people. Recently a LinkedIn conversation sparked my thoughts in a different direction – about the relationship between testing and quality. This is the first segment (of two) on my thoughts about testing. I will follow those up with at least one post on quality.

WHAT IS TESTING?

As I was pulling weeds in my garden (a very unfulfilling thing to do as I know they will be back again tomorrow if I don’t pull them up by the roots), I started thinking about similarities to the conversation between testing and quality management. One point that was made was:

“Testing helps people become aware of bugs (in ideas, requirements, specifications, designs, units, components, and entire systems. Testing doesn’t prevent bugs, so we had better focus on finding bugs.

Testing reveals where and how the system or relationships may be broken.”  ~Michael Bolton

I know I took this out of context, but if I look at these statements and think about my garden, it means that I can point out the weeds, (the bugs), but I can’t actually pull them. I could ask questions about the design of the garden, but I couldn’t contribute. That I couldn’t work along side the gardener and help prevent the weeds from growing in the first place. All I could do would be to ask questions and pull weeds, or maybe ‘only’ show the weeds to the gardener for them to decide what to do.

To me, testing is different. Perhaps I could ask the gardener questions about how we could prevent the weeds in the first place and suggest different ways – one may be organic, another a weed killer. I discuss risks with the gardener, and we could choose one method or perhaps none. Maybe we discuss that the best way is to bring is new soil without existing weed seeds. Is that helping prevent defects if one of the methods is chosen? Did I, as a tester help?

Gardens grow and change with time like our products, and if we don’t constantly work on our ‘technical debt’ by keeping the weeds down and pulling them up by the roots, then it gets overgrown and useless. Two years ago, we left our garden alone for 2 weeks at a critical time while I attended a conference. When we came back, the garden was overrun with weeds. The plants did not flourish very well that year even after we spent time pulling weeds and cleaning up our ‘technical debt’.

But enough with the analogy. Products are not a garden.

WHAT CAN TESTERS DO?

There is a definite delineation of thought about what testers do. One school of thought is that testers ‘test’ software. That is their job and they should be proud to be excellent at it and work diligently to be the best tester of software they can be.

I do not belong to that school of thought. My definition of testing is much broader. I have been working in agile teams for 20 years now, and the most successful agile teams are ones where testing activities are shared by the team. I think testers definitely add value to the team, but instead of taking on all the testing responsibility, they help to show how testing can contribute to the quality of the product. Testing is one piece of the quality puzzle, but more on that later.

In the same Linked In conversation, Dan Ashby said this about testers:

They are involved in the 3 amigo conversations about product directions, they pair with developers while they build the product, pitching in with ideas, they work with designers, they also take on coaching and mentoring activities to improve the team’s mindset re quality and advocate for quality and testing. It’s no longer a case of testers purely focusing on testing tasks.

Dan suggests that indeed testers may actually help build the product – even if they don’t do the coding. In my experience that is true.

GROWTH MINDSET

One phrase I like to use when thinking about the mindset for testers      

“Instead of thinking I’m here to find bugs, or ensure the requirements are met or to break the software (or the illusions),

 Think, what can I do to help deliver the product successfully?”

I think having a growth mindset can enable testers to help in different areas. Here are some examples of different times when testers can add value.

• Helping to slice user stories by contributing to making the stories testable.
• In the 3-amigos meetings asking for examples, highlighting hidden assumptions, or asking about the important quality attributes and how are they going to deal with those constraints.
• Reviewing a simulation or proof of concept.
• Contributing in a design meeting trying to figure out the simplest way to develop the story by asking testing questions, such as, “How are we going to test that?”
• Collaborating with the programmer or test automator to figure out what the test methods might look like and what data we will need, or at what level should the automated tests be captured.
• Analyzing and thinking about what tests to consider.

All those activities are done before a single line of code is written. Are those not testing activities that help deliver a better product? I think so.

SUMMARY

We are all individuals and have different opinions about the definition of testing, although I think everyone agrees that it is about identifying and mitigating risks. I encourage you to think about what it means to you. Is it is limited to testing the software, or extended to testing ideas, assumptions, the process, as well as the whole product?

In the next segment about testing, I continue with different types of testing, and some of the contexts which affects how we test.