Why testing is so important
Special thanks to Damian Synadinos who helped me form the ideas for this post.
Why is testing so important to a software project, or any project for that matter? If you have trouble answering this question then don't fret, you're not alone. Testing has been a part of software development for a long time now so most people assume that testing is important but few think about why, it's just there, it's just the way things are done. This might come as a shock but part of the reason this is difficult to answer is because it isn't important, well not inherently anyway. Testing may not be important if it's not conducted by a skilled tester or if you are able to live with the risk of not testing. If, on the other hand, you are not comfortable with that risk, testing becomes very important.
What is Testing?
So before we ask why testing is important we need to understand what testing is. Testing is very similar to experimental science. It's a process of experimentation and observation of some object or space in an attempt to disprove hypotheses about it. In other words, in software testing we perform tests to compare the software with oracles (documents that provide a source of truth) such as requirements, acceptance criteria, or our own expectations in an attempt to identify inconsistencies; and in the process we discover information about the software.
Knowing is greater than not knowing
The key word here is information. The value in testing lies in information, knowing is better than not knowing. In the real world where the people involved in software projects and the products they produce are not perfect the information provided by testing becomes vital to the success of the project. Regardless if the results of the testing are all positive, or not so much, you can be far more confident in the decisions you make based on this information than if you were going in blind. If your tester came to you with a report identifying potential issues with the software, then you can react appropriately. You can organise the resources required to fix them, or you can make the decision to go into production knowing and accepting the risk that users may experience these issues, but this decision was only made possible because of the information provided by the tester, without which you had no conscious choice in how the project should move forward.
Consider the risk
Another way of approaching this question is by considering the risk involved in a project. Think about a software product like a website and consider the risk to the project and your business if the product were to not function as intended. Risks like that of an issue causing some mild customer frustration are more likely but have a relatively low severity whereas damage to brand reputation or loss of data and/or sales have a significantly higher severity but are generally much less common. Testing cannot guarantee these issues do not exist but it can reduce the chance that any issue exists and hence reduce the project risk. The question is can you afford not to test? Can you live with the risk that exists without testing? For extremely simple projects, where the potential risk is already very low then perhaps you can live with it. But for most projects where a serious failure would have a significant impact on the business, I'm guessing you will want to do what you can to minimise that risk.
Who should be testing?
Perhaps as important as doing testing, you need to also consider who is doing the testing. It is broadly true that anyone can test software, and quite often many of the stakeholders involved in a project will do testing to some extent. The developers will test their code looking for errors, the project manager will evaluate the product to make sure it matches their intent and understanding, and the client will likely also want to evaluate the product before release. A skilled tester will also check these things and provide another set of eyes but more than that a skilled tester is practised at experimentation and observation. I'm sure most of us will remember performing experiments in science class at school but this isn't really comparable to the work that people in white coats who work in a lab do. There are few who think that the later is anything less than incredibly complex, methodical, and can only be carried out by people with a specific skill set. In the same way most, if not all, are capable of testing software in some sense. Anyone can click around a website, try a few things and if it's a new product you will probably find some bugs, but this only just begins to scratch the surface of software testing.
Skilled software testers devote a lot of time developing the skills and knowledge that will help them become better at this. However, much of the knowledge required to be a skilled tester is the kind of knowledge that is difficult to transfer to another person by means of writing it down or verbalizing it. Much like the ability to speak a language or perform improvisation, much of testing cannot be learned from reading about testing and this tacit knowledge has to be developed through practice. Skilled testers will be able to think of questions and test ideas that no one else on the team has, and in addition will often observe behaviours others will miss.
My overall sentiments are very well summed by in the following analogy taken from Lessons Learned in Software Testing: A Context-Driven Approach - A project is like a road trip. Some projects are simple and routine, like driving to the store in broad daylight. But most projects worth doing are more like driving off road, in mountains, at night. Those projects need headlights. The tester illuminates the road ahead so that the developers and managers can see where they are, what they're about to run over, and how close they are to the cliff. Testing is done to find information. Critical decisions about the project or the product are made on the basis of that information (Kane, Bach, & Pettichord 2002, p. 1).
Kane, Cem, Bach, James, & Pettichord, Brett 2002, Lessons Learned in Software Testing: A Context-Driven Approach, Wiley, New York