User Stories – Testing Early
We all know agile encourages early testing. So If this is the case, I see the tester best placed to write User Stories. Let me explain...
Whilst practising waterfall development at a previous place of work , I was asked if I'd like to help capture some requirements and write some functional specifications. At first, I was horrified at the prospect of this task, but as a person who never backs down from a challenge, I reluctantly agreed.
The whole experience was truly an eye opener, and I realised that testers can actually make good alternatives to the traditional BA (Business Analyst).
Rather than a BA writing the spec only for the tester to rip it to pieces and going through numerous reviews and amendeds, it was found that us testers have a knack of spotting if things are not going to work. And with our 'what if?' mentality, we can iron out these issues as we're capturing the details saving the need of a lengthy requirement process, development time and costs. I think of it as cutting out the middle man. Now I'm not saying my spec was perfect, but it was good enough to palm out to a remote team to develop. This also made test planning easier as I had written the spec in a similar style like test cases.
Now in Agile we don't have big functional specs, instead we have user stories that are like these but only smaller (bite size). Traditionally these are written very close to the start of a sprint with just in enough detail to start developing. However, sometimes enough is not enough and too much time is spent clarifying details during development. Now If a tester were to write these user stories upfront as acceptance tests bearing in mind the 'what if?' scenarios, I believe you can get the balance right between 'enough' and 'too much' detail prior to development. Clearly this is what testing early is all about!