Common Information Integration Testing Phases

Over the years I have seen a lot of patterns for Information integration testing process and these patterns will not be an exhaustive list of patterns a consultant will encounter over the course of a career.

However, two most common patterns in the testing process are:

The Three Test Phase Pattern

In the three test phase pattern, normally, the environment and testing activities of SIT and SWIT are combined.

The Three Test Phase Pattern

The Three Test Phase Pattern

The Four Test Phase Pattern

In the four test phase pattern, normally, the environment and testing activities of SIT and SWIT are performed separately and, frequently, will have separate environments in the migration path.

The Four Test Phase Pattern

The Four Test Phase Pattern

Testing Phases

Unit Testing:

Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. may require developing test driver modules or test harnesses.

 System Integration Testing (SIT):

Integration testing – Testing of integrated modules to verify combined functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems. Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. See also component integration testing, system integration testing.

 Software Integration Test (SWIT)

Similar to system testing, involves testing of a complete application environment, including scheduling, in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

 User Acceptance Testing (UAT):

Normally, this type of testing is done to verify if the system meets the customer specified requirements. Users or customers do this testing to determine whether to accept the application.  Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.

Related References

 

 

Migration Path Environments for Large Organizations

Migration Environment Pattern for Large Organizations

Migration Environment Pattern for Large Organizations

After describing the migration path environments for different customers, I thought it might be time to define some migration paths and their associated environments.  This is a migration environment pattern I have seen in larger organizations, perhaps, with some variation, but essential variations on a theme.  The definition of each environment is in the table below.

Environment Name Description
Development (DEV) The Development environment is used for developing the application and the submission of baseline code to the source control system.
System Integration Test (SIT) System integration testing is high-level software testing process in which testers verify that all related systems maintain data integrity and can operate in coordination with other systems in the same environment. The testing process ensures that all subcomponents are integrated successfully to provide expected results.
Software Integration Test (SWIT) Software Integration Test is where software module or component subset testing occurs to verify the functionality and/or usability of a module or component and interaction with associated software models and components.
End-To-End (E2E) Testing End-to-End Testing exercises a complete production-like scenario of the software system, it also validates batch and data processing from other upstream/downstream systems (interfaces).
System Acceptance Testing (SAT) System Acceptance Testing is to simulate the business environment, security, and regression tests. System Acceptance Testing is conducted to gain acceptance of all functionality from the user community and meets user requirements, as specified.
Production (PROD) The production environment is the final release environment, where the system will begin its Initial Operating Capability (IOC).
Control (CTRL) Control is the ‘Gold’ standard baseline environment from which migrations and new environments are provisioned.  This environment houses base configurations and metadata.  It is not used for testing.

Related References

Migration Path Environments for Small Organizations

Migration Environment Pattern For Small Organizations

Migration Environment Pattern For Small Organizations

After describing the migration path environments for different customers, I thought it might be time to define some migration paths and their associated environments.  This a migration environment pattern I have, usually, seen in small organizations.  The definition for each environment is in the table below.

Environment Name Description
Development (DEV) The Development environment is used for developing the application and the submission of baseline code to the source control system.
Quality Assurance (QA): The Quality Assurance environment is used for testing of configuration, performance, application processes, and functionality validation.
Production (PROD) The production environment is the final release environment, where the system will begin its Initial Operating Capability (IOC).

Related References

Infosphere Information Server (IIS) Component Alignment

Infosphere Information Server SDLC Alignment

Infosphere Information Server SDLC Alignment

In recent history, I have been asked several times to describe where different IIS components fit in the Software Development Lifecycle (SDLC) process.  The graphic above, list most of the more important IIS components in their relative SDLC relationships. However, it is important to note that that these are not absolutes. Many applications may cross boundaries depending on the practices of the individual company, the application spurt licensed by the company, and/or the applications implemented by the company.  For example, many components will participate in the sustainment phase of SDLC, although I did not list him in that role. This is especially true, if you’re using the governance tools (e.g. governance catalog ) and supporting your sustainment activities with modeling and development tools, such as, data architect.

Related References

IBM InfoSphere DataStage Migration Checklist

IBM InfoSphere DataStage Migration Checklist

IBM Infosphere Information Server (IIS)

Assuming that your InfoSphere instance has been installed and configured, here is a quick migration checklist to assist in making sure that you have performed the essential tasks.

 

Major Tasks Parent-Tasks Child-task Completion Status
Create Migration Package
Create Database scripts
Export DataStage components
Gather support files
Compress migration package
Baseline migration package in CM Tool
Upload package to target environment
Deploy Database Components
Backup target databases
Deploy database components
Resolve script errors
  Create JDBC, ODBC,  and/or TNSNAMES entries
  Install and Configure RDBMS client on Infosphere server
Load configuration and conversion data (if not loaded by ETL)
Deploy Support Files
  Create File Structures
WSDLs
Certificates
  Surrogate Key Files
  System Administration Scripts
  Job Scripts
  Node Configuration Files
Deploy DataStage Components
  Create Project (if required)
  Configure Project and/or Project Parameters (if required)
Import ETL’s into DataStage
Update Parameters and Parameter sets (if required)
File paths
Database names
Database credentials
Update job properties
File paths
Compile ETL using Multiple Job Compile
Resolve compilation errors
Smoke Test
Finalize CM Baseline