Testing in the Digital Transformation

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 dedicated offices and why collaboration across different continents was a challenge?

We have dealt with these and other questions and have gained many authors who have also given their thoughts on the subject. The dominant 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 intermediate results. How good must the quality be at what point in time? And how do we ensure that quality assurance measures scale with the complexity of the project? How do recurring questions about increasing test fficiency fit in 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 in the face of what is currently developing there. We had a long chat about his insights into the start-ups and companies based there and the challenges that the new technologies, working methods and systems pose for software testing and quality.

In view of the impending changes in many traditional industries, the term “digitalization” sounds almost a little cute - the changes are likely to be disruptive, opening up new areas of business and causing others to disappear. In some industries, people are still lulled into a false sense of hope that this chalice of change will pass them by. Some see concerns and problems while they are already being overtaken left and right. And yet others see the opportunity and use the potential that software and data already offer today. Regardless of whether the latter are concerned with artificial intelligence, autonomous systems, predictive technologies or augmented reality: Our core topic of software quality is affected to a large extent.

Large becomes complex

Recent decades have been characterized by systems becoming ever larger. 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.

But large systems are being replaced by complex systems. Their inherent dependencies, relationships and algorithms are becoming increasingly difficult to understand 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 designed in such a way that efficient and fast quality assurance is still possible; architectures for systems are designed in such a way that an 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 as a first step. The advantages are obvious: fast execution, fast feedback, especially for the regression test. Only the preparation of the associated test scripts requires significant effort when creating or adapting them.

But how do we manage to apply this process in changing environments? Frequent changes are finding in agile development processes. During each sprint, you need automatically executable test scripts that evaluate the functional quality of the system. These test scripts also need to be adapted quickly due to the likely changes in the current sprint. However, manually adapting a significant part of the test scripts per sprint is only feasible at high cost for any non-trivial project that is subject to change.

Should we give up automatic testing because of this? Not at all! Instead, we need to find ways to reduce the customization effort for the test scripts. This is known to find itself in approaches of data-driven, keyword-driven or model-based test design techniques. In addition, quality assurance is no longer just a task for the tester at the end of the process chain. Rather, the implementation of the necessary tests is part of development, just like 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 influences from other functions be reduced to the actual function to be tested? The architecture used plays an important role here. Small, interchangeable units are used intensively in the architecture approach for microservices: Each microservice has its own tests; each microservice is independent of others and communication is defined only via interfaces; each microservice is focused on a particular customer benefit.

Small teams, clear architecture, focused tests, customer benefits at the forefront: all of these advantages can result from the smart choice of architectures, processes and test approaches. We have highlighted microservices, agile and test automation as examples here, which in this combination keep even complex projects maintainable, testable and comprehensible. Here, the test effort remains appropriate, the test focus is directed towards the customer benefit and the scalability of quality assurance is given with the complexity of the system to be developed. The poster “Increasing efficiency in software testing” shows the interrelationships as an example. Figure 1 shows the rough structure of the poster and the relationships presented.

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 need to think about the development process holistically: in addition to methods and tools, people and mindset above all - when everything interacts 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 members of the team, this means a massive change process that requires experience, empathy, dedication and patience. A workshop or training course is not enough. It requires accompanying support, constant impulses and assistance 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 towards the project and the chosen process plays a decisive role in the success or failure of any project!

Of course, sound training is the basis on which such a change process must be built. Speaking the same “language”, mastering the quality tools, understanding and being able to apply the methods and procedures: In 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.

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, app or software is increasingly based on usability and the user’s experience, the happening. And this no longer only affects private users. The demand for software used in business is also increasing: If employees have to spend several hours a day fiddling with slow, overloaded and complicated interfaces, frustration is inevitable. Start-ups focus on these pain points and resolve them. There are always three main guidelines that should be followed:

• 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 me. 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 interface 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 won’t enjoy using it to any great extent. We are spoiled by apps & co. You clicked here? Then perhaps you would also like this and that …

These aspects usually affect not only individual components, but the user’s entire processes. Is the tester even entitled to scrutinize the business processes? Of course! A critical eye is required here. How can the application be made simpler? What can be taken away from the user? Do we still need function X and Y? Which old habits (e.g. interfaces, special locks, modules) can be cut off? What “historically grown” features can be rethought?

What happens next?

What are we going to do with the impressions of Richie’s trip? We live in exciting times. In the next few years, technology and, in particular, the latest software will provide us with possibilities that we are probably unable or unwilling to imagine.

One good example is autonomous driving: What is often countered in this country with extensive concerns and excuses has already reached completely different dimensions in other countries. If you walk through the streets of San Francisco today, every few minutes you will see a test vehicle from one of the countless companies that are allowed to drive it on public roads. And the advances in this technology have been enormous in recent years. The demand for quality and quality assurance in this environment is enormous and is unlikely to decrease in the future. Of course, accidents like the one involving Uber immediately make the international press.

Against this backdrop, it is easy to forget that there are many fatal accidents on the roads every day with people at the wheel. A direct comparison also shows that people are often to blame for accidents involving self-driving cars. 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 can be attributed to an error by a self-driving vehicle.

And as testers and quality managers, we have to rise to this challenge: with processes, architectural designs, tools, training and a suitable mindset.