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 idea.
To me, it means “do better testing”. This kind of testing that possibly some people wouldn’t know testing.
The #NoTesting hashtag is having a bit of a resurgence , 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 logical that they interpret it that way since the hashtag is completely saying “No Testing”. If people “interpret” the #NoTesting hashtag in this way without putting any thinking into it, then those people are damned to failure.
So after watching the tweets, and start thinking myself that people were promoting not doing any testing whatsoever, I decided to search to get to the bottom of the meaning of the hashtag.
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 that I have asked the question “what is software testing?” hundreds of times in work shops, meetups, work places and offices, etc to people from all over the world who work across so many different disciplines in the software industry. This is far the most “common” answer to the question I posture to them. Sometimes the words vary; “it’s asserting the requirements”, or “it’s checking the software works as expected” But it is always the same meaning behind the words, that is we have an “expectation” from some “artefacts” and we assert those “expectations” against the software once it’s been develop.
As an estimate from all these “conversations” I’ve had, I did say that over 90% of the people I’ve asked that question to, define testing in this way.
So, if you think about that being what people think software testing is, then the #NoTesting hashtag might be useful for us here. You can see, testing is much more than “argue” assumption. There are many more testing activities that involve searching 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.
Don’t just do the scripted:
Don’t just do the scripted, assertion side of testing, (Perhaps the “hashtag” could actually be created to #NotTesting for this to make people aware they are missing a lot of the other testing exercise 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 condition – #NoTesting” will hopefully “trigger” people to think about how they can better their testing or how they might not be testing completely.
But the “hashtag” can even be cooperative for people who do understand the “investigative” side of testing already too!
Lets go deeper for a second, and imagine I was “standing” over your shoulder at work time and I literally said to you: “Don’t test the software product!! #NoTesting!!“. What would you do? You know there are issues that need to be opened and investigated, but how might you test for these issues that you are aware need to be “investigated” if you’re not allowed to focus clearly on the product?
Take a second to think 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 how else, or what else you can test/investigate to uncover information about risks, quality and value).
If one of you set that “challenge” to me through that “statement” of “Don’t test the software product” and asked me the same “experience” to get me to think about that how I might test for the liability without checking the software product, my “aptitude” would be to find a way to “investigate” those risks sooner, before the software product is developed. possibly through pairing as the code is being written? Or even before that “pairing” while the code is being developed? Or before that still – when the idea for the software solution is being thought about and discussed, and while the artifacts are being created, and the UX and UI wire frames are being drawn?
I can search and raise the risks at any of these points in time to benefit and challenge the ideas, artefacts, “UX/UI” design wire frames, code design and “written code”, so that the risks are at the “forefront” of everyone is thinking within those activities. This might actually allow us to prevent many issues from being coded into the software product, if we catch the bugs in out thinking and “understandings/misunderstandings” before and during the develop of the software product.
I can use my testing skills all throughout the “SDLC” to enable others to be aware of the issues and to help them allay those compromise before I alike have a software code in front of me to test.
Now, I am still testing at least in my experience I am, based on the whole design of testing, including “investigative testing”.
Read this blog: https://softisans.com/notesting-heres-what-it-means-to-me/
Top comments (0)