MIT SAP Test Process
Test Process Summary:
Test strategy begins after the Discovery Phase of a new project.
- The test strategy addresses the risks, why the test should be performed, and the most effective methods to accomplish the test objectives.
- A test plan is developed to determine the type of test (unit, project, integration, usability), business rules, test objectives, setup procedures, and sign-off criteria for release to production.
- Finally, the test cases provide the step-by-step procedures and instructions needed to test functionality.
Test Request Form
After a project Discovery Phase, the Project Lead sends a Test Request Form to ist-quality@mit.edu. This process notifies Administrative Computing’s Quality Assurance (QA) that a test is needed for an SAP business process or project.
Within 48 hours after receiving the form, QA will contact the Project Lead to arrange an interview to gather detailed information regarding the project’s test strategy, goals, timing, infrastructure, location(s) and participants.
Each business area/department with processes in SAP should have an abbreviation in the QA Area Matrix; for example AP for Accounts Payable.
To request an abbreviation, please send an email to ist-quality@mit.edu with your request for a new department name abbreviation.
Test Acceptance Form
With various types of tests, (functional, integration, system, usability etc.) a Project Manager or process owner(s) needs to ?sign off? on the test results of one test type before proceeding to the next phase of the software life cycle. (Ex: Accept the functional test before moving to the integration test).
When this is the case, a QA staff member will prepare the Test Acceptance Form designating the type of test and the responsible individual(s) outlined in the Project test plan that will confirm whether the test was satisfactory or not.
Templates
Test Plan
It is important to develop a test plan that organizes a business area's overall testing approach for their business processes. The plan provides specific instructions regarding test objectives, the test schedule, set-up procedures for the test environment and expected results. Use the Test Plan Templates below to more concretely define the test methodology of your project.
Test Plan Template - use this template to document the test objectives and steps for processes, transactions and programs.
Dropbox Test Plan - Use this template to document the test objectives for the feed or upload process.
Test Case
A test case describes a series of steps in a transaction or set of transactions pertaining to a given business process carried out via SAP. Execution of a test case simulates the effort ordinarily performed by staff.
Standard information is required at the top of each test case no matter what template is used:
- Test Case Filename - For specific details on how to name your test cases accurately, refer to Test Case Name Format instructions.
- Tester(s) - name of persons executing the test case
- Menu Path - the custom menu path if one exists; otherwise note the SAP menu path or web URL
- Transaction/Program - the transaction /module or program being tested
- Purpose of test case - the functionality the test case is verifying
Each transaction in the MIT SAP transaction database should have test cases written in order to test their functionality.
The application functionality and business risks determine the type of test and required test documentation that must be developed for a business area. Listed below are test templates that a business area may need.
Transaction Test Case Template - use for single and multiple transaction test cases
Report Test Case Template - use for report tests
Test Issues
The MIT SAP Test Issue Database contains issues reported during various kinds of tests of the SAP R/3 system.
When
an issue is recorded, it passes through a series of status definitions,
which are used to track the progress of the issue. This process
and status definitions are charted
out in the Workflow diagram.
