Formal Test Approach
A formal test consists of running the CCS or TSC according to a documented test procedure, and recording the result in a test report, which we keep. To be released (appear on this web site), the software must pass these formal tests. The tests are largely automated, and are very thorough for monitoring, control and automation features. User interfaces are tested only insofar as they are used or explicitly tested.
The test documentation is "inspired by" the ESA ECSS-E-ST-40 standard for software engineering processes and covers 80% to 90% of the CCS requirements for most missions.
Test and Release Frequency
We aim to formally test both CCS and TSC at least once per 3 months, or as required by specific projects and contracts.
CCS and TSC are automated test systems and so naturally they are used for their own self-tests. We run the bulk of our tests automatically every night as part of the build process for all platforms. These do not require human interaction. If one of these tests fails, we find out about it the next day. A formal test is not started if there has been any problem with the automated test.
Nevertheless the formal test includes both the automated and user interaction; our formally run tests are executed and recorded by a human operator.
Supported Platforms for CCS5 and uNIS
CCS5 and uNIS are 64-bit applications that can run on Windows and Linux.
Officially supported Windows versions are Windows 10 and Windows Server 2012 (x64). Different projects are successfully using a variety of different versions (including Windows Server 2008, 2012, Windows 7 and Windows 8).
Officially supported Linux distributions are RHEL/CentOS and OpenSUSE. End-of-support policy of our products follows the end-of-life timelines of respective platforms. Therefore, please refer to this link for planned EoL of OpenSUSE Leap releases, and to this link for RHEL/CentOS.
For example, at the time of writing the oldest supported Linux releases are OpenSUSE Leap 42.3 and RHEL/CentOS 7.4.
CCS5 relies on an RDBMS installation as well. Supported databases are MySQL/MariaDB 5.5 onwards and PostgreSQL 9.2 onwards. When using MySQL version >=8, you may need to configure your server to accept legacy authentication methods.
Supported Platforms for TSC
TSC is supported on the same operating systems as CCS5, and it is provided as a 64-bit application. In addition, we provide 32-bit builds of TSC on Windows for compatibility with the CMDVS(1) data-source plugin. However, for new projects we advise to use the 64-bit version.
Windows XP is no longer supported.
Daily BuildThe daily build is, as the name suggests, an installer that has been built overnight from our configuration control most recent check-ins. We use it during our testing to confirm informally that a new feature is working or a bug is fixed. Our developers perform tests on their changes in a debug environment before checking in, so these builds are usually (but not guaranteed) stable. We use them to confirm that our changes still work in the release packaging that would be installed by a customer. They can be used if you need to check quickly whether we have successfully implemented a change or bug fix for you. The daily builds are automatically tested as far as possible without a user interface.
Note that we certainly do not recommend using such a release for flight operations or a critical test.