The #NoTesting hashtag is having a bit of a resurgence recently, so I thought I would jump on the bandwagon and write down my opinions on the whole thing.
The term is very confusing to say the least.
Many people take it to mean “don’t do any testing”, which is understandable that they interpret it that way since the hashtag is literally saying “No Testing”. If people interpret the #NoTesting hashtag in this way without putting any thinking into it, then those people are doomed to failure. I canonly hope those people read this post!
So after seeing the tweets, and initially thinking myself that people were promoting not doing any testing whatsoever, I decided to investigate to get to the bottom of the meaning of the hashtag.
I initially read one of Bob Marshall’s blogs about it (Bob is the originator of the hashtag). And I had some Twitter chats with him and a few others promoting the hashtag. Gus Evangelisti was really helpful in teaching me a deeper meaning behind the hashtag in a private conversation on DM that we had.
#NoTesting, as I understand it, is an attempt to kick people’s brains into thinking about a better way of doing things. Its not supposed to be a command to not do any testing without any thinking.
To me, it means “do better testing”. The kind of testing that perhaps some people wouldn’t call testing.
Let me explain…
The majority of people working in software perceive testing as: “ensuring that the software meets expectations set by requirements”.
This statement is based on my experience – I have asked the question “what is software testing?” hundreds of times in workshops, meetups, work places,etc to people from all over the world who work across so many different disciplines in the software industry. This is by far the most common answer to the question I pose to them. Sometimes the words vary; “it’s asserting the requirements”, or “it’s checking the software works as expected”… But it’s always the same meaning behind the words – that we have an expectation from some artefacts and we assert those expectations against the software once it’s been created.
As an estimate from all these conversations I’ve had, I’d say that over 90% of the people I’ve asked that question to, define testing in this way…
(I should mention here that the originator of the hashtag (Bob Marshall) regularly tweets saying those exact words, however, he hasn’t yet, to the best of my knowledge, to define what he means by “Testing” too).
So, if you think about that being what people thinksoftware testing is, then the #NoTesting hashtag might be useful for us here. You see, testing is much more than asserting expectations. Asserting expectations is only a small part of what software testing actually is. There are many more testing activities that involve investigating unknowns and risks to uncover information (i.e. all the stuff that aren’t in the artefacts and we don’t have expectations for). Think about all the variables, assumptions, ambiguities, unexpected things, etc.
I think there is away that the #NoTesting hashtag can be used to actually teach about all these other vitally important testing activities.
Don’t just do the scripted, assertion side of testing… (Perhaps the hashtag could actually be modified to #NotTesting for this to make people aware they are missing a lot of the other testing activities that they should be doing).
But with the real meaning of #NoTesting as it’s supposed to be used (to trigger thinking on how we can do things better) then the hashtag is supposed to generate thinking about how we can change things. E.g. “Only testing the requirements – #NoTesting” will hopefully trigger people to think about how they can improve their testing or how they might not be testing effectively.
But the hashtag can even be helpful for people who do understand the investigative side of testing already too!
Lets dive deeper for a second, and imagine I was standing over your shoulder at work and I literally said to you: “Don’t test the software product!! #NoTesting!!“. What would you do? You know there are risks that need to be uncovered and investigated, but how might you test for these risks that you are aware need to be investigated if you’re not allowed to focus specifically on the product?
Take a second tothink about this before reading on… Think genuinely about how you would respond to my challenge.
(Please don’t respond in an argumentative way… The point is to get you to think about howelse, or what else you can test/investigate to uncover information about risks, quality and value).
If one of you had set that challenge to me through that statement of “Don’t test the software product” and asked me the same questions to get me to think about how I might test for the risks without testing the software product, my instinct would be to find a way to investigate those risks sooner, before the software product is developed. Perhaps through pairing as the code is being written? Or even before that – pairing while the code is being designed? Or before that still – when the idea for the software solution is being thought about and discussed, and while the artefacts are being created, and the UX and UI wireframes are being drawn?
I can discover and raise the risks at any of these points in time to assist and challenge the ideas, artefacts, UX/UI design wireframes, code design and written code, so that the risks are at the forefront of everyone’s thinking within those activities. This might actually allow us to prevent many bugs from being coded into the software product, if we catch the bugs in out thinking and understandings/misunderstandings before and during the creation of the software product.
I can use my testing skills all throughout the SDLC to enable others to be aware of the risks and to help them mitigate those risks before I even have a software product in front of me to test.
Now, I’m still testing! At least in my opinion I am, based on the whole picture of testing,including investigative testing.
I’m sure the vast amount of people that still think that testing is simply checking expectations against a software product might not call this testing though, or it might be that they were just unaware of the investigative side of testing (we need to get better as a craft in teaching about this very important side of testing!!). Either way, I feel the #NoTesting tag can be helpful in this situation – AS LONG AS the detailed explanation comes alongside the use of the hashtag.
What’s your thoughts? Have you used the hashtag? What was the context? Why did you use it? Was it helpful?
Share your stories in the comments below!