Testing in the digital transformation 

 May 1, 2019

Like it?

Who remembers how our grandparents worked? What will our grandchildren learn about our work? Will they want to know how it was still possible to work in permanently assigned offices and why collaboration across different continents was a challenge?

We have dealt with these and other questions and gained many authors who have also thought about this. The defining theme in this issue is the digital transformation towards Industry 4.0: It is about quality assurance in internationally networked, borderless companies and their requirements for modern development projects: faster, more agile and with usable interim results. How good does the quality have to be at which point in time? And how do we ensure that quality assurance measures also scale with project complexity? How do recurring questions of test fficiency increase fit with the architecture patterns used or with development approaches such as the agile approach?

Traveling ...

Richie has just returned from Silicon Valley. Packed with new ideas, inspiration and humility before what is currently developing there. We had a long chat about his insights into the start-ups and companies based there and what challenges the new technologies, working methods and systems pose for software testing and quality.

Given the changes that are coming to many traditional industries, the term "Digitalization" almost sounds a bit cute - the changes are likely to be disruptive, opening up new areas of business and making others disappear. In some industries, people still lull themselves into a deluded hope that this chalice of change will pass them by. Some see concerns and problems while already being overtaken left and right. And still others see opportunity and are embracing the potential that software and data already offer today. Whether the latter deal with artificial intelligence, autonomous systems, predictive techniques, or augmented reality: Our core topic of software quality is highly affected.

Large becomes complex

Recent decades have been characterized by systems getting bigger and bigger. Processes, procedures, and tools were created to make this manageable. More and more optimizations (e.g., test centers), improvements (e.g., more efficient workflows, better tools), more automation (e.g., test automation at all test levels) have helped us to enable efficient quality assurance for large systems as well.

But large systems are being replaced by complex systems. The dependencies, relationships, and algorithms inherent in them are becoming increasingly difficult to grasp and comprehend. Nevertheless, they must be quality assured, i.e. at least verified and usually also tested. We are increasingly seeing ways of adapting to this change: process models are being designed in such a way that efficient and rapid quality assurance is still possible; architectures for systems are being designed in such a way that understanding of encapsulated units is possible and focused quality assurance is feasible.

Processes and architecture enable test fficiency

The typical means of increasing efficiency is the use of automation. For testing, this means automatic test execution in the first step. The advantages are obvious: fast execution, fast feedback, especially for regression testing. Only the preparation of the associated test scripts requires significant effort when they are created or adapted.

But how do we manage to apply this process in changing environments? Häufige changes are to be found in agile development processes. During each sprint, one needs automatically executable test scripts that assess the functional quality of the system. These test scripts would also need to be adapted quickly because of the likely changes in the current sprint. However, a manual adaptation of a significant part of the test scripts per sprint is only feasible at high cost for every non-trivial and change-prone project.

Should we give up on automated testing because of this? Not at all. Instead, we need to find ways to reduce the customization effort for test scripts. This finds itself, as we know, in approaches of data-driven, keyword-driven, or model-based test design techniques. Moreover, quality assurance is no longer just a task of the tester at the end of the process chain. Rather, implementing the necessary tests is as much a part of development as writing and checking in the source code itself.

The next exciting question is how we can maintain the focus of the individual tests. How can Einflüsse from other functions be reduced to the actual function under test? This is where the architecture used plays an important role. Small, interchangeable units find intensive application in the architectural approach to microservices: Each microservice has its own tests; each microservice is independent of others and communication is defined only through interfaces; each microservice is focused on a specific customer benefit.

Small teams, clear architecture, focused tests, customer benefits in the foreground: all these advantages can result from the wise choice of the architectures, processes and test approaches used. We have highlighted microservices, agile and test automation as examples here, which in this combination keep even complex projects maintainable, testable and understandable. Here, testing efforts remain reasonable, the testing focus remains on customer benefits, and the scalability of quality assurance is given with the complexity of the system being developed. The poster Efficienzsteigerung im Softwaretest (Increasing Efficiency in Software Testing) provides an example of the interrelationships. Figure 1 shows the rough structure of the poster and the depicted relationships.

Quality as an attitude in the team

In addition to the technical factors mentioned above, the soft factors are invaluable. If you want to create excellent software today, you have to think holistically about the development process: in addition to methods and tools, above all people and mindset - if everything works together in a flow, then potential development and innovation arise. Quality is ensured by the team. Quality assurance becomes a comprehensive task, supported by the attitude of the entire team.

For many team members, this means a massive change process that requires experience, empathy, dedication and patience. A workshop or a training course is not enough. Accompanying support, impulses, and assistance are needed so that a team can find its own individual way to live agile values such as courage, transparency, openness, and self-organization. The attitude of the team members to the project and to the chosen process makes a decisive contribution to the success or failure of any project!

Of course, a sound training is the basis on which such a change process must be based. Speaking the same "language", mastering the quality tools, understanding and being able to apply the methods and procedures: For the field of software testing, the Certified Tester scheme delivers exactly that as the world's leading in-service training scheme on the subject of SW quality. (www.german-testing-board.info)

In addition to the factors that support the success of the development project, there are numerous other factors that determine the success of the developed product.

Usability: Don't make me ...

The acceptance of a product, an app or software is increasingly based on the usability and the experience of the user, the happening. And this no longer only concerns private users. The demand for software used in business is also increasing: If employees have to spend several hours a day dealing with slow, overloaded, and complicated Oberflächen, frustration is inevitable. Start-ups take their cue from these pain points and resolve them. In the process, three major guidelines can be observed again and again:

  • Don't make me wait: Nobody wants to wait for anything anymore. Real-time availability counts. Loading bars, queuing and waiting are a knockout criterion.
  • Don't make me ask: Every question stops you. The system knows me, has my data. Then asking again is a no-go!
  • Don't make me think: Take the thinking out of it! Anyone who sits in front of an Oberfläche or website and first has to think about how what works where and why is quickly inclined to click on the "x", or at least they won't empfind any rampant joy in using it. We are spoiled by apps & co. You clicked here? Then perhaps you would also like this and that ...

These aspects usually concern not only individual components, but complete processes of the user. Does the tester have the right to question the business processes at all? Of course! Especially his critical view is required here. How can the application be made easier? What can be taken away from the user? Do we still need function X and Y? Which old habits (e.g. interfaces, special bells, modules) can be cut off? What "historically grown" can be rethought?

What's next?

What do we do now with the impressions of Richie's trip? We live in exciting times. Technologically, and especially with current software, there are possibilities available to us in the next few years that we probably can't yet imagine or don't want to believe.

Autonomous driving is a good example: What is often countered in this country with extensive reservations and auflagen has already reached quite different dimensions in other countries. Anyone walking through the streets of San Francisco today will see a test vehicle every few minutes from one of the countless companies that are allowed to use them on public roads. And the progress in this technology has been enormous in recent years [CA19, Her19]. The demand for quality and quality assurance in this environment is enormous and is unlikely to decrease in the future. Accidents such as the one involving Uber are of course immediately reported in the international press.

Against this background, it is easy to forget that there are many fatal accidents every day in road traffic with humans at the wheel. A direct comparison also shows that people are often to blame for accidents with self-driving cars [Kok17]. The challenge is and remains, of course, that the number of accidents is reduced to a minimum and that not a single one of them may be due to an error of a self-driving vehicle.

And this is the challenge we as testers and quality managers have to face: with processes, architecture designs, tools, training and an appropriate mindset.

The article was published in the 01/2019 issue of German Testing Magazin.

Do you like this post? Share it: