Lesson 5 of 5
Reading the landscape before you test
8 min
Listen to this lesson
Everything in this course comes together in one habit: before you run a test, read the landscape. A five-minute check stops you from testing in the wrong client, against the wrong build, with stale data or a mocked interface you thought was real. It also makes every result you record defensible.
The pre-test checklist
- System and client. Am I in the right system and client for this test level? Integration and acceptance at Contoso run in QAS client 100, not DEV or training client 200.
- Release and baseline. Which software release and which build or transports are imported? Has anything been imported since the last run?
- Data refresh date. When was the system last refreshed from a production copy, or loaded by migration? Is the master data I need there and current?
- Integrations. Which interfaces are connected to real partner test systems, which are stubbed or mocked, and which are switched off?
- Users and roles. Am I testing with a user that has the business role the real user will have, or with a broad project user?
- Background jobs and dates. Are the jobs that process this step scheduled in this system? Is the posting period open?
- System and clientRight place for this test level
- Release and baselineKnown build; nothing imported since unnoticed
- Data refreshMaster data present and current
- IntegrationsReal, stubbed or switched off
- Users and rolesBusiness role, not a broad project user
- Jobs and datesJobs scheduled; posting period open
Matching the system to the test level
| Test level | Where it should run | Why |
|---|---|---|
| Unit | Development (customizing or unit test client) | Builders check their own work before releasing a transport |
| String | Development or quality | Depends on whether enough data and integration exist in DEV |
| Integration / end-to-end | Quality (Contoso QAS client 100) | Transported configuration, realistic data, connected interfaces |
| User acceptance | Quality or pre-production | Business users test the transported solution with realistic data and roles |
| Performance, cutover rehearsal | Pre-production or a production-sized copy | Volumes and hardware must resemble production |
Typical placement of test levels. Your test strategy should state it explicitly.
Why the same test passes in one system and fails in another
When a test behaves differently across systems, the cause is almost always one of four things: different transports (a change is in one system and not the other), different data (master data, condition records or open periods differ), different integrations (a real partner system in one, a stub in another), or different users and roles (a broad test user in QAS, a restricted business role in production). Check them in that order; transports and data explain most cases.
Record the checklist answers in the test run itself, not in a separate document. In SAP Cloud ALM or SAP Solution Manager, testers can add the system, client, build and data notes to the test run or attach them as evidence. When a defect is raised from that run, the landscape facts travel with it, and the developer does not have to ask the first three questions every fixer asks: which system, which client, which build.
- Test run headerSystem, client, build, data notes recorded once
- EvidenceScreens and documents attached to the run
- Defect raisedCreated from the failed step, inheriting the landscape facts
- DeveloperStarts diagnosing without asking which system, client or build
- Are the same transports imported in both systems?Yes → check data · No → the missing or extra transport is the prime suspect
- Is the relevant master and configuration data the same?Yes → check integrations · No → compare condition records, master data and open periods
- Are the same integrations connected?Yes → check users · No → a stub or a different partner endpoint explains the difference
- Do the users have the same roles?Yes → raise a defect with full landscape details · No → authorization differences explain it
What would you do?
After Contoso's go-live, billing for Great Lakes Fleet Services fails in production with a missing output condition. The same scenario passed in QAS client 100 during acceptance. Which check should come first?
One subtle point from that scenario: some things that drive SAP behavior, such as pricing and output condition records, are often maintained as master data directly in each system rather than transported as configuration. A landscape check must include that data, not only the transports.
- Before testing, check system, client, release and baseline, data refresh, integrations, users and jobs.
- Each test level has a natural home in the landscape; write it into the test strategy.
- Different results across systems come from transports, data, integrations or roles.
- Condition records and other master data may differ even when transports match.
- Put landscape facts in the sign-off evidence.
Check your understanding · not graded
Lesson check
1. A UAT script passes in QAS but fails in pre-production. What should you check first?
2. Where should Contoso's integration tests run?
3. Why should evidence say which interfaces were real and which were mocked?
4. Transports match in QAS and production, yet output differs. What is a likely cause?