Friday, November 9, 2012

Finding problems before and during development

Recently, I've been thinking about specification by example. For the last two days, I've been thinking that with the datapoints I'm seeing at my work, it may be an investment not worth the effort we'd put there.

In the last two days, I've logged plenty of issues on a particular feature area not working as it should. It actually works as specified, or within the limits of how it's been specified, but just doesn't serve its purpose.

I realize I could have - if I even looked at the thing earlier - told about some of the issues we'll be facing later on. Now that I tell of them, they're concrete behaviors (or lack of thereof) in the implemented system.

But what surprised me is that there seems to be very little rework, but more of extra work that just hasn't been done yet. And for now, it seems that the risk of regression isn't that big a deal either - with the type of system, unit tests seem to do a decent job on their own.

I reserve my right to rethink this. But I just find it hard to digest, that using more effort before development than less during development would be the way to go.

1 comment:

  1. Hi Maaret!

    There's a change trying to happen in my current customer, where SBE with high tester involvement is targeted as a cure for many quality related issues. So I was hoping if you could go a bit deeper with this interesting statement? I prepared a few questions/opinions to maybe get u going?

    1. Are/were you doing the pre-specification work in some certain specific ways, using some formal expression like e.g. Gherking language or some specific visual models? Or some free form way of doing it based on people and situation? Or something in the middle?

    2. What do you feel, is the testers aid in this work? I have done plenty of req review and some analyst work as well, and have (also) noticed that even with a high effort on tuning the spec, some glaring misses are easily done. So testing the spec is a lot different than testing the system, on my point of view, and requires a bit different skills. And testing the spec also is not a replacement for testing the system (it may get you better testing though)

    3. I've been kind of seeing that the trend has been flowing first from lots of spec to little spec and now again to more pre specification work. How do you feel today about "Working software over comprehensive documentation"? Is it a fantasy (or one worth aiming for)?

    Yours truly,