Integrated Development/Test Project Teams

working hard to fix them. We decided to enter formal testing on schedule. Formal testing consisted of one final pass through all of the test procedures with QA witnessing the execution. Any defect or issue found at this time was formally documented and presented to the customer for review. Since development was unable to fix the last remaining defects, they were again encountered and documented. However, it was decided that these defects would not delay shipment to the customer’s facility. They were resolved in later releases.

Changing the Test and Integration Process
One of the most resisted concepts proposed to reduce the test schedule was a radical change to the established test and integration process. Because we were either reducing the amount of testing or replacing formal test activities with informal checkouts, the internal customer and their QA representative were wary of this approach. However, the test team was confident that this would not be a problem since hardware and software do not change between the development and operational facility (in theory). Even if there were problems, we felt they would most likely be configuration issues and quickly resolved.

Figure 4 is a summary of the activities that occurred during integration and test. Although the number of activities is similar, we significantly reduced the formality, and number of actual tests that were performed.

Conclusion
Issues: Although this process proved to be successful, it wasn’t without its issues, nor was it simple. The test team had to convince upper management, QA, the internal and final customers, that deviating from the existing process would not degrade the expected quality of the system. We had to assure them that test was actively involved in the development activities and that thorough testing was going to be performed. Being actively involved created it’s own issues. Some members of the development team initially had little respect for test’s involvement. However as development progressed, our value was recognized and we were repeatedly asked for our opinion on many development issues. Another issue of being too closely integrated was the potential to overlook minor issues as deadlines approached. Being part of the team, test did not want to be a problem, we wanted to be part of the team. However, we knew that being part of team meant delivering quality software. On the project, test was accused of this when the software was shipped with two known defects. One developer strongly voiced his opposition. The test team had a pivotal role in convincing management and the customer that these issues would not affect the performance of the system.

Successes/Benefits: Using these new processes and methods allowed us to meet the customer’s aggressive timeline without compromising the overall quality of the product. Even two years after the installation, only two minor defects where discovered in the original delivered code. Aggressively participating in the development activities prevented countless defects and when issues or defects were encountered, they were quickly resolved. Closely integrating the test and development teams also limited the usual friction between the two groups. And as a result, test was now viewed as a system expert and part of the ‘team’, not just a group who holds up the process.

In summary, integrating test professionals into the development team prevents defects, gives them up-front knowledge of the system, and promotes success of the entire project TEAM. It gives the testers the ability to create test documentation concurrently with software development, allows for quick resolution of defects. Also, challenging the normal process can be an effective means to reducing test time without sacrificing product quality.