Interrupt testing on mobile

Interrupt testing is process to replicate abrupt(Unexpected) interrupt to the application,This can be achieved in various ways and techniques depending on the application under test.


Common Interrupts :

1]Phone call when the application is running or is in background
2]Battery removal when the application is running or is in background
3]Device shut down
4]OS upgrade
5]Run other applications that uses your android resources to the fullest(suggestion : Bus driving 3d)

Some specific scenarios for application using network :

1]Connect to network but remove LAN connection from router so device can sense wifi state on device but cannot connect to internet
2]Connection via VPN and VPN disconnected

Scenario for Application using services :

1]Kill service by clicking on recent button and swiping the application right to kill app and services
2]Kill app using third party App killer
3]Kill specific services from Settings->Manage Applications

Scenarios for Application Linked to account Manager :

1]Remove account from Settings->Account Manager

Life cycle of BUG

Life cycle of BUG :-



Bug status description:
These are various stages of bug life cycle. The status caption may vary depending on the bug tracking system you are using.

1) New: When QA files new bug.

2) Deferred: If the bug is not related to current build or can not be fixed in this release or bug is not important to fix immediately then the project manager can set the bug status as deferred.

3) Assigned: ‘Assigned to’ field is set by project lead or manager and assigns bug to developer.

4) Resolved/Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.

5) Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by QA then developer can mark the bug as ‘CNR’. QA needs action to check if bug is reproduced and can assign to developer with detailed reproducing steps.

6) Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she can mark it as “Need more information’. In this case QA needs to add detailed reproducing steps and assign bug back to dev for fix.

7) Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix then QA can mark it as ‘Reopen’ so that developer can take appropriate action.

8 ) Closed: If bug is verified by the QA team and if the fix is ok and problem is solved then QA can mark bug as ‘Closed’.

9) Rejected/Invalid: Some times developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation.