With GUI-based test-automation (e.g. with Selenium) you establish a system of checkpoints (=testcases/ =scenarios (in terms of gherkin)) for the functionality of the software. The functionality is a set of features. Features have 0..n checkpoints. Beside the system as a whole, every checkpoint is ressource-consuming. That’s because you have to establish and maintain them – the latter in case of the feature changing. Hence the checkpoints shouldn’t be uniformly-distributed over the software for logical reasons. There are 3 main criteria for deciding about the density of checkpoints and which influence the efficiency of your test-automation efforts:
1.) criticality of the feature: How important is the feature for the over-all-functionality of the software – ask the manager!
2.) fragility of the feature: How frequently bugs have appeared in relationship with the feature in the near past – ask the developer!
3.) persistence of the feature: How probable are changes to the feature in the near future and as a consequence a ressource-consuming maintenance – ask the manager!
With these criteria you can make a lightweight plan, where to start the test-automation.
Over the time you add more and more checkpoints as new features come and as you learn about the „organism“ of the software.
Learning should result in heuristic rules like „make a new checkpoint for every new bug“.