Lazycoder

Sure you’re agile, what about your QA department?

For the past 14 years I’ve been a software developer for money, I’ve noticed a trend. The QA department finds the most bugs towards the end of the release cycle. Even when I’ve worked in departments that are supposedly following an iterative development process.

A lot of the “bugs” revolve around “fit and polish” issues. Making sure the font and wording is correct in all locations. Making sure the application looks and behaves the same across all platforms,browsers in the case of web applications. Most all requirements documents or stories include a note for the QA department to perform these checks well in advance of the final launch, yet these bugs always seem to come up and they usually are not regression bugs.

The places that follow an iterative cycle I’ve found don’t really deploy after each iteration to any meaningful customers. They are all still tied to the “big launch”. I think that getting the product into the hands of people who ACTUALLY care about it, rather than the ones that are just concerned about the launch, is crucial to delivering a high-quality product.

I’m wondering if the traditional QA department is a relic that we need to get rid of? If we move all of the testing/bug finding to the interation and fix them immediately, isn’t QA relegated to mainly verifying bugs reported by customers/users?

So the question is: How do we get QA more involved in the process?