More Agile SVT thoughts
Back in May I posted these thoughts on Agile SVT and I’m please to find I wasn’t too far of the mark all those months ago.
I was going through a presentation on ‘User Stories’ and one of the slides (page 73 out of 89) was dedicated to ‘Writing Stories for SVT scenarios’. Here’s the gist of it:
- §Write stories to test different System Verification Tests
- –OS testing, reliability, load, stress, security, serviceability, consumability, integration, usability, accessibility, scalability, migratability, availability, …
- §Work will often require more ‘tester’ effort, than ‘developer’ effort
§Examples:
- –As a system administrator, I want the system to support 500 concurrent users with sub-second response time with less than 50% CPU utilization.
- –As a solution deployer, I want to migrate from version 3 inside 1 hour.
- –As a principal, I want the system to be able to support 40,000 users and to be able to run on my existing servers.
- §Some system requirements will be tested across user stories
- –Ex: Test on IE and Firefox.
Good to see this is the recognized way to go. To me, the important thing here is to have the whole team understanding what user stories are going to be delivered by SVT (and perhaps even more importantly what user stories are NOT being delivered). Hopefully this will force teams into really thinking about what a deliverable is supposed to do. I remember some years ago working on a product that was capable of passing large amounts of data around a network. I was reliably informed that there were no architectural limits on the amount of data that could be passed around, so could I do some testing with really big amounts of data. In hind site this was a pointless test and I should have pushed back on it. All I eventually demonstrated was that the hardware became constrained before the software.
What would have been really helpful would have been a user story along the lines of:
Application programmer wants to send a 100mbs of data around the network every minute (and some business reason/value). This would have been much easier to understand and demonstrate rather than the open ended statement I had to work with.
Hopefully this is the way we are moving.