Chapter 10. Planning and Construction of Test Cases

The construction and execution of test cases verify and validate the captured in-scope requirements or the request for new system changes. Test cases contain test conditions, test data, and expected results to verify the design, functionality, and development of SAP advanced business application programming (ABAP) objects, security settings, segregation of duties, work flow, data archiving, business warehouse (BW) reports, and service-level agreements (SLAs) for system performance. A combination of test cases forms a test scenario, whereas a test script is the sequence of actions that executes a test case.

Test cases can be designed in spreadsheets, text editors, or within test management tools. Project deliverables such as business process procedures (BPPs), flow process diagrams, and functional and technical specifications are excellent sources of information for designing test cases. The most effective test cases are those that can be executed by nonfunctional SAP experts independently without the assistance of business analysts or SAP consultants. Templates and guidelines are hereby provided to build robust test cases.

Well-written test cases exhibit the following characteristics and attributes:

· Can be reused for user acceptance testing (UAT) with minimal or no modifications.

· Trace back to testable requirements or other existing documentation (BPPs, flow process diagrams, technical or functional specifications).

· Include preconditions.

· Have been peer reviewed and signed off.

· Include SAP role(s) to be used for verifying the test conditions.

· Include a narrative or description of the test conditions to be verified.

· Contain valid test data (i.e., master data).

· Have been rehearsed prior to approval.

Test cases that meet the aforementioned characteristics fulfill two major expectations in an SAP implementation: (1) reuse or repeatability for future testing cycles, and (2) provide comprehensive details for test case automation with automated test tools. Test cases to be reused for a future testing cycle will need evaluation and maintenance for possible modification. Projects that have version control and test management tools can maintain audit trails and history logs for the actions and modifications performed on test cases. A test case written for a single SAP transaction code can be combined with test cases for other transaction codes to form test cases for end-to-end test scenarios. Test scenarios vary in complexity since they may involve the staging and preparation of data, user exits, and execution through legacy systems.

Building a Test Case

In order to build a test case it is necessary to know what requirement or test conditions are fulfilled with the execution of the test case. The execution of a test case will need to trace to at least one requirement; otherwise, it calls into question the validity or merits of the test case. In turn, a requirement for which a test case cannot be constructed calls into question the validity of the requirement. After the underlying requirement(s) that trace to the execution of the test case are identified, it is necessary to construct and design the test case template. A test case template can be used for different testing efforts such as functional, development, performance, security, and regression testing.

SAP implementation methodologies such as IBM's Ascendant or SAP's ASAP Roadmap methodology offer test case templates that can be recycled "as-is" or modified for testing SAP. In the absence of a SAP methodology that offers test case template, it will be necessary for the test team to create test case templates in-house. At a minimum, the construction of a test case should include a data dictionary that clearly defines each field to be populated, the team or individual responsible for populating the fields on the test case template, and the attributes of the fields for the test case template. Exhibit 10.1 shows a customized test case template from the Ascendant and ASAP Roadmap methodologies. Exhibit 10.2 shows a partial data dictionary and instructions for populating the test case shown in Exhibit 10.1. A test case template can be constructed in spreadsheets, text editors, or directly within a test management tool. Depending on the test management tool being used, it is possible to transfer with macros or other utilities the contents of a test case designed in a spreadsheet or text editors into a test management tool.

Exhibit 10.1. Hybrid Test Case Created from the ASAP Roadmap and SAP Ascendant Methodologies
Section 1: Header Data
Test Script Title: Test Script Method:	Test Script Design Status: Test Script Execution Status:
Priority:	Reviewed by:
Test Case Author(s):	Date Reviewed:
Testing Level/Phase:	Reference Documents (i.e., BPPs, Specs, etc.):
Description of Test Conditions:
Inter Test Case Dependencies:
Test/Data Preparation:
Execution Date:	Tester(s) Executing:	Approver(s) for test results:
Section 2: Scenario Description for Test Cases
Number	Run #	Detailed Scenario Description	Mapped Requirements (CRs)	Pre-Condition(s)	Post-Condition(s)
1
2
3
Section 3: Test Script Documentation
TRANSACTIONAL STEPS—CASE: 1
No.	SAP Role	Business Process Step, with Data	T-Code	Output Data/Expected Result	Actual Result	Pass/Fail	Defect#

