Agile testing: a whole team approach

Agile testing is about two things: a whole life-cycle and whole team approach to testing. The whole life-cycle aspect stresses leveraging testing throughout a hip process as opposed to a distinct period. Likewise, a whole team approach welcomes all parties to the quality table as everyone (yes, that means all stakeholders) accepts responsibility for building in quality.

development 2.0: high costs!
While traditional software methodologies have the tendency to segment groups into logical units of responsibility, agile teams
favor a more collaborative approach that facilitates working along side various people and groups containing differing skill sets and expectations. That is, for example, the client begins to take responsibility for elaborating expectations through a working effort to understand how the process unfolds. What’s more, by working closely with a client, a team can better understand what is needed and why. As opposed to a test document fashioned from a bogue requirements document (often times done by various teams working separately), leveraging a story in a collaborative manner ensures all parties are effectively on the same page. Thus, the customer (or some proxy there of), development, and QA are working together in the process of constructing stories and indeed leverage the same stories for all related assets.

Because it’s their bag, when Agile teams embrace stories as a fundamental means as to conveying requirements (i.e. features) along with a means for validating them, a natural tendency is for all parties to begin to own quality. That is, since everyone is aware of how to validate a feature, everyone begins to practice validating such features. In essence, a story facilitates leveraging both TDD

and functional testing (which are also both automated and exercised via CI
) .

What’s more, when the whole team both works together off of the same artifacts that are continuously verified, everyone can better understand the meaning of “done” — that being the question “is feature x finished and ready for the client (or clients) to have?” Of course, if everyone has utilized the same artifact (i.e. a story

!) for both building and verifying a client’s expectations, then it is quite easy to check if the feature is done.

Thus, the whole team approach that leverages stories:

  • ensures all hip parties see and understand the “big picture” of a particular project
    • that is, why someone wants an application (and its related features) built, which in turn further facilitates whole team ownership (along with more effective testing!)
  • helps teams figure out the definition of done

Obtaining these benefits is a matter of providing a means for all parties on a team to collaborate, which is often found in leveraging a story. Plus, visibility into overall team progress as facilitated via CI and automation. The whole team approach also meets the original goal of software testing — that being the assurance that high quality code is delivered to interested parties. Teaming also reduces the tendency to throw up barriers that often plague efficiency.

Agile testing boils down to two fundamental changes, baby, that differentiate it from traditional software testing — both the notion that testing isn’t a phase but a whole life-cycle approach and that the entire team works together towards shared goals. Agile testing complements a highly efficient software development life-cycle and ultimately produces better software faster.

You can now follow The Disco Blog on Twitter, baby!