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
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.
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.
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
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)