When a bug is fixed, the dev set its status to "resolved" and the bug is reassigned back to the person that created it. In our case this is usually the product owner – we don't have dedicated testers.
But what's a good process for controlling how/when the PO tests the software? Should he be given the latest build after each bug is resolved/checked-in? Or what about every morning? Or should he only receive a build at (or close to) the end of the iteration, to include all of that iteration's new functionality and bug fixes?
We are using TFS by the way.
Best Answer
In most agile environments that I've seen, a continuous integration environment exists. This produces new builds and executes a test suite on that build on a regular basis - after every check-in to the integration branch of the repository, every night, or every week. It depends on how long and complex the build/test cycles are - it may not be feasible to do it extremely frequently.
In terms of when a build should go to a person for user acceptance testing, after every bug fix seems a bit too much. You should have automated unit and system tests that are ensuring that your builds are fairly stable and to find any key issues. The exact time to carry out user acceptance testing depends on the number of bugs fixed and the length of your iteration. The earlier you get feedback on the work, the better, so that it's possible to resolve any issues with the fixes or new features.
My recommendation would be to make a build available for user acceptance testing as frequently as possible (preferably every morning). This build should have already undergone developer testing and automated testing. The user acceptance testing should happen as often as schedule permits, but it may not happen daily. You need to note the risks of waiting too late for user acceptance testing - feedback on new development or fixes may have to be put off until the next iteration.