Scenario 1 - Tester, Developer and Product Manager Discuss a deletion requirement
Product Manager (pm): The requirement is to support the physical removal of items from the system
dev: Great, we've got an existing model for a logical delete using a system query to identify the items to delete. We can use the same model to identify items to physically delete.
tester: What happens in the situation where you've already logically deleted an item? It would not then be visible to the user to query so they wouldn't know that they needed to physically delete that item so the model won't work.
dev: Oh yeah.
The interesting point here was that the developer was tempted to fit the new functionality into an existing model based on current functionality. By breaking the model the tester highlighted the need for a new model, that was not based on existing functionality, and further discussion with the customer.
Scenario 2 - Product Manager, Developer and Tester Discuss a legal hold requirement
pm: The customer wants to be able to flag an object as on hold or not. This is to to prevent it from being deleted if a person or company is involved in a legal investigation.
dev: This just requires a simple boolean flag to identify the items that are held. The easiest way to tackle this is if the item is held then we'll prevent that entire container for that item from being expired or logically deleted
tester: Didn't we have a requirement to physically delete stuff for legal reasons? What happens if the same container contains 1 item that needs deleting and 1 that is held.
dev: Oh yeah, OR for that matter, what happens if the same item is involved in two investigations, once the first is closed the boolean hold flag could be switched off, even though there is still an active investigation. We need a reference count instead.
pm: That sounds better
tester: A reference count would mean that unsetting the flag for a set of items could not be re-applied in the case of failure or cancellation, as you could accidentally dereference the same item twice.
dev: Oh yeah - we need some kind of case ID to apply the hold under, then we can apply and remove based on the case reference, then this would never impact any other cases that have that same item on hold.
pm: Good thinking - I'll run this by the customer.
What I found particularly interesting in this case was that, the original discussion was based around implementing what the customer had asked for. Once the tester had started to introduce the idea of breaking this model, the developer actually went on to identify further examples that highlighted flaws in the original request. In this case the presence of a tester raising issues with the proposal shifted the focus of the session. Instead of discussing how to deliver the customer requirement, the focus moved to finding a model that delivered the business value they needed. This was a good example of challenging requirement, a subject which Gojko presented on at the Agile Testing and BDD Exchange last year. The result was a far more robust model for implementation, and one which addressed a series of issues which the customer had not considered themselves.
In both examples the value of having the Tester present in the early discussions around the requirement were clear. The product manager and developer gained the benefit of the expertise of the tester in critiquing proposed models before committing to a solution. The tester gained an insight into the customer requirement that was not biased by the developers having already started work on a specific solution.
Copyright (c) Adam Knight 2009-2010