EppsNet

The graphic on the right came up for discussion at the office today.

The V Model is a traditional model, still widely used, but (IMO) bad for at least a couple of reasons.

1. Look where User Requirements and UAT are — the first and last items in the V. This ensures that the maximum amount of time goes by between users saying what they want and being able to test out the implementation. The more time that goes by between users saying what they want and being able to try it out, the more likely it is that they’re going to change their minds, for any number of reasons. That’s bad.

2. If our testing is honest, there’s always some non-zero probablilty that the system will fail, again for any number of reasons — too slow, too buggy, not what I asked for, etc. By putting testing last, we don’t find out that the system is a failure until we’ve already invested the entire cost of building it, thus the rich history of big-ticket IT failures, where huge sums of money were spent and nothing usable was ever delivered.

IMO, you can use a design-code-test V model, but you have to use it iteratively every week or two weeks or at most every month on a project to avoid these problems and make sure users are getting what they want.

Thus spoke The Programmer.

It’s done but we’re still working on a few things.

Then it’s not done, is it?

It mostly works, but it still needs a lot of testing.

How do you know it mostly works if it still needs a lot of testing? Isn’t that what testing is for — to figure out if it works?

I’m not making these up, by the way . . .

Jerry Weinberg has suggested that “it works” may mean “We haven’t tried very hard to make it fail, and we haven’t been running it very long or under very diverse conditions, but so far we haven’t seen any failures, though we haven’t been looking too closely, either.” In this pessimistic view, you have to be on guard for people who say it works without checking even once to see if it could work.

 

“No user would do that” really means “No user I can think of, who I like, would do that on purpose.”

Who aren’t you thinking of?

Who don’t you like who might really use this product? What might good users do by accident?

 

In general it can vastly simplify testing if we focus on whether the product has a problem that matters, rather than whether the product merely satisfies all relevant standards. . . . Instead of thinking pass vs. fail, consider thinking problem vs. no problem.

— James Bach