Pair Specification as a further step to improve our development process
At VAIVA we develop embedded software and have to comply with various standards such as ASPICE, ISO26262 and KGAS (VW guideline). All these standards require a more or less high degree of independence for the role of the software tester. This means that the tester must not be the creator of the software (the test object). Therefore, we now use a new method, the Pair Specification, where the software developer is paired with the associated software tester. Both roles form a pair and create the software unit specification together in the future.
Current situation
Currently, according to our development process (APM), the software developers are responsible for creating the software unit specification. This specification describes the behavior as well as the solution approach for a single software unit. This procedure currently leads to delays in our projects, since, among other things, it is only discovered very late in the review by the tester that the unit is not testable as specified. Also, a lot of resources are needed for the reviews.
All these problems also lead to a delay in the start of the tests and the developers only receive feedback about possible errors in the software unit at a late stage.
Motivation
In addition to the above-mentioned problems in classic software development, the topic of agile development will come up in the future. In the future, many of our new projects will be carried out using agile processes and methods. An important principle in agile development is that developers get timely feedback on their implementations. For this purpose, agile processes rely on methods such as Test Driven Development. In this method, the software developer first creates his test cases and then implements the software. In this way, the developer gets immediate feedback on whether his implementation has software errors.
Question
This confronts the process development team at VAIVA with the question: How can we use agile methods and also solve our current problems and still meet the requirements from the standards for the independence of testers on the other hand?
Solution approach
The model for our new specification method is the Pair Programming method.
The new method we use is called Pair Specification. Here, the software developer, who is responsible for creating the software unit specification, is paired with the associated software tester, who is responsible for verifying the unit accordingly. The two roles form a pair and create the software unit specification in the future together. The principle is identical to the procedure of pair programming. Here the software developer takes over the role of the pilot and the Softaretester the role of the navigator. Both sit together before the PC and provide together the software unit specification. While the pilot creates the specification, the navigator tests it in parallel. In this way, the specification is created and reviewed in one step. A special review protocol with associated checklist questions was created for this purpose. Since the software tester is involved in the creation, it is ensured that the specification is also testable at the end.
Another advantage of this method is that implementation and software unit test creation can now start in parallel. Thus the test results are available much earlier and thus the developer gets now prompt feedback to its implementation.
The requirement of the independence of the software tester is further ensured in this way, since this is directly involved only as Reviewer with the specification. The implementation of the software is further independently made by the software developer, here the software tester is not involved.
It is still to be considered that if the components which can be developed has an ASIL classification after ISO26262, depending upon ASIL, at a defined time a formal inspection must be accomplished.
Summary
In summary, we can say that the Pair Specification method has contributed another step to the improvement of our development process (APM). We have achieved the following successes:
- The review effort has been reduced
- It is ensured that our software unit specifications are testable
- Earlier availability of test results and thus timely feedback for the software developers.
by Stefanie