Concepts of Continuous Integration

Thanks to advances in Test Driven Development, software testing has become an important subject of discussion. Test Driven Development (TDD) is incorporated in the software engineering process of many organizations. Discussions about using specific open source, free and commercial products to accomplish testing can be found all over the web. I think that test driven development can and should be a part of any product/project development life cycle from start to end. Speficically, I want to discuss my experiences with testing and how it has helped me weave quality directly into the sofware development process.

Sad reality is that waterfall software development process still dominates the industry. Activities are seen as tasks being performed by disconnected teams. I was a software developer for 2 years until I was introduced to Test Driven Development. Testing is regarded as an activity that happens in short intervals during the software development process. Following diagram demonstrates what software development and quality control activities look like in a waterfall software development process.

Figure above demonstrates how the development process starts and how it degrades over time. First development activity has the highest number of lines of code checked in. All the initial plumbing of integrating logging, validation, user interface design abstractions, etc. are checked in. This build has very minimal business logic, but it has an architecture that will support the business logic in the later builds. As you can see, the development group hands over the software to the testing group. Testing activity is significantly smaller and smoother at this stage. There are very few business rules to test, if any at all. However, as new builds are made, the testing activity gets longer and longer. In this world of no unit tests, there is no guarantee that new code will not break any existing code. It becomes testing teams responsibility to ensure that all rules are being obeyed. This model is clearly unstable. Software that was originally being designed becomes a mirage of some sort. The harder the software development team tries to accomplish their goals, it creates more problems. Sometimes, these problems are simple and easy bug fixes, sometimes they are so hard to duplicate that they are regarded as 'low risk known bugs'. It looks something like this..

The red graph above shows a project without any tests. The green graph shows a project with test driven development and continuous integration. As you can see, the red graph is doing very well, it was able to introduce a lot more features than the green graph in a shorter period of time in the beginning of the project. However, as the project rolled along, finding and fixing bugs overtook the development activity. The project without test driven planning became overwhelmed with bug fixing that new features were put on hold, delayed or cancelled due to lack of time and budget. The green graph here kept going at a continuous velocity and was able to meet the end result even though it seemed like it had a slow start.

In the next few posts, I would like to demonstrate how testing can be integrated in software development. I would like to discuss different types of testing techniques such as:

• Integration testing
• System testing
• System integration testing
• Regression testing
• Acceptance testing
• Functional testing
• Non-functional testing