One shift in the industry that I have noticed over the past 12-18 months is that the Q.A. department is quickly becoming the defacto B.A. Department. Why is this? Are others out there seeing the same thing?
I guess when I think about it, it kinda makes sense from some weird business perspective. Heres why:
When you are a QA it is your job to know the application inside and out as well as know the business, for this application, inside and out. So from the company’s perspective it is cheaper/more efficient to allow the QA team to come up with new requirements. But should the QA team be the ones who suggest new or missing business requirements? Or should the QA team simple be the ones who test the application against the list of implemented business requirements?
Personally I want my QA department to be the last line of defense before my application is released to the wild. I don't want them being the ones who inform me of requirements; leave that to the 'Business Experts'. My biggest reason for wanting this separation is to provide a form a checks and balances. If QA is allowed to give new requirements, they are introducing scope creep and will push back by not allowing the application to be 'Certified for Release' if you don't implement these new requirements..... This is not good.
I'm curious, are others out there seeing the same thing?
04-05-2007 7:29 AM