During Implementation
A tester’s role during implementation depends on how close the tester wants to be to the actual implementation of the system under test (SUT). If they are meant to be an independent tester, then treat the code as your Kryptonite. Don’t go near it! The less you know about how it’s implemented the better. Ideally you should know nothing, but depending upon your operating environment that just might not be possible. At the very least, you had better be able to forget about the how when you go to verify that the system does what it’s supposed to.

During the implementation phase of the project, the test team can take a built version of the system and exercise it inside its intended operating conditions. Testing should be performed from the perspective of all human actors in the defined use cases. This protects against the team concentrating too hard on one actor’s perspective. These “stagings” can be performed weekly, bi-weekly, monthly, or even daily if they so choose. How often depends on how quickly we want/need to receive feedback.

Hopefully the developers are performing test-first development (for all our sakes), but if they aren’t the test team will need to be extra vigilant during these stagings because they are effectively performing the unit and unit integration testing.

An added benefit to staging is that by the time the system tests roll around the test team should be well versed in the system. They should know what it’s intended to do, how to make it do those things, and what caused the most frequent failures in the past.

A note on communication. Test plans and procedures should be “public domain” on your project. Everyone should be able to access them at any time, specifically the development team. If the developers know how you intend to exercise the system, they can make sure the system works in those cases. Remember that the point isn’t to catch the mistakes of the developers to humilitate them. There is no line drawn in the sand, we’re on the same team! The point is to catch problems across the board to protect the project and the people working on it.

The sooner we catch these problems, the easier they are to fix.
The easier they are to fix, the cheaper they are.
The cheaper they are, the less overhead we incur.
The less overhead we incur, the more work we can perform with that excess.

Or we could just take that money to the bank. Either way, less money spent can be allocated elsewhere.