I understand that, in theory, QA should be working with dev "collaborating" right from the day 1 of a sprint. But how does it actually work in real life? Let me present two scenarios -
Scenario 1 where a story requires 3 days of development - Let's say it's a complicated report with time consuming database setup and domain logic etc and takes 3 days to code. Since the dev can't deliver anything meaningful to test before 3 days and assuming it takes only 4 hours to write all relevant test cases, what is QA expected to do until the report is ready for testing?
Scenario 2 where stories are tiny enough to be completed in hours - Let's consider a login/registration screen. There can be tiny stories for user being able to login, user being able to register, forgot password functionality etc. A dev can complete each one of these stories in hours and pass on to QA and move on to the next story but the next story might break the previous ones. For example, if dev finishes up login functionality and QA starts testing it and then dev starts working on forgot password functionality, it might the break login in unexpected ways because the functionalities are indeed related. If QA waits for all of the related stories to be completed then we end up with scenario 1 above.
In a perfect world, QA can be expected to do nothing if there is indeed nothing to do and accept it as part of the cost. But in a real world, PMO and other groups keeping track of resource utilization will certainly point it out as poor project management and worse. So, how does it all work in real life scenarios? How best to apply Scrum in these types of scenarios?