Eric Wilhelm wrote:
On Thursday 27 March 2008 12:42:13 Eric Wilhelm wrote:
What do you need to test that your users need to drive?
Business rules.
So, what is a good example of such a business rule? I posit that
payroll does not count because the user could more concisely write the
rule in a declarative form, this isn't Java, &c.
I'm confused by that response. FIT is declarative. You give the user a
table, they fill it in, it gets run through a routine that interprets the
inputs and outputs.
| gross pay | fed tax | state tax | medicare | social sec | net pay |
---------------------------------------------------------------------
| 40000 | 24% | 6% | 2% | 5% | .... |
---------------------------------------------------------------------
Categorization is a nice example.
| URL | Category |
---------------------------------------------------------
| hooters.com | Restaurant |
| whitehouse.com | Porn |
---------------------------------------------------------
Clear inputs and outputs.
Also no matter if you could write that out as a Perl hash or something you
don't want to be handing accountants a text editor and Perl program. Totally
alien. You want to give them a web page or Excel file to fill out. Part of
the point of FIT is the method of inputing and evaluating the test results is
comfortable to the user, not the programmer.
How can it be expressed in a non-tedious and yet understandable way
that makes them feel like it is a worthwhile process?
That's the guiding design question of FIT tests.
That's conveniently intuitive then. So where do I get the guiding
design answer? Or at least, how do you decide when to be asking the
above question vs when to be asking "how do I set this up such that the
business rules are 'programmed' directly by the users?"?
That would be highly situational, but it's the same sort of question as "when
do I put this into a config file"?
Of course, even if the rules are specified by the users they still need to be
tested.
At that point, you're pushing so much data into the test that it has
become tedious for the user to own (create, manually review) the
time cards, so you really only want to involve them at the
configuration. ...
Don't mistake FIT tests for unit tests. You'll stab someone if you
do.
Okay, so how do we be sure that the business rule is fully expressed by
the Fit input? (That is: guarantee that there are no edge cases.) Or,
is this one of those complicated things where worse is better because
we don't like better better than worse?
Same way you determine any other test. You run coverage analysis. You give
some thought to the data. If they're numbers you try 0, -1, 1, .5, 2**33,
etc... If it's strings try whitespace, special characters, nul bytes, SQL
commands...
But FIT is not really about doing full edge testing. It's about getting a
broad suite of blackbox tests that match what the users actually do, as
opposed to what the programmer things the users do. Since the users (or the
client) are writing the tests and they probably know the domain better than
you do. Also, lacking any knowledge of the internals, they're not going to
pussyfoot around known fragile spots.
Finally, as chromatic pointed out, FIT is *not* a replacement for unit tests.
It's another tool, specialized to allow the client to write their own
acceptance tests. It's as much about drawing the client into the development
process, getting them involved, getting them to use the iterations, getting
their feedback and buy-in, as it is about testing the software.
--
60. “The Giant Space Ants” are not at the top of my chain of command.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
