Home | Login | Recent Changes | Search | All Pages | Help

ContextFitting

By context fitting, I mean making use of the attributes compiled during context analysis to customize the set of activities performed during the testing. This might impact what is done, how it is done, by whom, how fast, how it is reported/communicated, and so on. DaveRabinek

I'm a little lost here (and that's OK). Can you provide a "fer instance?" It might help provide more information that I can grok. DonGray 2003.10.17

example 1:
1)Context analysis attribute: type of functional testing required;
2)Value of attribute: results from complex financial equations;
3)Context Analysis suggests:
a)testing skills: finance knowledge, ability to generate the expected result via some other means (excel spreadsheet, for example),

example2:
1)Context analysis attribute: testing goal;
2)Value of attribute: 100% statement coverage;
3)Suggests:
a)need tool to measure statement coverage (McCabe, for example),
b)need to plan to implement tool into environment,
c)need staff familiar with tool operation and how to interpret results,
d)need partnership with developers to interpret coverage tool output,

example3:
1)Context analysis attribute: testing goal
2)Value of attribute: 100% requirements coverage
3)Suggests:
a)need tool or process to measure statement coverage (requirements traceability matrix, for example)
b)need staff familiar with matrix creation/usage

hope this adds clarity DaveRabinek 2003.10.17

Use the project attributes to customize the set of activities performed during the project

?? -- JohannaRothman 2004.07.15

Hi Dave.

I may be talking about something different, but here's the sense I have about ContextFitting as you use it.

ContextFitting has a lot to do with choosing tools, techniques, methods, and even the method of introducing these things, based on the context.

The problem is the "one size fits all" methodology, tool, etc.

• "Perl is the solution - now what was the problem?"
• "Getting agile is the solution - now what was the problem?"
• "Getting disciplined development is the solution - now what was the problem?"
• "Test automation is the solution - now what was the problem?"

It turns out that proposals of technique have two parts, not one, and we mostly mess up in the first, hidden part of the proposals.

• The world works like this (the problem)
• So, this technique addresses that (solution)

A more useful approach IMO is to select from a mix of tools, techniques, approaches, and so on, based on the problem at hand. There's some small set of inescapable, powerful truths about building software (or being humanly effective). I'm not sure I have those wired, although we poked at that a bit talking about BestPractice and UsefulPractices. The vast majority of tools, techniques, etc. that we practitioners hold so dear are useful local approximations and heuristics. So, when they don't fit the context, try something else.

I introduce "improvements" in software engineering practices all the time. Rarely the same one two times in a row. The big pain, and the big payoff is different from one organization to another, from one situation to another, from one individual to another. So ContextFitting of the solution matters.

-- JimBullock 2004.07.17