Disclaimer: Peter B. Wilson, Ph.D., Executive Vice President, Mosaic, Inc. wrote an article plagiarized it without shame .called Ten Common Mistakes Companies Make Setting Up and Managing Software Quality Assurance Departments in 2004. It very eloquently supports my position of having a Quality Assurance Department, so I have copied and
The point I want to make is that a talented Quality Assurance group will save a company more money than they spend on it while ensuring fully functional applications in production. Now for those CIO’s and company managers, that pay for IT, please try to control the laughing and wipe the tears of laughter from your eyes. The best example that I have to make my point is what happened to Knight Capital Group this past August. “Knight Capital Group Inc.’s $440 million trading loss stemmed from old computer software that was inadvertently reactivated when a new program was installed, according to two people briefed on the matter.” See the entire article here.
As Peter B. Wilson, Ph.D. wrote in his article about Software QA departments “Let me add up front that by QA, I do not mean testing. Rather, I am describing a function with the responsibility to ensure that software will meet its intended requirements – functional, date, budget, etc. Testing is important, but it is different.”
Testing can prove that a system does not meet its requirements. It cannot ensure that a system will meet its requirements. Testing is quality control; it is not quality assurance.
The QA department must be at least a peer of the application development organization. The QA staff responsible for conducting the reviews should be at least peer level to project managers. If project leaders ask “do you want me to get the project done on time or do you want me to get QA’s approval?” the answer should be “I want it done on time and with QA’s approval.”
- Projects have no need for regression and automated testing.
- Each new project re-invents, with its Project team members the testing process.
- Each new project stores its results in the project storage location.
- Each new project is not aware of the testing environments of previous projects.
- The primary focuses (evaluation criteria) of the Project Team are Cost and Schedule, but the primary focus of the QA Department is defect-free applications delivered to users.
- The project team is trying to make it possible to use the application. Quality assurance is trying to find every defect that may ever occur during the production life of the application.
- Ensuring an organization’s success can also conflict with ensuring an individual project’s success. This is very common and usually occurs when there are limited resources that must be allocated – staff, budget, user time, senior management time, QA time, etc.
It is difficult being a team player on a Project when your focus is to find defects (which many developers see as criticism). When the QA team player wants to be accepted by the project team there is an increased tendency to overlook defects.
An Information Technology project is started after management and the project leader agree on the content, time frame and cost. If there is no agreement then there is no project. If the project leader feels that there is an increased probability of project success with independent testing included, and management agrees to pay the additional cost, then independent testing is included. Anything that does not lead directly to the success of the project is excluded (this includes Quality Assurance overhead items such as QA process and products).
Senior management not understanding their responsibility, or want to pay for Quality Assurance. If senior management does not understand their role in the QA process, then a QA department is doomed. Management is always tempted to reduce or eliminate the QA department’s budget. The rationalization is something like “QA is project management’s responsibility; we shouldn’t need a separate QA department.”
The primary objective of a QA department should be to ensure successful projects. A successful project, to the QA department, does not mean meeting content, cost and schedule criteria. It does mean that the project will meet its requirements and be defect-free. There are good secondary objectives, but they are not the same as ensuring successful projects. Focus too much on any one objective (e.g., date, budget, QA process and standards, etc.) and you will likely meet that objective at the expense of the success of the project.
It often happens that the QA Department is too busy with QA meetings, process, products, naming standards, personnel concerns and company commitments that when a project is planned / started the QA staff is unavailable.
If the QA department has been able to break through these hurdles and is doing a good job and projects are running smoothly, it may look like the QA department is no longer needed. The QA department’s contributions to the success of projects may not be visible or understood by senior management.
Regardless of the way you implement QA in your IT department, it will have an impact on the team’s productivity and help your company as a whole. My best personal example is a manufacturing company where I was brought in to do some testing on a shop floor project. The company was creating two different shop floor systems for two completely different shop floor environments. Neither was in production. The lesser of the systems was way behind and plagued with problems. Management decided to bring in a tester to see if it would help the lesser project. Slightly less than a year later the lesser system was in production and running defect free. The other system was still having problems and not in production. At this time the slowdown in the economy was beginning to happen. To save money, the first thing cut by management was Quality Assurance. The development group continued making changes to resolve some loose ends in the system. I received a call a few weeks after I left asking me to come back because they couldn’t get the new release to work in production. I was already working at a new contract so I don’t know the final outcome, but the results were obvious: the project’s production ground to a halt because QA was not there to keep it moving.
I am promoting QA because of its positive return on investment. To senior management I am not saying that “you should know QA”. What I am say is “if you are doing your job of maximizing profits you’re missing an opportunity by not implementing QA”.