Manage Learn to apply best practices and optimize your operations.

Collaboration in Agile development: Requirements analysis is a team effort

SSQ Site Editor Yvette Francino talks to experts Sue Burk and Janet Gregory about tester involvement in requirements analysis.

We hear a lot about the blurring of roles in Agile development. Developers, testers and business folks work together as a tight-knit team, each adding their own perspective, but not confined to performing only the tasks traditionally executed in their role. At STAREAST 2012, Sue Burk of EBG Consulting and Janet Gregory, co-author of Agile Testing: A Practical Guide for Agile Testers and Teams, will be co-leading a half-day tutorial titled: “Agile Requirements Exploration with Tester Collaboration.” Agile leaders and team members will learn how testers can participate in requirements analysis in this article in which Burk and Gregory give a sneak peek at what will be on their tutorial’s agenda.

Testers involved in requirements analysis

Testers who are used to working in a traditional environment may not be clear on how they should be involved with requirements. However, with their early involvement, they are often able to bring up the potential for defects before they exist.

Burk explains, “The skills and mindset of testers expose tacit requirements, uncover missing business rules, and help verify that you deliver the product correctly. We like to think of this as the ‘tester mindset.’ You will maximize the team’s time, reduce waste and handovers and expose misunderstandings faster by exposing flaws in your understanding of requirements early on using that tester mindset.”

Gregory adds, “Testers are used to considering the big picture - how the requested changes affect the system as a whole. When they are involved early, they can help identify these impacts so they are not discovered late in the release cycle.”

Certainly it makes sense that defects that are considered and prevented from happening in the first place are a much more efficient mode of operation than waiting to catch them with tests after they’ve occurred.

How is this different from the role of the product owner or business analyst?

Traditionally, it’s the business analyst, or with the Scrum framework, a product owner, who is “in charge” of eliciting requirements. How is this different? Burk answers:

Business analysis and testing disciplines are two sides of the same coin. That is why these roles complement each other so well. The disciplines of testing and business analysis require attention to detail and emphasize consistency, completeness and correctness. And both shared a furious focus on delivering value—not just a quality product, but also the right product.

The Product Owner (using Scrum vernacular) needs deep domain and product knowledge to make decisions about what to build and when to build it. The Product Owner, in collaboration with the delivery team, explores and evaluates product options to make those decisions. That’s business analysis work. And that work is best done collaboratively, with the whole team. The product options selected become requirements to be developed, tested and deployed.

Analysts have skills in analysis modeling, elicitation, longer range business planning and how to look at product needs (a.k.a. requirements) in a holistic manner. An analyst can help the team explore product needs---users, actions, data, rules, interfaces, quality attributes and the design and implementation environment.

Testers have skills in peeling open a product to uncover flaws, knowing how to smartly sequence verification activities, and taking the ‘what can possibly go wrong?’ angle.

Both of these strengths build on each other. Also remember: in some teams you may have people who embody all these skills sets.

It’s about the goal, not the role

Though one might wonder if this blurring of roles may leave team members confused and perhaps feeling that they’re stepping on one another’s toes or that the business analyst’s “territory” is being infringed upon, Burk says that her experience is that the opposite occurs. All parties act as partners without worries about traditional roles.

She says, “Business and value-oriented questions from developers and testers will help sharpen and improve the analysis and make it more complete and consistent. At the same time, when representatives for testing and development are part of analysis, it reduces the need for analysts and Product Owners to spend time repeating the rationales and context for business decisions made during analysis. This frees that time for understanding the requirements in greater depth.”

Burk stresses that in Agile development, the team is more concerned with the end goal rather than the roles, and that business analysis is best done collaboratively than in silos.

Gregory concurs, “The key is to recognize that it is the whole team working together that creates a successful solution. “

Techniques and tools

The whole team is involved, but how exactly do they go about doing requirements analysis? What techniques are Burk and Gregory going to demonstrate at their tutorial? Acceptance Test Driven Development (ATDD)? Behavior-Driven Development (BDD)?

Gregory says, “ATDD and BDD are definitely processes where testers and business analysts can work with Product Owners to define the high level tests before coding starts. These tests help define the scope and give a shared common understanding of the feature or story.”

However, Gregory and Burk will be teaching some additional skills to the participants in their session. Burk explains, “Some of the techniques we will be introducing are based on Acceptance Test-Driven Development (ATDD) and Behavior Driven Development (BDD). We will be looking at the Given-When-Then, data tables and also Planguage as ways of specifying testable requirements.”

Conclusion

Agile development teaches us to break down silos and collaborate as a whole team. Gregory and Burk will demonstrate how testers can help with requirements elicitation and give participants some hands-on experience at their STAREAST 2012 tutorial.

For comprehensive conference coverage, see our Software Testing Analysis and Review conference page.

Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.

Next Steps

Discover how critical the product owner role is to software development

This was last published in April 2012

Dig Deeper on Software Requirements Gathering Techniques

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

We do have a product owner/BA role on our team, and he is generally responsible for eliciting requirements and he does a fantastic job of it. However being in QA, I always insist on being there for the initial high-level meetings because it's very important to me to be able to comprehend the business goals and to begin formulating potential tests and issues in my mind. 
Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close