TESTERS NEVER ASSUME; TESTERS ASK QUESTIONS
When you’re curious, you find lots of interesting things to do.
-Walt Disney
By definition, software testing should encompass curiosity, and it needs to possess sufficient amounts of pessimism. As a consequence, we say that “testers are destructors, and developers are constructors.” A tester should be the one (but not the only one, of course) who stands against poor quality. He or she should also be a defender of the motto “All code is guilty until proven innocent.”
In a mobile world, a tester’s curiosity and pessimism should be even more intense. As mobile software producers tend to do more frequent releases including unique features and technologies, mobile testers should be more questioning than anyone else.
Other than that, some people define testing as an activity of asking questions. For them, testing is nothing but a way of questioning a software product. If the answers to our questions satisfy us, there is no problem. But if the expected answers are not forthcoming, we raise defects.
If we analyze testing from this perspective, we can also say that questions are really important, since they are the foundations of any testing activity. Moreover, we need to be selective in choosing our questions since there are infinitely many of them, but our and the client’s time is always limited. This fact is clearly explained in ISTQB (International Software Testing Qualifications Board) Foundation Level syllabus as one of the seven testing principles, defending the theory that “exhaustive testing is not possible.”
A tester’s curiosity also creates consequences other than questions. It also prevents testers from making assumptions. If you want to be a successful mobile tester, make the following your motto: “A tester never assumes.”
Imagine you are testing a mobile health application. Basically, the app works with an external peripheral that measures your blood sugar level (i.e., a glucometer) and pushes the results into a supported mobile device. After some releases, a new feature is added to the application, and now it can use the calculated blood glucose level to formulate how much and how often you should use a medication. In a situation like this, I wonder if a tester can come up with an idea like this: “In previous versions of our mobile app, the glucose level feature was tested by me, and it was perfectly calculating the glucose level. Even for the last couple of releases, we have observed no bugs at all. Now with the today’s release, I noticed a new feature (medicine amount calculator). In order to save time and make the product available for the waiting customers, I will assume that the legacy functionality (glucometer) is working perfectly and will only test the new calculations/algorithm coming with new feature. This will be more than enough, since we have limited time for testing.”
If you are testing a mobile daily horoscope application that is developed by your brother, and the only user will be your mother, you can make assumptions like the above. Otherwise, such kind of assumptions can be really hurtful (e.g., money loss, reputation loss, injury, or death).
A responsible tester should ask questions and never be sure about any untested matter. If you set this fact as your main driver all through your testing career, you will definitely be a better tester.