As much as possible, I like to get QA involved early in the software definition part of the process. I'm not interested so much in early exposure so that we can do test planning, etc. (although that's important!). I'm interested in bug prevention as early as possible. At WidgetCo*, where I currently work, my involvement starts in release planning meetings. Our releases are very date driven, and we're not currently hiring, so controlling features is our best chance of success. My job in these meetings is primarily to point out what we don't know so we can fix it before we make assumptions in code.
For example, one of the features on the marketing wish list that we talked about today is adding the ability to sort widgets by date. This sounded easy enough, until I said "which date?". So just for kicks we went around the table and each stated which date we assumed we were sorting by. Here were some of the answers:
- date uploaded to the server
- date added to the client
- modified date of the file as reported by the operating system
None of these choices is hard, but someone would have been surprised at the end of the day!
The lesson here? Even the "simple stuff" is sometimes ambiguous. Your job as QA is to remove ambiguity as early as possible.
*I don't really work at WidgetCo. That would be kind of cool, though.