The product I've been working on for the last 3 years has been a fairly small thing until very recently, and we've gotten pretty good at testing it.  But all of a sudden we're adding Stuff that increases the testing load - the GUI can now be used with multiple browsers, not just IE on Windows.  We've added some functionality and ease-of-use features that (1) have to be tested (2) have to behave consistently between the GUI and more-limited TUI interfaces (3) multiply the ways various other features can be invoked, which all need to produce the same result, and (4) make it very attractive to use a telephony feature that used to get very little use, so used to get fairly light testing.

The Sales people are delighted.

I foresee much angst over test duration estimates, the next time we do a major release and have to test the *entire* product.

I'm currently updating some test documents, with no urgency on the task, so I'm taking some time to think about whether some test cases are actually providing useful information.  Anything that's there now certainly seemed like a good idea at the time it got written, but sometimes, later and more detailed understanding of what some area of the product is really doing makes me realize that a certain test isn't actually useful.  If it isn't useful, it needs to go away. 

I hope I get get my coworkers do do likewise as they update test docs, but I'm thinking that probably won't bring down the complete test execution time as much as we'll need to.  I think we'll need to add some exploratory testing of the GUI (guided by knowlege of what sorts of things work in one browser and break in another) and some explicitly tracked combination testing, so that we aren't going numb and missing problems because we've run the same test so often. 

I don't immediately see any way for additional automation to help ... must think about that some more, though.