Integration Testing is a testing method by which components are integrated to form a functional solution. This type of Integration testing focuses on the transfer of data across an interface between a source and target systems, a complete transaction or request could in fact run across dozens of interfaces and components. As such the most practical way to test a large integrated solution would be to slice it up into smaller points and functional clusters.

Acceptance Testing is the phase of testing which follows Integration Testing, this is normally the phase which proves the solution is “fit for purpose” and ready for production user interaction. It is the final quality gate for your project post launch and the last time you will detect any defect before you deploy. This is the test measure for the success of all your previous phases of testing and the first point of user interaction.

Performance Testing is a non functional testing phase which is normally conducted post Integration Testing and during Acceptance Testing, why? Because the code base is more final at that point and your Performance Test phase will uncover less functional errors and more performance impeding errors.

Automation Testing is a tool based scripting process which enables the solution to be recorded step by step and exercise in an automated manner reducing execution time frames and cost, by increasing execution workload and productivity.

To reduce the risk, time, and costs associated with software functional testing, you need a solution that offers deep functionality and provides support for the widest breath of applications and environments.

Regression Testing is the phase which ensures that your current services or product offering still works as they did prior to the code related change or configuration enhancements you are making. Also as software is fixed, the emergence of new or old defects is quite common. Sometimes reemergence occurs because a fix gets lost through poor release management (or simple human error in version control). Frequently, a fix for a problem in one area inadvertently causes a software bug in another area. It has often been the case that when a feature is redesigned, the same mistakes that were made in the original implementation of the feature were made in the redesign.