Agile Analysis, Agile Testing: Synergies for Successful Software Solutions

By

My experiences working with agile teams have taught me that agile analysis and testing skills are truly synergestic.

So much so, that I put together a tutorial for the April 2011 Quest Conference (Quality Engineering Software & Testing) entitled, “Requirements  Exploration with Tester Collaboration”.  Subsequently, I had the honor to work with agile testing guru Janet Gregory to present this at Agile 2011.

Next month, EBG’er Sue Burk will co-present this tutorial with Janet at the April Software Testing Analysis & Review (STAR) conference. So, you might be wondering, what are those synergies?

The Testing Mindset

Product needs evolve into requirements that define what will be built, what will be tested, and how the product needs will provide value for the organization. People with testing skills need to be involved in requirements for the same reason the other product stakeholders need to be involved: to boost the team’s ability to deliver a high-quality product.

Testers offer important skills to any delivery team. Among other things, they expose hidden requirements (e.g., missing or unclear business rules), and verify that you’ll deliver the product correctly. We at EBG Consulting like to think of this contribution as the “testing mind-set.” It helps maximize the team’s productivity by reducing waste and handovers. Exposing misunderstandings faster early on, means it’s easier and less expensive to correct them.

Any product delivery effort needs the continual, direct, and active use of the “tester mind-set.”

“Requirements Exploration with Tester Collaboration” Tutorial

To demonstrate that, during the tutorial, we have attendees participate in a simulated facilitated workshop. During the workshop, they apply analysis modeling techniques and experience for themselves how these models can be effective for defining test scenarios, test cases, test data, and individual tests.

In the tutorial, participants are introduced to  Behavior Driven Development and Acceptance Test Driven Development (ATTD). They also explore BDD’s Given-When-Then technique, the creation of data tables, and the use of Tom Gilb’s Planguage for specifying testable quality attributes.

It’s the Goal, Not the Role

From a skills perspective, business analysis and testing complement each other – they require attention to detail and emphasize consistency, completeness and correctness. And both share a furious focus on delivering value—not only a high-quality product but also the right product. The right product is a subtle concept. It’s the product that actually address users’ problems or opportunities—as opposed to the product users may think they want at first blush.

The Product Owner (in Scrum vernacular) brings deep domain and product knowledge that guides the delivery team in deciding what to build and when to build it. Product Owners work together with the team to explore and evaluate proposed product options, and that’s business analysis work. It is best done collaboratively with the whole team. The selected product options become requirements to be developed, tested, and deployed. (By the way, in the book I am writing with Mary Gorman, we explain these practices in detail; please stay tuned for summer publication of our book.)

Key analysis skills include analysis modeling, elicitation, longer-range business planning, and techniques for looking at product options (a.k.a. requirements) in a holistic manner. The entire team needs to explore and evaluate product options including the users, actions, data, rules, interfaces, quality attributes, and development & operational environment—what Mary and I call the 7 Product Dimensions.

There’s a different, but related, type of evaluation that testing provides.  Because it is usually not possible to completely test every conceivable scenario that may occur, its necessary to identify the optimum subset of tests—out of all possible tests—to be defined and executed. This requires skills such as peeling open a product to uncover flaws, knowing smart ways to sequence verification activities, and taking the “what can possibly go wrong?” angle.

All these strengths build on each other. And the team needs all these skills in order to deliver a valued product.

It’s the Goal, Not the Role

Some people may be fearful of “role infringement.”  Testers and developers participating in requirements exploration; analysts helping with testing.  My experience has been just the opposite. In the best of situations, everyone acts as a partner, building a shared understanding of product needs.

In our practice at EBG, we focus on helping people learn to collaborate in the best possible ways—to appreciate and maximize their diverse skills and knowledge and to converge on a shared understanding of product options.

When we do occasionally notice role confusion, we surface that right away. If needed, we help the team conduct chartering activities to clarify and match up their skills and knowledge. We help them directly and transparently discuss their constraints, needs, and preferences. This is essentially social contracting.

In sum, “it’s the goal, not the role” (see, “It’s the Goal, Not the Role” ).

References and Readings:

One Response to “Agile Analysis, Agile Testing: Synergies for Successful Software Solutions”

Leave a Reply

Your email address will not be published. Required fields are marked *