Testing = thinking, thinking = testing

13 January

If you are having problems talking to people about testing or helping others in your organisation understand the role of testing in the development lifecycle my best advice is to change the words you use. The first change is to not say “testing” but instead, say “thinking”. This means that the common mindset applied to testing (let’s do it at the end, it’s ok to just cut testing short) cannot be applied – can you imagine anyone saying “let’s do the thinking at the end, just before we go live”, how about “let’s cut the code first, then we can think about it”? It is really clear that this is not the way to build a quality solution.

No one would ever say “don’t take the time to think”, so talk about your testing in terms of thinking, about when and where and what you are thinking about. Early in the lifecycle, you are thinking about challenges to the plan, at the design phase you can think about issues with the design in delivering not only the functionality required, but also the non-functional aspects needed. You can think about how the product will integrate with other products and how each phase of development will integrate with other phases or releases. You can think about the types of issues that are likely to be embedded in the products and at each level and think about the best ways to find these issues as soon as possible.

So changing the word testing to thinking has huge ramifications! But to be able to do this well you must also be able to articulate what to think about; for example, if you are testing (thinking about) a project plan, what do you consider? Obviously, you are looking for challenges in fitting scope of requirements, work needed to deliver the requirements, work needed to work within the team and then the teamwork allocation within the required time and budget constraints. You should test/think about the plan before any work begins – obviously!

Testing/thinking about the design is also a very effective way of removing defects and quality issues. This can be as simple as walking through the design on the whiteboard and thinking (out loud) about the approaches and techniques that you will apply to build the best solution. You can see a huge amount of defects on a whiteboard, and by thinking about them before they are embedded in the code you can save a huge amount of time and effort in finding them later.

Working in an Agile team requires collective testing/thinking. This is a very powerful way of working! At the beginning of the iteration the team collectively thinks about how to deliver the iteration with all its components, artefacts and work required to deliver them, then collectively works the plan. Each story has an elaboration session where everyone thinks together about how to build the story to meet the customer’s needs. This is upfront thinking that is very effective in building quality products quickly.

Thinking is a team sport and should be done collectively and as a learning exercise. Thinking is not dictating a previous set of ideas, thinking is the ongoing growth of thoughts and ideas and approaches based on what others need, share and teach you. Funny, that’s what I think about testing too! What do you think?

 

Posted by Sharon Robson

Thank you!

Your details have been submitted and we will be in touch.

Enhance your productivity, sign up to our newsletter

See our Privacy Policy for more details. You can unsubscribe at any time.

Problem submitting!

- {{formError.message}}

Submitting, please wait

/images/newsletter.jpg

Thank you!

Your details have been submitted and we will be in touch.

CHAT