LOGICARE Corporation

Number of people on the test team: 5

Number of developers supported by the test team: 12

Best Practice Description :

My career in Quality Assurance at LOGICARE began 5 years ago right after graduating from college. At the time, the QA team consisted of me and one other newly hired QA Analyst. At LOGICARE, many employees are “split-role”, meaning they split their week between two different functional areas. We were only allowed to work in QA for 2 days a week and our Manager was in Project Management and mainly served as an HR manager for our team. The department was completely disorganized, without any standards or documentation. The previous manager had left without leaving anything or anyone behind so we had to build our QA program from scratch. Our QA strategy consisted of “monkey testing” or “ad hoc” testing and our Development team didn't have or use written requirements. Being that neither one of us had any experience in the area; we decided to look to outside training and expertise.

Our improvements began with sending both of our QA Analysts through the CSTP program at IIST. We began to realize that until we were able to get written requirements from Development, our testing efforts would greatly suffer. Fortunately, after a few years, LOGICARE dedicated several Business Analysts with the task of developing written requirements for Development and QA. After that breakthrough moment, our process improvement efforts really took off.

Our initial efforts focused on requirements review and test scenario / test case development and writing. We were using a tool called Test Director (which would later change to Quality Center ). It was (and is) a good tool for the entire QA lifecycle of requirements, test planning, test execution, and defect reporting. Defect reporting was the ONLY use that the tool was getting, so we started with entering the requirements and getting the company used to the idea of Quality Center being a central hub for requirements, testing, AND defects. Using the training we received from IIST, we spent quite a bit of time developing or practices for writing test scenarios and test cases from our new requirements, using techniques such as:

• Boundary testing
• White & Black box testing
• Use Cases
• Positive & Negative testing

We were also able to increase the quality of our test execution by helping to standardize internal definitions of defect priority – what makes an “A” defect an “A” and so on. This helped our project teams to determine which of the many defects had to be fixed immediately during the project, and which ones were able to wait until later. Previously, it ended up working that whoever screamed the loudest got their defects fixed, but that caused strife on the teams and those defects weren't always the proper defects to fix. We still incorporated a small amount of ad hoc testing during test execution, but it was no longer the foundation of our efforts and it was preformed by testers not on the QA team and only at certain times. Any defects found had to be validated by a QA staff member – they would then write a test scenario/test case around it, properly put the defect into reproducible steps, and log it into QC for Development. The process of using short, reproducible steps for our defects is one of the favorite process improvements that our QA team has made. Development loves that the defects are now clear and they don't have to guess about what the tester was thinking when they logged the defect.

Using our new techniques and by more fully using Quality Center , we were able to be a help to our Development team rather than a hindrance. This allowed them to turn around defect fixes much faster, it lowered the quantity of defects (because they had written requirements to go from), and it GREATLY improved the Development / QA relationship. We were also able to track a defect from its written defect, to its test scenario/test case, to the requirement that it originated from. This allows our Development group to focus on areas that have weak requirements due to the increase quantity of defects for that section.

The results of our efforts have been significant. Before our process improvements, our Developers were very frustrated with the quality of the defects that were being logged. They were vague and mostly irreproducible. Now, we are a greater asset to the project team and our projects are getting done faster with much less pain. Now that we have a suite of test scenarios/test cases for each project, we are also able to better estimate how long the test execution phase will take, where before all we could do was guess. Also, we have been trying to preach Cost of Quality (COQ) throughout the company and I am happy to say that both Development and Project Management are behind the efforts to spend the time up front to eliminate defects during the requirements and/or design/code phases, which saves great expense in eliminating defects from the more expensive, later phases in the project.

Our QA group has several areas where we want to focus on next:

Impact Analysis:

  We want to work with our Development group to do better at Impact Analysis – so that when the requirements change part way though (or after the project is already in Alpha or Beta), they have a better idea of what components of their code has changed, and we know what test cases that we need to run, rewrite, or both.

Automated Testing:

We would like to develop a strategy behind how to best use automated testing. We currently have a few licenses of Win Runner, but we don't fully utilize the functionality. We use it for specific testing needs (such as doing the same thing many times in a row), but that is the extent of our use of the too. We want to be able to use this to help us better stress test our applications, which we've done in the past, but we want to be more intentional about.

Metrics & Better Tool Utilization:

Now that we have made such huge strides in our process improvements and use if the Quality Center tool, we want to develop a more complete suite of metrics that we can report to the company. This will also help sell the value of QA throughout the company. The IIST class I took (Test Process Measurement and Improvement taught by Alfred Sorkowitz) has and will be invaluable in accomplishing this task. We also want to use Quality Center as the only “home” for our various project's requirements. Currently they are stored in word in addition to QC and this has caused us problems in the past (requirements only being updated in the Word copy and QA not being made aware until during Alpha test, when test scenarios/test cases have already been written.

Presently, our QA department consists of a QA Manager, one full time Analyst, and 4 part time analysts (one of which is the QA Lead). All of our QA staff will be going through the CSTP training and the QA Lead (which happens to be me) has completed the CSTP certification and is half way through the CTM training. We have incorporated “Milestones” into the training of our Analysts that focus on the requirements, test design, & test execution procedures that we have developed.

We have been quick to let others in the company know that the key to our success has been being able to have written requirements from which to work from. Without that tool, we would be severely hampered in our processes. A benefit of the improvements we have made are that we are able to quickly justify the expense of training costs, test execution time, and QA lab material upgrades/expenses do to the tangible improvements that we have made over the past 4 years. LOGICARE's QA future looks bright as we continue to look to build on the foundation that we started through IIST's training and continually try to improve how we do our work and contribute to helping deliver quality projects, on time, to our customers.