There's a demonstrable link between test automation and organisational change. That’s what I believe so please allow me to explore my thinking in this article.

Any type of change at tech companies can be a bit hairy because often people hope that by focusing on the technical side of change (e.g. new software systems or new automation frameworks) they'll overcome some of the difficulties they face on the organisational front. This is sometimes true, but mostly any effort at project level that doesn't plug into a strategic overview can be lost in a sea of undocumented change, and the impact it has made gets diluted.

Some of the organisational difficulties include the people (i.e. colleagues) who might not want anything to change – often for good reasons. Others are founded on fear – that there's no room for them to exist in the new model. However, the organisation usually needs to evolve to stay competitive. So how to proceed then? I'll go deeper into some of these questions a bit later in the article.

If change is not measured, we can't analyse its impact. So quantifying the change is a critical element. Further, showing how it progresses the overall strategy is vital because by doing so we can appease uncertainty in people that are worried about where the change will take them.

A common motive for organisational change might be 'to improve customer experience'. The problem with a siloed business process workflow is that initiatives can be passed back and forth between different siloes resulting in resolution taking longer and can even impact a customer's experience.

I believe that an improved customer experience requires better bridge building between siloes. I'm fascinated by organisational bridge building: we build the organisation up one brick at a time and by doing so help create a new reality for employees within that system. On a personal level, we build our understanding of the organisation itself similarly, and it helps us to operate well when our efforts are aligned with a clear, big-picture strategy. We can see our efforts positively impacting the overall strategy, which I find very motivating.

Identifying the catalyst (generally, collaboration) and then linking it to overall strategic performance can help propagate success, which ultimately leads to replication across other projects and easier reporting to stakeholders. It also allows us to quantify collaboration itself and document it, which is crucial as we'll see shortly.

Often companies aim to simply improve existing processes. If instead they focused on re-conceptualising the entire customer experience, they'll reveal opportunities to unlock huge value in the form of simplified and streamlined interactions with the client. This is usually framed via a strategy which is ultimately rolled out.

I've noticed that simply having a strategy mapped out doesn't help people go ahead and start to create the new reality. The change doesn't happen automatically. People don't always know where to begin. Limiting people's choices can help them not to feel overwhelmed. When people are facing a situation where their decisions will help drive organisational change, it often helps them if we define a starting point. I'll use Shift Left as an example.

Shifting Left is a testing term used to describe shifts in responsibility in software development teams and environments. In a nutshell, it helps each project team take more collective responsibility for quality. Where each Tester is an expert in their field, and a Developer is an expert in theirs, they can collaborate and take equal amounts of responsibility for the quality of the finished product. In this context, quality can be that of the code, or it could also mean the quality of collaboration between team members.

Sometimes project teams struggle to collaborate at first. I don't think this is always due to active resistance to the new direction (although it definitely can be). I believe it's because people don't really know where to start. They've had their role in the team for a while, and they are used to working in a certain way. They enjoy the inertia they've generated for themselves and (what they perceive as) outside interference in the form of organisational change can look like a massive risk to their work. However, without their buy-in, the change process might be put at risk.

So here we see the first psychological risk factor in what is ostensibly a project-driven change process.

We can manage the risk through good communication; and by being open-minded about how the other colleagues want to proceed.

I find that creating a path for people to start walking along means placing the first flagstone.

Shift point 1:

In my interactions with my teams internally and on the client-side, I often propose that they take responsibility for change themselves. To help limit their choices and to help them figure out their next steps, I start off with a single objective: to improve collaboration between team members and then, as a secondary objective, to show me how they did it ('creating the evidence').

The common denominator between diverse IT staff is quality. In general, people want to generate quality work, and they also want a high quality work environment. We can guide them forward by using things like workshops designed to increase their experience in Agile methodologies (BDD, TDD etc.). The team can quantify that need and collaborate, the action of which helps to generate a Shift Left change. This demonstrates our first triangulation point between test automation, strategy and organisational change.

Shift point 2:

Alignment of individual team's efforts with an overall strategy, and mapping those efforts to points within it. This is a chicken and egg scenario. Sometimes a large scale strategy is in place at an organisation, and it generates the needed changes at project level. Other times, efforts at project level can guide and influence the broader strategic initiative. Sometimes the CEO provides the vision and different times it emerges as a need from the colleagues themselves. Whatever the case, mapping efforts to a broader strategy is a requirement for any successful change to occur. As we've quantified the currency of change as 'collaboration', and we have the evidence of this from our efforts in Shift Point 1 above, it's easier for us now to map our efforts to points in the overall strategy and demonstrate the positive progress made.

Shift point 3:

Map outcomes from Shift points 1 and 2 to the organisational processes that work well already. E.g. rolling out of Managed Services, which as an example might be the task of taking a labour-intensive manual testing job and automating it. I endeavour to understand their current project delivery model and then draft strategy that pins key interaction areas to, for example, an outsourced software automation team. When both the external automation team and the client's internal teams are aligned using Shift Left, and the collaboration they create has been quantified, it is then possible to share the outcome with other project teams and motivate for them to make a similar type of change. This causes the change to trigger and propagate across the organisation.

Shift point 4:

Describe the successes and create positive inertia. Now that we've quantified collaboration in any one client-side interaction and tracked the outcome it's created for specific project teams; we can plug those learnings back into the overall strategy and show how Shift Left has helped achieve these objectives. Not only does this mean that other project teams will be able to replicate this success more quickly now they have a functional example, but it also actively progresses the client's strategic aims.

Shift point 5:

Focus on the technical side. Reports can highlight good examples where collaboration was efficiently used within a project. For example, how did the team overcome geographical constraints and get to the point where an Automated Tester in Cape Town felt close collaboration with a Development Manager in Johannesburg? How is this reflected in the quality of their Unit Test cases; and how easy was it for them to use these to generate more detailed system test cases, making use of each team member's expertise to do so?

Change Champions can be identified and their experiences can be applied to other areas of the business, helping to increase further the value obtained from those initial collaborative offerings.

Testing as an engine of change

People around the world are discussing the pros and cons of Robotic Process Automation (RPA). Elon Musk warns us against over-reliance on AI algorithms, while Mark Zuckerberg thinks we shouldn't be overly cautious and should pursue automation energetically. Workers are afraid automation could cost them their jobs. But it's not only the factory worker or data capturer that has these fears. In fact, there's a breed of Manual Tester that has faced this concern for quite a long time now. That's because of all the technical industries, software testing has arguably had the longest exposure to test automation, and the skillset there has matured a lot.

We use automation to facilitate Shift Left strategy as well as to find bugs in code. To the Manual Tester (who doesn't want to code or become a developer), change means adapting to new methodologies being introduced by the industry and finding ways to apply their skillset and remain relevant.

The good news is that there's plenty of room for automated agile methodologies. Functional Testers become excellent use case authors, their experience in test writing means that the developer's unit tests benefit from their analysis. Detailed feature files follow, as well as thorough system test cases and automated regression packs. Potentially their most significant impact is in User Acceptance Testing (UAT – which is the stage when business people assess the system to see if it meets their initial requirements), where they can show a notable return on investment. Where tests used to take weeks or months to run manually, automated regression can do it in days.

But it's not only the tester that is benefiting from automation in this scenario. The organisation that's going through a period of change will also benefit. If we go back to my previous example of laying down the first flagstone to kick off a change process, then we see that the manual tester is doing just that - by using their skill set to improve collaboration and refine well thought-out unit test packs. This activity helps remind the project team that all people involved can take responsibility for quality.

The Manual Tester learns how to implement and maintain a Managed Service by helping their teams to shift left.

Robotic Process Automation

Where non-techies can see robots as self-sufficient employees that don't need to eat or sleep, I think most testers see them as routines they can kick off to do some testing. Other areas of the business can then run the scripts themselves and are often able to automate some of their work by doing so. For example, someone can edit a test data file using real-life values and then execute in the Production environment, which is faster than updating it all manually (we shouldn't forget to do a dry run in the Test environment first, of course!).

Testing frameworks have evolved and, luckily, some of the best are open source and available to anyone that wants to learn more. One client I've been working with asked if we could utilise the Serenity framework. We were able to do so because the principles of automation remain the same, no matter which toolset is used. In the same way, the principles of RPA remain common across any toolset or operational environment.

Therefore, when we are able to quantify change itself, map it to an overall strategy and use automation to propagate the values of that change, we are robotically automating the strategic change.

Experience shows that when we do this, it doesn't lead to job loss or redundancy. Instead, it shows that when people receive their first flagstone and the permission they think they need to lay down more, they'll happily create the pathways that lead them towards better emotional and job security within their organisation. The result is a happy client, and an ongoing change process maintained by the colleagues. That's good inertia!

Conclusion

I do think that software testers and their methodologies have been at the forefront of RPA for years. Today's automation landscape owes a lot to the manual testing fore-runners that laid down the tracks we can follow today. When we shift left within our projects, we build the bridges needed to progress our organisational change.

As for robots - I think ours are friendly Zuckerberg ones – and definitely not the Terminator, killer drone types that Musk envisages!

References

1. The psychology of change management
2. The next generation operating model for the digital world
3. Robotic process automation and the testing future
4. Six top open source automation frameworks

About Michael

Michael is a Lead Consultant at DVT, where he works on IT and Test strategy for his clients. His job allows him to roll out new ways of working across organisations and within his onsite teams of consultants. He’s passionate about the role that colleagues play in the work environment and how technology can be used to support their efforts. He has insight into the project testing and organisational change management sides, both in South Africa and internationally; across sectors ranging from education to banking and research.
Connect with Michael on LinkedIn.