In larger safety-critical projects, quite often I hear the following statement: “Well, the Requirement A is indirectly or implicitly proven with the test XY!” Do you know this sentence as well? Have you ever experienced what can happen in late project phases when you have tested many requirements indirectly?
The blog defines the term in part 1 and it discusses the causes of implicit testing.

What is meant by indirect or implicit testing?

Implicit or indirect testing of requirements means that there is no direct possibility to prove the requirements with the existing test equipment. Instead, the test of other functional requirements is used, to “prove” the “not testable” requirements. Arguments are developed, to demonstrate the correctness of the “indirect” requirements.

Let’s make an example:
Req. A: If Weight on Wheels = TRUE is present at Discrete Input DS 1, the software flags shall be set as follows: SWW1 = TRUE and SWW2 = FALSE.

Req B: If SWW1 = TRUE and SWW2 = FALSE then the AFDX Msg “ON_GROUND shall be sent.

Access to internal software variables is generally not possible in many test environments. This makes it impossible to check the status of the software variable directly in the test. Only an indirect test is possible by setting the discrete input DS1 to TRUE and then checking if the AFDX Msg. “ON_GROUND” is sent.

This is a typical example of indirect tests.

Typical root-causes:

Basically, I see two root-causes for the development of many indirect tests:

• Tests should prove the architecture
• Test environment is not adequate for the requirements to be tested (example above)

About the first case I have already written in other blogs (IEC61508: Specification Architecture Requirements – Is there any difference). Proof of the correctness of the architecture is not possible by means of a test. If you prove an architecture with a test, then this will always be done indirectly. You will prove the functionality implemented by the architecture. There is no way to prove the correctness of the architecture by a test in a direct way.

The second case often occurs when at the beginning of the project it is not clearly defined how many steps are used to break down the system. Most common there are two levels for a control unit consisting of a hardware with a microprocessor and the software for the microprocessor. In Aerospace projects there are three levels required (system, high-level (SW), low-level (SW)).
The necessity of indirect testing occurs when requirements for the second or third level are described but there is only one test environment for the system level.

The disadvantages arising from the indirect testing and approaches for minimizing such tests are discussed in the second part of the blog.

Related HEICON Blog posts

• Implicit Testing – A good idea (Part 2)?
• Testing of Platforms: A challenge!
• Management aspects of testing
• Psychology of Testers

Are you ready for a status workshop, to analyse improvement potentials in your test engineering, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.