Forget what you know about Quality Assurance

qa1.jpgWhen you think of Quality Assurance (QA) you likely think testing, testing, and more testing.  While this would be correct, QA isn't just about pushing buttons and recording results.  Take a recent project ' migrate and upgrade 75+ production databases from Oracle 10g to Oracle 11g and move the data from HP hardware to SUN hardware complete with the various 150+ applications that update/use that data.  There was a huge testing component, don't get me wrong, but if you think that the QA work started and stopped with testing, you may be misinformed.  Let me see if I can clear up that popular misconception.

Here are a couple of questions to get started with.

  1. Who owns the data?
  2. How much data is in the database?
  3. How does the data get updated (scheduled jobs, file drops, SQL, applications)?
  4. Who uses the data (applications, scheduled jobs, SQL, Toad, Brio, reporting)?
  5. For all the people/departments/groups involved, what is the maintenance window? (Don't forget about the hardware maintenance window!)

k4003678.jpgIf you think about your own data and databases, and apply these few simple questions, you might think of these major tasks required: gathering accurate information, contacting all parties involved, installing required software, obtaining correct log in credentials, get all applications connected to test database, coordinating the testing effort, performing the testing,  ensure the accuracy of the migrate/upgraded data, recording the results, facilitating the meetings with all parties, and overseeing the move to production.  Whew!

Even tasks that sound simple can turn out to be more complex.  Take for example the 2nd question, how much data?  Once you know how much data, then you can start to calculate how long the migration will take.  Will that fit into your maintenance window?  What process and what tools will you need to employ in order to fit the job into the available window.  What changes to the testing process will be required?  Does it sound like every task has spawned another task? 

Another misconception would be that after you had completed a number of these migrations/upgrades, all the rest would be simple, just write out the steps required and repeat for all the databases that remained.  Unfortunately it doesn't really work like that either.  One database might have 20+ applications connected, all with their own up-time/mission critical requirements, another database might be so large (think 8+ terabytes) that it cannot be migrated in the time allocated, or perhaps a major application is undergoing some enhancements or an upgrade.  Factor in staff holidays, days when no changes are allowed due to risk, etc and the variations become endless.  The general steps and the high level process really will not change that much, but for each database the detailed step by step process changes every time.

k9442148.jpgWith all these issues and variables it is no wonder why a company would outsource this work.  ESTI has a proven track record performing database migrations/upgrades and all the testing and organizing required to ensure a successful finished product.  When we came on board we brought years of experience, a calm and confident approach to the project, and a proven methodology. 

We followed a fairly basic process in order to ensure that when it came time to get it all done in production no steps were missed.  Each time we built up the testing environment a script and sequence of written steps were followed.  Then testing occurred.  If a problem was uncovered, the script and the steps were modified, and then the test environment was scrubbed and rebuilt.  This was repeated many times until everything was deemed solid.  At this point we also were confident that the timing was correct and that the work would be completed in the allocated window.  Building up the production environment was straight forward and allowed all parties to be confident in the finished product.

As soon as all the steps were solidified, we brought all the data owners, application owners and technical staff together to review the roll out plan.  Step by step we ensured that everyone knew what their tasks would be and at exactly what time they would be expected to start and complete their task.  Once the roll out plan had been reviewed and agreed to, we were ready.   Some roll out plans covered three hours, some covered 10 days. 


This QA project was all about juggling all of the tasks, people, and resources while ensuring that sound testing practices were followed.  Do it yourself or bring in the experts?  For this client the decision was clear.

So, was it all about testing?  The simple answer:  yes and no!