Bugs and Creepy Crawlies

Testing Custom Software

There is a huge amount written about the testing phase of the software development cycle.  There is the traditional concept of Inception - Analysis - Design - Implementation - Testing - Deployment.  Wikipedia articles expand on this in all directions.

These theories focus almost entirely on large-scale team development of commercial software.  Fair enough, I suppose - the bulk of software development falls into this category, I suppose.

But I, and the people I most closely associate with, live in the world of custom software development by very small teams - often a team of one. I have written here before, and here, about some of the contrasts of scale.  The same rules do not apply.

Nevertheless, it caught me by surprise recently, to learn how many of my colleagues take a similar approach to me.  Quite a few of us were discussing this.  Funny how one's assumptions can be off-beam... for some reason I imagined that many developers of targetted custom solutions would nevertheless work more closely with traditional development life cycle processes.  Not so.  Which is nice to know.

Here's the approach I take.  As part of the process of discussing a project with a client (whether it's a new application, or modification to an exisiting one), I will explicitly broach this subject.  I tell them they have two options:
1.  After building the application, I will extensively test before delivery.  This will significantly delay delivery, and increase (in some cases double) the cost of the work.  I will then guarantee the app, and fix any bugs free of charge.
2.  As part of the development work, I will check that I am "reasonably satisfied" that it works properly, and then deliver.  After that, they are the testers, and I will promptly fix any problems that they find, at their cost.

So far, I have never had anyone choose #1. Nor do I really expect them to.  In fact, I only throw the idea into the ring in order to put the nature of our relationship into perspective.

If anyone ever does choose #1, I will have to be careful to define the difference between "bug" and "specification creep".  You see, one of the main causes of post-delivery work on a custom application, is the result of the user trying to do stuff that you never imagined, in ways that you couldn't have predicted.  The work to "fix" this normally has to be seen in terms of providing extended functionality, rather than correcting a programming flaw.

And wrapped around all this, are the main things that I love about working in this sector.  First, the fact that you are usually working with unique and very specific requirements, to produce a solution at a high level of efficiency, and the satisfaction that comes when "it works", in terms of the benefits to the client.  And second, the fact that you know the people who will use your application, and working in with them directly.

Tags: Micro-ISV, Microsoft+Access, Software+development

Powered by Qumana