Testing Levels in SDLC

In the V-Model, at early stages testing process will be started and equal importance is given to testing.

Usually SDLC has different testing levels.

Each level is explained clearly below:

1)      Requirements Review

After the preparation of requirement documents like BRS and FRS documents formal reviews will be conducted to check

·         Whether all the business needs of the client covered or not?

·         All the requirements are covered or not?

·         All the requirements understandable or not?

·         All the requirements reliable or not?

2)      Design Review

After the preparation of GUI , Database and application (HLD+LLD) design documents review will be conducted on the documents by checking the following factors.

·         Design logic is correct or not?

·         Design logic is complete or not?

·         All the requirements are covered or not?

·         Design logic is reliable or not?

3)      Unit Testing

Once the preparation of source code is completed at developer’s site the development team performs testing to check for the following factors using White box testing techniques.

·         All the statements are performing in the execution or not?

·         Loops are executing perfectly or not?

·         Conditional statements are executing correctly or not?

·         Path coverage and complexity of execution.

After the successful implementation of individual components unit testing is performed.

4)      Integration Testing

After unit testing all the individual components are combined to form the system and checks the data communication among the modules.

But practically, completions of all the modules are not possible at a time to perform integration testing. At that time we follow either big-bang approach or incremental approach.

                                I.            In the big –bang approach the team has to wait until all the components are implemented to perform integration testing.

                              II.            In incremental approach the team can able to perform integration testing before the  implementation  all the components using two different techniques.

a)      Top-down Approach: whenever the sub components are under construction the temporary program called “Stub” is used to carry the result from sub components to main components while implementing integration testing.

b)      Bottom-up Approach: whenever the main component is under construction the temporary program called “driver” is used to carry the result from main component to sub components while implementing integration testing.