Of the many ways to plan your testing, I find entity-based plans to be the most reliable. An entity, such as a user, item or order, is one of the relative constants in applications and websites. Entities might gain and lose characteristics along the way, but they are rarely removed or added to because they are central to the architecture.
That means that a test plan based on entities retains its structure for multiple versions, making it relatively easy to update. Compare it to a test plan that is based on the UI or on work-flows, which might change with every version (in fact, their changes might be the whole point of the version), and you’ll begin to see the benefits of this mapping.
Let’s see how entity mapping can work, using an e-commerce site as an example.
When selecting entities for testing it makes sense, on the face of it, to follow the architecture. For example, an order on the website might be “new”, “in packing” and “done”. These examples are all a single entity in its various states; both you and the architecture are likely to see it that way.
But is a a shopping cart an order or a different entity? Although the architecture might treat a shopping cart and an order as a single entity, they have such different abilities and sub-states that I think it’s far more helpful to consider them separately. Here, then, you will go against the architecture.
The opposite case I do not recommend. If the architecture treats what you consider one entity (or its sub-entities) as two different entities, insisting that they be treated as one entity will cause you to miss a lot of tests.
Thinking of Tests
From what I’ve already said, it’s easy to see that entities have two main logics:
1. State changes within an entity, with entry and exit parameters for each state. For example, a paid order and a packed order are a single entity in two states.
2. Type changes between entities, with entry and exit parameters for each type. For example, from shopping cart to order.
The differences between the two logics, and the details of each one, can usually be used as the skeleton on which the test plan is built. This sort of thinking lets us consider the following elements when writing our tests:
1. Entity characteristics that change the entity type. For example, a shopping cart marked as ‘paid’ is an order. Here it’s very important to check that with the type change the right state is reached, the right actions can (or cannot) be taken, mandatory information is verified and no information is lost (doubly important if the entity is moved to a different table in the database or any other major beyond-the-scenes change).
2. Entity characteristics that affect its state. For example, ‘not in stock’ is a characteristic that should put an item in a particular state. It’s important to check what an entity is and isn’t allowed to do at any state.
3. The various states a single entity can go through in a single work-flow, and the states it reaches in interrupted work-flows. It’s important to check the entry and exit parameters for each section of the work-flow.
4. The relationship between different entities, and the states and actions permitted by these relationships. For example, in many sites any casual visitor can have a shopping cart, but only a logged in user can change that shopping cart into an order.
Writing the Plan
The plan should be split by entity, that much is obvious. But organizing it is a little more complicated. I find that the following sub-plans usually offer a good coverage:
1. Follow each process an entity can be involved in and design tests to cover all entry and exit parameters, along with all permitted and blocked forks along the process. Take care to cover these processes in all possible entity states. You might be tempted to treat interfacing with 3rd party components such as PayPal as a separate test, but since it affects the entity’s state (and perhaps type), it should be an integral part of process testing.
2. If there are states an entity can reach without a specific work-flow (for example, a user may be considered inactive after six months of inactivity), design special tests for these.
3. To these large tests add smaller tests that verify correct handling of entity characteristics. But be careful not to make your large tests too complicated and messy – if there are many small characteristics, you might want to design a single test to cover all of them.
4. It’s best to treat as separate tests issue of security (such as character sanitation), areas of the site that are not interactive (terms and conditions page, for example) and UI tests.