Derik Whittaker



Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at
Since when does QA == BA?
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?

Posted 04-05-2007 7:29 AM by Derik Whittaker



Zach Bonham wrote re: Since when does QA == BA?
on 04-05-2007 12:11 PM

This is the defacto standard at my company though we actually perceive it a little differently in that our business experts are asked to do QA.  

I don't agree that this is good for business on these counts:

- these are business process people; they have had little exposure to any level of testing process(es).  Our sign off process to release to production is typically that it worked for a specific test that was contrived by the analyst and thats it.  Most of the time, these tests are DESIGNED to succeed.  There are many other facets to this response... :)

- workload; designing and optimizing business processes is a full time job.  Software QA is a full time job.  Mixing the two has shown that quality in one, or both, areas will usually suffer.  

That being said, our BA/QA team does a phenomenal job under the constraints they have, but I disagree that this is the way that it sould be.  

I work for a 'corporate' company, meaning that our customers/end users are other teams/divisions in the company.  Prior experience with ISV companies is that we had a fulltime QA team.

Derik Whittaker wrote re: Since when does QA == BA?
on 04-05-2007 4:09 PM


I also work a 'Corporate' company and it seams to work pretty well here.  Our also, have very little 'QA' knowledge, but they are experts in the business.  

I would love to see our team lean more towards a 'techie QA team' but currently the process works (in the eyes of the business) so why change it.


About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)