Automated tests maintainability

From time to time while reading different publications we may find the opinion that any "heavy-weight big vendor" automated testing tool ( actual tool names are usually omitted ) is associated with such thing as unmaintainable tests. But at the same moment any hand-made solution or even simple library is positioned as something flexible and easy adaptable. Of course, I also prefer taking something little and simple and using it effectively rather than taking something heavy-weight and thinking hard about how to bind it to my processes.

Nevertheless, such comparison between tests maintainability and automation tool is at least incorrect. Maintainability problems are mostly point of "crooked hands". In other words, it's low qualification problem of test engineer developing automated tests. And this is really issue. So, in order to make automated tests maintainable (this point is very critical for automated testing ), we need to follow the idea: one code modification per one functionality change. It means that in case some separate application under test functionality is changed ( either on core level or GUI level) the modifications to the test code are applied in one place where these modifications really take effect. Of course, it's an ideal model but there are some approaches to achieve it as much as possible.

1. Correct code design. Everything begins from this point. In order to make code easy maintainable we have to make it readable at first. Almost every widely used programming language has specific naming and code conventions. At least we may develop our own conventions (e.g. SilkTest tool has its own built-in language with some specific features). These conventions have to be developed and code has to be checked to fit them ( using automatic tools as well ). Firstly, this is effective way to set up and control single coding style for all team. Secondly, this is one of the most effective way to reveal and neutralize the "parasites", the people intentionally writing code which is difficult to read with the only aim to position themselves as irreplaceable because in this case they are the only people who is able to read and maintain the code. Such phenomenon is not so rare due to some reasons but it is not good and we have to deal with it.
2. Components decomposition. Very often during automated tests development we may notice that some part of the code is copied very frequently. It's widely spread practice at least owning the fact that in testing there is some common or similar action set for different components which makes almost the same or similar steps to do. As the result, in case we clone some code fragment in many different places and after some time there comes necessity to make corrections in this cloned part then have to modify all occurences of cloned code. And this highly increases maintainance costs. In order to avoid such problem this code may be brought out to some separate function/method ( or any other module type ) specifying varying parameters. And finally, we have only to call corresponding module everywhere we need the actions from it specifying required parameter values. This can be done almost always. The main thing is not to be over-diligent in it. Each code is reasonable to group under some module in case it occurs at least twice in some other part of test code. Also there is a reason to think about specified module scope. There are test-specific modules groupping just some repetitive steps or test actions. There are some application-specific modules using some components related to application under test. There are modules specific for some platform or technology ( technology-specific ). And there are common purpose modules having no relations either to application under test or any specific technology/platform. We may develop some criteria to divide all modules into the classes described above. Such decomposition has some advantages:
   
   
   
   1. In case of application under test modifications it is enough to modify modules affected by product changes and all tests calling updated modules are adopted to recent changes.
   2. Some modules may be groupped into library which can be simply moved to another projects. This ability highly decreases costs for next similar automation project development. The bigger the library this greater cost savings we achieve. It's very important but unfortunately the most of the automation projects I've seen do not have ability to take some part of the code to another even similar project. It's mostly related with the fact that such automation projects require some outcome just here and right now and nobody is interested about future projects. Nevertheless, we have to think about it as early as possible.
3. Fixed GUI objects access interface. GUI-level testing specific problem is window objects definition. In most cases application under test modifications affect some changes in GUI. So, automated tests working on GUI level require modifications. The most universal GUI level maintainance optimization approach is to separate window objects logical structure from their actual "physical" structure. The idea is quite simple. We describe window objects, group them into structures according to their visual presentation and logical sense rather than their real window hierarchy. As example, web-application table objects may be used just for some elements placement. But visually these tables are not taken as tables ( they may be even invisible ). For example, you see login/password entry form and visually interpret only input fields and buttons as some window objects. And you don't pay any attention to the way these window objects are aligned on the page. But in most cases they are actually aligned by means tabl objects. So, in this case table doesn't have any functionality. It's just decoration. As the result, we have to describe window structure in such way that there is some main page and this page has child elements represented by input fields and buttons.
   
   Several GUI level automation tools have built-in capabilities for such objects organization and definition. Some other tools require some work to do in order to achieve this result. It would be especially difficult to implement such idea using tools which do not support OOP because window elements actually correspond to objects and it's difficult to define hierarchial structure using procedural programming. But in case OOP is supported the wrapper classes will be very useful.

Each of the points listed above may be described in more details. Here is just an overview of existing approaches optimizing maintainance costs.

P.S.: I didn't concentrate on any specific automation tool because approaches described in this post are common not only for automated testing but also for programming in general.