Modeling is how we build cohesive ideas about the software we're testing. It's how we take the random bits of information we gain about the software we're testing and put them together to build something useful. When we work on projects, our models grow and contract over time. As we learn new information, we test the model with it. If we need to, we incorporate that new information into the model.
As testers, we work with models all the time. Sometimes these models are formal, defined using UML or drawn up in a modeling tool like Visio. Sometimes they are informal, created in your head, drawn on the back of a napkin. Regardless of the format, we use models when we're learning about the product and when we're testing the product. When we're learning, we're model building. When we're testing, we're model checking.
Using models to help generate test cases
When I'm testing, I do a lot of modeling. I actually draw pictures. I draw them in my notebook, on whiteboards, and using tools. They aren't just in my head. I have a couple of heuristics I use to know when I'm done modeling a testing problem:
- If I can't derive explicit test cases from my model, perhaps it's not detailed enough and I need to keep working on it.
- If I can't explain it quickly to another tester, perhaps it's too detailed and I need to abstract it a bit more to simplify it.
Let's look at quick example. The following screenshot comes from bullets and lists in Microsoft Word - it displays the New Style dialog.
[IMAGE] Figure 1: New Style dialog in Microsoft Word
If I were going to test this dialog and it's features, one of the first things I'd want to do would be to model different aspects of the problem space. One complex area that occurs to me when I look at this is how this dialog interacts with different boundaries in the application. The various sizes for page size, margins,...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
indentation, font size and image size all come into play when you look at this dialog.
Here's an example of how I might model the problem:
[IMAGE] Figure 2: Example model showing the relationships of various boundaries in Word
Once I have a model like this, I can use it to start generating test ideas. For example, if the software will let me make the left indentation for my list object greater than my right page margin, I might find a problem. Similarly, if the software will let me make the left indentation for my list object greater than my right page size limit, I might find a problem. This process continues for each variable I've drawn.
Very quickly I can generate a large number of test cases. For example, just working from left to right you can come up with the following base test cases:
- left margin plus left indentation greater than right page margin
- left margin plus left indentation greater than right page size limit
- left margin plus left indentation plus image width greater than right page margin
- left margin plus left indentation plus image width greater than right page size limit
- left margin plus left indentation plus rendered font width (based on font size) greater than right page margin
- left margin plus left indentation plus rendered font width (based on font size) greater than right page size limit
For each of those test scenarios, you can have a number of tests where you look at different values for each variable: like zero, a default value, a common value, a very large value, etc.... That process can then be repeated, working from right to left, top to bottom, and bottom to top where in each case you identify possible relationships between variables.
When I'm testing, models get my mind moving again. Sometimes when I'm looking at a screen -- particularly a screen I've been looking at for the last four hours -- my mind goes blank. But if I'm looking at a diagram, the ideas come back.
Using tours to help model the problem space
If I'm completely unfamiliar with the application I'm working with, I start by touring. This is a model building technique that helps me understand what's in the application. As I'm touring, I make notes, sketch pictures, and write down all my questions.
I have a mnemonic I use when I'm touring applications: FCC CUTS VIDS. The mnemonic stands for the following:
- Feature tour: Move through the application and get familiar with all the controls and features you come across
- Complexity tour: Find the five most complex things about the application.
- Claims tour: Find all the information in the product that tells you what the product does.
- Configuration tour: Attempt to find all the ways you can change settings in the product in a way that the application retains those settings.
- User tour: Imagine five users for the product and the information they would want from the product or the major features they would be interested in.
- Testability tour: Find all the features you can use as testability features and/or identify tools you have available that you can use to help in your testing.
- Scenario tour: Imagine five realistic scenarios for how the users identified in the user tour would use this product.
- Variability tour: Look for things you can change in the application - and then you try to change them.
- Interopeability tour: What does this application interact with?
- Data tour: Identify the major data elements of the application.
- Structure tour: Find everything you can about what comprises the physical product (code, interfaces, hardware, files, etc...).
They are called tours because you are not necessarily looking for problems. You are simply learning the application. For a tour to become a test you would have to have some way of knowing you've found a problem, like a requirements document, another product or some other method. If there's no software to tour, so you can also simply tour documents: like requirements documents, design documents, mock-ups, etc...
Next steps
In a future tip, we'll take a look at applying application tours to a real application. As part of that tip, we'll look at example findings and you'll be able to see how those findings might lead to various models that you can use to help in your testing. In the meantime, take some time to look at some common project diagrams and modeling techniques. I particularly like sequence diagrams and state diagrams, but I find that good use case diagrams and class diagrams can also do the trick. A bit less common, I often find creating a simple UCML diagram is enough to get me thinking about new types of risks or areas of the application to cover.
If you're already familiar with creating these types of models, then I recommend practicing drawing your own. It gets easier with practice. Once you're comfortable reading and creating models like these, practice using them to generate test ideas. For example, when looking at a sequence and activity diagrams, ask yourself what would happen in the system if a specific line didn't happen or didn't happen correctly. As you generate your test cases, find some people whom you can work with to get feedback on your test ideas.
Over time, you'll find that it becomes easier to both create and use models like these to help with your testing. As you gain experience, you'll also find that your ability to develop ad hoc models will steadily progress.
