Legacy products usually have some common themes around them. Typically older technology stacks along with ‘not so efficient’ processes as well. Among the many legacy teams I’ve known, I see this pattern clearly and has an immense effect on automation initiatives.
Front end testability
Most applications using older technologies do not have a sound architecture at the front end, a central location from where the application on different layers can be controlled. If using a framework like Angular 2, there would be a central control flow and defined modules. With classical applications, since all web traffic is asynchronous, there are might be multiple frames running around independently creating a sever timing issue for automation. This cannot be generalized obviously but many legacy applications might have similar problems.
Apart from finding dynamic delay challenge, for UI automation you might get lucky or in serious trouble. Either all objects would have unique IDs since they are independently created and sent from the back end, or they might be using some really outdated framework which hardly any UI tool would understand, in which case it might be best to let go of UI automation.
Mostly it’s the former case because pages are typically designed by the developer at the back end. With modern frameworks like Angular, they facilitate development by doing the heavy lifting and require just a skeleton design at the front end and sending data to display from the back end. That makes life easier for rendering the page, but the DOM is not that ‘UI automation’ friendly then so to speak.
Back end testability
Back ends or the business layer would be even worse. Exposed APIs which can be used to create API level tests might be very few, again a generalization, but not as many as a containerized application for sure. Plus since the APIs were not designed for other than developers to consume, sometimes it’s really hard to make sense of what’s going on. In many cases the documentation might not be as strong either making it even more difficult to decipher the web services.
This has a greater impact than most would imagine. Tests at API level are efficient and easy to maintain, which goes a long way in automation. Trying to test everything from the UI level is not possible and takes lots of ‘unnecessary’ effort.
The same might happen on the database layer. Except for the UI level, nothing else might have been prepared keeping in mind anyone other than the developers would use. The database schema might have similar architectural challenges for testers. Finding out what tables are being updated and when and architectural change does happen in the schema, noting its effect on tests might be another challenge.
Release and patching
Like server side programming, the release process might not be designed for anyone other than the person doing the patching to interact with it. To get the most out of automation, some level of continuous integration would go a long way. This piece can vary a lot from team to team, but at times this can also be a big challenge. Getting hooks into the source control manager might not be as easy. The processes being followed might not be compatible with the true essence of code versioning, which might necessitate getting the release process changed first.
Second problem would be rendering test environments at different stages of the SDLC. Traditional testing might not be requiring that before automation. But automation would need separate environments on all stages we run tests. Render isolated environments on demand which can patch the latest code base and get latest automation tests would not be easy to being with.
It’s more than just the technology
The technology is not the only important piece. The culture in legacy teams is the bigger challenge. These teams are mostly formed by a few colleagues who have been working for a very long time together. In the early years of the product, the processes they used might have worked perfectly for them. But as technology changes happened and eventually senior team members start to leave and new folks come in, the legacy processes start to fall apart.
The culture part is far more of a significant player, which we will examine in the next post.
It’s still worth it
If you do have a legacy product and are looking to automate it, it might still be worthwhile to automate it. In the process, the complete product team will have to evolve to some extend as well. The truth is, it’s better to evolve than to be extinct. All the challenges we discussed and more that we will shed light on in future posts, all do have ways to solve them I believe. The point is it’s not going to be a cake walk and to have realistic expectations of what to expect from this endeavor is the whole point of this post.
Ali, you have hit every point on the head here with regards to Legacy systems. I can relate to each point you have mentioned above. I have overcome some of the challenges you mention, it is definitely not easy and definitely not applicable in every legacy system out there.
Thanks again for your great article.