Scrum and Testing

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.


The power of the Scrum taskboard

At my job we are using Scrum developing projects. After each sprint-planning we fill the task board with stories and tasks. Recently, I noticed the team gets really focused on these tasks. As a side-effect tasks which are important to the project, but are not on the board because they were so obvious, receive less attention. This behaviour had some serious implications for the sprint goal.

To counter this behaviour, I have asked each team member to explicitly name their tasks for the sprint goal and put it on the board, even if the task was little or obvious. This seems to work.