Shakedown Testing

Shakedown Testing?

Testing levels or Test Phases constitute an important part of STLC Component
testing/Unit Testing, Component Integration testing, System Testing, System Integration testing are different testing levels. Each level has its own well defined test objectives. To successfully meet the test objectives, various test monitoring activities are employed. One major success factor which contributes to the testing success is availability of a stable & working Test Environment. There are many ways to certify the readiness or usability of a Test Environment, of which the most common is Shakedown Testing.

Why, Shakedown Testing?

Shakedown testing one of the most important entry criteria to kick off testing activities, irrespective of the test level. In many cases, it has been observed that once the test team is officially into a particular test level, numerous environment related defects are logged, some of them showstopper defects which forces the test team to suspend testing. This problem is more prevalent in the higher stages of testing, especially System Integration Testing & End-to-End testing. This

leads to wastage of effort and delayed test schedule and impacts project budget too. Valuable Test Cycle time is wasted. To avoid this situation, test teams include Shakedown testing as part of their project effort

schedule.

When Shakedown Testing?

Shakedown testing is usually performed duirng System Integration Testing & End-to-End testing.

The shakedown testing schedule depends on many project factors like complexity of the project,number of participating applications, the number and type of basic minimum functionalities to work to proceed/start with the official test level or phase and so on

How Shakedown testing ?

A selected number of test cases are identified for this purpose, which are tested for the

following objectives:

1. Validate the connectivity between all participating applications / systems in terms of data flow between different interfaces, channels, middleware & backend databases – basically the end-to-end business processes
2. Validate that the applications are pointed to the correct Test Environment. For example, if a transaction is triggered from say SIT1 environment but the backend application in SIT2 gets updated,it is an environment set up defect.
3. Validate that the correct build / configuration files are deployed.
4. Validate that all the necessary servers and queues are set up and working correctly.
5. Validate that the basic minimum functionalities are working in order to start testing. For example, if the login screen itself fails to work, further functionalities cannot be tested.
6. The term ‘basic minimum functionalities’ is specific to each project /application and should be identified accordingly

The test environment handed over by the development team to the testing team is accepted only if the above validations are successful. Else environment defects are raised with appropriate severity levels.