Testing During the Construction Phase

Quality is a concern throughout the project. The spirit of RUP tells us that quality is a way of life. As your project progresses, you emphasize different aspects of the quality of your product. The Test discipline in RUP describes this approach to quality by recognizing that each iteration often has a different quality goal, or mission. At the beginning of each iteration you determine the mission for that iteration and decide upon the appropriate approach to fulfill that mission.

In the Inception phase we identified a general approach to testing the software and indicated who was responsible for each type of testing. In the Elaboration phase we focused on getting our unit test harness, JUnit, working and relied on manual use-case scenario testing. This was the state of the PSP Tools testing when we started the Construction phase.

For the first few Construction phase iterations we maintained the testing practices from the Elaboration phase. However, as we got closer to the Transition phase, we knew we would need more detailed testing and more types of testing. Gary and Chris were responsible for the unit testing, ensuring that the modules they created performed as specified. Liz and Jas initially ran the use-case scenario tests. But as we inched towards the Transition phase, Liz's time was occupied with documenting the product and Jas had significant time constraints because he had started a new job. Gary and Russell tested each drop, but Gary was too close to the code as one of the developers, and Russell had a business to run.

Gary used Rational PureCoverage to derive test coverage data from the unit tests and the manual use-case tests. He was already familiar with PureCoverage and we didn't need to run it that frequently. We used coverage tests to help us identify code that was either not needed, or that was never executed.

We needed to do something. We needed more automated tests. But we had a problem automating the use-case tests. We were unable to find the time, or experience, on the team to automate use-case tests.

The solution was to add a testing consultant to our team. Fortunately, Chris worked with a quality professional at Rational who volunteered to help us. Raj Srinivasan offered to set up an automated environment for us, using the Rational Java testing tools. ^[13] Our goal was to create a good set of automated tests by the time we entered the Transition phase. The automated tests would give us confidence that any changes we added late on the project, specifically in the Transition phase, did not cause regressions.

^[13] See Chapter 9 for more about the test automation.

In retrospect, we should have addressed the test automation issue earlier. Our project was small enough, and simple enough, and our quality didn't suffer from this late start. However, we might have just been lucky. Our advice is to have the test automation environment up and running, with the team trained on its use, by the end of the Elaboration phase .

There is a lesson to learn from this tale. Many people think that you choose a team for a project and, barring people leaving the project for another job, the same team stays together for the project duration. This is seldom the case. You should plan for the team to change.