Software Development for Infrastructure

The concept of how software is developed has changed significantly over time. In the past, it followed the waterfall methodology, which involved moving sequentially from one phase to another. Developers started with a very detailed design and only began testing at the end of the process. However, it was eventually discovered that this way of developing software never resulted in something that an end customer truly wanted. Additionally, these processes tooka lot of time.

This realization gave rise to the agile movement. By keeping the scope as small as possible and focusing on what an end customer really wants, a small part can be built first and then expanded upon. Today, we develop increasingly complex software starting from an initial building block. Two essential techniques for creating well-functioning software are Test Driven Development (TDD) – where developers start by developing small units of software – and the Behaviour Driven Development (BDD) approach. In Behaviour Driven Development, it begins with defining the requirements in a language that is readable for stakeholders.

This presents quite a challenge. When you develop software, you write it as logic. Everything becomes an explicit choice: where something should appear on the screen or which values may be entered in a field and where. By clearly establishing this beforehand, the BDD approach enables better collaboration and communication among all project stakeholders.

“It leads to more automation, with quality assurance moved as far forward as possible”

Shift-Left

The BDD approach has also greatly impacted the testing process. Development cycles are shorter, necessitating new tools to ensure quality. Testing is essential to ensure that the software works correctly. While we develop more complex software for complex problems, such as automating processes in IT infrastructure, people have the same expectations as they have for regular applications: that it just works all the time. However, in a complex environment, this is often more complicated. After all, it remains human work.

The BDD approach makes it possible to effectively shift the testing process to the left, known as shift-left testing. This approach means testing begins earlier in the product development lifecycle. It leads to more automation, with quality assurance moved as far forward as possible. As a result, defects are discovered and resolved at an earlier stage by working in parallel with the development team. It also prevents data loss and brings security and compliance considerations forward. This is good news because the later in the process re-work is needed or incidents occur, the more expensive a project becomes.

Therefore, testing does not only take place at the end of the development process (unit tests) but also during code writing (code reviews) and at many other points in the delivery process. This includes integration tests, load tests, acceptance tests, tests for specific user groups, or security tests. For instance, all our code is tested by Securify. They check the code for security aspects and analyze which part of the code poses the greatest risk when changes are made.

Language

The most important aspect of BDD (Behaviour Driven Development) is that it uses a common language based on simple and structured sentences. For testing, this means describing what output you expect when you know the input provided. Our stakeholders are usually IT architects. When a feature is proposed, they need to understand how it will be tested. If they can read and comprehend the test, they can provide input and confirm if it indeed meets their requirements.

We follow a very structured approach in our projects. For example, we built a private cloud platform for a client where two different organizational units operate on the same hardware in the data center but must remain strictly separated virtually. To enable access to this environment for the client, a service portal was developed using a standard VMware product, enhanced with various functionalities from other suppliers. Our software allows these applications to exchange messages with each other.

To gain control and test this setup, you need to know how to write requirements properly. These requirements are written within a framework, as you need strict boundaries, which can be divided into three phases: business value, acceptance criteria, and non-functional requirements. Writing the functional requirements starts with breaking down three key components. Why are you building something, what is the value and context, what are you building it for (what should it do?), and for whom? This looks like: As a [role], I want [feature], so that [benefit].

"Besides functional requirements, there are also non-functional requirements, as there is a whole world beyond the functional aspects"

Testing

In the next phase, we then establish acceptance criteria on how each step should be executed. Given this situation, if this happens, then this outcome should result. Besides functional requirements, there are also non-functional requirements, as there is a whole world beyond the functional aspects. We examine how much impact certain events have on performance, whether there are potential scaling issues, and what the client expects from us.

Only then can we begin testing. In this case, four layers of testing can be distinguished: unit tests, integration tests, system tests, and end-to-end tests. Testing starts at the functional level, then moves to the integration level because all the small pieces of software must function together. This is fully automated. After system tests, we finally reach the end-to-end tests. This is the essence of Behaviour Driven Design: when everything is combined and connected, what should it ultimately do for the client?

Besides running all the tests, several other tasks need to be completed before a piece of functionality can be declared truly finished. For this, we use the Definition of Done checklist.

Result

The advantage of this method over only written documentation is that by executing the tests, you can verify if the documentation is accurate. Additionally, we can provide the client with a dashboard and reporting. When we roll out the entire test suite, they can see where any bugs have been identified or how long the tests took. This ensures transparency. The essence of testing is to prove and demonstrate that what we have developed meets the requirements.

All the preceding steps impact the final product to be delivered. The key to success is ensuring that when creating and testing software, you check beforehand if you are speaking the same language.