Peeping Toms

According to Wikipedia, the fountain of all knowledge, a scientist engages in a systematic activity to acquire knowledge. When it comes to software testing, I feel this description of a scientist applies well to the day to day activities of a tester. For example, a tester, with varying degrees of structure, will systematically test the software, through these actions, the tester will learn how the software behaves, so acquiring knowledge. From this new knowledge, the tester can assess if there are any issues which he raise to the project team.

At school, during my science lessons, the teacher will ask the class to come up with an hypothesis, we would then have to test this hypothesis to confirm or reject it. Again, this isn't very different at all to testing. For example, when testing a login screen, I might come up with an hypothesis that the login screen will accept my username without a password. I would then test this out to check if my hypothesis is right (hopefully I'll be wrong!). If time permits, I could create new hypothesis and continue to learn about the software I'm testing. It might do these actions in parallel, I come up with hypothesis and test them out at the same time (a more exploratory style of testing) or I might write the hypothesis down, as in test scripts, and execute these tests at a later date. Either way, it's testing using a hypothesis to drive the testing.

Another aspect of using scientists as an analogy to testing, is the fact the they need to keep many variables constant. In testing we often do this, sometimes without being aware of it. When first testing the login page, let's say it's a web app, we would keep the browser and version constant to test the main features. If it works on one browser, we may choose to test on other browsers, or possibly try out some performance testing by adding the number of users already logged or trying to log into the web application.

James Bach came up with a short definition for testing: "testing is questioning software". By questioning and gathering the answers from using the software, we learn more about the software and where the bugs may be hiding. Here’s a definition of my own (taken from Mr Koestler), “Testers are the peeping toms at the keyhole of software”, ok, it’s not as good, but hopefully the point comes across J