Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 1 of 5

Testability requirements

10 min

Listen to this lesson

0:00 / 11:36

Most SAP quality problems that surface in testing were designed in months earlier. An interface without a business key cannot be traced. A custom calculation buried in a user exit cannot be unit tested. A Fiori app with generated control IDs breaks every automated test after each change. None of these is a testing failure; they are architecture decisions that ignored testability. This course is for the architects who can prevent them.

What testability means

The ISTQB test automation syllabus defines testability of the system under test as the availability of interfaces that support testing, for example to enable control and observation. It says testability should be designed and implemented in parallel with the system's other features, that it is a non-functional requirement, and that this work is generally performed by a software architect, often with a test automation engineer. It names three aspects:

AspectMeaning (ISTQB)SAP example
ControllabilityInterfaces that can be used to perform actions on the systemA released API to create a test sales order; a way to set a pricing date for a test
ObservabilityInterfaces that give insight into the system so tests can compare actual and expected resultsApplication log entries with the order number; an OData service that returns the calculated discount
Architecture transparencyDocumentation with clear components and interfaces that give observability and controllability at all test levelsAn interface catalog listing each flow's keys, error queues and owners

The three aspects of testability from the ISTQB CTAL-TAE syllabus, with SAP examples.

A test drives the system through control points and checks it through observation points, never by guessing from the screen.
The Sign-Off Table · thesignofftable.com/academy/sap-arc-303

From principle to requirement

"The solution shall be testable" is not a requirement anyone can verify. Write testability requirements the way you write any other: specific, per component, with a way to check them. Good testability requirements usually fall into a handful of families.

IsolationBusiness logic in classes with clear inputs and outputs, callable by ABAP Unit without the UI
Control pointsReleased APIs or services to create and reset test data; configurable dates and parameters
Observation pointsStructured logs with business keys; read APIs for results; status fields
Stable identifiersDeveloper-set control IDs in custom Fiori apps; documented technical names
DeterminismNo hidden dependence on system time, user settings or random values without a way to fix them
Families of testability requirements an architect can specify and review.
The Sign-Off Table · thesignofftable.com/academy/sap-arc-303

Each family maps to review questions at design time. Can the fleet discount calculation be called with test inputs without creating an order? Can the portal interface be fed a message in CMQ without the real portal? Does every inbound message carry the portal reference into S/4HANA? Will the custom Fiori app's buttons have IDs that the team sets and keeps stable?

Testability and clean core

Clean core and testability pull in the same direction. SAP's clean core guidance favors extensions built on released, stable APIs, whether on-stack with ABAP Cloud or side-by-side on SAP BTP. Those same APIs are natural control and observation points for tests: a test can create a business partner or read an order's status through the interface the extension uses, instead of driving screens. Conversely, extensions that modify SAP code or write to SAP tables directly are hard to test in isolation and must be retested broadly after every upgrade. When an architect weighs extension options, test cost belongs in the comparison.

Moving the fleet discount rules out of the pricing user exit into a class made every tier unit testable without creating an order.
The Sign-Off Table · thesignofftable.com/academy/sap-arc-303
  1. DesignArchitect lists testability requirements per component in the solution design
  2. ReviewTest lead and automation engineer review them with the architect
  3. BuildDevelopers implement isolation, logs, IDs and control points
  4. VerifyUnit tests, API tests and a review checklist prove the requirements are met
  5. OperateThe same observation points support monitoring and incident analysis
Testability requirements follow the same lifecycle as functional ones.
The Sign-Off Table · thesignofftable.com/academy/sap-arc-303

What would you do?

The design for a new custom approval process routes every purchase order above $25,000 through a workflow with logic spread over a BAdI, a custom table and an email step. Priya asks how her team will test the approval rules. What should the architect do?

Key points
  • Testability is a non-functional requirement owned by the architect, designed with the automation engineer.
  • Three aspects: controllability, observability and architecture transparency.
  • Write concrete requirements: isolation, control points, observation points, stable IDs, determinism.
  • Review testability at design time, like any other requirement.

Check your understanding · not graded

Lesson check

  1. 1. A testable architecture makes it easy to:

  2. 2. Who generally performs testability design work, according to the ISTQB TAE syllabus?

  3. 3. Which is a well-formed testability requirement?

  4. 4. What does architecture transparency refer to in the ISTQB syllabus?