Lesson 1 of 6
Non-functional requirements that can be tested
9 min
Listen to this lesson
Functional tests prove the system does the right thing. Non-functional tests prove it does it fast enough, at the volumes the business really runs, inside the time the business has, and that it can be operated and recovered when something breaks. On SAP programs these tests are often left until late, run once, and reported as "performance OK." That is not evidence. Evidence starts with requirements you can measure.
From vague to measurable
A requirement such as "the system must be fast" can never fail, so it can never pass. A testable non-functional requirement (NFR) names the process, the measure, the target, the percentile and the conditions under which it applies. The conditions matter most: a sales order that saves in one second for one user tells you nothing about the last business day of the quarter.
| Vague | Testable |
|---|---|
| Order entry must be fast | 95% of sales order saves complete within 2 seconds with 300 concurrent users and month-end order volume |
| MRP must run overnight | MRP for plants 1710 and 1720 completes within 90 minutes, starting 01:00, with current production data volumes |
| Billing must be done before the morning | The billing run for all deliveries goods-issued by 22:00 completes by 05:00, including output |
| Reports should not be slow | The open AR overview for company code 1710 returns within 5 seconds for 95% of calls at 50 concurrent finance users |
| The system must be available | Database takeover to the secondary completes and users can log on again within the agreed recovery time objective |
Contoso Motor Co. NFRs before and after rewriting. The targets are Contoso's own; yours come from your business.
Kinds of non-functional test
Performance testing is a family. The ISTQB performance testing syllabus treats load generation, test types, metrics and results analysis as separate skills; for SAP programs the useful types are:
- Load test: the expected peak workload (for Contoso, month-end) runs against the system for long enough to stabilize; check targets.
- Stress test: push beyond the expected peak to find where and how the system degrades.
- Volume test: run processes against production-sized data, for example a full year of journal entries, to expose growth-sensitive code and reports.
- Endurance (soak) test: hold a realistic load for hours to find memory growth, lock build-up and queues that only appear over time.
- Batch window test: run the real job chain with real volumes and measure it against the business deadline.
- Operational acceptance test: prove the system can be monitored, backed up, restored and failed over by the people who will run it.
What would you do?
Contoso's order-to-cash design document says: "Sales order performance must be acceptable." The sales process owner owns the process, and Maria is the order-to-cash key user. What should Priya do?
- A testable NFR names the process, measure, target, percentile, conditions and owner.
- Load, stress, volume, endurance, batch window and operational acceptance tests answer different questions.
- Use percentiles rather than averages, and production-like data and concurrency.
- Process owners agree targets; testers and Basis measure against them.
Check your understanding · not graded
Lesson check
1. Which requirement is testable?
2. Which test holds a realistic load for hours to find memory growth or queue build-up?
3. Why are percentiles better targets than averages?
4. Who should agree the target in a business NFR?