Developing, delivering and deploying mobile test automation is an ever-going hurdle. However, we’ve learnt a lot while building on-premise setups what must go in to the product that runs, manages and controls all of this. And as we are not only building one product, but instead three that can be deployed from the same code base, process and deployment are in essential role to inspect how to approach the delivery and deployment of entire mobile test automation, with software and hardware. In this blog, we’ll take a look what it takes to deliver and deploy mobile test automation – and specifically from the customer success management point of view.
3 Core Parts in Mobile Test Automation Deployment
Even the best plan of deploying anything is just a plan without proper execution. Like a famous general once said “No battle plan survives contact with the enemy.” However, planning is the mandatory step between the promise and the value.
The actual deployment consists of 3 parts; 1) developing the solution, 2) deploying it, and finally 3) adjusting the existing process to utilize the new tools in use. It’s the final step of process change making the value to realize, but there’s no shortcut in achieving it.
Project execution is as much hard work of completing the planned tasks, but also managing and follow up the progress. You cannot really prevent the surprises to happen in project execution even by the most careful planning. Even though you cannot predict the surprises the best project managers are well prepared. The most common way is to add some slack in the schedule. Couple of extra day here and there forgives you some random delays in single tasks. There can be also some alternative routes defined beforehand in the schedule.
Regardless the failover strategy selected later the most important thing is to be aware of the deviations as early as possible and act promptly. This is called control. It’s easier to adjust the work little by little everyday rather than redoing the whole week work on Friday afternoon.
Additional Moving Parts – OS and Framework Versions
In case of the Testdroid solution development the biggest challenge is the moving target. You cannot really freeze the scope of mobile OS or test framework versions too early in advance. For example, there has been four iOS 9.x versions in last 6 months – and the latest one rarely works without workarounds. The same applies to Appium – or any other test automation framework – having a new major version every 9 months and minor version every month. Luckily we’ve handful of great assets turning these risks as opportunities.
First of all, we’re not developing the support for the new versions of frameworks and tools only by ourselves, but we’re getting leverage on active open source communities. Secondly, Testdroid’s open and modular architecture enables us to replace the most parts on the fly without additional integration effort. These both mean in practise we’re able to take an additional ace from the sleeve by adding significant amount of resources to critical path tasks. Every project manager knows this isn’t usually possible in traditional projects without significant additional cost.
Putting Software and Hardware Pieces Together
The deployment phase is the most predictable part of the plan. This is basically assembling the HW and SW pieces together like lego blocks building the final solution. We know all the components and their dependencies beforehand and it shouldn’t be a no-brainer to put the puzzle together. It is so simple in theory you don’t really expect any risk, but the infrastructure possesses the biggest risk actually.
This is because the infrastructure is the first step in the critical path having all the remaining items dependent on it. None of the tasks can be started, if you don’t have the properly configured servers having the needed connectivity and the components ready to go. Testdroid doesn’t require any specific HW, but even a half a day delay in the first step starts to cumulate dramatically in a short 1 week deployment project. This is why it’s mandatory to have all the needed infra components in place on-line as a prerequisite of the deployment team arriving to site.
Finally the step making the change visible is the process change. There’re 2 roles needed to succeed in implementing the enhanced process utilizing Testdroid. These are the Technical Admin and the Testing Process Champion.
The Technical Admin is the first point of contact on any Testdroid related questions by the customer team. She’s able to configure and administrate Testdroid. She knows how to search information on problematic runs, but she’s also able to configure Testdroid too when need. This can be adding a new device or configuring new CI integration. She’ll also act as the first point of contact towards the Testdroid support team. Testing Process Champion owns the testing process in the customer company. This isn’t a Testdroid specific role, but naturally she needs to be involved into Testdroid deployment to act as an internal advocate to enable the leap towards automatic mobile testing. She’ll help the internal teams to come over the obstacles what might come up while adjusting the existing processes to use new tools.
Executing even a well defined plan isn’t a walk in a park. However the prize in the end of the road is worth pursuing. Successful Testdroid implementation frees your team to focus on the real value adding work. This is making your customers love your product. They won’t very likely put much value on you manually testing every single feature on every release nor honing your home-grown test automation system. Successful execution is built on two pillars. At first it’s the prerequisites. There’s certain lead time for infrastructure you cannot much affect. You must know them and be prepared. Another one is people. The change isn’t possible without the actors.
Weigh in with a comment on what you think are the most critical elements of mobile test automation deployment!