This article describes a real-life situation where the test organization participated as part of the development team and was included in all phases of the development lifecycle for a highly successful software project. The project was an upgrade of the software and hardware for a mission critical communications system in the aerospace industry.
This article describes a real-life situation where the test organization participated as part of the development team and was included in all phases of the development lifecycle for a highly successful software project. The project was an upgrade of the software and hardware for a mission critical communications system in the aerospace industry. It consisted of converting approximately 70,000 lines of Fortran on a VAX mainframe to C and C++ on a DEC Alpha. This paper will discuss the project situation and the solution. It will also present the issues, difficulties, and successes of working as an integrated team to develop software.
As part of a major overhaul to a mission critical message processing system, our development team was challenged with replacing the system’s core software that consisted of the user interface, message router, and external hardware commanding functions. This software was written in Fortran and hosted on an old, slow VAX 11/785-mainframe computer. As well as being slow, this old architecture limited the user interface. The new chosen architecture was to use the faster Dec Alpha, write the software in C and C++, and use a Tolarian graphical user interface. The conversion effort was not limited to re-write the existing 70,000 lines of code, but to re-engineer the existing design and add new features and functions. The system, including software and the host computers, was to be developed in one location, shipped to the customer’s facility, installed/integrated, and tested with a minimum amount of down time to ongoing operations.
Due to budgetary constraints, our customer strongly requested that we meet an aggressive, almost unrealistic deadline for this type of effort. Basically, the customer was asking us to reduce our planned development and integration effort by approximately 6 weeks. And, as most testers know, the development (coding) team was not going to budge on their code complete date. More likely, this would probably slip out.
The project team consisted of the following:
Since we—the test and integration team—knew that the development team was not going to reduce their schedule, our challenge was to develop a new test and integration strategy that would allow us to meet the new schedule and not sacrifice quality.
To reduce lost time and minimize the test schedule, we needed to change established processes and would also need to be aggressively involved in all development activities. The customer agreed.
Changing Tests Involvement
The established methods that had been used for years at this company minimally involved the test team in any software development activity. Involvement mainly consisted of giving the test team the requirements document and letting them develop test cases from it. Test was invited to reviews, but usually didn’t know the system well enough to effectively participate. Also, the test team was usually isolated from the development team, rarely meeting until it was time to test the product.
This had to change. We proposed and implemented a much more aggressive approach. This approach intimately and formally involved the test organization in every development activity. The test team was required to work closely with the developers to understand the inner workings of the system. They were to ask questions and challenge design and development concepts. During analysis and reviews, the test team was tasked to look at the system for testability and usability as well as meet required functionality.
During this process, both teams freely shared information about their efforts. Developers would ask ‘how do you plan to test this function?’ Testers would ask ‘how are you going to handle this