Written by Red Hat’s Luigi Pellecchia, Senior Software Quality Engineer, and Gabriele Paoloni, Senior Principal Engineer
Introduction
Most of the safety standards across different industry domains are based on requirements definition and associated verification and validation measures to bring the residual risk of failure down to an acceptable level (according to the target safety integrity level). When it comes to claim the systematic capability of SW elements, it is very important to trace requirements down to the specification of such SW elements and to respective tests at different levels (unit tests, integration tests, validation tests).
There are different reasons behind this:
- Verification of completeness of safety activities: once we have full traceability in place from requirements to testing, it is much easier to detect if there is a gap between safety requirements, SW specifications and tests.
- Assessment feasibility: with traceability in place it is easier to verify the correctness of tests against associated requirements and code specifications.
- Maintainability of the safety case against incoming SW changes: if there are SW commits added later, with such traceability in place it is easier to determine the scope of requirements being impacted.
- Scalability of the safety case: if there are requirements to be added / removed, with such traceability in place it is much easier to determine the impact on the rest of the safety case (i.e. which code and associated tests to be added or removed)
Complying to safety standards imply a great effort for quality departments.
Quality Engineers have to produce different work items, like Software Requirements, Test Specifications, Test Cases, Test Reports and need to provide evidence and traceability for internal and/or external audits.
Usually that happens across a complex toolchain that involves several tools, and different file formats.
Having the data organized in a structured way helps to keep the situation under control and enables a proper data visualization for the most meaningful picture at any time.
BASIL provides a way to create quality related work items and to relate them to a snippet of the specification document or to a snippet of the source code creating a view that will help you keep track of the status of the analysis.
A snippet is identified in BASIL with an offset and a text. That is because we can have the same text multiple times in a document and we need to be able to distinguish which one we want to use.
When creating a work item and a relationship against a snippet of the target document, the latter will be split in different sections showing the related work items in a 2 columns view.
Work items can be nested in different ways and BASIL provides different views focused on work items with direct mapping against the specification document or source code.
That is because any company can implement its own workflow and define which work items want to create and maintain.
So we can distinguish two different types of relationships in BASIL: direct and indirect.
Direct means the relationship is against the specification document or to the source code.
Indirect means that a work item is related to another work item and the relationship with the specification document or to the source code happens via an hierarchy of work items more less complex.
Each relationship, direct or indirect, will be characterized by a coverage percentage and the overall coverage will take care of all the work item hierarchy that users can specify.
BASIL can be easily integrated in other tool chains thanks to SPDX and a REST api.
All the data can be exported to SPDX in json format and it is possible to interact with the data via http requests as well.
Even if this level of traceability is mostly requested by Functional Safety projects, any software company can leverage BASIL to implement software quality management.
Software, its Specifications and work items are in continuous evolution and BASIL keeps track of this.
So any changes to any work items or relationship will be recorded in the database and it will be possible to see the history of each one.
What happens if the source code or the specification change?
First of all we can test in advance how our work items are affected by any change and we can automatically fix what the tool recognizes as a warning.
A warning means that a particular snippet still exists in the target document or source code, however it does in a different position (offset). We can set BASIL to automatically fix all these warnings.
If a new version of the specification document or of the source code breaks any relationships, BASIL will show them in a separate section and we can adjust the mapping or delete it if no more needed.
BASIL was created to be a collaborative tool and due to that it comes as a web application and It provides also support for comments.
BASIL was developed by Red Hat during the first stages of RHIVOS (Red Hat In Vehicle Operating System) certification story and was presented to the Elisa community in June 2023 during the workshop we had in Berlin. Thanks to the interest of the community we published it as an open source project in the Elisa GitHub repository in October 2023.
Started as a static html report of test mapping software components, it became little by little a dynamic tool that today implements state of art web technologies like REACT and PatternFly and it also comes with an e2e test suite in Cypress and a unit test suite for the REST api written in python.
Learn more:
- GitHub: https://github.com/elisa-tech/BASIL
- Documentation: https://basil-the-fusa-spice.readthedocs.io/en/latest/
- Video: https://elisa.tech/blog/2023/10/04/introducing-basil-video/
