Test object: a big monolith application (~500k loc) developed in Java for the last 15 years. Big and (probably overly) complicated backend + web frontend. There are many business processes implemented in the app. Currently there are 10 teams working on it.
Tests: there are unit tests and integration tests implemented. Code coverage is at around 70%. There are also MANY automated system and e2e tests implemented in a commercial test tool.
there are way too many system and e2e tests. They were added over the years as at first there were no other tests being written. Only after a while someone thought of adding Java-based unit and integration tests.
Apart of the code coverage of the unit und integration tests the test coverage is a big unknown. The knowledge about which functionality is tested by what system test is kept only in the heads of the testers. There is no real way to know which tests need to be fixed, when a new story is implemented, other than running the regression test suite and to look what broke.
Question: In my opinion we need to get rid of a big chunk of the system tests ASAP, as they are not maintainable any more, flaky and take waaay to long to run (~24h concurrently on 50 VMs). There are dead tests, that test removed functionality, many duplicates etc.
In order to do that first I would like to know the test coverage, to be able to tell which tests are useless and can be deleted safely.
I am looking for a way to determine/estimate the test coverage in such a project
The obvious way of connecting the test with the corresponding user story/requirement will not work, as for quite many of the implemented functions there are no documented requirements.
The monolith is right now in the process of being refactored into roughly independent modules. The current idea is sorting the system tests based on their belonging to these modules. Additionally the tests belonging to one module can then be sorted based on the business process they test inside that module. With this I should have database of tests broken down by the modules and then by business processes, and thus a rough test coverage estimation by process and module. This still does not convince me, as being the best approach though.
So does this make sense? How else could the test coverage be determined/estimated?