1 Star2 Stars3 Stars4 Stars5 Stars
Loading ... Loading ...

By Lisa Crispin
When Brian Marick came up with his ideas about using examples to drive development (I think that was back in 2003), my team latched on to the concept. We are fortunate in having an expert product owner who is talented at coming up with good examples. People often ask me how this works. Our current and previous sprints contain a good illustration of how we use examples to drive testing and coding.
We’re working on a theme to display internal rate of return on account statements. This involves a complex algorithm. Here’s just one part of the formula. Our development team hashed out this formula together with the product owner in the course of a couple of meetings to discuss it. Because our programmers and testers have a lot of domain knowledge, we were able to question the PO’s initial formula, and come up with one that was simpler to code and still provided a correct value.
The reason we were doing this theme is that our previous IRR formula got way off with edge cases, for example, if a participant started out a quarter with a zero balance, and got a big asset rollover in the middle of the quarter. The product owner researched nine different edge cases, pulled their data out of the production database, and created spreadsheets showing all the cash flows and the resulting IRR value. Here’s a small snippet of one of the spreadsheets, showing some of the cash flows for the first quarter of 2008, and the IRR value.
A developer and tester worked together to first write a simple FitNesse test (here’s a snippet of the FitNesse test) using data from one of the product owner’s examples. The IRRs came out different than the product owner’s. The PO did some research and found some problems with his own calculations. This process iterated a few times until both the example in the spreadsheet and the one in the FitNesse test produced the correct values.
From there, the tester has been creating more FitNesse tests using the other examples from the spreadsheet. All the known edge cases are in the spreadsheet, so this is a great start on covering all the possible test cases. We’ll do more tests, both through FitNesse, and through the UI, until we’re satisfied that the correct value displays on the account statements.
It’s taking us two sprints to complete the different stories in this theme. I think it would take much longer if we didn’t have the examples. The PO has saved us lots of time by researching the examples from production data up front, and putting those in a spreadsheet so we can see how he reached his IRR values. He worked closely with programmers and testers as the tests and code were developed in several tiny iterations until everyone was satisfied that the code was performing correctly, at least initially. Now we have his edge cases as examples to make sure we cover all possibilities, along with all the test cases we think of ourselves.
We have good confidence that we can deliver the right business value. As we have a firm deadline, this is a good thing. Some of the FitNesse tests will be put into our regression test suite that runs in a continuous build process. There are so many benefits to using examples to drive development.
Do you use examples to drive testing and coding? Please share your stories.

The post Using Examples to Drive Development appeared first on Agile Testing with Lisa Crispin.


Category: agile testing, driving development with business-facing tests, driving development with examples, examples, specification by example

Você também pode querer ler

Comments are off for this post.