z Products & services
98 |^
APRIL 2015
AEROSPACETESTINGINTERNATIONAL.COMTest requirements traceability – not a
phrase that sets the pulse racing, yet it’s the
essential thread that runs through all formal test
implementations. Making sure that LRU (line
replaceable unit) functional test requirements
have been correctly fulfilled is the core quality
assurance activity for test solutions.
The usual scenario encountered by test
solution providers such as Red Earth Systems
is that test requirements are set out in a text
Test Requirements Document (TRD) created
by one or more system designer, hardware
designer, or test engineer. The test equipment
hardware is provided by an in-house team or
by outsourced suppliers and similarly for the
software that implements the functional
testing. Individual requirements in the TRD
are tagged with unique IDs and these are then
referenced in the test software and the results
files produced by executing the tests.
There are software tools on the market
that implement end-to-end requirements
management and can do it very well if used
correctly by experienced staff; however they
typically come with substantial costs in terms
of both finance and the amount of training
required. Users of such applications may also
have experienced the feeling that a significant
amount of effort can be spent satisfying the
demands of the tool and the original objective
of simplifying requirements management can
seem to be lost along the way.
However, there are obviously very good
reasons to make the process of managing
requirements as easy as possible because it’s
fairly certain that anyone at the start of their
working life thinking of making engineering
their profession hasn’t been attracted by the
lure of requirements management. It may not
be the interesting part of the job for most
people, but it has to be done – and done well.
TRANSPARENCY
Rather than going down the path of attempting
to produce another requirements management
application, the approach at Red Earth
Systems has been to make the test process
more transparent by simplifying the
implementation of the functional tests. A
PC-based test management application has
been developed that executes test scripts
written using a very simple set of programming
commands. A layer of driver code provides the
interface to represent test instrument I/O as a
set of variables within the script language,
e.g. to set a power supply voltage, the
command would be of the form ‘Primary_DC_
PSU_Volts = 28.0;’.
A test evaluation is performed by a single
statement that includes a reference to the TRD
test ID, the limits for the parameter being
measured and a comment to be logged to
the results file with the test result. The systems
test manager enables the parallel execution
of test scripts, making the implementation of
tasks such as background alarm monitoring
very simple, but the majority of test code will
be implemented as a linear series of test steps
of the form: ‘set inputs to LRU’, ‘wait’,
‘measure outputs from LRU’.
The two key points about the use of high-
level scripting are firstly that the
implementation of the functional tests has an
almost one-to-one correspondence between
test steps in the TRD and test script
statements; and secondly that the scripts
themselves are eminently understandable by
people who aren’t software professionals but,
crucially, are those who have the greatest
knowledge of the product that is being tested
and the equipment being used to test it, i.e.
the system, hardware and test engineers. This
approach provides the informed oversight of
the test solution that is an essential part of
driving up quality.SCRIPTING LANGUAGE
In practice, when test solutions using this
approach have been deployed, users have
not simply been passive reviewers. Systems
and hardware engineers have found that the
accessible nature of the scripting language
has meant that it’s been easy to create
variants of formal test scripts and also write
separate bespoke tests to aid integration,
commissioning and fault diagnosis. The test
scripts are plain-text files so it’s not essential
to have special development environments
to create, edit or review them.
This leads on to another key aspect
of supporting test solutions – change
management. Changes to the functional
tests are initiated by updates to the TRD
that then drive the requisite changes in the
test implementation. Typically, new revisions
of the affected source files are raised within
a configuration management system, then a
new build of software is created, tested,
verified and released.
The verification activity will usually consist
of a combination of functional test and
scrutiny/review of the changes in source files.
The high-level, text file implementation of the
script files used by Red Earth Systems has
the dual benefit of minimizing the number of
statements to be changed and enabling the
use of freely available, powerful, text file
comparison tools. The review process is
therefore made much more straightforward in
comparison with tracking changes in graphical
or database-based test systems.
There are many ways to implement test
systems, but by keeping things simple,
transparent and maintainable, customers
are both engaged and empowered. zIN PRAISE OF SIMPLICITY
Keeping test solutions simple is key to reducing costs. Using a Test Requirements
Document keeps the program clear and straightforward for the customer
FREE READER INQUIRY SERVICE
Red Earth
(^) To learn more about this advertiser, visit http://www.ukipme.com/info/tea NOW!
READER
INQUIRY
105
application, the approach at Red Earth