Define user satisfaction

Quote from Software facts and Fallacies by Robert L. Glass - page 133:

"A user will be satisfied if he gets a product that meets needs, is available at an appropriate time, doesn't cost a fortune and is of reasonable quality".

We had a couple of real world users testing the website that we have been building for the past 3-4 months. I noticed a few things walking around yesterday evening while they were testing:

• Nothing crashed. I never had users come in to test any of my code on an entirely new website without anything crashing with an ugly ASP.NET stacktrace showing up.
• Nobody gave up and needed a lot of guidance help to complete their testing. There were a lot of questions of course and quite a few logical errors but people seemed to have a basic understanding of what they were supposed to do to keep moving forward.
• 4 out of 5 questions could be solved with a textual changes / graphics instead of written text or layouting the page a little differently. We could really use a dedicated tester which knows something about design and usability in our team.
• Nothing is as painful and as to see users revealing stupid logical errors. In Denmark we usually write the zipcode and the city on the same line: "7100 Vejle". We had an inputfield, some 30 characters allowed but we had clientside validation which threw an error if you entered any non-numeric value or more than 4 characters (all zipcodes in this country consists of max. 4 numeric characters. Small country, you know...). During our own day-to-day testing during development we had always just entered the 4 numeric characters which would pass validation check - and we would gladly have put this in production if users hadn't pointed out our own stupidity to us in advance.

As the wise men say: "You learn the most by your biggest mistakes". Point taken - we had a few things to correct. And - given the quote from above: We actually delivered something the users testing our system felt was useful - we tested on the night scheduled a month ago - we haven't spent more than a few months developing and it provided a solution to our Product Owners problem. How about that? :o)

Regards K.

Test-Driven Development and the quality issue

There has been quite a lot of fuzz lately regarding Test Driven Development (TDD) - I have seen a number of posts where poeple are asking if the maturity of the tools on the market make old-school TDD obsolete. I have also seen posts where Ben Hughes asks if TDD really ensures quality.

That made me think about the term "quality" - what is software quality seen from a customer's point of view and how can we convince them that the software we produce are better than the one of our competitors?

I don't really think you can measure very much out of TDD in a sense of software quality seen from a customer's point of view. I mean - do you really care how Microsoft develops Windows XP and Windows Vista? I couldn't care less - neither do our customers as long as our sh** works every time. Even when our customers have a negative experience because they are unable to fulfill whatever task they were set to do because we as software engineers have failed to deliver - do they start to ask questions? Not really - they start looking for the products developed by our strategic competitors on the market to look for a replacement of the crap we have convinced them to install on their harddrive.

The principles and paradigms on which a software product has been built upon can and should never be a quality metric for our customers. They will never care anyway. TDD is just one (very useful) tool out of many when we develop software. In terms of quality it should only be a metric inhouse whether or not our software has a certain degree of code coverage for instance... We must not be mislead to believe as developers that anyone else but us really care what tools are in our toolbox!