Lesson 5 of 5
Using Readiness Check results to scope testing
11 min
Listen to this lesson
Readiness Check does not test anything, but it is one of the best inputs a test lead gets in a conversion. It tells Priya where the system will change, which data is suspect and which code and interfaces are at risk. Used well, it turns a regression scope from "test everything a bit" into "test what changed, thoroughly, and the rest by risk".
From findings to test scope
| Readiness Check result | Test implication | Contoso example |
|---|---|---|
| Relevant simplification items with business impact | Process tests for the affected flows, with expected changes documented | Business partner maintenance replaces customer and vendor transactions |
| App availability: unavailable or successor apps | Tests of the successor apps and changed navigation for the roles that used them | Planners move from MRP lists to material coverage apps |
| Custom code findings | Regression for adapted objects; deletion check for removed ones | Morning exception report replaced and retested |
| Integration impact analysis | Interface tests for impacted interfaces, end to end | IDoc for customer master to the CRM system |
| Customer Vendor Integration analysis | Business partner completeness and correctness tests | Every customer has a business partner with the right roles |
| Financial Data Quality | Reconciliation tests before and after conversion | G/L, asset and material ledger balances by company code 1710 |
| Business process discovery backlog | Cutover and data tests for old open documents | Open orders older than 365 days closed or migrated deliberately |
| Planned downtime estimate | Timed rehearsal tests | Dress rehearsal fits the 60-hour window |
Turning Readiness Check findings into test scope.
Worked example: from findings to Contoso test cases
| Finding | What changes | Test case and where |
|---|---|---|
| Business partner approach | XD01 and XK01 lead to transaction BP | Create and change Great Lakes Fleet Services (17100001) in BP; roles and sales area 1710 / 10 / 00 |
| Material document transactions | MB1A, MB1B and similar are replaced by MIGO | Goods issue and transfer posting 311 from 171S to 171L in MIGO |
| SD pricing data model | Conditions move from KONV to PRCD_ELEMENTS | Order pricing 240.00 per CMC-ALT-100; custom pricing reports retested |
| Credit management | FD32 replaced by SAP Credit Management (UKM_BP) | Credit block and release for a fleet customer |
| Storage Location MRP | Planning moves to MRP areas | MD01N run for plant 1710 excludes 171S |
| Financial Data Quality | Corrections before conversion | Before/after trial balance comparison for 1710 |
How Priya turns specific findings into test cases with real transactions and Contoso data.
What Readiness Check cannot tell you
Absence of a finding is not evidence of safety. Readiness Check relevance is mainly based on table contents and used transactions; it does not know your business calendar, your seasonal processes or your contractual obligations. Year-end processes, rare but critical variants and processes that were not run in the analyzed period can be missing from the results. Priya adds them from the process owners' knowledge, not from the dashboard.
- Processes that run only at quarter or year end, such as fiscal year change or annual planning.
- Rare but high-risk variants: recalls, warranty returns, intercompany corrections.
- Data-driven behavior that only appears with production volumes.
- Authorizations and roles, which need their own tests after conversion.
Readiness Check also helps with test data and environments. Sizing and data volume results tell Sam how large the mock conversion copies will be and how long refreshes take. The transactional backlog tells Luis and Priya which old open documents will be converted and must therefore be tested, for example open purchase orders from years ago that will appear in buyers' worklists after go-live.
Keep the link alive
Each test scenario that exists because of a finding should reference it, so the trace runs both ways: a finding shows the test that proves it, and a test shows why it exists. When a re-run changes a finding, for example a new simplification item becomes relevant after a support package, the trace shows which tests to review. In SAP Cloud ALM, findings, follow-ups, requirements and test cases can sit in one project, which makes this practical.
- Findinge.g. Storage Location MRP relevant in plant 1710
- DecisionMove 171S planning to an MRP area
- RequirementSpare stock in 171S is not available to MRP
- Test caseMRP run excludes 171S stock; proposals as calculated
- EvidenceStock/requirements comparison in CMQ
What would you do?
The Readiness Check shows no findings for Contoso's warranty returns process. The PMO proposes dropping it from regression to save time. What should Priya do?
- Map every finding with business impact to a test implication.
- Combine findings with business criticality to set test depth.
- Add seasonal, rare and data-driven processes from business knowledge.
- Keep finding-to-test traceability, ideally in SAP Cloud ALM.
Check your understanding · not graded
Lesson check
1. How do Readiness Check results help test leads?
2. Which process is most likely missing from Readiness Check results?
3. A critical process has no Readiness Check findings. What test depth fits?
4. Which Readiness Check result leads to timed rehearsal tests?
5. A Contoso test script from ECC still tells testers to post a goods issue in MB1A. What should Priya do?