we have identified need to be worked at that time.
For this journey, it's like using a GPS system in our car. We know where we need to get to, but the GPS is constantly recalculating our route and our progress. It knows that if a road takes longer to travel than expected it will adjust our end time. Also if we choose to deviate from our route (like finding somewhere to eat along the way in a town we are passing) it will suggest we make u-turns until it recalculates a new route from our current position. Newer GPS route systems will even keep an eye out for hidden problems (road works, traffic jams and accidents) again recalculating our route if these are encountered. It's constantly testing its own assumptions (as well are we) to ensure that we have a trouble free journey and arrive safely at our destination. This is something we are not very good at doing when developing our software system. For traditional software development models our assumption test is towards the end of the life-cycle while with agile software development we bring that closer to the code being written through automated testing. We incrementally derive our requirements through user stories / use cases then rely on our automated tests to validate if our code meets our assumptions. This is a huge improvement over testing late in the cycle. Better still, how about testing our assumptions of our requirements prior to any system design or code being produced by expressing them as a series of tests. Enter the world of Test Driven Requirements.
Are we there yet?
Let's explore first how we know if we have reached our destination: For a car journey it's quite simple in that we have arrived and stopped the car. In software though it's a different story. We think we are done when all our features are implemented, tested and that we have stabilised our defect find rate to a level we expect would be acceptable by our customers. However, due to the complex nature of the system we have produced and the project timescales, we know that there are certain combinations which have either not been exercised or not exercised enough. We stress test key paths through our system but knowingly omit large sections.
An extremist would state that when there are no defects in our system we are done. Since we know in our heart of hearts that there will be some defects and that our timescales will not permit a completely defect free system we compromise with defect free-enough. We soften the blow of this message by producing find / fix projections. We even set targets against milestones on our project plan. Find / Fix curves are calculated by estimating how many lines of code we will touch or introduce, how many defects per 100 lines of code there will be, how long it generally takes for us to fix a defect and projecting this information on a graph. Our targets are set against a launch criterion of reliability which is rarely zero defects. It's this thinking which allows us as a delivery team to become complacent about bugs in our system. At the end of each iteration we kid ourselves by announcing that we are done. We demonstrate the functionality we have added and hide the fact that there are certain scenarios which will cause problems. We say that we have tested within the iteration when actually a good deal more testing is required. We pat ourselves on the back with a job well done and shelve