Some might say that discussing about software quality and software development practices in my project management blog does not make sense, but I believe it really makes sense, because project manager is a key person to get commitment from management in order to apply the following practices in projects.

I have seen similar mistakes repeating in many projects, and one of those is the lack of continuous integration and testing. A while ago I discussed about the problem of late integration and tests, and actually these following practices help removing the problem. So, if you think you are having quality problems in your project, consider utilizing these practices.

Test Driven Requirements

Tet Driven Requirements is a practice that calls for the customer to provide requirements in an unambiguous format, such as acceptance tests. This not a one-time practice, but repeated in the beginning of each iteration or sprint. The benefit of Test Driven Requirements is that it drives the system architecture to right direction. Unlike waterfall processes it also helps focusing on the most important in the iteration or sprint, because developers build only what is required.

In order to get Test Driven Requirements happen you need customer representative in your project team, and naturally he/she must be willing and competent enough to develop Test Driven Requirements.

Test Driven Development

Test Driven Development is much like the previous practice, but the focus in this case is in creation of automated developer tests. The basic idea is to first write a test case  for a requirement and then implement the requirement. In XP a test case is understood as a requirements, but many people are still used to differentiate requirements and test cases.

Tehe benefit of Test Driven Development is that it produces loosely-coupled designs which are easy to maintain, reduces defect counts and enables building only what is needed.

It is not easy to get your team practicing Test Driven Development if they have never done it before. You are quickly faced with high resistance because so many developers are strongly used to go straight into coding phase. It is best to have an experienced Test Driven Development mentor or consultant to help applying Test Driven Development. If you succeed, you definitely see the results. Test Driven Development is something I always emphasize because I have seen it pays back.

Continuous Refactoring

Refactoring could be understood like “cleaning up” the code but not totally redesigning. Refactoring changes the structure of the code and aims in better design. Continuous refactoring during iterations or sprints leads to incremental improvements of the products, which again leads to higher quality. Without continuous refactoring the design can degrade over time, which usually leads to difficulties in code maintenance and fixes.

Refactoring should be done in every iteration of sprint before checking in to version control. Project manager should arrange time for continuous refactoring by emphasizing the meaning and importance of refactoring from quality perspective.

Automated Unit Regression Tests

Unit tests are pieces of code that validate implementation, and in most cases unit tests are automated. Unit tests are done by developers, and a set of unit tests form so called unit level regression test suite. This regression test suite is automatically or manually executed right after an automated or manual build process has completed.

One of the biggest benefits of Automated Unit Regression Tests is that bugs are found very early during development. Another great benefit of (any) regression test suite is that team can verify that latest changes did not break existing functionality. Certainly I have to point out that no test suite is able to verify 100%, so by building, maintaining and executing Unit Regression Test suite team can lower the risk of serious defects in the end of a project.

It is important to notice that building an Automated Unit Regression Test suite takes time and requires discipline. Project manager should emphasize the importance of unit tests and encourage team members to keep on building the test suite.

Automated Acceptance Tests

Automate Acceptance Tests are written in the beginning of the iretation or sprint. These tests basically answer the question “What will this requirement look like when it has been implemented?”. Execution of the test case typically fails several times during development, but when it passes, in theory no more development is needed.

Just like the automated unit tests, also Automated Acceptance tests are gathered into a regression test suite. They provide similar benefits, such as early defect detection and higher quality. The difference is that Automated Acceptance tests are built on different level where focus is different from unit level tests.