Lesson 5 of 5
Analytics
8 min
Listen to this lesson
A steering committee does not want to read runs. It wants three answers: how far along are we, what is failing, and are we ready? Cloud ALM's analytics answer these from the same data testers create, so no one builds a status spreadsheet by hand. That only works if test cases are linked and runs are executed in the right plans.
Where the numbers live
| View | What it shows | Question it answers |
|---|---|---|
| Test Execution Analysis | Runs by status over time; executed manual actions per day against the remaining total; distribution by scope or test plan; a table view you can export | How far along are we? |
| Overview app cards | Test execution status, failed manual test actions, defect distribution | What needs attention today? |
| Defect reporting | Defects by status, priority and responsible party | What is failing and who owns it? |
| Requirement Traceability | Each requirement with its user stories, test cases, runs and defects | Is each requirement built and proven? |
| Solution Process Traceability | Each process with its requirements and test execution status | Which processes are ready? |
Cloud ALM analytics for testing. Names may evolve with SAP's continuous releases.
Progress by plan, process and tester
Test Execution Analysis is the daily view. Filter by the current cycle's test plan to see passed, failed and not-yet-run test cases and the burn-down of manual actions. Switch the distribution to scope or plan to compare streams. For tester workload, filter the Test Execution list by plan and tester: a tester with fifteen unstarted test cases two days before exit is a planning problem you can still solve.
Watch trends, not just snapshots. A pass rate that rises slowly while open defects climb means fixes are not keeping up with findings. A burn-down that flattens mid-cycle usually means testers are blocked by data, access or a critical defect. Looking at Test Execution Analysis daily, at the same time, with the same filters, lets the test lead see these patterns while there is still time to act, rather than explaining them at the exit meeting.
| Pattern in the analytics | What it usually means | What to do |
|---|---|---|
| Pass rate rising slowly while open defects climb | Fixes are not keeping up with findings | Add triage and fix capacity; review priorities |
| Burn-down of manual actions flattens mid-cycle | Testers blocked by data, access or a critical defect | Find the blocker today; rebalance testers |
| One tester with many unstarted test cases near exit | Workload or availability problem | Reassign test cases while there is still time |
| Dashboard looks too good | Missing links, wrong plan or tests moved back to In Preparation | Check the inputs before reporting |
Readiness by requirement and process
Requirement Traceability shows each requirement with micro charts for its user stories, test preparation, test execution and defects. Extended filters find gaps such as approved requirements with no test case. Solution Process Traceability does the same from the process side: you can list processes whose requirements are all confirmed and whose test executions all passed. That filter is the closest thing Cloud ALM has to a one-click readiness answer.
A readiness report that decides something
At Contoso's SIT 2 exit, Priya presents one page: the plan's execution status from Test Execution Analysis, open defects by severity from defect reporting, and the processes not yet ready from Solution Process Traceability, each with an owner and date. Grace, as PMO lead, records the decision against the quality gate. The numbers are exported from Cloud ALM, so anyone can check them.
- Execution statusFrom Test Execution Analysis for the SIT 2 plan
- Open defects by severityFrom defect reporting, S1 to S4
- Processes not readyFrom Solution Process Traceability, each with an owner and date
- DecisionGrace records it against the quality gate, with the exports attached
What would you do?
The SIT 2 dashboard shows 96% passed, but Priya notices that 40 test cases were run in last cycle's plan by mistake and 15 were set back to In Preparation mid-cycle. What should she report?
- Test Execution Analysis tracks runs by status, action burn-down and distribution by scope or plan.
- Overview cards and defect reporting show what needs attention and who owns it.
- Requirement and Solution Process Traceability show readiness by requirement and process.
- Analytics reflect only linked, correctly planned data; check inputs before reporting.
Check your understanding · not graded
Lesson check
1. Which view shows executed manual actions per day against the remaining total?
2. Which view lists processes whose requirements are confirmed and tests passed?
3. Why might a dashboard look better than reality?
4. How can a test lead check tester workload?