As testers, they work with models all the time. Sometimes these models are formal, defined using UML or drawn up in a modeling device like Visio. Sometimes they are informal, created in your head, drawn on the back of a napkin. Regardless of the format, they 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.
Modeling is how they build cohesive ideas about the program we’re testing. It’s how they take the random bits of information they gain about the program we’re testing and put them together to build something useful. When they work on projects, our models grow and contract over time. As they learn new information, they check the model with it. If they require to, they incorporate that new information in to the model.
Using models to help generate test cases-
When I'm testing, I have a lot of models. Actually draw. I draw in my notebook, on the boards, and using tools. Not just in my head. I have a couple of heuristics that I use to know when I'm done modeling a testing problem:
1. If you cannot derive explicit test cases of my model, maybe it is not detailed enough and I have to keep working on it.
2. If I can explain quickly to another tester, it is perhaps too detailed and I have a little more abstract simplification.
Let's take a quick example. The following screenshot comes from the bullets and lists in Microsoft Word - shows the New Style dialog box.
If I were to try this dialogue and its characteristics, one of the first things I would do would be to model the different aspects of space problem. One area complex that I can think when I see this is how it interacts with different limits dialog in the application. The different sizes for the page size, margins, indentation, font size and image size all come into play when you look at this dialogue.
Quickly I can generate a sizable number of check cases. For example, working from left to right you can come up with the following base check cases:
Once I have a model like this, I can use it to start generating check ideas. For example, if the program 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 program will let me make the left indentation for my list object greater than my right page size limit, I might find a problem. This method continues for each variable I’ve drawn.
* left margin and left indentation greater than right page margin
* left margin and left indentation greater than right page size limit
* left margin and left indentation and picture width greater than right page margin
* left margin and left indentation and picture width greater than right page size limit
* left margin and left indentation and rendered font width (based on font size) greater than right page margin
* left margin and left indentation and rendered font width (based on font size) greater than right page size limit
For each of those check scenarios, you can have a quantity of tests where you look at different values for each variable: like zero, a default value, a common value, a sizable value, etc…. That method can then be repeated, working from right to left, top to bottom, & 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 — a screen I’ve been looking at for the last two hours — my mind goes blank. But if I’m looking at a diagram, the ideas come back.
Use of travel to help model the problem space If am completely familiar with the application I'm working, I start touring. This is a modeling technique that helps me understand what is in the application. As I'm touring, I make notes, sketch, and write all my questions.
I have a rule of thumb I use when I'm on tour applications: vides FCC CUTS. The mnemonic for the following positions:
* Visit Feature: Move through the application and become familiar with all controls and features that come through
* Visit Complexity: to find the five most complex things on the application.
* Visit Claim: For all the information in the product that tells you what the product.
* Visit configuration: try to find all the ways you can change the settings in the product so that the application maintains the settings.
* Visit Username: Imagine five users for the product and the information you want the product or the major features that are interested
* Visit Testability: Find all the features you can use as testability features and / or identify the tools you have available you can use to help your test.
* Visit Scenario: Imagine five scenarios of how realistic users identified in the tour of the user who uses this product.
* Visit Variability: Look for things that you can change into the application - and then try to change them.
* Visit Interoperability: What does this application interact with?
* Visit Data: Identify key data elements of the application.
* Visit Structure: Find out everything you can about what comprises the physical product (code, hardware interfaces, file, etc. ...).
They are called tours, since they are not necessarily looking for trouble. You are simply learning the application. For a visit to become a test you should have some way of knowing that you have found a problem, as a requirements document, another product or another method. If there is no software on tour, so you can also simply turn documents: as requirements documents, design documents, models, etc...
Next steps in a tip for the future, let's take a look at the implementation of tours application to a real application. As part of this Council will look at the results of example and you will see how the results could lead to several models can be used to assist in their inquiry. Meanwhile, take some time to see some common project diagrams and modeling techniques. I especially like sequence diagrams and state diagrams, but I think the best case diagrams and class diagrams use can also do the trick. A little less common, which often include the creation of a simple diagram UCML is enough to make me think about new types of risks or areas of application to cover?
If you are familiar with creating these types of models, then I recommend the practice of his own drawing. It gets easier with practice. Once you are comfortable reading and building models like these, the practice of using them to generate test ideas. For example, noting the sequence and activity diagrams, ask yourself what would happen in the system, if a specific line did not occur or did not happen correctly. As you build your test cases, we find that some people who can work to get feedback on your ideas of proof.
Over time, you will find it easier to create and use models like these to help with your test. As they gain experience, you will also find that their ability to develop custom progress steadily.
0 comments:
Post a Comment