J
A few things to consider come to mind:
Only run in Chrome
Controversial huh? Let me explain more fully though. My question for multi-browser and indeed multi-device (responsive web sites) testing is always what kind of browser / device specific issues have we seen and do we expect to see? How many browser specific errors have occurred in the last year. That's the first question. frequently the answer is yes but the business demands that we support x,y,z, versions a,b and it means hundreds's of thousands of dollars a year... and before you know it boom everything takes 6 times longer for those combinations... So there is a second piece - blue/green releases. This is the process of being able to release two versions at once. The idea is that you release a small percentage of one version. You can start with 1% and then you monitor that version and the browser breakdown and if you see a browser specific issue you can roll back the new release to 0% and the old release to 100% and then investigate the issue. You'll only have affected a very small number of users, but you know that 100% coverage of every device ever doesn't ever happen either. The key point is not much money loss or customer inconvenience. The reason behind all of this is to speed up development and head towards waiting for minutes for full test runs rather than hours or days and thus enabling continuous integration and continuous delivery. This requires that there be a role for analysts who monitor the staged releases to know when there issues. Sometime you pick a quiet time of the day (depending on market) to do the release to avoid issues with user sessions, cookies, etc. May take a little fiddling here to get it right but I've seen it done.
Session adaptation
What this means is look into a way that you can get to a particular point in the UI by going directly to that page. Users may need to go through many pages but there are ways to set test sessions to just go to the desired page. With multi form page workflows that can be very significant. One example of this is ruby-rspec-capybara and the rack session gem https://github.com/railsware/rack_session_access
Parallelism
Not really sure from your answer if you are doing this but you definitely want to use the cheapo power of multiple virtual machines in the cloud to speed up tests. You'll need to make sure the tests are independent from each other which you should be doing, e.g. correct setup and teardown procedures for each test.
Run headless
There are a couple of flavors here. First is using a headless browser like phantomjs but we've found it only works for some tests, mostly non-js ones.
The other (exciting) news here in 2017 is that google has produce a headless version of chrome, now available for download at https://developers.google.com/web/updates/2017/04/headless-chrome
I haven't played with it yet.
Tag browsers specific tests
Tag tests to only run other browser tests for certain functions
You may now from experience which pages or areas have historically have multi-browser issues. Based on this knowledge pick out a subset of tests that you want to run in the other browser(s), tag them appropriately and then setup the full suite to use those tags in runs.
Get funding dollars
Make the case to management for more funding for the vm's and other tools.
So the tests take 5 hours. Lets say that means that 4 people have to wait a couple of times week for that. So that is 40 hours in lag time, in other words a full developers time. If a developer costs $70,000 a year, how much should you spend on vm's in comparison ? The fact they are different cost centers on different budgets, blah blah should not be an excuse for doing the right thing for the overall business finances.
