Fluxica Peregrine is a software testing tool based on more than two decades of experience in the domain where computing science and electronic engineering meet. It enables automated in vivo software testing without bias. In vivo software testing is testing (embedded) computer source code at the execution level, it is the software equivalent of in-circuit hardware testing. Concepts and considerations that are particularly common in embedded software development have structured the thinking behind the Peregrine testing tool.
Software Testing
Software testing is often explained as a way of showing that the software works as expected, but the Peregrine testing tool is developed with the assumption that software always contains faults and the number of faults can be reduced by testing. The better the testing process, the less faults the software contains. Peregrine is a software testing tool that has been tested by itself following the definition given in the book The Art of Software Testing (G.J. Meyers, John Wiley & Sons, 1979): "Testing is the process of executing a program with the intent of finding errors."
Embedded Software Testing
Developing embedded systems requires an understanding of electronics engineering and how to use an electronics test bench. Fluxica Peregrine approaches software testing as in-circuit hardware testing, which differs from the tendency in common software engineering approaches to abstract away the details that define embedded software development. As set out in the book An Embedded Software Primer (D.E. Simon, Addison-Wesley, 2004), a software engineer may write applications without learning anything about the hardware, but an embedded systems software engineer has to understand the hardware in a fundamental manner to write correct software. Software and hardware is tightly coupled in embedded system development, explaining why Fluxica Peregrine allows for a hands-on workbench approach towards software testing.
Software Product Line
The Peregrine testing tool has at its core a software product line architecture that defines both the functionality that is shared and the functionality that is not shared across the Peregrine product line. The main benefit of a software product line is increased product quality through better control of product complexity. A software product line architecture fits an iterative software engineering approach with a focus on continuous development and deployment. Especially the series of Software Product Line Conferences (SPLC) have made the concept of software product line engineering available to a wider audience.
BAPO
As Fluxica Peregrine is a software testing tool, its goal is to solve development problems in (embedded) software product development. It is developed and maintained according to the BAPO model (first Business then Architecture and Process and finally Organization) for developing software systems. BAPO is a proven and successful approach in industry and starts by asking what problem to solve and why. All the rest follows from this question. The BAPO model has its roots in embedded system development and was first documented in the research paper Software Product Family Evaluation (F. van der Linden et al., 5th International Workshop on Software Product Family Engineering, Siena, Italy, pp. 352-369, 2003).
Understanding Test Engineering
Developing a software testing tool requires understanding the requirements for successful testing of (embedded) software and how to properly implement these requirements. For example, the Peregrine testing program is able to generate (pseudo-)random Peregrine Test Probes on-the-fly and inject them into the program under test at high speed in real-time while both programs run in parallel. To make such performance possible, one of the requirements for the Peregrine program is to generate test probes faster than a typical program under test will process them. This requirement is met by ensuring that the of the core testing algorithm is not just constant, but a minimum constant as well. Understanding how to define and implement such requirements is at the heart of developing easy to use and relevant test engineering tools.
