Adopting the scrum process for software development can have some unwanted
side effects. As we pick up in each sprint small stories, testing
becomes too narrow focused. The tester is often testing the internal
workings of the application. The reason is that we need more than one
sprint to complete stories that converts input to output.
We are currently developing a middleware application. Because of the
small size of the team we keep the stories necessarily small to digest
them in sprints of three weeks. The drawback is that some of these
small stories do not fulfill a complete requirement. The story does not deliver an end product, but an intermediate one. The tester directs his efforts to test the result of the sprint, which in the case of a partially ready requirement, is on this intermediate product. This causes that the internals of the application are tested, tying acceptance tests and internal workings of the application together.
The danger is that in the upcoming sprints the developers may refactor the interal solution for a better one. Moreover, in the next sprint the tester uses his old testscenarios with new testscenarios in a sprint that could finish the requirement with a follow-up story. But by finally finishing the requirement with the follow-up story, the testscenario for the old story is useless.
Therefore, a tester must always be focused on the whole and be critical about his testscenarios. Ask a member from the development team to review the testscenarios so no useless work is done. Likewise, communicate as team that a story is partially completing a requirement. Communication is key. The question remains if you should deliver partially ready requirements as a potentially shippable item.