We have some issues with QA processs in our current firm (in India). This QA process is been in place from last 12 years.
Database changes do not go through the formal QA process. All new procedures(new code) will go through QA but any changes to the procedures are directly deployed to production. Database programmers/DBAs verify that the output of the procedure remains same for the set of input parameters before and after code changes and move them to production. They do not modify number of input parameters during this change.
I think this is risky and all changes should get Regression tested at the minimum.
What do you think about this process? From a technical stand point, what could go wrong with this type of a check?
You are right, all changes which can effect the company's livelihood should be tested completely. In my experience though, this is usually a risk companies are willing to take and therefore they do not test DB changes to any great extent. The more progressive companies however do an extensive pre-change evaluation to insure no data loss prior to making hugh changes in DB structure and content. Perhaps this is something you should research and prepare a presentation to your company about.
Yes, having DBAs test their own changes is a risky proposition. But, have there been any risks that have turned into real issues? This could be an area worth discussing. If these procedure changes have not resulted in any issues, then it might be asked whether change is necessary.
Depends on the complexity of the stored procedures, what your data is and how your database is structured. If these were procedures that were part of critical business operations, I'd say those need to go through Regression Testing and a good QA prcoess/test cycle. However, if these are stored procedures for reporting, internal items or other non-Customer facing functionality then let the DBA's do their job. I've dealt with both, and non-critical procedures got put into QA at some point, maybe not right away, but so long as they got there I was ok with it.
These are the database changes for customer facing applications (not internal apps). Most of these changes are done for optimizations and some of them are just "tweaks" to existing code (probbaly right way of coding, best practices etc).
I believe we had some production issues beacuse of these changes before I started working here.
Can some one point out what could techically go wrong with this type of check?