A strategic approach
If you cut a couple of hours and don't make other changes than next week more tests will be added... and the time will increase again.
So this is an excellent opportunity for a discussion on strategy.
Not to seek immediate answers (hence I'm not providing them), but to start the conversation for your given situation to see what will work for you.
Items worth discussing when focusing on value:
- How to know the value of testing a particular device / browser / version? 8 hours is already a subset of the hundreds of hours you could take to test more devices and browsers and versions.
Don't spend $500 fixing a device that one user, revenue $3, uses.
Always talk % of users, not IE version for 0.0001% of users when choosing browser support.
- How to choose unit vs. integration vs. UI testing?
Time to talk test pyramid and agile testing quadrants
- How to choose happy vs sad paths? There are infinite number of sad paths. How do you decide which ones to test?
- How to set up parallel testing?
- What are the current bugs being reported when changes are made?
Creating tests for real pain points can often add the most value
- What breaks the most when developers make changes, either for functionality or in the UI. Create automated tests for those breaks.
- How to 'stub' UI dependencies. This can be the 'big' slow down in calling network services (APIs etc). Set up mock data or a local proxy server with canned responses. This can be dramatic.
- Use production monitoring of dependent services availability without going through all the UI. Consider monitoring services and using Postman (for example) for checks for API endpoints. This way you'll still know if real production breaks but you can mock and stub dependencies for your tests. Test endpoint format to check breaking API changes.
However... this is what your manager themselves should be considering. If they are not... and you are... you can end up in a very awkward place. I've been there myself. In such a situation you should prepare a long list of questions that start to prompt your managers thinking to change. This change however has to come from them, You can only provide good leadership to them. Leadership is not always managment though we initially think it is.
In this light maybe try to gently start conversations about what is most important to test ('everything' is not a mature answer but bite your tongue if told this). People don't always behave logically (in the best interest of the company and customers that is) in 'management' situations where the style is authoritarian ('you must do x') as opposed to collegial 'How can we work together to meet this objective'.
Focus more on asking additional questions that will guide your work instead of focusing on statements such as 'technically cannot be reduced or removed', 'Technically is impossible'. When you use such absolutist terms to stress your argument you actually lose faith because programming in the real world is a pragmatic activity not an exercise in logic.
Save impossible for anti-gravity machines. At least for now ;)
- layout the factors affecting the choices to take (cost, coverage, people, etc).
- provide various alternatives with pros and cons for each
- let management pick the approach. Be sure you have covered the cons well.
- the options are essentially always: more computing power, more people power and reduced ('better targeted') scope.
The factors to juggle and balance are money, people and time.