In Pursuit of Learning in Creating and Testing Software Products in an Agile Context.

Thursday, 11 March 2010

The power of the tester in requirement meetings

It is my firm belief that Testers should get involved in the development of requirements at the earliest opportunity. In a recent discussion with Gojko Adzic he pointed out the similarities in the process we use at RainStor and that of Chris Matts model of Feature Injection. I have had some occasions recently which provide excellent examples of the presence of a Tester making an invaluable contribution to requirements discussions for the purposes of Breaking the Model.

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.

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.

ShareThis

Recommended

Pages

About Me

I am passionate about software quality and delivering value across Product Ownership, Testing and supporting activities. I'm a keen contributor to the software testing and agile communities. As well as an active blog I've also spoken at various events including Agile Testing Days, UKTMF, TestBash and EUROStar and contributed to popular agile books Specification by ExamplebyGojko Adzic and More Agile Testing by Lisa Crispin and Janet Gregory. All opinions expressed here are entirely my own and do not represent the opinions of my current or any previous employer.