Testing STAND – ALONE application :

Examples of stand-alone applications are – Photoshop editor, Nero, MS-word, etc

Here, we are installing only 1 s/w which is client s/w.

The developers write the programs, they compile and compress and save it in,

            D : // Builds / B01 / AutoCad.exe

Development lead sends a mail to Test lead saying that the product is ready.

Now, the Testing Team should copy, paste and install the s/w in his own computer or local computer and test the allotted features.

Whenever the developer sends a new Build, the Test engineer will uninstall the old build and install the new build. Before releasing the product, we should also test for compatibility. Always we should work on latest build.

 Now, the Testing Team should copy, paste and install the s/w in his own computer or local computer and test the allotted features.

Whenever the developer sends a new Build, the Test engineer will uninstall the old build and install the new build. Before releasing the product, we should also test for compatibility. Always we should work on latest build.

RELIABILITY  TESTING

Testing the functionality of an application continuously for a particular period of time.

For ex – let us consider our cellphones / mobiles. The s/w may not work continuously. In mobile, after a week (or) ten days, the phone may hang up because whatever feature is present in the phone, whenever it is used it continuously creates an object in the RAM of the phone. Once the RAM is completely filled with objects, if we get any call or message – we will be unable to press the call button and the phone hangs up. Thus we make use of a clean-up software. When we switch off the phone and switch it on again, all the objects in the RAM gets deleted.

For doing Reliability testing, we write an automated program or script and click on Run. We do Reliability testing using ready-made tools and not manually. The test engineer will run the programs using Automated tools.

RECOVERY TESTING

Testing the application to check how well it recovers from crashes or disasters.

The steps involved in Recovery Testing are,

1.  Introduce defect and crash the application – Somebody will guide us as to how and when will the software crash. OR. By experience after few months of experience on working the project, we can get to know how and when the s/w can and will crash.

2.  Whenever s/w crashes, it should not disappear but should write error log message (or) crash log message where in reason for crashing should be specified. Ex – C : // Program Files /QTP /crash.log

3.  It should kill its own process before it disappears. For ex – In Windows, we have Task Manager to show which process will be running.

4.   Re-open the application. The application must be reopened with previous settings.

For ex – when using Mozilla FireFox, if the power goes off. When we switch on the PC and re-open Mozilla FireFox, we get a message asking whether we want to start a new session or restore previous session.

For any product developed, the developers write a recovery mechanism which explains – why the s/w is crashing, whether crashlog messages are written or not, etc.