How to make management to accept major refactoring of the test codebase?

Question

Our test codebase is relatively huge - more than 1300 tests with about 23000 lines of JavaScript.

We've been thinking towards migrating to a TypeScript and/or potentially to a different testing platform (like Cypress), which would involve major refactoring of the whole test codebase. But, I can already imagine difficulties proving the need to management and trying to come up with answers to "our tests are working and helpful, why change things and invest time/money?" question.

What are the general tactical moves and supporting arguments to make the management accept such a proposal?

_{(I would like to keep the question on a high-level having specified migration to typescript or cypress as base examples only)}

Answer 1

To add to Rsf's excellent answer:

You can't "make" management accept anything. You may be able to convince management that migrating your test codebase is a good idea. If you can demonstrate that a migration stands to improve ROI by enabling any of the following advantages you stand a better chance of management approving the change:

• The proposed new framework would allow new tests to be added more quickly than the current framework.
• The proposed new framework would have fewer flaky tests (this can be very difficult to demonstrate).
• The proposed new framework can better manage large numbers of tests (i.e. it is more scaleable).
• The proposed new framework is easier for test automation specialists to learn to work with.
• The proposed new framework allows an easy way for non-automators to add new tests (If you are data driving your tests, this is a feasible argument to use).
• The proposed new framework allows for better integration between the test automation team and the development team (that is, it will be easier for developers to assist with automation and/or use the framework for unit or integration tests).
• The proposed new framework has better support than the current framework.

You are going to have to make this a business proposal, using automator time requirements for maintenance and failure inspection as your proxy for the cost of running the current automation solution. If you can demonstrate that your proposed solution will reduce the amount of time needed by test automators to add new functionality, maintain the existing functionality, and analyze test failures, then if that time saving is enough that the test automation team would "earn back" the time to implement the proposed framework within a reasonable period, the business may decide it's worth doing.

Just to illustrate (numbers are pulled from nowhere: this is not a realistic scenario):

Let's say your current automation team needs, on average:

• 12 hours per week analyzing test results
• 12 hours per week maintaining the current codebase (making changes to account for changes made to the AUT)
• 30 hours per week adding new functionality (i.e. new tests for new features)

That's a total of 54 hours per week dedicated to keeping the current test framework running and up to date.

If it's going to take 400 hours to convert the existing framework, and after that maintenance will be:

• 5 hours per week to analyze results
• 3 hours per week to update to handle code changes in the AUT
• 30 hours per week to add new tests for new AUT features

You will have a total time of 38 hours per week to keep the test framework current - 16 fewer hours than the old framework needs.

That means that you will "earn back" the 400 hours conversion time in 25 weeks - just on 6 months. That's an attractive proposal for a business.

Obviously the numbers aren't that simple, and your projections will be largely guesswork, but being able to give this kind of information in a proposal gives you a much stronger case.

Answer 2

The answer would be the same as for any other project and change- if you can't justify the change for yourself why would you expect others to approve ?

So start collecting facts and statistics, for example-

• How many bugs were found in your test code
• How long did it take to fix those
• Can you find the root cause of those bugs and link it to code complexity ?
• How long, if at all, it takes others to add tests
• Some numbers about code complexity, even simple ones like number of layers between X and Y
• Are there scalability, performance or other -ility problem that you can directly link to your code complexity ?

TLDR; use facts, not vague ideas

Answer 3

In his SOLID course UncleBob says:

• The primary value of software is that it’s soft. The ability of software to tolerate and facilitate such ongoing change is the primary value of software.
• The secondary value of software is its behavior.

Most people think the secondary value is the most important though.

I fully agree with UncleBob here. The main job of a developer or test-automation-engineer is to be able to maintain and extend an existing codebase.

Therefor refactoring is part of the discipline of software engineer. You continuously refactor your code, so that you do not have to do major refactorings. Every Time you need to change your code you first restructure it to facilitate the new change in such a way you do not have to change it again in the future.

Now you have to go to management and tell them you didn't do your job (in retrospect) and made a mess out of it. If you don't clean up you will go slower and slower in the future. I would watch the first free episode of CleanCoders together and discuss the options. I think he clearly shows examples of the problems if you do not refactor and clean your code.

See if you can clean up in small steps. For example every time you touch something. A major refactoring starts sounding like a re-write...

Answer 4

Go Agile.Take small incremental steps.

In these situations, I normally implement a small MVP(minimal viable product) through a quick smoke suite implementation of a highly business critical and small module in the AUT and demonstrate how quickly new tool/technology/framework solves a problem X more gracefully/cost effectively.

Then based on feedback I will plan the next steps then next and so on.But keeping the feedback loop fast and effective is the key.

Practically, as per my experience, there is no such thing as complete re-write/major refactoring in the single go.It's simply a NO-GO from a management perspective.

Plant a seed, not a tree.