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 at 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. A couple of extra days here and there forgives you some random delays in single tasks. There can be also some alternative routes defined beforehand in the schedule.
Regardless of 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 every day rather than redoing the whole week work on Friday afternoon.
Additional Moving Parts – OS and Framework Versions
In the case of Bitbar Testing 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 have been four iOS 9.x versions in the 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 have a 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, our open and modular architecture enables us to replace the most parts on the fly without additional integration effort. These both mean in practice we’re able to take an additional ace from the sleeve by adding a 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. Bibtar Testing 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 online as a prerequisite of the deployment team arriving at the site.
Finally the step of making the change visible is the process change. There’re 2 roles needed to succeed in implementing the enhanced process utilizing Bitbar Testing. These are the Technical Admin and the Testing Process Champion.
The Technical Admin is the first point of contact on any related questions by the customer team. She’s able to configure and administrate the Bitbar Testing service. She knows how to search for information on problematic runs, but she’s also able to configure the service too when needed. This can be adding a new device or configuring new CI integration. She’ll also act as the first point of contact towards our support team. Testing Process Champion owns the testing process in the customer company. This isn’t a specific role, but naturally she needs to be involved in Bitbar Testing 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 at the end of the road is worth pursuing. A successful implementation frees your team to focus on 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 a certain lead time for infrastructure you cannot much effect. 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!