Test Strategy documentation for Scrum

147 views
Skip to first unread message

Shantanu Sharma

unread,
Apr 10, 2015, 8:20:34 AM4/10/15
to scruma...@googlegroups.com
We have agreed to follow a testing strategy for testing the product that the team is building. It includes a healthy mix of everything that team thinks is necessary to ensure a quality product each sprint.
I am to document this strategy for everyone, inside and outside of the team, to refer. I don't want to make this a comprehensively written document as typically done in other SDLC models, because we don't want to get into extensive documentation work. Since Test Strategy is a important and living document, I want to create something that provides concise and "to the point" information of what we are adopting and is easily maintainable in the longer term.

Can someone suggest me an approach/template to write a test strategy document that my team can adopt. Please share experiences from your teams and suggestions for us to improvise.

Markus Gärtner

unread,
Apr 10, 2015, 9:03:05 AM4/10/15
to scruma...@googlegroups.com
Janet Gregory describes one of her lighhtweight test strategy approaches in the book Agile Testing by Lisa Crispin and Janet Gregory.

James Bach also describes his Heuristic Test Strategy Model. It's included in the seminal book Lessons Learned in Software Testing as well as on several pages on his website satisfice.com

Best Markus

-- 
Dipl.-Inform. Markus Gärtner
Author of ATDD by Example - A Practical Guide to Acceptance
Test-Driven Development
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

Kamlesh

unread,
Apr 10, 2015, 10:58:34 AM4/10/15
to scruma...@googlegroups.com
If 'All' of you have agreed and established a shared understanding, I would ask, do we need a dedicated document? Most teams capture it as part of their 'Definition of Done' which is usually Big and Visible to everyone.

I've seen teams create test strategy document where someone wanted to have it and others simply had to follow it. Obviously this document resided on a SharePoint site and hardly anyone looked at it. On the other hand, I've worked with teams who worked in regulated environment, following SOX, there the test strategy didn't exist as a separate document.

If you are still pressed to create this as a separate document, I would ask myself - Do the developers have a Development Strategy Document ? what about the Product Owner - does she have a dedicated Product Ownership Strategy document where she's listed the way she'll come up with ideas, refine, validate and manage ideas? No. I recall how one Scrum Trainer (CST) explained a similar question that when we go somewhere, we don't just forget to put our clothes on. Why? Was it because it was documented somewhere? Because right from childhood we learned it and shared the same understanding with others in family and society. Now it has become common sense.

Cheers!

--

Ram Srinivasan

unread,
Apr 11, 2015, 11:48:41 AM4/11/15
to scruma...@googlegroups.com
+1 @ Kamlesh :)

Wouter Lagerweij

unread,
Apr 12, 2015, 6:43:46 PM4/12/15
to scruma...@googlegroups.com
Hi Shantanu,

Very good that you're looking to keep things lightweight. Especially in organizations that are still new to agile, this can be difficult to do.

I'd suggest that you start with adopting a shared Definition of Done for your work, in which the team agrees on what types of testing should be done. Remember that this is for the whole team, and not just testers. So it should include all the automated testing developers implement, as well as things like exploratory testing.

For more detail, I'd strongly recommend focusing on 'Working Software': make the tests that you think should be made(as described in that DoD), make them self-documenting as much as possible, and only write supporting documentation to link those together, and where it can't be avoided. And it can be avoided much more often than you'd assume.

Wouter


--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages