The old SDLC waterfall method has each phase start at the end of the prior phase. This can lead to a lot of wasted time and a 'throw it over the fence' attitude.
There's a concept of coding to the test, as in the TDD which was mentioned in Michael Durrant's answer, which basically means that the test team gets in at requirements time and helps design tests that will satisfy the requirements, then the code is designed and written so that it satisfies the test, thus the test team is involved very early on.
It's a truism that the earlier an issue is identified the cheaper it is to fix. I can't cite a source, but I've seen it presented as an order of magnitude at each phase. If it costs $1 to fix a problem in requirements, it will cost $10 to fix it in design, $100 to fix it in development, $1000 to fix in test, and $10,000 to fix it in production. Whether the actual costs really follow such a curve isn't something I can speak to, but the general principle is sound, so it makes good sense to involve the test team right off the bat.
In an agile environment, this sort of forward thinking is baked right in to the process.