Our QA specialists perform any or all of the QA Life Cycle Phases starting from defining the architecture of QA process thru performing specific testing cycle (i.e. functional, system, load/stress testing etc.).

A thorough review of the processes and design of the product/ application. Subject matter specialists and senior designers do this exercise. Architectural, Development and Implementation issues are discussed and frozen at this point in time. Our QA architects get involved at this stage to determine the potential influence of architecture and design on the QA process, platform and tools selection.

The most 'micro' scale of testing to test particular code modules. Typically done by the programmer and not by QA engineers, as it requires detailed knowledge of the internal program code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses.

Code walkthrough entails looking at a programmer or developer's code. We encourage it as a part of the QA Engineering process. There is no substitute for a close examination a programmer's code by other qualified members of the team as it catches programming errors early. The idea of code walkthrough also ensures that a programmer has used good coding practices and established coding standards.

Our QA engineers develop test cases to target each desirable and undesirable function of the software. Each function of the software is targeted and tested in separation from other functions of the software.

We test the combined parts of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc.. An automated tool can also be used to do an integration testing.

In this phase, we ensure that a bug fix or modification of software doesn't have undesirable impact on other parts or functions of the software. A mix of test cases involving different functions of the software form a regression bucket. This regression bucket needs to be executed each time a bug fix or software modification is released to QA. Automated testing tools are especially useful for this regression testing.

This is more of a customer (or user) side function as opposed to being a part of QA life cycle. We ensure that the software system meets the set criterion of quality before being accepted or released. The acceptable criterion of quality could be based on results from previous phases of QA (system testing or performance testing etc.) or may involve entirely different testing phase independent of previous testing phases performed.