Identifying the Steps
The steps in the test case must be written out explicitly to make sure that everyone runs the test the same way. That way, if bugs are found, they're easy to replicate. This is why it's important that each team member only run test cases that were written by someone else: It ensures that everyone writes their test cases in a way that can be reproduced.
There will almost always be more than one round of execution and review. After the testing session in which all of the team members execute their tests, the team sits down to review the results that they added to the spreadsheet (or the database). For each bug that was found, the team must make a decision about whether or not to fix it. It is entirely possible that they will decide to release the software even though it contains defects that they know about.
The only rule is that if the team makes any changes to the code, they must agree to spend another iteration running the next round of execution and review. It's often tempting to just fix the code and release it, rather than take the time to run another round of tests. But when you change code, you run the risk of introducing more defects. The only way to make sure the change didn't break the software is to re-run the tests. After all, you thought the software was ready to deliver before you started the integration testing. If you hadn't run them then, you wouldn't have even known about the bug that's now giving you trouble.
To keep this interesting for the team--and to make sure that they all get a good sense of how the product is behaving--the team members trade packets after each round. No team member gets the packet that he or she created. This ensures that nobody ever tests his or her own code, because people tend to be blind to bugs that they introduced. For each bug that the team decides to fix, the person who fixes the defect must create a new test case to verify the fix, and add it to the packet.
One big advantage to having different people test parts of the software that may be new to them is that it keeps the testing from becoming monotonous. Programmers generally only get to work on a small piece of a project. It is interesting and rewarding for someone to see how her piece fits into the overall project. By working with features that other people created, she can gain perspective about what her teammates have been working on. This can really help the team crystallize, which will help them cooperate better on future projects.
There is no set number of iterations that the team must go through. Instead, the testing process repeats until every single team member feels confident that the product is ready to ship. This consensus is the most valuable product of integration testing. Performing these tests will give the team members a good feel for the quality of the software. If they can run through these tests, discuss the results, and still feel that they can get behind the final product, then it's going to be much more polished when it finally reaches the users. And if users come back with issues, the team members will have a much better sense of how they actually use the software in real life, which will give the team a head start in understanding and fixing the problem
