Maximize the value
of your ALM

The test basis is anything on which to base your tests. This may be the business processes, testing requirements, user guide, design specifications, or interviews with the business owners – there is always (something) to study and analyze. While analyzing the test basis, you should constantly be thinking: “How am I going to test this?”, “How does this flow together?” and “Is there risk to this and if so, what is the risk.”

Here is an example of a simple test basis:
Online orders will be processed on the next working day. Payment must be made by standard credit card. Orders will be mailed within two days. If a partial order must be sent, the customer will be notified and can return their order within 30 days for a full refund.”

Here are a few questions about the example:

• What does “working day” actually mean? Is working day Monday – Friday; Monday – Thursday; or, Tuesday – Saturday?
• What does “standard credit card” actually mean? Is that only VISA and MasterCard or does that include American Express and Discover as well?
• What does “orders will be mailed within two days” actually mean? Is that two WORKING days – or does that include the non-working days as well?
• What does “If a partial order must be sent, the customer will be notified…” actually mean? Are they going to be sent a US postal letter, an e-mail, or part of the order confirmation onthe website?
• What does “….can return their order within 30 days for a full refund” actually mean? As a tester, you need to think about what would happen if a customer orders two items and returns only one of the items. Does the customer still get a full refund?

Although there are some questions, the first step in the process is complete – you have analyzed the test basis. As you continue through the test basis, you need to prioritize. As you begin to prioritize the test basis, keep three things in mind:

As a tester, you should prioritize the test basis with the business owners since they built the test basis or at least had some input into the test basis. Therefore, they understand, in great detail, the overall importance of various components within the application.

The second phase is to identify the test conditions, which can be effectively done by conducting a brainstorming session. Identifying test conditions is not a process that begins and ends on certain dates, it’s an ongoing process. As you start testing the application, you are likely to identify more test conditions. High-level test conditions will be conditions that are important to the business, and lowlevel test conditions are infrequently used business processes. Identify both high-level and low-level test conditions.
Continuing with the online order example, some test conditions might include:

• Place an order on a weekday.
• Place an order on a weekend.
• Return a partial order.
• Update customer address.

Once test conditions are identified for the test basis, you will prioritize once again. You need to ensure you are continuing with business processes that are important to the end users. Keep in mind the prioritization can change.

When the test conditions are prioritized, you can begin to design the test cases. Test cases consist of a pre-condition (What needs to be setup before testing can begin?), inputs (What are the data needs?), output (What are the expected results?) and the postcondition (What is the final state?). Based on the conditions, you can begin designing the test cases. Bi-directional traceability is very important. We need to know which part of the test basis is being tested by which test case. It may take multiple test cases to adequately test a portion of the test basis.

Once you have completed the test design process, you need to reprioritize again – ensuring the tests most important to the end users, tests with the highest failure rate, and tests that are most complex are completed first.

Once you design the test cases, begin filling in the details -- called Test Procedures. Writing test procedures is the process of filling in details for each test case including the user actions and expected results as well as combining the test cases into logical processes. For example, if there is a test case to make an online purchase on a weekday, there must be a payment to make the purchase. Therefore, the “online purchase for a pair of shoes” test case and the “payment made by a VISA card”test case can be combined. Write each individual user action with an expected result. Once the procedure is complete, determine the specific order for execution.
An example, continuing with the online order example:

Login
Place the order for shoes
Add a shirt to the order
Pay by VISA card
Complete the order

Combinations you need for execution are also part of developing the test procedures. Once the test procedures are complete, you will once again, reprioritize by business importance, high failure rate, and complexity.

In summary, developing and designing test cases is a four step process: analyzing the test basis; identifying the test conditions; specifying the test cases; and developing the test procedures. Whether your organization has an informal or formal process – it is still a process – just like better test case development!