All About Agile | Agile Development Made Easy!

How is QA done (effectively) in an agile environment?

Hello all,

I am working in a medium sized organization that is moving to an agile development process. We have a QA person who is looking to put together some traceability matrices and such, and because we are new to agile and the methods used to document requirements in such a process (we are using the scrum flavor at this time), I am having trouble figuring out a way to record requirments in a manner that lends itself well to that.

Does anyone have any specific suggestions for how to document requirements that might change on a frequent basis in such a way that a QA person could create a traceability matrix from them? And suggestions on resources I could access (books, white papers, etc) that address this topic well? I appreciate any and all replies.

Thanks!

Kevin W

▶ Reply to This

Replies to This Discussion

Permalink Reply by Kelly Waters on January 27, 2012 at 23:39

Hi Kevin. The most common way for agile teams to capture requirements is in the form of User Stories, i.e. "As a [type of user], I want to [goal], so I can [reason]". They start out like this - as potentially quite large stories or epics - on the Product Backlog and get broken down (still in the form of user stories) nearer development until they are small enough that the team can ideally complete several in a single iteration, including testing. Since a user story represents a unit of work that can be carried through the entire development lifecyle, from requirements being expressed this way, captured on the backlog, prioritised, broken down, analysed further, developed, tested, and ultimately signed off, there is no need for any mapping because only one thing exists. There is a lot of content about User Stories on my blog - http://www.allaboutagile.com/category/agile-user-stories/ - and the best books on the subject that I have read are 'User Stories Applied' by Mike Cohn and 'Agile Software Requirements' by Dean Leffingwell. Both are highly recommended.

Can you tell us a bit more about how you capture and manage requirements at the moment?

Kelly.

▶ Reply

Permalink Reply by Kevin Wood on January 30, 2012 at 19:51

Hi Kelly,

Thanks for the reply. Currently, we have 3 BA's on our team (myself and 2 others), and we are each using different methods. One of us is using purely Excel spreadsheets and capturing individual requirements; one of us is using an online tool called Trello and capturing primarily high level user stories only; and I am using a bit of both - Trello for user stories and task management with a little Excel mixed in.

The issue is that our QA people (we have 2) would like to create some traceability matrices for testing, but I am unsure of how we can accomodate them without having some method of recording requirements - especially in an Agile manner - that lends itself well to that. Perhaps you, or someone else, might have some helpful advice for me/us...? Thanks so much!

Kevin

▶ Reply

Permalink Reply by Kelly Waters on January 30, 2012 at 21:00

Hi Kevin. What is it that QA want to trace?

Normall it's to map two documents together to make sure everything has been covered. Do your excel requirements come from an initial business document or something like that?

As I mentioned before, if the requirements on your backlog are expressed in the form of user stories and they are the only source of requirements, there is no need for any traceability matrix because there's nothing to trace them to, and that's fine. In fact it's good because with only one source of truth there is less chance for confusion, misunderstanding and gaps...

Kelly.

▶ Reply

Permalink Reply by Arup Mondal on February 28, 2012 at 18:19

Hi Kevin,

User stories with ' acceptance criteria' are the requiremets which agile teams follow.In my current project, We have been capturing our requirements in the most siple way possible to avoid complexity. Product Backlog is an one liner overview which leads to user story in a specific format (As an User, I want [the following], so as to [meet the following need]). But we do generally back those user stories with 'Proper set of acceptance criteria'. This provides us with a detailed view of what is expected of the team. The testing team also finds this useful to cover test scenerios and test cases.

Hope that would add some value.. Please let me know if you have some other ideas.