The proof of the pudding is in the…testing

May 14, 2024

Our pilot with reverse designing is now well advanced. After weeks of building, we enter the stabilization phase. To be honest: it is never our favourite phase. The development phase offers room for creativity, discovery and trying out new technology, the satisfaction of creation. Although – as we also shared in our previous blog – we experienced more pressure towards the end of the build phase than in a traditional development process, the build phase is always very energizing too. The stabilization phase is less scintillating and always follows a set roadmap at Rulecube.

Scalability and speed

Our first step in the stabilization phase is to check whether our application is still performing as it should. That is to say: even under high load and when processing large volumes of data. The load benchmark test was therefore completed early on. Because if our code is not fast enough, even at high volumes, we are not living up to our core promise and need to make adjustments. Fortunately, the new release passed this test at an early stage with flying colours.

Quality code

The second step is code quality testing. For this, we use Sonar Cloud, among others.  . This service checks all our source code for readability, consistency, quality and security, and helps ensure our quality standard. Code quality is comparable to the quality of any text. A text may be readable, but the punctuation may be missing. Brackets are opened, for example, but never closed. Or sentences are a bit long, making them harder to read by someone else. Clean code contains no unnecessary information and is neatly ordered. This keeps the software fast and easy to maintain.

We also test the security and vulnerabilities of both our platform and the packages in which we make our products available to customers. Third-party software components that we use for that purpose are also part of this.

Regression testing

Finally, we test the application itself. We also do this almost entirely automatically. Using systems such as Cypress, we test whether the use of the application when we enter the test cases has remained the same as previous versions, so-called regression tests. With completely new functionality, most attention goes to developing test cases for that functionality. That’s where we do see a big difference this time through our reverse designing process: in fact, our test cases are already in place. Our active customer cases are the ideal cases for the test run. With them, you touch all the scenarios you will encounter in practice. No self-made case can compete with that. It takes some effort to write the tests, but the content is already known.

Manual testing is minimal. About 90% of our regression testing is automated. By incorporating customer cases directly into our automated tests, we keep that percentage high.

Fortunately, we encounter few surprises. With such a large amount of new functionality, stabilisation can be a lot of and especially tedious work, but fortunately we are spared that.

Read more