Chunking QA Projects

Bug fixes are easy. They're very focused. I work until the bug no longer exists.

New implementations (of QA code, anyway) are harder. There are a lot of stopping spots that are conceivable. How do you know when to say that you're done with this project? It's inefficient to say that we're going to do the whole thing before we check it in. It's also silly to check in something that flat out doesn't work. We have to chunk our projects just like software chunks functionality into releases.

So, what are our rules of QA project chunking?

• getting something in is more important than getting all the features
  
• continuing to add is perfectly acceptable
  
• meet your current goal before you start your future goals
  
• incomplete is better than not at all

Long story short, writing QA software is like writing any other software. Start with a small feature set, and keep adding. Finish your first feature set, then refactor and add new features. And whatever you do, don't let perfect be the enemy of good.