What is testing?

(brooding music) - [Instructor] This course is designed to support learning automation skills and tools for the purpose of testing apps. But before we get into automation itself, we need to talk first about testing. What is testing anyway? I think we would all have a fairly good intuitive idea of what testing is. It's making sure something works, right? Indeed, but as a former linguist, I think it'd be great to dive a bit into the etymology of testing. The background and history of the word testing itself to get a sense of the roots of the concept. The English word test originally came from a Latin word testum which referred to a kind of container or pot made of earth. These were pots that were designed to hold very hot metal and people want it to heat metal up for a number of reasons but one was to determine whether there were any impurities in the metal. So by association, the pot itself became tied up with the act of checking the quality of the metal. And so now we can say that to put something to the test, in other words to heat it up in the earth and pot called a testum is to determine the quality of whatever that thing is. You might also have heard someone talk about a crucible or maybe heard the expression going through the crucible. This word crucible is another word that has a very similar history. A crucible is another kind of container for heated metal. To take our analogy a bit deeper, we can say that testing is therefore the process of applying some kind of energy in some kind of container to determine the quality of something we want to test, something whose quality we care about. Now, what we care about is software. Our job as testers is to get some kind of indication of the quality of the software that sits in front of us. Maybe we developed it ourselves or maybe someone else did. How do we even start thinking about the process of testing software? There are a huge number of methods and tools that we can use in the process. But one simple way of thinking about it is realizing that our responsibility is to design and bring about the specific conditions like heating up hot that will reveal the quality of the software. One common way of bringing about these conditions is to use the software in its normal modes as a normal user. The software is meant to run in certain conditions and we can simply run it in those conditions as any normal user of the software would to determine whether it works the way it's supposed to in those conditions. We could also try to imagine conditions for the software that its developers might not have thought about. These are often called edge cases. The trouble with software is that there can be a near infinite number of conditions, a piece of software can run in and a near infinite number of situations or states it can get itself into based on user input or other factors. When developers write software, they usually assume a fairly simple and minimal set of conditions. It is the job of a tester to design crucibles or test scenarios that show how the software behaves in all kinds of situations. Obviously if there are an infinite number of situations that software can get running, it doesn't make sense to try and test every possible case. So testing becomes a real mix of engineering and creative out of the box thinking, just to figure out what test and that's only the beginning. Testers don't have an infinite amount of time to evaluate each potential release of software. Sometimes software gets released multiple times a day. Choices have to be made about what's most important to test and which additional tools and strategies we need to adopt to make sure that we can test as much as possible. So imagine if you were an ancient Roman tester and people brought their metal to you to heat up and determine its quality. Once the metal starts piling up faster than you can gather logs and heat up your pots, you've got a problem and you need to figure out not just new and clever methods for determining the quality of the metal but also the mechanics of how to scale your metal testing practice. Maybe you buy more pots or invest in technology that starts fires faster, maybe you get super advanced and figure out that by mixing certain reagents in with the metal, you can get an instant read on one aspect of the quality of that metal. Anyway, I don't want to push this analogy too far but this is very much the situation encountered by software testers. Almost all testing of software nowadays is done in a context that requires great breadth and depth, speed and scale. It's an impossible set of requirements unless testers adopt some of the same modes of thinking that have propelled software development itself to huge levels of scale. And yes by that I mean automation. I won't talk more about what automation is now because we have a whole separate unit on it in a little bit. The main takeaway for now is this, testing is a practice which uses creativity and technology to build and execute special crucibles for software with the goal of determining the quality of the software to as accurate a degree as possible. We often focus specifically on the technology side of the equation but never forget that there is a whole lot about the practice of testing which will require your creativity.