Where is actually the quality of a software to be found?
The short answer:
It is only partly in the source code. Rather, the quality of a software is characterized by its technical qualification. Software testing can prove and improve this quality. You can read the detailed answer here.
One focus of my work is to develop test strategies in order to be able to test software in the most resource-efficient and targeted way. I claim that the quality of a software is only partly to be found in the software itself and can therefore only be increased to a limited extent by testing. So what is the point of all this?
What baking bread can tell us about the quality of software.
As an amateur baker, I sometimes work on a loaf of bread for days. To get a perfect bread, it is important to know the processes of creation. If I understand the processes, for example the proofing, I can use them correctly. In addition, I need good ingredients and tools that work.
Which part - process, ingredients or tools - is most critical?
The best ingredients and the best tools are no good if I don't know what to do with them.
With software, this means that I need to understand first and foremost what the software is supposed to do. Then technology and tools are secondary.
The tiresome but important topic of requirements.
Who doesn't know:
"If the requirements were known, then..."
"If the requirements were user stories, then..."
"If the requirements were complete, then ..."
Having requirements is important, but reality often looks different.
Software solutions have often been developed over years. What the software is supposed to do is already in the source code and has been coded by very experienced and very dedicated software developers:inside. Separating this built-in expertise from the source code is almost as impossible as separating the egg white from the yolk after it has been whisked.
But without this expertise, developers cannot significantly improve the software. Parts are deleted and functions are rewritten without keeping track of all the interrelationships, which leads to ever new error effects and ultimately drives up the testing effort. The costs for testing are disproportionate to the added value generated.
Agile development methods therefore focus on the requirements of a software. In the SCRUM method, we talk about business value, i.e. the feature that can be sold.
A feature is assigned user stories that contain the business value.
To justify the business value of a feature or user story, it is not only important to know what the software is supposed to solve, but also why.
While the expertise was built into the source code, the "why" escaped without leaving a trace.
Strict structures in requirements harbor problems.
If I am a manufacturer, for example of calculators, I build in various functions or features (addition, subtraction, etc.).
With the user story I then tell what the customer can do with it: I as a user can correctly calculate the term 5+3-8.
The customer pays for the features, and the user stories should show him what they can do with these features.
But if I specialize in developing custom software, the features are not the focus. Customers talk about their requirements: for example, they want to be able to correctly calculate the term 5+3-8. My job is then to identify the underlying requirements and derive the appropriate requirements from them. The customer does not pay for features, but for the user story.
This simple example shows that the rigid hierarchy of requirements can lead to problems depending on the application.
However, this should not prevent us from developing good quality software.
It is crucial that I know what the customer is paying for (feature or user story). Then I capture the requirements in a precise and machine-interpretable way, so that any toolchain can support me increasingly and in the long term.
What about the requirements?
We should stop talking about requirements. Requirements sound like contractually guaranteed services, like a waterfall, like a precautionary safeguard in case something goes wrong.
Years ago, during the development of a new software for a fully automatic coffee machine, I experienced that formulated requirements alone do not lead to quality.
We had the order to rewrite the software for a fully automatic machine. Because the existing software was very complicated (a source code written over the years by Expert:innen), it was decided to rewrite the source code. The resulting source code was much leaner, more efficient and clearer. It was intensively tested and complied with all good principles of good software quality. Only: It did not work. Nobody had thought about the fact that it makes a difference for the coffee temperature whether you make one or several espressos in a row. Nobody had considered this, because we lacked the appropriate expertise. We adapted the source code. The resulting software worked, but was again so complicated that no one understood it except the developers who wrote it.
With the necessary expertise of the customer, we would have identified the right requirements and thus achieved the goal at the first attempt.
From such examples from my professional everyday life I conclude that the professional competence of the customer is the decisive factor for the success of a software product or software project.
And where is the quality of a software now?
A good testing strategy should aim to test as much as necessary, to ensure the technical qualification of the software and to prepare the quality of the source code for resource-saving management.
To produce a high quality source code is demanding. But for this there is a lot of experience in the form of patterns, tools, guidelines, concepts and much more.
When it comes to expertise in relation to the task to be solved, things are more difficult. How do you measure professional competence and what does it depend on?
In my opinion, this is exactly where the quality of a software is hidden.
A qualitatively good software serves the subject, independent of the implementation, it saves resources during development and maintenance and can be ported to new platforms without technical problems.
The knowledge and experience of a company, its products and services lie in its expertise. Not in the source code. This added value of a company cannot be replaced by conventional software, it belongs to the intellectual property of a company.
The goal of a company should therefore be to capture its expertise independently of the implementation, precisely and automatically readable and usable. This should be done in a form that can be used directly for technical tests without media discontinuity.
There are many approaches, products and methods for modeling processes, mapping expertise in databases and describing expertise in specialized languages.
It should be the primary goal of a company to map its expertise in its own language so that it can be used directly again and again during development.
With suitable tools, the captured expertise can be used directly for testing, without media discontinuity. Changes in the requirements thus find their way directly into the development and ultimately help to keep the quality of the software high.
The test strategy should ensure that the software reflects this expertise and that the associated source code enables resource-efficient and sustainable management.