The “Tester Teatime” is a post format on this blog, in which topics are taken up that testers deal with on a daily basis. Certain problems or themes recur again and again, so we want to create a basis for explaining such phenomena and finding solutions to them. Discussions and new ways of thinking are also to be stimulated. In testing, we can learn a lot from each other by observing our daily lives!
Moderator: Welcome to the first tester teatime! In an interview with testers from ZEISS Digital Innovation (ZDI), we will discuss exciting topics.
Let us now turn to today’s subject. We talk to Sandra Wolf (SW), tester at ZDI. What is the myth of “historical growth” all about?
SW: Well-versed testers will probably roll their eyes in the title of the article unwittingly. Because what sounds so steeped in history here is for many one of the most common answers that cross their paths in everyday work. As soon as a deviation is found in the software that cannot or should not be corrected immediately, this phrase is very popular. Examples of such deviations are poor user-friendliness and a constant inconsistency in the software to be tested. If the testers draw attention to an improvement here, they will be glad to receive the answer from team members from the areas of development, project management, etc. that this particular abnormality has grown so historically and that there is therefore no need for action. Often, the quality-driven testers are left puzzled and frustrated – after all, they are not shown any perspective for action in the sense of their role. What, then, is the meaning of the phrase “historical growth”? And how can this be handled professionally and effectively? That’s what this is about.
Moderator: Okay, that sounds interesting. What effects does this so-called “historical growth” have on the project and its software?
SW: Many project participants are not aware of the importance of the problem. The “historical growth” is an avoidance, because in fact it hides the fear of a renewal of the respective software, which, however, inevitably moves closer with further ignorance. Especially the software components that have been expanded over the years develop more and more interactions, which means that the maintenance effort and the maintenance costs continue to rise. The different extensions may no longer fit together, have neither a uniform operation nor a uniform design. The quality of the software thus decreases congruently to customer satisfaction. At this point, innovative further development becomes increasingly difficult or no longer exists at all. Looking at all these facts, it quickly becomes clear that “historical growth” goes beyond mere words and can have serious consequences for the company, project, and software itself. Something must therefore be done here and a rethink must take place.
Moderator: How can the project challenge “historical growth”?
SW: The fear of many project members about “historical growth” is that the only way to solve this problem is by stomping software and re-build it completely. That this seldom makes sense, however, is something everyone can imagine. A complete renewal of software would also be very costly. The question now arises as to how this problem can be solved. Here I would like to point out that the task of the tester is not to eliminate or control the “historical growth” itself. As testers, we can only provide the impetus for change and should definitely do so, as we act as an important interface between development, technical department and project management. Our perspective on the whole process is worth gold here. We have a comprehensive overview of all steps of the process, as we act at the end of it.
Moderator: What might a solution for “historical growth” look like?
SW: Given this wide-ranging problem, it is advisable to advance the solution in smaller steps first. First of all, contact should be sought with a suitable contact person, e. g. the project manager, since a tester can never decide on such overarching project topics. In conversation with this person, attention can then be drawn to the consequences and risks of “historical growth”. The next step should then be defined jointly by the entire team. Perhaps it is not necessary to renew the entire software, but rather to limit it to certain parts of the application. Here, too, testers can contribute important knowledge from their daily lives. The development of the entire project must be considered and also which sub-areas arose first. The aim of the discussion is to draw attention to the problem and thus to provide the impetus for changes to restore the quality of the software. The form in which this happens – also by external companies, for example – must also be decided. For us as testers, however, this is an opportunity to contribute to the overall quality of the software to be tested. After all, the most important thing is that the very far-reaching theme of “historical growth” is no longer used as an excuse, but is finally placed in the project.
Moderator: A solution can only be found together. In this context, we are also interested in the perspective of a developer. We now talk to Hendrik Lösch (HL), software architect at ZDI. What solutions do you see for “historical growth”?
HL: I myself would not call it “historical growth”, because that implies that growth is in the past. I prefer to speak generally of “software evolution”. Because growth is always there, it only becomes problematic when the structures of the software mutate unintentionally. We also refer to these mutations as technical debts because they require future investments in restructuring and thus tie up funds that cannot be used for value-added measures. The longer you delay these restructurings, the harder they will be to carry out. This is probably where the “historical growth” comes from. It has grown over time and no one knows exactly why anymore. To solve this problem, a thorough analysis of the structures is required, in which experienced software architects determine the actual architecture. A target architecture is then created and a path is sketched to get from one to the other. With the Health Check, we as ZDI offer a suitable procedure.
Moderator: Thank you, Sandra and Hendrik for your insightful presentations. So, we can sum up that the problem of “historical growth” is more of a myth. Growth is always there, but the lack of structure can make it problematic. However, this requires not only action, but also concrete strategies to deal with it. ZDI itself already offers them in its portfolio today.
In the following articles, we will take up further problems from the everyday life of testers and discuss possible solutions.
This post was written by:
