How an automation engineer could maintain a large messy existing test code base?

Question

Background: For an UI automation large codebase having thousands of Selenium tests, which multiple people have developed/updated/patched over a period of few years. There is no documentation/manual test cases mapping these automated cases as well.We are talking 20k + lines of code with more than 2k + tests.

Problem Statement: Given this big test suite , in which many badly needs update to properly work in first place as many tests are kind of patched just to make it work without much consideration of overall design and structure of the test suite.

Current Situation & Proposed solution:As a QA automation engineer, we need to maintain this suite and keep it updated against current UI however it seems there are deeper issues on the overall design of the code base due to numerous code patches over a long period of time which brings issues like code redundancy, magic numbers,tight coupling & other design issues for which 'refactoring' is the general remedy.

Question:What kind of strategy/approach should be considered to maintain/update/refactor such kind of test code base(mess) considering return on investment in Agile world?

Note: Too much specifics are intentionally not added to keep the question more generic as I am not referring to any specific project but to a more generic test automation problem.

Answer 1

Well, I believe there is no proper answer here. There is also a lot of details missing here which could bring the light on certain aspects of the issue. However I can see couple of possible ways here:

Another thing is that we need to have a clear problem statement. What does "maintain" mean and why would you need to "refactor" existing tests.

However I have some thoughts which could probably be applied to some general maintenance/refactoring case:

1. I would measure the execution time of each of your 2k tests. With certain assumptions we could consider that the tests which take less time are more "atomic". Fast tests probably could bring more values for regression practices since you can integrate them more effectively in CI process. Having such breakdown I would go group by group and migrate them (refactor) to more effective architecture (taking advantages of OOP). This advice is applicable to the cases when you need to integrate your tests into well-structured code and you have not very much time.

2. As you mentioned you have 20K lines of code and 2K tests. Which means you have 10 lines of code per test in average. This makes me think you have some sort of code reuse and class hierarchy since 10 lines per test is quite a small value for even a very atomic test. This might play a positive role if you have the time to migrate your tests within some more or less big time range. When you see that your test needs some changes (for example it stops working because the application changed its design) you take that test and integrate it into a new well-structured code-base. So you do that one by one (each time when your sequential tests becomes a subject of change demand) mastering the new code structure.

Both the ways can be done in some separate branch which can be used as the alternative test execution. Thus after each integration your "old" branch will decrease the number of tests and "new" will increase.

Answer 2

Suggestions: There may be many other opinions or ways to deal with this situation. But what I tried when I faced this are as follows:

• Do not directly consider what all task needs to be done across amount of code
• Choose premium functionalities + priority tests and fix those specific tests first
• As few repetitive used tests/methods get fine tune with correct & structured manner you will see things and ready for you to consume as a fast food. i.e. ready to use as it is in other tests
• I experienced if we identify huge task is to be done individually we might fail to plan and it actually means we are planning to FAIL

All the best, You can do it!