All About the Apps
Showing results for 
Search instead for 
Do you mean 

Improving your software testing with better test case development

HPE-SW-Guest ‎09-26-2013 12:01 PM - edited ‎09-17-2015 03:34 PM

Guest post by

Sarah Roderus, CTFL, CI, ASE

TCT Computing Group, Inc.


Before we talk about the specific steps to achieve better test case development, it is important to discuss the formality of testing. The particular level of the formality of testing you may experience at your organization (or even project) can vary greatly.


A testing process may be very informal, like when a business owner and a developer talk over a cup of coffee and determine the goals for a limited-use internal application. This discussion is the perfect example of an informal process – with little or no documentation. An informal testing process can also occur when the application development lifecycle has a limited amount of time.


Testing can also be very formal with (everything) from the test basis to the test summaries being evaluated. This is a situation where you need (everything) documented with approval signatures.


Identifying yourself on the map


However, where do YOU actually fall in the process? When it comes to your situation is an informal or formal process the right way to go? The answer depends on where you are. The following questions can help you decide:


  • How mature is the testing process at your organization?
  • Is a testing group established?
  • How much time is available?
  • Are the right people involved and are they properly trained?
  •  Are there regulatory requirements that need to be met?

Regardless of the level of formality for the application development lifecycle, there is still a process. The four steps in the test case development process are

1)      Analyzing the test basis

2)      Identifying the test conditions

3)      Specifying the test cases

4)      Developing the test procedures


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 on the 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. When you prioritize the test basis, keep three things in mind:

  • Business: How important is this to the business? If this process doesn’t work, what will the users do?
  • Failure: Is this a process that may actually fail? Is it new? It is based on a new platform? What is the anticipated failure rate?
  • Complexity: Does it take multiple screens to get through the process? Does it integrate with other applications? How complex is this piece?

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. This allows them to understand, in great detail, the overall importance of various components within the application.


The second phase is to identify the test conditions; this is done effectively 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 low-level test conditions are infrequently used business processes. It is important to 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 need to prioritize once again. This helps ensure you are continuing with business processes that are important to the end users. Keep in mind that 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?)
  • Post-condition (What is the final state?)

Based on the conditions, you can begin designing the test cases. Remember, 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.


Here is an example of a test case based on the online order placement case.

If the test case is to place an order on a weekday:

  • Precondition = item is in stock
  • Input = order one pair of shoes
  • Result = shoes are in the order
  • Post-condition = stock is reduced by one

If the test case is to place an order on the weekend:

  • Precondition = calendar defines weekend
  • Input = order a pair of shoes on a Saturday
  • Result = order processed on Monday
  • Post-condition = order is stored until Monday

Once you have completed the test design process, you need to r-prioritize again.  By re-prioritizing at this point you are ensuring that the most important test 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. It also includes 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:

(1)    Login

(2)    Place the order for shoes

(3)    Add a shirt to the order

(4)    Pay by VISA card

(5)    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!


Do you have any additional thoughts about test case development? I would love to hear them. Feel free to reach out to me in the comments section below. Testing is a passion of mine, and I love connecting with others who understand.

0 Kudos
About the Author


This account is for guest bloggers. The blog post will identify the blogger.

John Sk
on ‎11-08-2013 03:56 AM

Very informatic post, I like your point "Are the right people involved and are they properly trained? :)

on ‎03-20-2014 05:03 AM

Good article, very useful for software testing people!

27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all