Testing As Analysis

Testing as analysis is when we find new things using testing techniques. The goal of this activity is analysis, not serendipitous finding of functionality during validation or verification. This kind of testing is performed during GorillaTesting? or AdHocTesting?.

In the role of tester, the AvailableCustomer often discovers new requirements. This is the idea that something can be DoneDoneDone? but still not be right or meet existing requirements. AdHocTesting? is not validation; it is analysis.

-- DanRawsthorne, DouglasShimp


In AgileDevelopment, this is basically the feedback loop from frequent deliveries.

-- Author Unknown?

There are many feedback loops in AgileDevelopment. TestingAsAnalysis is a useful distinction in handling some organizational impediments.


Often we see testers doing their job and logging defects against the code base when, in fact, these are not defects but new behavior that is wanted. We might have tried during analysis (e.g. writing use cases, stories, feature decompose etc.) to identify all of the important behaviors that we wanted to handle but are not found until testing. Testers are not recognized for their analysis work. As a result, a common set of impediments to agility occurs. For example, If this problem is not handled well, the entire organizational situation is prone to ConflictBlamePolitics.

-- DouglasShimp
Let me echo what Doug says. In a normal (bad) project these defects cause scope creep within a story, which is forbidden - stories have fixed scope. By saying that these are automatically new stories, and that the testers are doing TestingAsAnalysis, we have produced a new paradigm for the testers. While this is something that we (as agilists) have known for years, it is new for them...

-- DanRawsthorne

CategoryTesting CategoryAnalysis

View edit of March 27, 2006 or FindPage with title or text search