
Photo: Imagewell – shutterstock.com
Software developer Benjamin Willenbring was thrilled when his employer Autodesk introduced automated software testing in 2015. However, this enthusiasm subsided relatively quickly because communication with the small automation team was difficult and the results of the efforts did not meet expectations.
“My colleagues talked about test runs failing for unpredictable reasons and left no doubt that they weren’t particularly convinced of the whole thing,” says Willenbring out of the box. Getting the test phase up and running was difficult: there was no documentation and files in abundance. Automated testing was supposed to simplify Willenbring’s work – instead, the automation project posed so many new problems that the developer had to invest the majority of his energy in the following years to solve it.
However, the experience that Willenbring has gained in automation is not uncommon. The higher the level of automation in IT departments, the more instructive examples are that show how automation should not be tackled. Regardless of whether it is automated DevOps workflows, robotic process automation or process automation – the technology should actually ensure that specialists are freed from repetitive tasks. But inadequate framework conditions and rollouts with failures can quickly turn the automation dream into a nightmare. We’ll show you six ways to avoid automation disaster.
Willenbring’s testing automation nightmare was particularly triggered by one circumstance: the only ones who were able to understand the automated tests were the ones who set them up. Unfortunately the team in question was located in another city.
“One problem with the test framework was that it didn’t provide really good feedback in the event of errors,” says Willenbring. “If an error occurred, the first step was to take Slack to ask the test lead for the cause. The lead then repeated the test manually and communicated the cause of the error.”
The testing framework thus violated essential rules with which every automation initiative should be aligned, says Robert Haas, DevOps Product Manager at DXC: “Automation code must be documented, regardless of whether you use modern methods such as Documentation-as-a-Code or link Visio diagrams. Solving problems is much easier if you can understand what the original state looked like. “
Because that didn’t happen in Willenring’s case, the test results were unusable for his team. This in turn led to a decline in trust in the tests and the team that set them up. “Sometimes the developers just blocked and ignored obvious errors,” says the software developer.
Due to the spatial distance between the developer and testing team, additional problems arose: “You need experts who know what they are doing and select what is being tested. Lots of tests without a real plan generally do not lead to usable and meaningful results”, so Willenbring.
Only a new head of the development department was able to free Willenbring and his team from this vicious cycle – he made it clear that quality has top priority, even when it comes to testing automation. Since then, centralized testing has been a thing of the past – individual departments now set up tests for “their” code. In this way, Willenbring and his team were able to launch tests that were adapted to their needs and ultimately integrate this process into everyday work. Willenbring’s conclusion on this experience: “You shouldn’t even allow an attitude in the sense of ‘that is not part of my job’.”
- The over-slip
Especially in situations where there is immense pressure, some employees tend to make all kinds of absurd promises. Either to get attention or to please the manager or the management. Making promises is always easy, but if the mega-project is not completed within the promised two and a half weeks, it is unfavorable.Alexander Maasik recommends: “If there is a team member who keeps making false promises that are already known to be impossible to keep, you should no longer take his words at face value. If you can, extend the promise Time frame and / or increase budget or resource allocation to compensate for bottlenecks in other areas. ”
- The responsibility shifter
Then there are these colleagues who interpret the collaboration principle of shared responsibility in their very own way. True to the motto: “The others will fix it.” In such a case, expert Maasik advises that the employee in question be assigned a defined role and specified responsibilities in the team. Alternatively, you could also ask the responsibility slider whether there are areas that particularly interest him. Maybe you could rekindle his passion for performance.“Sometimes you can motivate such people by giving them managerial responsibility or giving them responsibility for a particular area / topic that is close to their heart. Unfortunately, if a colleague in question is known for excessive reluctance to work, the only thing that helps is him (or her) to keep an eye on and to contact higher authorities if necessary. “
- The foreign spring connoisseur
It is only human to strive for appreciation and recognition. But some people overdo it to the extent that they almost believe it themselves if they wrongly attribute the success of others.Maasik: “Unfortunately, the enthusiasm of these people is declining rapidly when it comes to taking responsibility for failures. In order to counteract such developments, it is advisable to record exactly who is responsible for which part of the project work. So everyone involved can do the same see who’s doing what. If someone insists on getting laurels, make sure they get their fat in the event of failure. “
- The blemish magnate
Team morale does not lead to the abyss faster and more straightforward than someone who constantly criticizes, “points out” mistakes or only complains about every aspect of a project. Regardless of whether it’s about responsibilities, workloads or strategy, the Makel-Magnat always has something to complain about.“This behavior is utterly poisonous for teamwork. These people spend more time complaining than doing their job. The best way to act like this: 1. Ignore the grumbling, 2. Give him so much Responsibility that he (or she) has no time to whine. “
- The dropout
Some people work better alone. No problem at all. Unless they are people who are involved in team projects. Then someone who ignores instructions on principle and is affine for going it alone could jeopardize the whole project.That is why Alexander Maasik recommends that such people should be put on the siding: “Find an area in the project where such an employee can work alone or realize yourself. This way you can get the maximum productivity out of this colleague and provide at the same time, make sure the rest of the team stays intact. “
Tripwire, a provider of automation solutions in the area of IT
security and compliance, was recently amazed at the processes at a major customer in the financial sector. “Our solutions are rolled out automatically,” says Irfahn Khimji, Country Manager for Canada at Tripwire. “So at some point we wondered why it was taking so long for this customer. We saw no increase in license usage, which was not the normal pattern.”
As it turned out, the ideal of an almost completely automated CI / CD pipeline was caught up in reality: each of the many different departments at the customer’s own, individually designed set of software components.
“The customer wanted to integrate more than 30 applications – which led to numerous problems, for example when it came to the various libraries,” says Khimi. “Adjusting the pipeline so that it reliably covers all requirements slowed down the automation process significantly.”
There is no magic bullet to solve such a problem. However, you should be aware that with an increasing number of components that are to be integrated into the automation process, the complexity increases – after all, these components have to be linked with one another and corresponding adjustments have to be made. This, in turn, will result in the automation initiative taking more time and resources. It also plays a role where these components come from: The majority of the pipelines and RPA environments contain a heterogeneous mix of in-house and third-party components. The latter in particular can lead to real problems if errors occur.
- AI and automation
At the invitation of Computerwoche in late November 2018, experts in Munich discussed artificial intelligence (AI), machine learning and automation. - Bernhard Mandutz, Business Unit Manager Valuemation at USU GmbH: “In the future, AI will play a central role in service processes, regardless of whether it is automation, predictive maintenance or chatbots.” USU GmbH is a specialist in enterprise service management.
- Santiago Cabrera-Naranjo, Consulting Director at Teradata: “Today, data science is too often a process in which new knowledge and models are developed as a one-off effort or used ad hoc in production. They therefore require regular babysitting for monitoring and updating. We want to change that. ” Teradata, formerly known primarily as a data warehouse provider, has long been devoted to topics such as business analytics and big data.
- Stefan Gössel, Managing Partner at the IT service provider Reply: “If you have workstations with two screens, we have something to do.” Reply is a specialist for business models based on paradigms such as big data, cloud computing or the Internet of Things .
- Tobias Mirwald, Managing Director at CRM manufacturer Adito Software: “It is often difficult to access the data because it is in silos. You have to think networked before you can use the data with AI. ”
- Sven Munk, Partner Technical Sales Lead EMEA LATAM, at Informatica: “The data volume is exploding, more and more data types are being generated. Companies need to use this data strategically to innovate and drive digital transformation. ”Informatica is a leading provider of enterprise cloud data management solutions.
- Thorsten Urbanski, Head of Communication at security provider ESET, values the challenges and potential in the area of automation and IoT equally highly. In the course of digital automation, it will be essential to protect yourself against manipulation of the relevant data: “If we imagine the consequences in the area of robotic and Industry 4.0 or autonomous driving, the effects would be more than fatal.”
- Kristina Appelt, Manager Systems Engineering at Cisco: “It is important to provide user companies with a high-performance, validated infrastructure for AI and automation.”
- Alexander Hartmann, Member of the Executive Board at SYSback: “We German companies are far too reserved in marketing AI.” SYSback is a service provider for holistic automation and uses this approach to orchestrate and automate a wide variety of processes and IT resources.
Robotic process automation and chatbots are particularly popular in the financial sector. In this context, Muddu Sudhakar, CEO and co-founder of the software company Aisera, warns of a common scenario: Processes are seen as a monolithic functional unit, the internal processes of which are difficult to separate and thus become a black box: “In a monolithic structure, the customer wants check your account balance, withdraw money or transfer money – all of this happens in one step, “explains Sudhakar. “If something goes wrong and there are no monitoring measures, all that remains is a call to customer service or a physical visit to the branch.”
According to the experts, this type of architecture is typical of the initial efforts of companies with automation technology. Such projects could produce good results, says Sudhakar, but only as long as everything goes according to plan. If not, all that remains is to remove the individual functions from the black box – which is why you should avoid them from the outset.
“Divide each process into building blocks that can be audited and checked,” recommends the automation specialist from Aisera.
Many automated processes can benefit from the poka-yoke principle. The error prevention strategy invented in Japan is used, for example, in the Toyota production system. Here, a single process step is divided into two different ones – the second step depends on the first. Paradoxically, the multiplication of the individual steps leads to efficiency gains because mistakes do not flow into the production chain – where their effects can multiply.
Individual automation steps should not only be auditable, but should be constantly checked by other automated processes. This brings you closer to the AIOps area: automated platforms relieve human specialists of the burden of IT management.
Automated CI / CD pipelines often have a dirty secret: Many were initially rolled out by shadow IT to circumvent security guidelines. “Developers just want to develop and move forward quickly with their code,” explains Irfahn Khimji from Tripwire. “When rigorous IT and security processes get in the way, they immediately have ideas in their head to avoid them.”
This does not mean that such CI / CD pipelines are unsafe per se – but you should definitely keep an eye on which security practices have been sacrificed to gain automation efficiency. In addition, you should not forget that every automated process is always another attack vector. Autonomous processes, which are equipped with extended authorizations, can be particularly attractive targets for attacks. Muddu Sudhakar can not only remember one case in which intruders misused the DevOps pipeline to infiltrate malware. This could make its way into the production environment and paralyzed the entire system.
Every hype comes with misunderstandings in tow. Ajeet Dhaliwal, lead developer and founder of Tesults, has seen many companies whose vision of automated testing contrasts quite clearly with best practices. Smaller companies in particular, whose management level has no technical background, seem to be affected by this phenomenon. In the logic of these people, automated tests are simply manual tests without human involvement.
“So they encourage traditional QA testers with no knowledge of software development to automate testing,” summarizes Dhaliwal. “The robustness and flexibility of such approaches is far behind what a software developer with automation know-how can do.” Of course, it is no problem to involve young developers too, a
ccording to the testing expert. But these should be guided by experienced developers to ensure good results. (fm)
This article is based on an article from our US sister publication CIO.com.