What we do
The tests are often arranged in campaigns, which means that before each software release, we need to repeat the same tests or perform their updated version.
If you give us product specification, we will create a test plan. Or you can provide us with a test plan for review and test performance.
Technologies and Tools
In static code check, we utilize Clang or Lint-based tools; in some other cases, it is sensible to use built-in checks within the IDE, like Visual Studio.
Regarding unit tests, we always use the tools suitable for a specific programming language – some languages have built-in unit test support, and some need to import special testing libraries.
When performing feature tests, we often combine automated and semi-automated test setups, especially for tests with HMI interfaces.
Almost all market segments, which utilize software, need software testing.
We develop and perform software tests for medical devices with very strict safety standards – corresponding to the high value of life and health.
Another segment is emergency communication systems, where we usually test embedded software – often developed on our own.
We have also developed embedded software for the measurement instruments, where we planned, designed, and performed the tests as well.
Our Typical Workflow
We make a test plan based on the specification of the system.
The second option is to get a test plan from the customer. This happens usually in case a customer comes with their product during a late stage of development.
We implement the tests in one of the programming languages. Scripting languages are mostly preferred but compiled languages can be used as well.
Test report is an important output of the test implementation. We include all the test conditions and details (test date and time, device under test ID, configuration details, parametric settings, ambient temperature etc.).
During the last step we make a review together with the customer and ask for their feedback.
Our current software testing activities come from the projects which we did in the last few years.
We started with the software-defined radios (SDR) where we tested the behavior of the configuration and control interfaces. Later, we continued with another radio project. In that case, we tested our part of the job – a hardware abstraction layer. We cross-checked if the control of hardware exactly corresponded to the interface control description document.
Sample of implemented projects:
Please leave us your contact details so that we can get in touch with you.
We will get back to you via e-mail as soon as possible to discuss our cooperation opportunities on your project acceleration.
* Required fields are marked with an asterisk.