Testing Methods

4.1.1     Unit Testing

The developers test their module to check if individual units of source code are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual function or procedure. Ideally, each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended. Its implementation can vary from being very manual (pencil and paper) to being formalized as part of build automation.

4.1.2     Smoke Testing

A quick high level test that the major functions of a piece of software work originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.

4.1.3     Functional Testing

This test will confirm that all the functionalities mentioned in the requirement document are working correctly as designed. From the tester’s perspective, this test will be carried out from Unit Testing to all the way to the production.

4.1.4     Regression Testing

This is a repeated test to check whether the application is working as intended after a bug fix or after adding a new functionality in the application.

4.1.5     Pre-System Testing:

As the developers finish writing their code for Mercury Tours or are about to finish, the Mercury Test Team will create a test environment where the testers will test to check whether there is any major break down in the application. This test will also test the integration of components. Any critical defects (or high level defects in some cases) will be resolved immediately before it goes to System Testing environment. This testing will help create a cleaner application in the System Test environment.

4.1.6     System Testing

This activity will test Mercury Tours in the Test Environment upon the completion of pre-system testing, Mercury will create System Testing environment where the all the functionalities will be tested as per Use Cases. All the Test Cases will be executed and the defects will be logged as found. This environment will be environment for Mercury Test Team and will not be available for Mercury Tours Test Team. Once the System Test meets the exit criteria, then the system will be ready for Beta Testing.

4.1.7      Beta Testing

Upon completion of the requirements, development and system testing phase, Mercury will create a Beta Testing environment (the Beta site). The Beta site will be created within the Mercury network but will be available to the Mercury. The Beta site will be a scaled down version of the planned production environment and as such will not have all of the security and redundancy that a production environment would normally have. It will also not have the same performance as a production environment, but the performance will be adequate considering the minimal number of users accessing it. The network configuration and software codebase will be identical to the planned production environment. Mercury anticipates using the Beta site to continue our own internal testing, and the

Mercury or any of its designees will have full access to test any or all of the features. Mercury will create a test bed of data that the Mercury can use in their testing. These data will not be a full representation of the production site, but will allow a tester to complete an application and choose from a small subset of the member institutions, for example. A couple of supplemental forms will be available, and the e payment testing will use test credit cards and create test transactions. The Beta site is not intended for stress testing. If any problems are discovered, a mutually agreed upon process of reporting and tracking defects will be used. Mercury will use an iterative approach, fixing issues and releasing new code to be retested by the tester who reported the problem until the issue is resolved to the tester’s satisfaction.

4.1.8      Acceptance Testing (UAT)

After Beta testing is completed, Mercury will create a User Acceptance testing environment (the UAT site). The UAT site will be created within the production network environment in the AT&T Data Center and be fully available to the Mercury. The UAT site will be on the production hardware, and will have all the security features of our standard production environment. Redundancy will be added before going live. Performance will be identical to that in production.

Sapient will work with the Mercury to create a full test bed of data .  The UAT site is intended to verify the final configuration of the site and the data, and will be the basis for the production environment.

4.1.9     Stress Testing:

After the Beta Testing is complete, Test Team will perform this testing which will determine the stability of Mercury Tours This testing will be conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Often this is performance testing using a very high level of simulated load.

4.1.10  Load Testing:

Load testing will be carried out by putting a computer, peripheral, server, network or application to a work level approaching the limits of its specifications. This testing will be done under controlled lab conditions to compare the capabilities of different systems to accurately measure the capabilities of a single system. This testing will be as per realistic and close environment.

The above three different types of testing will be done in three cycles:

1. Cycle 0

2. Cycle 1

3. Cycle 2

The QA Team will execute all scenarios