How to make use of our test automation talent to close the gap between IT and business

How to make use of our test automation talent to close the gap between IT and business

In this blog Fredrik Scheja dicuss soultions to close the gap between IT and business. And what we can do within IT to understand business on a deeper level. Get to know more about Robotic Process Automation (RPA) and it's roll in Quality Engineering & Testing.

A couple of years ago, I had a discussion with a fellow engineer at a global retailer. We were having a good laugh together when he told the story where the business had problem transferring orders from one system to another in one of our warehouses. Their approach to solve this was not to turn to global IT support for a solution to this, but instead hire a local IT firm to set up a nightly script that read each order – copied it – and brought up the other system to fill in the data. This was done during the night, and we had a good laugh thinking about the screens flickering in the back office of the warehouse in the dark when no one was around. Why on earth could anyone be satisfied with – what we interpreted – as such a homebuilt do-it-yourself solution?

Just recently I found myself thinking about this situation from the complete opposite angle. I understood that the business people endured a lot of struggles when handling the orders and were forced to do a lot of manual work since the two order-related systems weren’t in synch. They identified the problem and found a way to fix it. The solution was implemented through Robotic Process Automation (RPA) that only would´ve taken a couple of hours for a skilled RPA engineer to set up. This, compared to submitting a request to a global IT department – that would take at least six months to have a “proper” solution in place. The business just wants things to work with less friction possible. Now.

The reason I came to think about this story was that I got a question recently: “What can we do within IT to understand our business on a deeper level – sometimes it feels like we are talking completely different languages. We can´t even understand the test cases written by our own business.”. This question made me think, why can´t we use RPA as a conversation starter with our business? Why are we perceiving RPA as a lower form of software engineering when it is clearly providing value for our businesspeople? And – a side of RPA often foreseen – it can create wonders for us breaking down the silo between IT and business.

Just by merely designing an RPA solution together with business will inevitably generate great conversations and helps IT people to understand the day-to-day business struggles on a deeper level. But what is even more important to consider is the business data we as software developers will obtain when the RPA solution is in place. In many traditional organizations with old architecture, it is often difficult or virtually impossible to get the proper business data we need to design and develop a great digital experience. Legacy systems are often very low on observability and analyzability capabilities. As a matter of fact, it is still not uncommon that the only intelligence we can get out of the application logs is when crashes or very severe failures would occur. This does not help when we as developers need to know how many orders a microservice need to handle in a normal day – because we need to obtain that data in a friction-less almost real-time manner to feel confident that our design will be sufficient.

In the case of the two order systems that a bot was moving orders between at night – if that would have been set up by global IT support the knowledge of for example which systems were involved and the nature of the orders that were to be moved would be clear and known. We would even be able to track the number of orders, understanding the workload for the bot and how it would be changing over time – even been able to perform a workload prognosis for our bot. After that we could together discuss and analyze further possibilities on how we could possibly solve this in a smoother way, how to make the bot unemployed in a safe and effective manner.

So, in many cases RPA can act as that easy-to-implement first important sensor for us out in the field, providing us with vital requirements, needs, patterns and signs of our business processes before we start to develop any more advanced solution to the overall problem. By analyzing the data we get from our fellow bots in our production environments, we are able to detect patterns or deviations in our business flows – sometimes even before the business start experiencing the consequences. We would even be able to design our test scripts based on the actual business profile from the real world in almost real time – creating a sense of a digital twin of our business inside our test environments.

Therefore, I recommend each tester with engineering skills and test automation experience to indulge in the world of RPA. Because if we would be able to master this skill we could short-circuit the disconnect between business and development teams, creating a smoother engineering experience and increase the level of confidence in our systems ability to provide real value in the end.

If you have read this far and are still curious – if you are interested to try this approach on your own, please reach out to me. We are able to combine our RPA Kickstart and Test Automation Kickstart so that you are able to get a Minimum Lovable Product – a working prototype that offer you hands-on experience of this and what it might mean to you in your own organization – just within weeks.

  • Fredrik Scheja
    Fredrik Scheja
    Test Architect/Test Automation Expert
    070-345 27 13