Introduction
Most software companies strive to create a high quality product. They put processes in place to ensure a high level of quality. However, quality is not achieved by processes alone, it is achieved by people understanding the importance of these processes and implementing them in the right spirit.
Enforcers of Quality
The Quality Department can definitely set standards, and create checklists and tons of documents to enforce quality. But, ultimately these documents are only as good as the people who fill them out.
The individual team members should believe in quality taking pride in delivering high quality software. You should not need a quality police to enforce quality as it should be the responsibility of each and every team member.
Quality in an organization
In a software organization where standards like SEI CMM are not being implemented, it is still possible to maintain that high level of quality by instituting quality as a discipline.
Some of the tools you should use are:
Bug Tracking Solution
Everyone agrees on the need for a bug tracking solution to effectively manage bugs and defects. However, the bug tracker is useful even after the project is delivered and all the bugs are closed. It is a good practice to revisit the bug database and identify the cause of the bugs and defects. This can tell you a lot about the shortcomings in your processes and allows you to learn from mistakes.
Example:
If you identify that the in-house tree control is unstable and is the cause of 10% of the bugs, then maybe you are better off buying a stable tree control from another vendor.
If the project is very small and the company cannot afford a bug tracking solution, check out open source solutions like:
- Mantis - PHP/MySQL/Web-based bug tracking system.
- Bugzilla - Perl/MySQL/Web-based bug tracking system.
Understanding the root causes of your bugs using the data in the bug tracker enables the team to avoid making the same mistakes in subsequent projects. Quality is an ongoing process and you get better at it with each release of your product.
Source Control System
A source control system allows multiple developers to work on a single project and share files efficiently. You should define the process on how the source control will be used. Otherwise, each team member will define their own process.
The source control system should have one branch from which the main build will be made and another branch with workspaces for the individual developers. Developers can use their branch as a backup mechanism for their code where they can check their work in progress. Once they have unit tested their code, get the latest versions of all the other files, compile the source, and run a test once more to make sure that they have not broken any thing else. After the tests are executed successfully, they can check in their code to the main build branch with appropriate comments.
The main build branch will be picked up by the automated build system and will be given to the testing team. If your source control does not support transparent branching, please select a source control which does.
A nice to have feature would be to have the bug tracker integrated with the source control so that the developer can easily specify and track the files changed for the particular bug fix.
Using a source control system enables the team to manage multiple versions and releases of a product and still maintain your sanity.
Automated Build Mechanism and Unit Test Verification
The automation should include automatic retrieval of the right source files from the source control system. The goal should be to ensure that the build process is consistent and repeatable, a must for large software projects comprising of multiple inter-dependent components.
After the automated build is ready, a sanity verification test should be executed to ensure that the basic functionality is working. This verification test should be automated and there are various tools available in the market such as:
- NUnit - a unit-testing framework for all .NET languages.
- JUnit - a regression testing framework for Java.
This Build Early and Build Often will help to identify issues due to incorrect check-ins and also all issues will surface up earlier rather than later. It helps shorten the loop between the development and QA cycles. And finally, it helps the team morale to see a working version of their application.
Backup Mechanism
You would not like to lose your week�s work just because your server died. Create a checklist of all the items you need backed up and automate this process.
Some simple guidelines are to store backups at different locations and should be easily retrievable.
When a final release is due, backup all the configuration items to a disk and file it away. Label these backups properly.
Code Reviews
Every piece of code which is checked-in should be reviewed by a peer. Create a code review checklist mentioning the bare minimum criteria which need to be satisfied depending on the project.
Code reviews are an excellent way of teaching new software developers good coding practices and helping them get up to speed in this crazy industry.
Even if you are on a very tight schedule or in a fire fighting mode, do not neglect reviews. Make sure that the critical parts of the system are reviewed thoroughly, not just after they are coded, but in the design phase itself.
Remember to keep aside at least 50% of your development time for the review process.
Conclusion
Quality is a discipline. Follow simple rules which work for you and take pride in creating your masterpiece.
