views:

83

answers:

1

Is this something you do already or do you know of a good tool?

GOAL: Help team understand how recent source changes impact risk so they know where to focus testing efforts. Provide data over time and feed it back into planning and scoping phases of the dev cycle.

PLAN: Combine svn change data with clover complexity data in a report showing impact of change on complexity or risk of change (# of lines x complexity = risk?). It is not perfect, but it could help the teams understand the changes better.

Anyone try this? If so, what tools did you use and how did providing this cue to team work out?

+1  A: 

My experience has been that tests and risk(s) are identified when new features are put in or when defects are fixed. This was all done "manually" in all my jobs.

Yours is an interesting idea - basically a CI server type of plugin/component to focus testing based on statistics of prior defects and of complexity analysis on the changed files.

You'll obviously need a map of code/files to test cases and if you had the reverse (failed test cases and the files that were changed to make the fixes) you would have some autmatic way of generating some of that information.

I suspect that "risk" might also contain a "developer" component. i.e. some developers have an inherently higher "risk" for checkins than others - and this may be local to some functionality as well... In some cases the "Developer" would be the overriding component - either totally reducing risk, or making it certain.

Tim
For unit tests I can probably generate that data. For integration tests and high level functions I'd need the teams to keep the data up-to-date (which isn't a nice). automated, ubiquitous systems seem to do better (as long as they nag effectively)
Peter Kahn