• Twitter
  • LinkedIn
  • Xing
+49 7353 981781
Heicon Ulm
  • HOME
  • COMPANY
  • PRODUCTS
  • HEICON BLOG
  • English
    • Deutsch
    • English
  • Menu Menu
You are here: Home1 / B_Validation and Verification2 / Implicit Testing – A good idea (Part 1)?

Implicit Testing – A good idea (Part 1)?

B_Validation and Verification

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.

 

 

21. February 2017/0 Comments/by HEICON Global Engineering GmbH
Tags: Functional Requirements, Functional Safety, Requirements, Software Engineering, Software Requirements, Software Testing, Testing, Validation, Verification
Share this entry
  • Share on Facebook
  • Share on Twitter
  • Share on WhatsApp
  • Share on LinkedIn
https://heicon-ulm.de/wp-content/uploads/2020/08/DI1A5942_klein_VV_Eng.jpg 431 553 HEICON Global Engineering GmbH https://heicon-ulm.de/wp-content/uploads/2020/07/heicon-logo-5.png HEICON Global Engineering GmbH2017-02-21 22:50:232021-02-03 21:25:04Implicit Testing – A good idea (Part 1)?
You might also like
Requirement EngineeringUser Stories – The better Requirements?
RailwayEN 50128 Functional Safety in the railway industry
Other Functional Safety StandardsISO 25119: Software Development for Tractors and Machinery for agriculture and forestry
Functional SafetyGood safety development process – What is it?
Requirement EngineeringHow many level of Software requirements are necessary and useful?
RailwayEN 50129 Safety Case
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Categories

  • A_Requirement Engineering
  • B_Validation and Verification
  • C_Config- / Change Management
  • D_Security
  • FuSa__General
  • FuSa_Aerospace
  • FuSa_Agriculture
  • FuSa_Automotive
  • FuSa_Industrial
  • FuSa_Railway

Contact

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Phone: +49 7353 – 98 17 81
Mobile: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRINT  |  DATA PROTECTION

User Stories – The better Requirements?Requirement EngineeringValidation and VerificationImplicit Testing – A good idea (Part 2)?
Scroll to top