Archive for the ‘Testing’ Category

Ayesha Saeed, Ultimus Pakistan

Programming is a game of vision and testing – the assessment of sight; this is what I used to think about testing. This pre-conceived notion had deep roots in my mind. Now, after spending few months into the task, I can definitely say that being a tester is not an effortless task.
Initially when I joined my current job, I was ignorant of my assigned product and the testing strategies. However, in software testing, ignorance can become your strength. Software testers who are not familiar with the fact that how the system has been put together can be in a better position to find certain bugs. On the opposite, ignorant testers are more likely to report bugs that are not meant to be fixed. It being a part of product functionality or because they are simply reporting a known design problem that is not going to be fixed.
At the beginning, I started getting fed-up easily of as-designed issues because of my lack of knowledge about the product under tester’s scrutiny. What would be the key of having control on these as-designed issues? During this distress period, I started going through product related documents and day by day started getting familiar with known issues of product. Result was obvious; count of known issue reporting started depreciating. Vigorous reading of product related documents was giving positive results. Bug count, new issues and defects, was increasing gradually and I was pleased with my habit to report known issues. Active reading of reference materials, trying the product’s in and out made testing coverage easy. Next issue was that of bug count that obstructed at a point as testing coverage was completed.
Someone asked me to do exploratory testing. Now what is that?

I later found out that exploratory testing is not just a testing technique rather it’s a way of thinking about testing. Testers who emphasizes on exploratory testing use variety of tactics to learn about product under test and its context.
Exploratory testing emphasizes adaptability and learning.
Three factors that make explorers different from ordinary testers are product attack, failure gauge & risks.
An attack is a stereotyped class of tests, optimized around a specific type of error. For example, test product for input attack. Overflow the input buffers by repeating same input or series of inputs numerous times.
Failure gauge is a way in which product under test can fail. Every time when a product crashes tester repeats the scenario and execute it to reproduce crash.
Threat of breaking any quality criterion of product under test is a Risk. Quality criteria are used to determine the problems faced in product’s working.
Do not get upset if your bug count is stuck at some point even if you are trying functionality, negative or regression testing; work on all these three factors. What you will achieve through this practice is exploratory testing that remains confided in the boundaries of product’s testing specification.

This is my Expo-Spect. Stay tuned for examples of Expo-Spect in my next article.

Read Full Post »