Software testing is not … part 2.
Software testing is not … part 3.
Software testing is not … finding bugs
This is one of the first things that I thought in software testing – that our job is to find bugs or defects. It’s true, but it took me some time, couple of books and a lot of hours reading different resources in order to figure out it’s not just that. To claim the above is like claiming that software development is just about writing code and it’s not.
At first, it is good to mention that we don’t automagically find bugs just like that. We have to learn the system and build our oracles based on our knowledge of it, previous experience, knowledge of the domain, technology knowledge and so on. So, no bugs included here.
How about documenting our process – writing models of the system, mind mapping it, write check lists or design test cases (in case that works in our context, of course). Is that finding bugs? No.
In other words, if we say that testing is about finding defects, we probably never had a more profound thought on what testing is and what is its role in the big picture.
Let’s talk about defects. What is a defect? To us, as testers, normally it’s an error in the code, may be a typo, may be a logical misunderstanding, but might be also bad interpretation of requirements, or due to missing requirements, it might be “taking the easy short way” due to laziness, might be bad design or unexpected dependency. It might be a lot of things. What it is for our management? It is a way to lose money, a way to lose credibility, a way to lose clients, or combination of all of them, or even go out of business. What does a defect means to our clients? It means they can’t use the service or product they paid for, or have a risk to lose their clients and their money due to a mistake that we made, sometimes, defect on our side might cost someone’s life. So, here you see three different perspectives of what a defect is and I bet you can think of more.
So, what’s the point here? Testing is not about finding bugs, it’s about examining the risks that defects in our software might introduce. Who is impacted by these risks and how serious will be the impact. I believe this is a better way in determining what our job is, not just in our day-to-day tasks, but in the context of our business, how our job is valuable for what we are producing as end product. In other words, it helps us think of our work holistically.
… meant to add value
This reminds me a silly statement somewhere over the internet, that you see, testing is not necessary or important, because it doesn’t add value to the product. Well, that’s almost as stupid as saying that brakes are not necessary in a car, because they don’t add horse power.
From my point of view, testing was never meant to add value to the product, in fact one of the main goals of testing is to help the product and project from devaluation or in other words, loosing quality and our clients’ credibility due to defects that we might have missed.
So, to frame this in another different way – testing won’t help you to make a valuable product – that is something your ideas and strategy should take care of, but testing will help you not to fail miserably due to low quality and bugs that might have serious impact for your or your clients.
That’s for this week. Thanks for reading and if you found it interesting, please share in social medias and/or share your opinion in comments! 🙂
Mr.Slavchev
Senior software engineer in testing. The views I express here are mine, they don't represent any position held by any of my employers. Experience in mobile, automation, usability and exploratory testing. Rebel-driven tester, interested in the scientific part of testing and the thinking involved. Testing troll for life. Retired gamer and a beer lover. Martial arts practitioner.
Follow Me:
It is a good way to explain to those person who say you are only finding defects
Maybe you mean brakes in a car, not breaks
True, that’s what I meant. Good catch! 😉