In the past, I’ve spoken about the importance of test automation and how applying and integrating it correctly can solve a multitude of problems like reducing time to market, improving customer satisfaction and importantly, providing predictability to an unpredictable business. I am not the first to identify the trends and many companies and teams have gone forth and implemented strategies such as these. However, one mistake that often gets made is that individual teams and products within companies all go off and build their frameworks separately without releasing the importance and potential of a centralised framework.
So what do I mean by a centralised framework? I’m not talking about a centralised server/mainframe terminal architecture or putting everything in the cloud. I’m referring more to programming object repositories or libraries that interact with each other without the need for expensive APIs to translate their language. A centralised framework essentially represents a common language that your entire organisation and teams will use to speak with when it comes to ensuring the quality of the product. You would all agree that having a team of engineers working on a product together, but not been able to speak the same language would be highly disruptive. Well, the same actually works for your different frameworks as well.
To make things more manageable and serviceable, teams tend to break up and do their own things only integrating and collaborating when absolutely necessary. While Agile and DevOps trends try to reduce these development silos, the truth is you will still find software developers writing their own unit tests fee of a framework, test engineers writer their automated tests in a spate framework, often utilizing multiple different tools that don’t always work well together and then you still have performance, security and deployment engineers each writing scripts that add a lot of value, but in their own way.
Doing this means that each team will at any point in time starting doing some element of rework from the other team and from a code perspective, things become more complicated to maintain, especially as your company and software architecture grows. As you can imagine, this can become very inefficient and doesn’t scale well.
You might initially think that these areas don’t and shouldn’t have anything in common, but the truth is they do. There will certainly be obstacles in your way if as a company you already have a diverse and fragmented framework and toolset for your testing efforts. Imagine the benefit though when your performance team can get tests up and running by simply calling functions that already interact with the product or having a deployment team easily roll out streams of products because all the end to end tests speak the same language.
That is why companies should invest in rather having a group of architects and engineers design a common framework that all engineering teams will use with their testing. Deciding on what this “language” would look like is always going to be a challenge because some of the tools that the company may already have in wide use are or the different teams have programming expertise in different languages and a compromise can’t seemingly be reached. And I’m not promising that I have a definite framework or answer to every challenge you are going to face, what I can promise though is that if you want to grow your company and keep producing quality software in a timeous manner, you are going to want to invest in it. There will be challenges and the path will likely face pushback from certain engineers, but it’s time to put your short term concerns aside for a long term journey to greatness.
Comments