Integration Testing 102

Author: Dayle Fish

Introduction: The purpose of this course is to describe the roles and responsibilities involved when conducting Integration Testing.  

Background:  When an application is built, it is built in the developer’s environment which likely will not also be host to the myriad of other applications that will exist down line in an operational site.   A very coordinated procedure must be in place in order to ensure that the Integration Testing phase will be accomplished with creditability. The purpose of this course is to define these processes.  It cannot be overstated that there is significant financial benefit with identifying problems and performing corrections at the earliest and least costly opportunity, but in lieu, this final phase is a key opportunity to avoid the embarrassment of shipping a product that does not function correctly in the environment it is intended to perform in.

Responsibilities and Risks for Integration Testing

  1. Roles 
    1.  
      • §  WEB App  Testers
      • §  Desk Top App
      • §  Documentation
      • §  Automation Tools
    • Test lead ,  coordinates all efforts of assigned testers
    • Test Engineers (List Names and assignments)
    • Documentation (for reports as required)           
  2. Risks
    1.  
      • Prioritize critical metrics that must be collected
      • Identify minimal degradations that can ship, with customer
    1.  
      • Personnel vacations
      • Tasking of other products under test.
      • Staffing in general
    1.  
      • Need to be adhered to as best possible
      • Agreement on redeliveries during test cycle. (test and fix?) a redelivery of software should because for a redo, you can also pick up at failure point. 
      • Identify alternate dates  
    • Development time infringes on test schedule. Periodic status meetings between all stakeholders should alleviate.        
    • Miss understanding customer’s expectations 
    • Funding shortfalls
    • Manpower issues
    • Start and End dates
  3. Defect Recording
    • Select tool use such as remedy (normally use on used for earlier testing)
    • Agree with customer on priority definitions

    Summary: Integration testing as defined herein requires that assumptions be made as to the end configuration of the users systems. Ultimately it would be useful on the onset to query the customer as to what environment they anticipate their product to be used in, and then set your test bed up as same in order to give good credence to the Integration test.

    It is of vast importance that each and every time integration testing of a product be done, it be done in exactly if possible, the same environment as it’s earlier version.  This way the Key Performance Parameters will be valid metrics. Therefore, it is also important to write trouble reports when items do not meet the established parameters.  This is vastly important in the case of commercial products. This will add credibility in the customers’ eyes when judgment is made as to a firm’s capabilities.

    utest Help Taxonomy:

    Thanks for contacting uTest