How can software testing help you design better software?

Think of software testing like baking a cake for a picky eater (your user). User stories and acceptance criteria are like the recipe and the list of ingredients – they guide you on what to bake and how it should taste. Test cases? They're like taste tests at different baking stages. You want to ensure the cake (software) is sweet but not too sugary, fluffy but not airy – essentially, just right for your eater's (user's) specific taste. By doing this, you avoid the all-too-common baking blunder – a beautiful cake that no one wants to eat because it tastes like salt instead of sugar!

Software testing plays a crucial role in designing better software by identifying defects early in the development process. Through testing, you can ensure that the software meets requirements, functions as intended, and is reliable. It helps uncover design flaws, improves code quality, and ultimately leads to a more robust and user-friendly end product.

Not long ago, we implemented Unit Tests in SAP S/4HANA aimed at establishing a robust foundation for regression testing. This approach also offered an added advantage: Consultants and Developers gained a deeper understanding of the requirements. Unit Test development shifted focus towards more thoughtful solution design, which, in my experience, led to an increase in 'first time right' developments and a reduction in incidents during User Acceptance Testing (UAT).

It is also vital to know your audience. The users may have assumed certain functionality will be included. This could include but not be limited to 2FA, reporting and auditing features. This is particularly true for enterprise users and these assumptions need to be identified early

"Software testing defines requirements"? That is just plain nonsense. The requirements define what to do. User stories are an abstract bla-bla for not-so-tech developers to understand what to do. Acceptance criteria give the even more non-tech PO an idea how to check whether it is done. What testing has to do with all of that ... depends on the type of testing meant here. Manually, from a user perspective? So that the UI behaves correctly? Yeah then maybe. That gives 0 information on whether the implementation is correct, has side effect and so on. "[...] ensure ... meets expectations", again, depends on your focus - on the surface or technically.

One critical aspect I've observed is the importance of writing testable code. By structuring objects in a way that facilitates testing, we not only streamline the testing process but also ensure the code's long-term maintainability and extensibility. Interestingly, simply focusing on writing testable code can yield significant benefits, ensuring reliability and adaptability of the code over time, even if the actual unit tests aren't written.

"Meets the requirements", that is usually not enough, "meets the requirements, has no side effect, does not harm anything, does not cause data loss, does not open security holes, has an acceptable performance and scales well if required, ...". The type of testing applied depends on the type of work performed.

As an SAP Specialist, I find the concept of automated testing particularly intriguing. While we may be entering this space later than other industries, the capability to automatically execute all unit tests with each line change is remarkable. Additionally, the use of automated user regression testing helps to verify critical processes will still work for upcoming releases. However, it's important to acknowledge that these innovations require investments. In my opinion, the additional cost makes it challenging to justify their implementation, despite the potential benefits.

Security testing such as SAST, SCA and DAST testing also needs to be a focus during the process. Leaving these tests till the end will result is delays and frustration both for the users and the developers

Be careful on the super-hyped TDD. For those who don't know that, it basically swaps the order of writing code and writing test (TDD = write test first). The claim is that this improves "quality" because the test will for sure be there. I disagree and I don't like it. While TDD solves a (trivial) discipline problem, it drastically raises the chance for side effects as while writing the test, possible glitches affecting not-so-clearly-affected parts of the program cannot be seen upfront. So a "correct" cycle in the sense of minimizin sideeffect risk would be write test-write code-fix test. Which does not sound very efficient. Not everything that is hyped and "new" is a good idea.