Testers who are new to agile software development often struggle to find a way to test the code in smaller pieces. This is mainly because they are trained to test only after everything is done. It is big change in mindset for them.
I think testers should take an approach that they are just trying to see if the code works. Though they might be really testing it, an “I am just trying to see… “ mindset will make them loosen up from the formality of entering bugs etc. Every time the developer says that something testable is checked in, tester should try it and inform developer if it doesn’t work. This notification could be as informal as telling the developer at the water cooler or send an email or add a task card to the task board.
Once tester has tried the functionality enough times and gained confidence that the functionality is mostly working, she could do more formal testing. However, at this point, testing the standard cases should be a breeze, and that allows tester to spend more time on exploratory testing.
Sure, this causes fewer bugs to be entered in the defect tracking system, and some testers seem to be concerned about that. One tester told me that her performance review is based on how many bugs she entered. I think it is a really bad thing to use that metric. In this situation, probably the tester prays for her teammate (developer) to fail, so that she can have a better performance review. All members
of a team should have common set of goals rather than conflicting ones.
Another concern I’ve heard is that if you don’t enter bugs, you can’t control the quality. That doesn’t make any sense, because at the end of a sprint, if you don’t have any bugs to enter, the code is of highest quality.