In my previous article called: Quality Management of Software Projects, Part 2: Preemptive Strike, I described the quality management actions, which reduce or eliminate quality problems of a software project, when taken before the project is started. This entry describes the quality assurance methods, which should be used during the implementation phase of a software project. The goal of these methods is to ensure that the requirements for software quality, which are set before the project, are met.
The main idea behind every quality assurance method described in this article is continuity. If you feel that individual actions will help you to ensure that the requirements for software quality are met, you are mistaken. Individual actions will help you to achieve your goal for one time, and one time only. On the other hand, a continuous process will help you to achieve your goals time after time. As you might have already guessed, the quality assurance of a software project should be seen as a continuous process. It is a process aiming for continuous improvement, where every stakeholder should be asking from themselves: What can we do better next time?
Continuous integration. When discussing quality control methods, continuous integration cannot simply be disregarded. It replaces the traditional quality control methods, which are typically executed after the implementation phase, when it is too late to fix them in a reasonable amount of time and money. Continuous integration aims both to improve the quality of the produced software and to reduce the implementation time. These goals are met by addressing quality problems as soon as they are found, which in theory makes problems easier to fix. Some of the recommended practices include
- Automatic building and deployment. When a developer commits source code to the version control system, it should trigger a process, which builds and deploys the project automatically to the test environment. The build process should also ensure that the possible deliverables of the project are generated and prepared for distribution. Dependency management tools such as Maven or Ivy should be used to achieve this goal. One important requirement for the build process is that all team members must be able to see the result of the build and the changes, which triggered it. This ensures that the implementation team can fix possible build errors as soon as they are detected.
- Test automation. When an automatic build process is started, unit tests must be executed automatically as well. The goal of this phase is to ensure that the application is working as developers are expecting. If all tests do not pass, the build must be marked as failed, and the project team must be notified about it.
- Automatic reporting. The build process should also generate reports, which are used to identify possible quality problems from the build in question. There are several open source tools available, but I have found that Findbugs and PMD can be useful for inspecting the source code for possible problems and bugs. Code coverage reports can be created by using Cobertura. It is also a good idea to store historical data from previous builds so that the results of the current build can be compared with them.
Code reviews. I am not a big believer in the power of traditional code reviews. Generally speaking, it is very hard to get people to commit to the goals of a traditional code review, because they are often dictated by someone else. The lack of commitment causes sloppiness, and no one really wants to take a proper look of the source code. After the findings of the review have been fixed, everything goes back to normal again. People's attitude remains unchanged, and instead of fixing the problems found from source code, they choose to wait for the next code review.
This process can be more efficient and less bureaucratic. Actually, I happen to believe that there should not be a process called code review. It should be an attitude, which can be determined by a single sentence: commit code back to the version control system in a better shape than it was, when you checked it out. Creating this kind of an attitude to the project team is much harder than just using the ordinary method, because it requires a higher motivation among team members. However, the the reward of success is great. Imagine that people would be ready to audit the code created by the project team without bickering and playing the blame game. If they are ready to see the project's source code and architecture as a common asset, and to guide their actions towards excellence, there really is no need for code reviews. Just lay down and let the project team do their magic.
Communication. No one cannot write a perfect specification. Communication is necessary for dealing with the deficiencies found from the specification. Unless the customer wants the implementation team to make a guess every time when a deficiency is found, one must allocate enough time for communication. Even though the specification would be really good when the project was started, it is more than likely that the customer wants to make changes to it during the project. Again, communication between the customer and the implementation team is needed. Luckily, the importance of communication has been acknowledged, because of the rise of agile development. The time of select and forget projects is over.
Testing. Even though automated testing is a part of continuous integration, only a small part of needed tests can be automated. The other tests must be executed manually. These tests are described in following:
- Performance testing should be repeated on a regular interval, and the results of the previous test runs should be stored. If this is the case, it is possible to identify performance issues as soon as they appear. Thus, finding the cause of the performance problems should be easier, because the changes made after the previous test run are known.
- Functional testing is especially important, because it ensures that the application is working as the customer expects. The actual end users of the application should be used to verify that their expectations are met. This ensures that the customer is not wasting its time and money on a useless application. It is also a great way to increase commitment and enthusiasm among the end users. To maximize the benefits of functional testing, it should also be repeated on a regular interval.
I have now described the quality assurance methods, which should be taken during the software project. Following the advice given this article will help you to improve the quality management of your software projects. In the end, this will improve the quality of the implemented software as well. The next part of the series describes guidelines, which are used to ensure that the outcome of the software project is working as the end user expects. We are going to take a trip to a zone controlled by business people, who do not care about technical details. They just want that the software works.