Sometimes when I'm trying to think of a new test condition, I stand back and think of the functionality in terms of objects and actions. What is this object I'm testing? And then what are all the actions I can do with this object? Sometimes if its applicable I then continue thinking in abstract terms and think about what other objects I'm working with that behave the same way - or should behave the same way or have the same actions available. By stepping back in thinking in more generic terms, I can sometimes collect different test ideas.
Sometimes while I'm testing a new application, I struggle to get started. To help me focus and better understand my testing, I use application tours to support my testing. One the tours that I use is the testability tour.
Take a testability tour and try to find all the features you can use as testability features and identify the tools you have available that you can use to help in your testing. Take a look at James Bach’s Heuristics of Software Testability . Due to my automation background, this is of course my favorite tour. A testability feature is a feature of the product that gives us more visibility into the inner works of the product or more control over the state of the product.
The main testability features I look for when performing this tour are scriptable interfaces, test harness and stubs, log files, and diagnostic utilities. For example, I often look for WSDL interfaces for web services, Junit test harnesses for Java applications, and log files for web application servers. An excellent example of leveraging a scriptable interface can be found in Brian Marick’s article Bypassing the GUI . In addition, attempt to identify modules or layers of the application that can be tested independently. Many systems I’ve tested have had some level of diagnostic utilities associated with them (especially those that used external web services). The easiest way to find those is to ask developers, but you can sometimes find them lying around in admin consoles if you are lucky enough to know where to find them.
For a more descriptive look at using application tours, see an article I did for Software Test and Performance a few years ago. (It starts on page 20.)
Take a testability tour and try to find all the features you can use as testability features and identify the tools you have available that you can use to help in your testing. Take a look at James Bach’s Heuristics of Software Testability . Due to my automation background, this is of course my favorite tour. A testability feature is a feature of the product that gives us more visibility into the inner works of the product or more control over the state of the product.
The main testability features I look for when performing this tour are scriptable interfaces, test harness and stubs, log files, and diagnostic utilities. For example, I often look for WSDL interfaces for web services, Junit test harnesses for Java applications, and log files for web application servers. An excellent example of leveraging a scriptable interface can be found in Brian Marick’s article Bypassing the GUI . In addition, attempt to identify modules or layers of the application that can be tested independently. Many systems I’ve tested have had some level of diagnostic utilities associated with them (especially those that used external web services). The easiest way to find those is to ask developers, but you can sometimes find them lying around in admin consoles if you are lucky enough to know where to find them.
For a more descriptive look at using application tours, see an article I did for Software Test and Performance a few years ago. (It starts on page 20.)
Sometimes while I'm testing a new application, I struggle to get started. To help me focus and better understand my testing, I use application tours to support my testing. One the tours that I use is the interoperability tour.
With the interoperability (or compatibility) tour you attempt to answer the questions, “What does this application interact with?”, “How well does it work with external components and configurations?”, and “What does it depend on to function properly?” I recently worked on a project that experienced under 75% uptime in it’s test environment for the entire test cycle due to all the environmental problems we had and all the external services the application relied on.
In this tour, look for what applications, operating systems, hardware, and services the product needs to function. Does it need any special plugins, drivers, fonts, or language runtimes (Java, Ruby, etc…) to operate correctly? An easy tip that you might be interfacing with an external service may be the appearance of data that you (the user) didn’t enter. In addition, sometimes degradation in performance can be a clue that there is something happening in the background.
For a more descriptive look at using application tours, see an article I did for Software Test and Performance a few years ago. (It starts on page 20.)
With the interoperability (or compatibility) tour you attempt to answer the questions, “What does this application interact with?”, “How well does it work with external components and configurations?”, and “What does it depend on to function properly?” I recently worked on a project that experienced under 75% uptime in it’s test environment for the entire test cycle due to all the environmental problems we had and all the external services the application relied on.
In this tour, look for what applications, operating systems, hardware, and services the product needs to function. Does it need any special plugins, drivers, fonts, or language runtimes (Java, Ruby, etc…) to operate correctly? An easy tip that you might be interfacing with an external service may be the appearance of data that you (the user) didn’t enter. In addition, sometimes degradation in performance can be a clue that there is something happening in the background.
For a more descriptive look at using application tours, see an article I did for Software Test and Performance a few years ago. (It starts on page 20.)
Sometimes while I'm testing a new application, I struggle to get started. To help me focus and better understand my testing, I use application tours to support my testing. One the tours that I use is the configuration tour.
The configuration tour is similar to the variability tour and the data tour, but this time we are looking specifically for persistence and how it affects product features. Attempt to find all the ways you can change settings in the product in a way that the application retains those settings.
For a more descriptive look at using application tours, see an article I did for Software Test and Performance a few years ago. (It starts on page 20.)
The configuration tour is similar to the variability tour and the data tour, but this time we are looking specifically for persistence and how it affects product features. Attempt to find all the ways you can change settings in the product in a way that the application retains those settings.
For a more descriptive look at using application tours, see an article I did for Software Test and Performance a few years ago. (It starts on page 20.)
Sometimes while I'm testing a new application, I struggle to get started. To help me focus and better understand my testing, I use application tours to support my testing. One the tours that I use is the data tour.
In the data tour you identify the major data elements of the application: what they are, where they are, where they go, and where they come from. When taking your data tour, don’t only identify application inputs and outputs, look for default values, configuration files, options settings, and temporal data (data that has relationships with time). Note the size and structure of the data you find (especially if it’s representative of production data). Look for possible ways to corrupt data or for ways data can get into the system in ways developers may not anticipate. Attempt to identify how the data can be created, accessed, modified, and deleted.
For a more descriptive look at using application tours, see an article I did for Software Test and Performance a few years ago. (It starts on page 20.)
In the data tour you identify the major data elements of the application: what they are, where they are, where they go, and where they come from. When taking your data tour, don’t only identify application inputs and outputs, look for default values, configuration files, options settings, and temporal data (data that has relationships with time). Note the size and structure of the data you find (especially if it’s representative of production data). Look for possible ways to corrupt data or for ways data can get into the system in ways developers may not anticipate. Attempt to identify how the data can be created, accessed, modified, and deleted.
For a more descriptive look at using application tours, see an article I did for Software Test and Performance a few years ago. (It starts on page 20.)