Having A High Quality Test Case Repository And How To Get It

Recently I was asked about is there the perfect way of writing a test case. Regardless of the application that is it will be executed against. Interesting enough I have a case study that discusses this notion of test case format. Do I feel what I wrote as the best format to use? So far it is the most robust and effective way of writing the test case description that leads to the ability to have data variability and ability to have a flow of cases to be efficient in execution.

This is is a case study with recommendations. The data is scrubbed and there are no mentions of the organization.

In any software, testing is the final stage in assuring a quality product is produced (Software Testing, 2011). It provides validation that the end product is what was expected and it ensures that no other scenarios can impact product use or shortens its lifespan. Testing is the last procedure completed before the software is published to public systems. Months of work from all stakeholders depend on properly executed testing processes to find and correct all possible before product release.

TEST ORG conducts processing of client transactions on a day to day basis and they must follow strict government guidelines to ensure data integrity and safety The organization relies heavily on the efforts of the technology testing teams and their successful execution of the testing process to ensure the products used by staff and clients are of utmost quality and secure. These teams ensure the information is safeguarded and handled as per expectations

Scope

This analysis will provide a thorough investigation of the TEST ORG testing methodology Test Case creation process, thus identifying connecting processes, such as upstream and downstream procedures that are impacted by the execution of test cases.

In scope

• Analyzing the following components of the Test Case Creation process:

  • Test Case naming conventions

  • Storage structure of Test Cases.

  • Test case content layout and documentation

  • Coverage and Traceability of test cases to Requirements

  • Test case review processes

• Analyzing the impacts to the following processes:

  • Test Planning

  • Test Execution

  • Cross Line of Business impact

  • Test Estimating

Out of Scope

1. The systems that are impacted by the Test Case Creation process will not be included in any recommendations; they will only be used in a support function.

Assumptions

The following assumptions are considered:

1. All Lines of Business use an approved Test Tool for documenting test cases.

2. All Testing groups are in compliance with the organization set of testing processes. Information provided by the various Test Groups is accurate and indicative of completed work 

Major Issues

Test Case naming conventions and storage structure

Current processes do not state how Test Cases are to be identified and stored. This permits all groups and individuals within a group to have control over naming test cases which can cause confusion in identifying test case differences during cross Line of Business initiatives (Palley,2004).

Test case content and layout 

Currently, to write a Test Case there must be three components: Setup, Input and Output. No explicit set of expected content within each of the sections has been identified. However, a guidance page providing information on the type of requirements needed for each section is provided. This creates confusion similar to Test Case naming and prevents synchronization of all lines of business across the organization.

Coverage, Traceability and Review Processes

The main component of testing is to ensure that all test cases created and executed meet organizational expectations (Johnson, n.d.). Part of this process includes Test Case review by stakeholders to ensure the highest possible quality standards are met before signing them off. TEST ORG does not conduct these reviews in a consistent format between lines of business nor within a line of business..

The above issues share a common theme: inconsistency. Although there is an Enterprise Methodology that provides rules regarding conducting the testing process, the system for test case creation does not contain enough controls to ensure standardization throughout the organization. (Slack, Chambers, & Johnston, 2010, pg. 20)

Analysis

Test Case Naming Conventions and Storage Structure

Figure 1 is a project that involves multiple Line of the Business Programs between 5 applications involved with the initiative.

Figure 1 has no indicator within the test case name demonstrating the intent of the test. As per the TEST ORG guidance, it is recommended that the names be unique with the use of numbers or acronyms.

Identifying errors in these test cases would be time consuming with this generic set up. It would be difficult to distinguish which change in formatting a particular test case is testing without actually opening the test case. Once open the reviewer must consider all of the test case content to determine which application to focus on for correction procedure; this is time consuming. The development team would also break down the test case to pinpoint a specific function. In this project with multiple development groups working on it at the same time identification of the application error would create lost many time hours.

In Figure 2 the use of acronyms for test cases are uniquely identified. However the names are too long for the window on the side. An individual would have to open the test case to understand what is being tested.

Other differences between the two projects are the use of folders to separate components of the testing effort. In Figure 2, a department uses acronyms Software Testing. (February 20, 2011). as identifiers. This will work for that department; unfortunately it can create confusion for the other working groups (King, 2009).

Other projects use a numbering system that resembles a Dewey Decimal system (“Dewey Decimal Classification“, n.d.) identifying different functions by numbers (Figure 3). In this project a mix of numbers and words are used to break down the storage structure for project stakeholders and categorize the cases.