I hope the title grabbed your attention, and I bet if it did, it was the ‘Robotics’ part that did it, right?
I was privileged to be involved in a round table talk a few weeks ago, thanks to Andrew Turner and the London TAD sessions (you can listen to the session here https://youtu.be/GUr1U_c50HU) about Robotics and Test Automation, and it led me to start thinking about the way we automate tests.
The phrase Test Automation annoys a lot of people, but I think it encapsulates the use of using automation tools to write code which will exercise specific scenarios that need to be checked multiple times. The point being, that whatever people decide to call it (and I really dont mind – life is too short to be pedantic about it), the aim is to save time without having a human running the same tests repeatedly, as it takes a lot longer, and is not easily repeatable.
This post isnt concerned with the pros and cons of writing automated tests either – we all know that they do not give 100% coverage and should only be used as a guide to the health of an application, and I am not getting into a debate around testing vs checking (again life is too short!). The point is that we have been following a certain approach to writing automated tests for the last 20+ years. Who among you was a tester in the 1990’s when Rational Robot was around? Yep, me too. I also remember prior to that working on Dec Vax applications and hand crafting tests in around 1995 even before Rational. It seems that we are still writing code to test other code that has been written – I have often wondered how far we should take it, i.e. who should write code to test the testers code that tests the developers code, but I’ll park that for now (my mind does go off on tangents).
Back to the round-table discussion. It was a very interesting one as it opened up my eyes to a possible new way of creating tests that can be scheduled and run without a human doing the work. Robotics tools were primarily used for automating work processes. A good example of this is employee onboarding, where there is a need to capture and process a lot of information, trigger checks and provision user accounts and new hardware etc. There are many examples on Robotics vendor websites of organisations who have implemented these to replace the mundane tasks that a human would have previously performed. Of course a human needs to set up the process and maintain the tools, but essentially the processes can run during work hours or after work hours – lets say a document is received at 9pm, a robotic tool can process the document ready for the next working day.
That was my view of robotics tools, great for automating business processes, but not necessarily something to use for testing. However, these tools have evolved a lot in the last few years, many now have an AI capability, so that they can ‘learn’ about different business processes and make decisions. So how does this affect testing?
It struck me that at a basic level, when we need to create sets of test data, a Robotics tool could be a better solution to use than writing C# or Java code in a Selenium Webdriver wrapper, as the act of creating data often needs to be performed via a UI rather than injecting into a database, particularly where there are a number of legacy applications that share data and all need to be in alignment. The same process that business users follow in a Production environment can be followed in a test environment using the tools. We could by-pass this by adding data to a db if that is possible, but using the tools is one way of ensuring that the process works – it acts as a regression test. It may not be possible or practical with legacy apps to inject data via a DB, so this would be a good approach and if an organisation is already using tools in this way, we as testers could leverage the work that has already been done rather than having another set of tools that duplicates it.
At a more advanced level, if a tool is following a business process, it could be one where data is sent from one application to another, or a batch process is triggered, and the tool needs to wait for a job to complete or to be at a particular status – which means that the tool has the capability to check whether a condition has been met or not before continuing. Hang on – that sounds a bit like testing doesnt it? Validating that a particular outcome has (or has not) happened after certain steps have occurred. In which case there is more of an overlap between a more tradition test automation tool and a Robotics tool.
So, what could this mean for testers?
Many testers do roles which are described as Test Automation Engineer, or Software Developer in Test, where the focus of their role is writing code, whether C#, Java, Python etc, and this has been something they have spent time investing in. In the short term I cannot see a great deal of impact, but in the medium term we could see a shift away from writing code to perform tests and a wider use of Robotics tools, particularly as they evolve.
As testers we need to be thinking about the skillset needed if the tools that we are going to use change. I’ve seen a number of posts over the past few years about ‘codeless automation’, and it isnt going to go away. I believe that the emphasis will move away from learning a particular language, and instead focus on the business processes and rules and the requirements that need to be tested, which is where I believe the focus should be anyway. The danger with existing automation roles is that too much time can be spent on the coding part (it can be a massive drain on time), and not enough on the test analysis part, and testers who have lost the ability to analyse the application, the stories and requirements and think about the tests, will be at a disadvantage.
I know that I have said this before, many times, but I think it is becoming even more important for testers to focus on the 3 core skillsets – technical, analytical and soft skills. We need to be good all-rounders, not just proficient in one area.
From what I have read and from the round table conversations, testing is about to change, and we need to be ready.
If you are using Robotics tools to help with your testing, I’d be really interested in knowing more about how you use them and the pros and cons, so please do get in touch.
Thanks for reading.