How would you define software testing?

I saw a blog post released recently called 41 Definitions of Software Testing. When I was reading it one missing word really struck me: Risks.

I didn’t see any mention of risks in the 41 definitions. I, personally, found the definition from the Software Testing Clinic to be a better rounded definition. Having recently taken RST with @mb1, I don’t think I could write a post about this without mentioning his blog post Testing is…

I’d like to discuss our own definitions of software testing in a safe space where we might refine them as we discuss.

How do you yourself define software testing? Does it differ to any of the suggestions above?


I do like the way MB used the language, “among other things”. In my experience, a role in a team can not be defined by a simple, “this role is” statement. Not testing, not programming, not managing. Further, most job adverts which say “testing” miss the mark about what they really need in a tester.

So, I’ll begin with things that aren’t in either list:
Testing is, among other things, helping your team to identify the risks of releasing your product in its current state.
Testing is, among other things, helping your team to understand the risks of releasing your product in its current state.
Testing can be (not always is), among other things, acting as an advocate for our customers.


Identifying Risks

Looking for potential issues

Correcting Misconceptions

Reporting first hand information about a product


The art of making reality more accessible


This is one I’ve never heard before. I like it! It opens the floor for so many more questions.

The basic definition I tend to use is ‘the discovery and investigation of risk’.

I like this one as it easily fits in with early testing of ideas, entire team collaboration in discovery and investigation and primarily the general ‘activity’ nature of testing.

It also fits with my preference of looking for testers who fit sort of highly technical Sherlock Holmes type hats.

I do though occasionally work with test missions that do not lean entirely towards that definition but I have not yet found it of value to have one definition of testing that would cover all possible testing missions.

1 Like

I don’t understand some of them.

Like: ‘Testing is learning to think well.’


I don’t (personally) believe that is what testing IS. Testing might involve that but testing is not thinking well.

(I inserted the ‘personally’ bit so I don’t get attacked for being wrong :smiley: )


My personal working definition is - approximately -

Software testing is the process of evaluating the ability of software to solve the problems it is intended to solve.

There’s a lot of implied other information nested in that definition, but it gets at the reason testing activities happen.


is the activity that ensure the right behaviour and quality of any software.

I attempted to put some thoughts into words (with the help of a freelance writer) into this blog

I think everyone should develop their own pitch for:
Explaining software testing to a 5 year old, a 15 year old, a product manager, a software engineer and to a colleague. Kinda like how this video tries to explain cryptocurrency on 5 different levels.


@rosie I thought I could think well prior to becoming a tester because that’s why I left insurance and moved into testing hehe…

1 Like

Adding Constance’s blog post into the mix here -

1 Like

Also, Claire Reckless’s article is good to cover this -

At the risk of digging old thread, I’ll try to refer back to original question.

I’ve been thinking about the essence of “testing” and I think that the core is really “seeking answers for questions”.

Sometimes questions are asked explicitly, sometimes we must state them ourselves. Sometimes we must provide thorough answer supported by various data (and we must prove that our support arguments are correct as well!), sometimes quick chat is alright. Sometimes it takes us weeks to find answer, sometimes we have them in matter of minutes. Sometimes we must provide answer to questions that are meant, not merely asked. Sometimes we must explain why our answer is sufficient. Sometimes we must work with clients to help them understand consequences of their questions, effort required to answer their questions and to help them refine their questions. And sometimes we fail to find answer we were looking for.

Yes, such definition is not specific enough. Many other professionals seek answers as well - scientists immediately spring to mind - and yet, they are not testers. There are many questions that testers have no interest in answering. We work within - broadly defined - IT, which limits scope of our work in some way. And finally, there probably should be something about how our work impacts other people and products we test.

Sometimes I feel that if we want to know “real truth” about testing, all substantial definitions are deemed to fail and should be abandoned. If we “really” want to understand what testing means, we must define it through usage of the word in the community of word-users and recognize that it changes and shifts meaning, it is elusive and sometimes self-contradictory. But then - such definitions, even if they are charming for some, aren’t really helpful.

Adding another blog post that goes into this, by EvilTester -

I have tested a lot of software over the years and from my experience, I would define software testing as a method to check whether the actual software product matches expected requirements and to ensure that the software product is defect-free.

Software Testing is defined with two parts:

  1. Exploration for new knowledge
  2. Verification that things work as per already acquired knowledge of expected behaviors.

That’s it! Enjoy!

Beside all of the above, I describe software testing as:

it’s not just pushing buttons

You get a new piece of software/hardware which no-one ever saw and you get the chance to break it down, nuke down the server with performance tests, hack it and criticize someone’s work (in a proper way of course)… and you get paid for it.

I would also like to add it’s change management, in many legacy-settings there is still a lot of lack of quality assurance.