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.

The puddle on my XPath

I always tried to stay out of the XML world, but there is no escaping for me now. Currently, I have to deal with the Open Archives Initiative (OAI) Protocol for Metadata Harvesting (PMH). This appears to be a popular protocol to disclose public archives. Technically, it boils down to XML messages with lot’s of different namespaces.To give you an example:

<?xml version="1.0" encoding="UTF-8"?>
<OAI-PMH xmlns="" xmlns:xsi="" xsi:schemaLocation="">
<request verb="GetRecord" metadataPrefix="abc" identifier="AB.abcid1"></request>
<ns1:ns1 xsi:schemaLocation="
<ns1:beginTag xml:lang="en-us">

Now, how can you select with XPath the content between the metadata tags?

The metadata tag is in the default namespace, so my first guess was to use


as XPath. But to my surprise this delivers not the content between the metadata tags. It appears that although the tags record and metadata are in the default namespace, there is no link made with the default namespaceuri.The solution is to create an artificial NamespaceContext with a made up prefix and the default namespaceuri. Let’s take for the sake of the argument ‘oai’ as prefix for the default “” namespaceuri. The XPath expression would then look like this


This delivers the content between the metadata tags.

Every technology has it’s quirks, but I hope not to meet many of them in the XML world. XML appears on the surface simple, but combined with XPath and XSLT you really can find yourself lost. I rather stick to Java were I am in my natural habitat.