The rumors are true… we have a Validation Team and they are hard at work preparing the new Verification Test cases (formerly called the OQ suite).
First, let’s meet the team (in no particular order):
- Piyali Chatterjee- software engineering and testing since 2007
- Paramita Bhakta- project management and testing since 2005
- Sagnik Chatterjee- software testing since 2008
- Geetartha Hazarika- software testing since 2008
- Fernando Casanova- too old to mention
Our strengths: expert understanding of our software and strong testing background; quick to respond to changes
Our weaknesses: expert understanding of our software and strong testing background
Our opportunities: customer needs validation; we have the regulatory and testing background; no matter the economic forecast regulated customers will need validation
Our threats: many self proclaimed validation consultancies out there; legislation changes may arbitrate the need for a different kind of validation
The team is located at our office in Kolkata, India under a rotating Team Lead basis. Our first goal as I mentioned earlier, is to re-factor the old OQ and align them with our current definition of the functionality of the software. We decided to use the LABVANTAGE DOC file supplied with the software to target the functional sets. We started by dividing the load into four major areas, three of which will be complete by year’s end, System Admin, Lab Admin and LIMS. The fourth to be worked on during next year’s first quarter, will encompass something we have never attempted before, Verification Test cases for the API!
In the past month, we sustained three customer audits from the pharmaceutical industry and gave them a preview of the use case and test design documents. The repeating question was… when can we have it? They are excited about the level and quality of the documentation being done.
I mentioned use case and test design specifications, but what are they? They are our methodology for getting to a quality end game. First, we decided on a standard to use as the functional descriptors of the product, the help file. Next, we read through it, cajole developers and testers for understanding how it is used and how it can be abused. We write it in a standard Use Case (UC) worksheet where we gather all of the necessary information for what is under test and what data we will be using to test it. Then, we formalize the information into a TDS or test design document, and look at any special setup or requirements needed for testing including any interdependency with other test cases or functions. Both the UC an TDS are peer reviewed and all final documents are stored in a final folder in SharePoint.
Almost there, so hang in with me. The individual team members then dry run the information in the TDS and capture what they are doing in an AVI first. When it comes to writing the Test Case (TC), all possible angles are covered! The TC is the final step in the process. This is what we are doing in a nutshell! Stay tuned because we are going out there and doing the same with our regulated customers.