Test Anything - A look at Static Analysis

Today I'd like to recommend a series of "How to Test Anything" posts on the Software Testing Tricks blog authored by Debasis Pradhan. These posts embody the concept of static analysis - the process of analyzing an object or process without actually exercising it - via actual use, code execution, or other direct interaction.


http://www.softwaretestingtricks.com/search/label/How%20To%20Test


Efficient static analysis is an important skill found in the tester mentality. Many QA job interviews will include an assessment of the tester mentality - the aptitude and intellectual tool set for investigation, discovery, and diagnosis.


The tester mentality thinks about the object under test - whether that object is a software program, an integrated process, or an item like an ATM or even as humble as a water bottle - from the perspective of fully exploring and proving its capabilities - both what it can do and what it can't.


This form of test exercise allows the tester to brainstorm a variety of novel approaches to investigating any object. In the How to Test series at Software Testing Tricks, the author illustrates generating test ideas and relating them back to areas of software testing, such as

• Functional testing - positive path - Does the object do what it's supposed to?
• Functional testing - negative path - What happens if you do something you aren't supposed to?
• Load testing - How does the object perform when used?
• Stress testing - How does the object perform in stress conditions - temperature, impact, frequency, duration, etc?
• Usability testing - Is the object intuitive and friendly to use?
• Installability testing - Can the object be set up and used as expected?
• Compatibility testing - Does the object work as expected in various possible uses?
• Interoperability testing - Does the object work with other things as expected?

A useful adjunct is the identification of pre-requisite clarifying questions which can confirm specifications and requirements. Sometimes these requirement clarification questions can significantly influence the test approach and if not asked, would represent gaps which can be found early in the product life cycle and save considerable expense. For example, if you were tasked with testing a piece of paper, you might identify the following requirements clarification questions:

• How big should it be? Standard printer size? United States or Europe?
• What is this used for?  Writing? Drawing? Origami? Blueprints?
• If used for writing, who is the intended audience? College students? Kindergarten students? Calligraphers?

Quiz yourself and see how many test ideas and test requirement questions you can come up with for the following common objects!

• Bubble gum
• Light bulb
• Sidewalk