The relationship between the test team and developers should be close and harmonious, with high levels of communication.
The programmers expect a few things from the test team:
Come along to the standups so they know what's coming soon and feel part of the team.
Thoroughly test specific functionality when delivered.
Know which version of the software they are testing.
Report problems back to the team leader, stating which version the problem was found in, what conditions were used to create the problem, and how it can be reproduced.
Know the difference between a stated requirement and a nice-to-have change.
Try to avoid interrupting the development flow at all.
Have the strength of character to reject a release that isn't sufficiently tested.
In return testers may expect a few things from the programmers:
Code will be desk checked before delivery to the test team.
Advice on how complex parts of the software could be tested, perhaps some prepared test data.
The releases will be numbered and reproducible (source code control).
Releases will be supplied with release notes to explain what is new and what has changed.
Bugs will be marked as fixed in a particular release so they can be retested.
Planned releases on specific dates.
Documentation against which the code was done (eg. use cases, requirements documents, wireframes).
If some of these do not occur, testing can be of limited value to the project.
Tip: Independent testing (i.e. non-programmer testing) is always beneficial for overall software quality. Testers are trained to look at a solution from a different angle to a programmer and will find off-the-wall problems. Always support independent testing.
