It is time to change the way quality assurance works at the enterprise level within an organization. Time to cut out the hefty overhead costs of having a full-time employee[s] or a contractor[s] sitting in on meetings, conference calls, and other random get-togethers.
This is a waste of money. You are paying to have someone ‘listen’ in on conversations and for the most part not contribute. Quality assurance for software and application development should be on the developer, project manager, and product owner of the tool being developed.
Nobody wants to deploy half-ass work. That is not in anyone’s best interest. I don’t want to hire a developer or team that I have to keep calling back to fix an app that I hired them to build. The developer and team that built the app does not want to have to keep putting out fires by constantly reworking a broken application. And, as the product owner, you sure don’t want to have to deal with the customers trying to work with your broken app. Releasing sub-par work is not in anyone’s interest. By having someone sit there, a QA specialist, and listen to your meetings surely is not going to make your code any better.
This does not mean that you do not need QA. You just don’t need QA present all the time in the development process. This adds to team bloat which financially means additional costs.
So, how do you utilize quality assurance?
The team responsible for the application being developed should be held accountable for the quality of the application. This means it is written into their performance appraisals. This goes for every member of the team including the product owner (if the product owner is from outside the IT organization).
What about the Quality Assurance department?
In the military, all units have annual inspections. A third-party team of inspectors come into your unit and review your paperwork, your weapons, your vehicles, tools…etc. This inspection provides your unit with a score on your unit’s overall performance and readiness for deployment. The team identifies areas of improvement. The score is reported up the chain and recorded in a location that everyone can see. The unit commander also reviews the inspection, score, and if required – remediation plan – with the upper-brass in an open forum.
We can apply this same concept to how QA works. Quality assurance inspections can be provided by third party annual inspection teams. The inspection will review source code, review paperwork, review all areas of compliance set forth by department, agency, corporate, and policies at a frequency to be determined by the organization. The teams leadership and frequency of use will depend on the results of the audit. For example, if a team receives sub-par scores then the team can be put on notice, sent back to clean up the discrepant areas, and then continue on a probationary period. If the scores are really bad or continue to perform below standards, then the team may be disbanded, members may be terminated, or reassigned to duties that are more inline with their skill-sets.
How do you make this a reality?
The organization and the development teams need to set documented standards in place that the QA inspection team can audit. Create a level of trust and accountability for the performance for the systems being developed.
Some methods that may help accomplish this:
- Published coding standards and guides
- Reusable pre-approved code snippets, gems, libraries
- Single code repository
- Peer-to-peer code reviews performed by the development team