There are alot of things to consider. First here are some tool links as there are tons.
Various automation companies:
Some brief info on Approaching Automation:
Ok, now that you are thoroughly overwhelmed with data here is the most important things to keep in mind. What is the best value for testing. By "value" I don't mean cost, but importance. If you already have a large code base there should be a few critical components to start out.
- Where is the biggest risk if not tested?
- What has the biggest client impact if broken?
- What code is utilized the most (i.e. if this breaks there will be lots of places that break instead of just one)?
- What is not covered currently by any other verification method?
- What is repetitive and easiest to script and rerun?
Some of these are manual testing questions and some are automation questions, but your goal isn't "what do I automate" it's "how do I ensure the best quality". Once you can determine that in detail it's time to separate what to automate vs. what to manually test vs. what to take a risk on. Based on what you have said in your description it seems you have a group of developers, if you don't have QA folks I recommend getting one. There is a reason it's a separate job and it is because it's a different way of thinking and approaching things. If developers were able to do all the QA there wouldn't be a need for the job itself. It's important to have someone with the right way of thinking and perspective to bring that into the team dynamics. Maybe you already have this person in which case great (maybe that is you...).
Once you have a solid team the answers to the questions will become evident. Risk could be customer impacting, but it could also be something like divergent code bases that are no longer maintainable vs. a centralized approach. It could also be inline styles vs. css or copied code instead of reused code.
This should be your client perspective. If it seems really bad but noone cares, don't put it here as it could offset the whole project. The ultimate goal should be customer satisfaction even if there are some things that are "need to do later".
This will likely overlap 1&2 but the goal is anything that overlaps more than 1 of these is more critical by nature than something that doesn't. Dead code for instance might just be in here, but it might also confuse and make the footprint confusing which causes more breakages. It's important, but not as important as copied functions that are actively utilized but not maintained, centralized coding becomes a 2 part making it more important even though both are along the lines of confusion and duplication.
This will start out huge and hopefully grow smaller over time. The starting point on whittling down this will relate to the other categories. If something seems critical to 3 places than naturally start there first and work towards the lesser impacted areas.
Sometimes the quickest way to improve quality is getting the most coverage first. Even if it's less critical if it covers 25% of the application in 1 swipe it might be worth automating it first.
I recommend doing a weighted point system based on categories to get a proper analysis on the overall scope of the application. After that it's deciding which tools and where to utilize them. This should be part of the SDLC though and not treated as an after thought. If you are going to do this right, you need to change the process going forward to include QA as part of the process prior to release.