In today's retrospective, a developer complained that he deployed a bug fix to testers and didn't hear any feedback until 5 days later, at which point the bug was reopened.
I'm embarrassed by the above occurrence because I'm a firm believer in providing feedback on new bits as quickly as possible. Let's say you have 5 equally complex features (user stories, whatever) to test by the end of the week. All 5 are ready for testing. One approach (Approach #1) would be to spend about a day on each feature.If you manage to find bugs in some of these features, it's possible that we would not have enough time to get it fixed and retested. The problem gets worse if these are blocking bugs.
Approach #2 works under the assumption that blocking bugs will usually get discovered early and easily by executing your first tests (e.g., your happy path tests). If you do high level testing of all 5 features on day one, you can report the bugs sooner.
While said bugs are being fixed, you can dig deeper in the other areas. If it ain't broke, you're not trying hard enough, right?
Maybe by day 3 the blocking bugs are fixed and you can interrogate those areas again. And perhaps you can follow your tester skills for determining how to spend your remaining time.
Think about how often you've cracked open some new dev bits that have been sitting there waiting for days, only to find they blow up during your very first test. Some flavor of Approach #2 will help.