Testing Architecture

There are many aspects to look at when one is trying to define or describe the architectural elements of a system.
-application architecture
-infrastructure architecture
-security architecture
Etc, etc, etc....

One aspect that I see that is completely missed by by most software vendors and system developers and integrators is what I call Testing Architecture.




I define testing architecture as a description of the testing tools, products and other system components that are dedicated to supporting testability of the solution.

Testing architecture describes the patterns used to support building testable components, and provides guidance on when and how to utilize stubs, mocks, data setup and cleaning services, automated testing frameworks and other testing artifacts.

Finally Testing Architecture describes testing coverage metrics for various aspects of the solution, and lists any constraints that may limit the use of automated testing.

It's time for major software vendors to take a page from many OSS groups and start making tests and testability far more prominent in there solution.


Jef

Sucesssive Planning Poker

While I think planning poker is an excellent way to estimate any software delivery work, I've noticed that actual development work is sometimes started to soon, supported by a backlog and release plan that are made up of largish items (12 - 20 ideal days)

While agile methods espouse getting started as soon as possible I think a little more up front analysis can actually help reduce rework and eliminate ambiguaty.

I've come up with something I call Successive planning poker. The premise is simple

1: Conduct an initial round of planning poker

Frequently the estimating group groups will often end up with lots of items that end up with big estimate ranges. (ie 10 ideal days +) Large estimates represent work that is not well understood, contain many assumptions, and are riddled with unknowns.

2: Conduct analysis and research activities necessary to resolve ambiguities in any large estimates

During the initial planning poker session make sure to keep careful track of ambiguity and uncertainties that could be resolved with a reasonable amount of research. Because the group doing planning poker is cross functional, they should be skilled to answer questions ranging from existing legacy functionality to product limitations to existing business processes or policies, etc,. Give team members a day or two come back with answers.
3: Conduct a successive round of planning poker

Go through each largish estimate from the initial planning round and use the answers and research completed by the team to break up the work items into smaller, more manageable pieces and estimate these pieces independently, hopefully ending up with work items ranging from 1- 8 ideal days.

4:Repeat

Repeat successive rounds of estimating and researching until you have a quality backlog of items that are reasonably fined grained enough to tackle within an iteration in a reasonably predicable manner.

While the above approach might be obvious to some, I've been on several projects where we didn't do this an the first few iterations really suffered, of course a couple iterations of development really did alot to smooth out future iteration. Still I think just a little but more planning dillegence (done in a collaborative and cross functional way of course) could have helped to gain the same information faster and far easier.