Monday, November 24, 2008

artistic testing

I like to point out that historical, well-vetted aesthetic frameworks are useful for evaluating software.

But what if similar aesthetic frameworks could not only validate software itself but also *predict* software test techniques?

For example, let's examine overarching schools of painting: first came realism, where painters attempted to represent as much as possible what appears to the human eye. We can test realistic scenarios, we do this all the time. I would suggest that most bugs are not discovered under what we understand to be realistic circumstances.

Then came expressionism, where painters attempted to express things not seen. Likewise, test techniques moved on to persona testing (imagining the use of software by peculiar users) and soap-opera testing. Such techniques expose significant bugs.

Then came abstract expressionism. Think of Jackson Pollack. Are there abstract expressionist test techniques? Of course there are.

I would really like to hear of any other explorations along these lines...

Saturday, November 22, 2008

two agile antipatterns

Both of these have been crossing my path with increasing frequency in recent months (not at work, but in conversations with others whom one would think would know better):

1) Stories are scheduled work for features. Stories should not include:
  • testing
  • refactoring
  • documentation
  • undefined customer support
  • calling your mom
The problem with writing stories for stuff other than scheduled work on features is that you completely undermine the concept of velocity.

Velocity is the number of story points accomplished per iteration. If you assign story points to activities other than scheduled work on features, you cheat the business of accurate information about release schedules. (Although it might make you feel better to be accomplishing so many points each iteration, if you are not delivering features, you fail.)

2) Doing it "by the book".

Part of the agile culture is to have retrospectives at the end of each iteration. Each retrospective is an opportunity to change your process.

So if you're doing 2-week iterations, at the end of a year, you've had 25 or so opportunities to change your process. At the end of two years, 50 process changes.

If after all of these retrospectives, you are doing your work the same way you were at the beginning, you fail.

Wednesday, November 12, 2008

Finally joined Twitter

I'm chris_mcmahon there if you want to follow me.