As the other answers have said, there is no "typical" process. Everyone handles things their own way.
That said, there are some common factors:
- most places will have some form of test plan repository. I've seen
everything from a mix of documents and spreadsheets in a shared
directory structure to the high dollar professional tools.
- most places will figure the test plan gets executed manually. It's rarely a good idea to automate manual test plans - what constitutes a good manual test is not necessarily a good candidate for automation.
- most places that automate will have a way to identify tests targeted for automation and a strategy to add targeted tests to their regression codebase. The exact strategy varies a lot.
- places that are serious about automation will not use record/playback whether their tool supports it or not.
- places that are serious about automation will treat their automation codebase as code
- places that are serious about automation will keep their automation codebase in a version control repository. It may not match the application code version control repository, but if it isn't matching the application codebase version control, it will be flagged in a way that allows regression to be run against any version of the application codebase required.
- places that are serious about automation will ensure that time is devoted to maintaining automated regression.
- automated regression for a new feature will not be built until that feature is stable.
It sounds from what you've said that you've got most of these points covered, so you're probably on the right track with your process. The main thing is that it works for your situation.