Submitted by labraham on August 31, 2009 - 1:15am.As a program manager, something you'll need to give a lot of thought to at the beginning of the project is integration testing, both across the components that are in your program, and with other systems across your company. Most programs allocate a lot of time for functional testing of each component and relatively little time to integration testing under the assumption that things will go pretty smoothly.
The truth is that integration testing is often very complicated and involves more cycles of testing than most people set aside for. It is a critical part of software quality assurance and should be adequately accounted for. There are 3 main areas that drive the complexity:
- Integration Testing between components: This is the testing required for each of the touchpoints between individual components. (ie. File exchanges, messages, services, trigger points, etc...) If there has been a lot of coordination between the component teams, and a lot of early testing of these touchpoints, then these rounds of testing will go smoothly. If not, you'll find a lot of issues popping up that will require coding changes on both components, which will require regression testing and more rounds of integration testing. You'll also need to schedule integration testing for each component that interacts with each other, so for a large program with a lot of interactions between components, this can become a complex matrix very quickly.
- Performance Testing: Some programs will do performance testing of each component individually using stubs to simulate the interactions between components. And for the first rounds of performance testing, that's fine as it isolates problems to one system. However, to really understand the performance impact on a system, it's important to do at least one round of performance testing with the connectivity between the components activated, so that the performance of the interactions can be measured.
- End to End Testing: For the final set of integration testing, it's important to run through end to end test case scenarios, taking an interaction from the very first component that will be used in a user scenario through to the final backend system, and then back to the last user interaction. These tests are crucial because the number of moving parts is typically large and you don't want to wait until you are in production to make sure that they are all triggering in the correct sequence.
So with all these layers of testing required, it's important that at the start of the project, that the program manager ensures that enough time / resources is allocated in each component's project plan to incorporate all of this testing, or you will find yourself scrambling to complete the testing and take shortcuts when the production date is looming large.
Trackback URL for this post:
http://www.allianceglobalservices.com/trackback/453
|
Recent comments
9 weeks 5 hours ago
12 weeks 4 days ago