A simple one I just made up out of a combination of others that I like:
Evaluating a product, through experimentation, exploration, and experiencing it, on behalf of people who matter, to find ways in which it fails or might fail.
i usually say that i test websites or software to evaluate if they are fully functional and accessible to everyone. and write reports about what needs changing or fixing.
I’m looking for problems in complex systems and helping the team to cope with them.
If I do not find (many) problems it is also fine. Then I make visible to other how good the work of the developers was.
For that I explore the product, often supported by tools.
With other words: I’m the very first user while my usage of the product is intended to reveal its actual state.
These two recent ones comes to mind
—-
It’s about understanding the unique value your product brings to its users and stakeholders and then ensuring every update, feature, or change enhances that value.
By @kato
—-
The purpose of testing is to] facilitate the continuous discovery of information about the product to help the team make informed decisions about risk, quality, and success
By @heather_reid
—-
Edit: I have the links, if needed for proper quoting
There’s been some pretty awful software that met all the requirements and where all the functionality worked correctly without issues. Users might have different expectations than our requirements.
Maybe it would be enough to amend the quote to:
It’s the process of evaluating software to ensure it meets the explicit and implicit, functional and non-functional (or extra-functional, if you will) requirements.
When I explain it to relatives - as the majority of people eat food, I explain it like this. Imagine you’re creating a new recipe for a party. Before serving it to your friends/family, you’d want to taste it yourself, right? So software testing is a bit like that, but instead of food, it’s checking computer programs or your phone apps to make sure they work correctly. Testers (moi) are like taste testers; they try out different parts of the software to make sure it’s easy to use, doesn’t have any mistakes, and does what it’s supposed to do. It’s like making sure your dish is delicious and perfect before serving it to your guests. But we can also go much deeper than that if required or if we have the right experience. The quality of the ingredients, can it be reheated, is that pepper organic because that’s what a specific person in your party wants. Can you make a base sauce then add more ingredients to cater for specific people. If you make it to salty do you have a mechanism to take some of the salt out etc. etc. I could go on for ages on this lol.
I’d like to share an incident from my experience with software testing at Testrig Technologies. During an interview, I was asked to define software testing.
My response was that software testing is the process of evaluating software to identify bugs, errors, or defects, ensuring it functions correctly and meets specified requirements.
Short elevator pitch: Software testing is the process and collaboration of checking the quality, design, functionality, impact and performance of a software product before, during and after launch.
I found that a biggggg part of what I used to do as a “tester” was to examine assumptions that were the foundation of user stories or design. The need for this was less on more sophisticated / experienced teams, but, just as one example, accessibility needs often were unanticipated.
So my definition of “software testing” would include the testing of ideas whose end result is the software.
Of course, proceed with caution on this. You don’t want to be seen as an inveterate second-guesser. However, if you can deliver feedback in a compassionate, gentle way, your suggestions will often be welcome and appreciated.
Software testing it’s about validating the user/customer needs, related to a product or service, and considering if they have met the expectations during software lifecycle with a minimum of defects possible.
Software testing is what you do when you want to find out how the software works, so you can inform the people who (should) care about that software about any possible loss of value to them.
The software’s functionality can be compared with how those people think it should work, which can be explicitly stated (for instance it can be documented, or it can be a new version of existing software, …), or which can be implied (for instance it should not do stuff that it isn’t supposed to, or it should not take so long to do the stuff that people get impatient, …).
Learning about a product wearing thinking hats and asking context based questions that helps me to discover bugs, highlight risks, perform experiments and make informed decisions about the product that iam testing.