The Battle for Automation – Exposed by a Software Engineer

Automation in Software Integration

Integrating multiple elements of a large system always requires accuracy. It is a very sophisticated engineering process that often demands more time than the development of two or more components in isolation.

The whole process can get quite confusing and understanding the full scope can take a long time, so it is worth considering solutions that accomplish tasks without direct interference from the user. Automation is especially useful in cases where there are multiple engineers involved in the project and the degree of knowledge of the system may vary dramatically. Alongside the essential elements of software engineering; such as code comments, documentation and test coverage; for particular tasks automation is a valuable time-saving addition.

A good example of what I mean by this can be seen in the simple act of turning on a computer or laptop. No one would really like to manually initialise drivers or configure the kernel of the OS at the PC start-up to just simply access some data from the hard drive, move the cursor along the screen or to simply finish off typing the C++ script that remains unfinished from last night.

Regardless of what a user is going to use the computer for, they don’t necessarily need to know or have performed the whole integration process; everything is being handled and set automatically during the start-up of the system.

Case Study

While working in a team fixing bugs for a customer, part of the testing process was to establish a clean, errorless build which would then be used to create a Board Support Package image. The Board Support Package could then be deployed and installed onto the target system. I was able to fix the first bug I worked in just 2 hours, but I then had to spend 3 hours creating the board support package. I began to think that automation could be a useful solution to save time for my team and that the customer may also benefit. Testing and debugging freshly written code would become much easier and quicker providing instant feedback.

At the next customer meeting, the idea was discussed and we found that they had also been considering solutions in this area and that my idea for automation would be a welcome complement to their activities.

The build required integrating multiple elements of the system, which were mostly written in different languages such as C, C++ Python and some JavaScript. I had to set up my own environment for Board Support Package production. It was quite an absorbing process as I had to deeply analyse all of my previous steps. One of the most significant tasks was to install multiple dependencies, Linux RPMs and port numerous libraries with attention to the version.

Through a combination of having had exposure to global knowledge of the system, the support of my team and close communication with the customer, I was able to automate the generation of the board support package image. After presenting the automation to the project manager we agreed that I should generate comprehensive documentation, which would contain enough information so that other engineers could set up their environment for Board Support Package image generation.

Why is it Worth Spending Time on Automation?

I quickly realised that the process of setting up the whole environment would be very difficult and error-prone even for someone who has previous experience with the product and UNIX based operating systems. Another set of problems would be generated by debugging low-level applications used to create Board Support Package in case something went wrong during the configuration process.

I compared the product to the computer startup example used above, and I comprehended that automation could provide a way for engineers with less knowledge of Board Support Package generation to be able to utilise the beneficial features of more robust testing, without having to know how to create the Board Support Package themselves.

This was the reason behind why I decided to create fully automated software, a Linux wrapper, which would accomplish all of the steps automatically. I wanted to reduce the need for all of the engineers working on this project to read mighty documentation and have a detailed understanding of the whole system scope, which was not necessary at that point. Essentially, it allowed us to be a more efficient team, saving our customer’s time and money.

Automation

The Outcome

After a few weeks of analysing source code, building scripts and going through all of the possible outcome scenarios, the automated Linux wrapper was created.

I decided to put it through functional testing. One of the multiple tests was to break it by emergency stopping the installation process at different stages. The test passed with the result that, it would just abort and then try again on the next attempt.

Another interesting test case was to pass invalid arguments into the user ID analyser of the program. This was the most challenging point of my software because it was the only module, which required user interaction. Luckily, the latest version of my code was equipped with an ID and password validator so it was impossible to break it.

My automated software handled all of the interrupts and weird scenarios very well. When it comes to the release version of my Linux wrapper, I did not manage to break it even once thanks to its automated process nature and defensive design.

My next step was integrity testing, which in this case meant running my automated Linux wrapper on multiple workstations just to make sure that it is universal.

The automation recognises the stage of the workstation and, based on this information, decides what needs to be installed and then downloads it and installs it. Subsequently, it gives the user option to store some information in the ‘cache’ to provide further comfort when it comes to typing in user credentials such as email, login, password etc.

Is Automation Something to be Worried About in the Future?

We hear a lot of bad prognoses about what automation will do to jobs in the future, but in my opinion, there is no need to be afraid. We can already see the benefits of automation in multiple industry sectors such as banking, IT or HR. Fully automated processes are running 24/7 allowing us to transfer money from one end of the world to another and yet we can note that financial services employee numbers are at highest levels ever and they are still increasing. HR and Marketing offices are equipped with all sorts of tools, which automate and improve some of the tasks. The only difference between now and then is that some positions require a little bit more training.

When it comes to IT engineering industry, automation provides major benefits such as an increase in productivity, high performance and reliability of software. The project I worked on provides much evidence, which proves that automation brings faster feedback, accelerates results of debugging, reduces business expenses, improves precision and provides earlier detection of potential system defects.

My automated solution saved approx. 4-6 working days of each engineer employed on this project. No one lost their job, in fact, the result was quite the opposite. Sectors, which required more attention, were found, fixed and tested quicker. Instead of an unnecessary step of setting things up and having to learn the scope of the whole system, the Linux wrapper allowed engineers to spend more time on actual fixes and problem-solving and everyone involved in the project benefitted, from the customer to the team here at Zircon.