Exhibit 10.2. Partial Data Dictionary and Instructions for Populating a Test Case Template
Field Name	Characteristic	Content
Description of test conditions	Mandatory	A high level explanation or summary of the process(es)/scenario(s)/business case(s) to be tested and what prompted the testing of this process (i.e., process impacted by change request, verifies a change request, etc.).
Test method	Optional	Manual or automated.
Reviewed by	Optional	Provide the name(s) of the stakeholders reviewing and approving the test case design.
Test data preparation	Optional	Any data that requires staging or preparation in order to execute the entire test script which can consist of multiple test cases.
Inter–test case dependencies	Optional	List any test cases that must be executed or completed successfully prior to the execution of the test script.
Reference documents	Optional	List any documentation such as technical or functional specifications, BPPs, flow process diagrams, and process design documents that map to the test case (scenario/process) being tested.

For initial SAP implementations the configuration, functional, business analysts, and subject matter experts play a role in documenting and peer reviewing the fields on the test case templates. For existing SAP implementations, the test team, assigned testers, and business analysts perform the activities of updating and modifying the contents of the test cases templates. Documented test cases can be approved and signed off prior to test execution. Testing cycles that include test readiness review (TRR) criteria can be included to ensure that all test cases have been peer reviewed, and signed off prior to test execution. The quality assurance (QA) team (if one is present) also can play a role in ensuring that the documented process and methodology for designing and completing a test case is enforced and adhered to.

The authors of test cases must assume that individuals other than the original authors of the test cases will execute the test cases to support future tests such as user acceptance testing (UAT) or regression testing. Hence, it is important that all test cases have expected results, preconditions, valid test data, and conditions to be verified during testing. The constructed test cases must be written with sufficient details to allow non-SAP-knowledgeable individuals to execute them.

Leveraging Information

SAP testers can leverage the following sources of information or work products for constructing test cases and populating the fields shown in Exhibits 10.1 and 10.2:

· Business process procedures (BPPs)

· Flow process diagrams

· Technical and functional specifications

---

[Pages235 - 236]

· Process design documents

· Requirements

· Customer input (CI) templates

The primary purpose for a BPP is for training; however, the SAP ASAP Roadmap methodology offers an accelerator for the BPP template that can be enhanced to include test conditions that makes it suitable for the execution of unit test cases. BPPs with test conditions used for unit testing can be strung together to create larger test cases for scenario and end-to-end testing. Larger SAP scenarios can include test conditions for SAP work flow, migrated data from legacy systems, user exits, interfaces, converted data, and security roles.

Flow process diagrams based on Unified Modeling Language (UML) notation such as use cases are effective techniques for constructing test cases, since they reveal the expected interaction and tasks of end users with the system. Diagrams representing user tasks or larger end-to-end processes must include notations that describe the assumptions, constraints, high-level description, user roles, preconditions, postconditions, and business priority for the described process. UML use-cases diagrams are suitable for providing such notation. Furthermore, it is necessary to maintain all relationships and diagrams, since it is possible that a diagram for a single process forms part of a larger end-to-end scenario. Flow process diagrams provide a high-level description of the process to be tested, which can help the resource assigned to creating test cases document the test case template.

Functional and technical specifications provide the logic for configuring the system, creating report, interface, conversion, enhancement, work flow, and form (RICEWF) objects. Furthermore, SAP configuration settings and changes made to the production system such as new business logic, validation rules, and radio buttons also need to be documented when maintaining the SAP production system in order to allow proper testing coverage and documentation of test conditions for future testing cycles. As an example of the value of technical specifications assigned, testing resources can leverage technical specifications to create test conditions and document test cases for validating interfaces for the following parameters: business rules for converting all data and field mappings, number of records to be extracted, how the interfaces are batch scheduled, and data reconciliation between source and target systems.

Requirements are critical because they tell "what the system will do," and thus the test team must develop test cases to ensure that all requirements are validated and verified. Test cases and requirements are tightly intertwined since a test case can demonstrate that a captured requirement is not suitable for testing or implementation, and requirements provide the basis for constructing a requirements traceability matrix (RTM). Assigned testing resources must develop and design test cases that have test steps that successfully validate the design of the implemented requirement.

In addition to leveraging the aforementioned sources of information, assigned testing resources must review "as is" documentation from the legacy systems to be replaced by SAP, company business rules, project's scope statement, key performance parameters, and industry standards to ensure that the documented test cases contain sufficient information for validating all expected end-to-end business scenarios and business requirements. Peer reviewing of test cases is an effective technique for eliminating or modifying inadequate and ambiguous test cases prior to the start of test execution.