Services

Test Phases

The following are compulsory test phases in any project

  • Unit Testing
  • System Testing
  • Acceptance Testing

The following are optional test phases. The test plan of the project should mention all the required test phases in its test plan
Regression/Smoke testing is not considered as a separate phase.

Strategy

A generic strategy at the application level that is applicable to all projects can be added if necessary in a separate document. This generic application strategy will sit above all of the test plans produced. In this case, the individual test plans should include a detailed strategy section tailored for this individual project

General approach

This paragraph shall present the provisions made by the service provider to achieve the test objectives defined in the quality requirements.

Present the test approach to be implemented, the general objective to be achieved and the sequence of test phases.
The general approach used for each test phase can be broken down into three tasks:

  • test preparation,
  • test performance
  • test documentation

Answer the following questions for each test phase:

  • When are the tests going to take place?
  • Who is going to test?
  • What is exactly going to be tested?

This paragraph shall also present the strategy adopted for regression test approach. This regression testing is necessary to ensure that existing functionality remains intact after the fixing of defects or the addition of new functionalities encountered during each testing phase.

Caution: This paragraph shall only present the general test approach: each test phase will be detailed in the following paragraphs.

Naming Convention

Naming convention of the test plan, cases, scenarios and the mythology has to be clearly stated in the Test Plan.

Configuration Management

Either a separate configuration management plan as per XLANZ’s configuration management guidelines needs to be prepared or he can be part of this plan as well.

Issue Management 

The bugs/Issues identified are either maintained in a separate log sheet depending on the type of testing and parameters captured or to use XLANZ Issue Management.

Test Objectives

The objective is to get the development team to complete end-end code testing. The development team members would be responsible in and out code testing on the piece of code developed by them.

Test Methodology

Test cases would be written by developers based on the requirements document and high level design, before or during detail level designing. The test cases would be more focused on the piece of code the developer would be developing. Tools like JUnit can be used during the development or test programs would be written to test the individual pieces.

Test Coverage

The test coverage of the unit test would be usually a single method to check if it performs as expected in all possible cases.

Test Objectives

The objective is more functional to check several pieces of code to work together as expected. Developers or Lead Engineers plan and execute the integration testing.

Test Methodology

Test cases are documented during part of detail level design phase. The test cases would be more functional in nature, and covers the flows of integrating modules. The testing can planned in various iterative phases based on planned integration code builds by developers.

Test Coverage

Coverage would be across modules, performing a functional flow. The testing stabilizes the module to module connectivity protocols across developers in all possible flow cases.

Test Objectives

System is large scale test used to ensure that the overall system provides the expected service in a useable and easy manner.  Sometimes these are called Black Box tests, because they test only the user interface and need to know nothing about the internal source code. 

Test Methodology

Test cases are documented based on requirements and expected functionality of the system. The test plan is reviewed with one of the stakeholders to make sure it is expected functionality

Test Coverage

Covers End-End flow of the complete system.

Test Objectives

Usually performed by customer stake holders, acts as final confirmation that the system is ready for go-live. An acceptance test confirms that an story is complete by matching a user action scenario with a desired outcome.

Test Methodology

Acceptance tests are designed and specified; often a client or end user group will document what level of results will be considered sufficiently successful for the system to be accepted.

Test Coverage

All end user scenarios are documented and tested with real time setup

Below are few testing performed based on scenario.

Sanity or Smoke Testing>

All the major flows on intermediate build will be initially Sanity Tested to check whether the system is stable enough for further testing.

Regression Testing

 Performed during incremental builds or major bug fix involving major functional flow to make sure all other basic functional flows are working

Performance Testing

Performed on modules which has to be closely tested for the performance to be in conform with the response time expected by customer or end user

Load and Stress Testing

Testing to benchmark the application to understand the graceful degradation of system performance helps customer to understand the expectation on system.

Recovery Testing

This will be decided based on the Hardware and Server configurations used. Will include the Failover Clustering and the Load Balancing techniques involved and the type of Redundancy systems decided to be used in the production setup.
 
Also the Database Backup and the Recovery Procedures - both Incremental and Absolute DB backup/recovery to be tested.

Usability Testing

User friendliness and system navigation is checked under this testing. The product will be usability tested and be bug fixed only if it requires minimal code change or on very critical end-user usability issues are identified. Usability issues must be discussed at design stages for the further enhancement or during code fixing.