Quality management

The specific definition, which does not aim to assure 'good quality' by the more general definition, but rather to ensure that an organization or product is consistent, can be considered to have four main components: quality planning, quality control, quality assurance and quality improvement. Quality management is focused not only on product/service quality, but also the means to achieve it. Quality management therefore uses quality assurance and control of processes as well as products to achieve more consistent quality.

Change Managment

Once requirements are finalized and frozen the work starts on any project. If after that customer wants to add or change requirements, it is called a "change request". Managing change requests is called change management.

Difference between Inspection and Audit

Inspection A formal evaluation technique in which software
requirements, design, or code are examined in detail by person or group
other than the author to detect faults, violations of development
standards, and other problems.
Audit - An independent examination of a work product or set of work
products to assess compliance with specifications, standards,
contractual agreements, or other criteria.

How to Test Banking Applications

Banking applications are considered to be one of the most complex applications in today’s software development and testing industry. What makes Banking application so complex? What approach should be followed in order to test the complex workflows involved? In this article we will be highlighting different stages and techniques involved in testing Banking applications.
The characteristics of a Banking application are as follows:

• Multi tier functionality to support thousands of concurrent user sessions
• Large scale Integration , typically a banking application integrates with numerous other applications such as Bill Pay utility and Trading accounts
• Complex Business workflows
• Real Time and Batch processing
• High rate of Transactions per seconds
• Secure Transactions
• Robust Reporting section to keep track of day to day transactions
• Strong Auditing to troubleshoot customer issues
• Massive storage system
• Disaster Management.

The above listed ten points are the most important characteristics of a Banking application.
Banking applications have multiple tiers involved in performing an operation. For Example, a banking application may have:

1. Web Server to interact with end users via Browser
2. Middle Tier to validate the input and output for web server
3. Data Base to store data and procedures
4. Transaction Processor which could be a large capacity Mainframe or any other Legacy system to carry out Trillions of transactions per second.

If we talk about testing banking applications it requires an end to end testing methodology involving multiple software testing techniques to ensure:

• Total  coverage of all banking workflows and Business Requirements
• Functional aspect of the application
• Security aspect of the application
• Data Integrity
• Concurrency
• User Experience

Typical stages involved in testing Banking Applications are shown in below workflow which we will be discussing individually.

1) Requirement Gathering:

Requirement gathering phase involves documentation of requirements either as Functional Specifications or Use Cases. Requirements are gathered as per customer needs and documented by Banking Experts or Business Analyst. To write requirements on more than one subject experts are involved as banking itself has multiple sub domains and one full fledge banking application will be the integration of all. For Example: A banking application may have separate modules for Transfers, Credit Cards, Reports, Loan Accounts, Bill Payments, Trading Etc.

2) Requirement Review:

The deliverable of Requirement Gathering is reviewed by all the stakeholders such as QA Engineers, Development leads and Peer Business Analysts. They cross check that neither existing business workflows nor new workflows are violated.

3) Business Scenario Preparations:

In this stage QA Engineers derive Business Scenarios from the requirement documents (Functions Specs or Use Cases); Business Scenarios are derived in such a way that all Business Requirements are covered. Business Scenarios are high level scenarios without any detailed steps, further these Business Scenarios are reviewed by Business Analyst to ensure all of Business Requirements are met and its easier for BAs to review high level scenarios than reviewing low level detailed Test Cases.

4) Functional Testing:

In this stage functional testing is performed and the usual software testing activities are performed such as:
Test Case Preparation:
In this stage Test Cases are derived from Business Scenarios, one Business Scenario leads to several positive test cases and negative test cases. Generally tools used during this stage are Microsoft Excel, Test Director or Quality Center.
Test Case Review:
Reviews by peer QA Engineers
Test Case Execution:
Test Case Execution could be either manual or automatic involving tools like QC, QTP or any other.

5) Database Testing:

Banking Application involves complex transaction which are performed both at UI level and Database level, Therefore Database testing is as important as functional testing. Database in itself is an entirely separate layer hence it is carried out by database specialists and it uses techniques like

• Data loading
• Database Migration
• Testing DB Schema and Data types
• Rules Testing
• Testing Stored Procedures and Functions
• Testing Triggers
• Data Integrity

6) Security Testing:

Security Testing is usually the last stage in the testing cycle as completing functional and non functional are entry criteria to commence Security testing. Security testing is one of the major stages in the entire Application testing cycle as this stage ensures that application complies with Federal and Industry standards. Security testing cycle makes sure the application does not have any web vulnerability which may expose sensitive data to an intruder or an attacker and complies with standards like OWASP.
In this stage the major task involves in the whole application scan which is carried out using tools like IBM Appscan or HP WebInspect (2 Most popular tools).
Once the Scan is complete the Scan Report is published out of which False Positives are filtered out and rest of the vulnerability are reported to Development team for fixing depending on the Severity.
Other Manual tools for Security Testing used are: Paros Proxy, Http Watch, Burp Suite, Fortify tools Etc.
Apart from the above stages there might be different stages involved like Integration Testing and Performance Testing.
In today’s scenario majority of Banking Projects are using: Agile/Scrum, RUP and Continuous Integration methodologies, and Tools packages like Microsoft’s VSTS and Rational Tools.
As we mentioned RUP above, RUP stands for Rational Unified Process, which is an iterative software development methodology introduced by IBM which comprises of four phases in which development and testing activities are carried out.
Four phases are:
i) Inception
ii) Collaboration
iii) Construction and
iv) Transition
RUP widely involves IBM Rational tools.
In this article we discussed how complex a Banking application could be and what are the typical phases involved in testing the application. Apart from that we also discussed current trends followed by IT industries including software development methodologies and tools.

Telecom Testing

Telecom testing is an automated, controlled method of verifying operation of your products before they go to market. Any product that connects to the PSTN (public switched telephone network) or a telecom switch (PBX) can be tested with a telephone line simulator, bulk call generator, or similar telecom test platform. Telecom testing is ideal for all telephony applications and equipment, including:

IVR systems
Switching systems
CTI applications
VoIP gateways
IADs
Why use a telecom testing solution?

A telecom test platform minimizes costs and simplifies engineering, QA, and production testing, as well as integration and pre-installation testing. A test solution can simulate telephony protocols and functions for:


Feature and performance testing
Load and stress testing
Bulk call generation
Quality of service testing
Equipment demos and product training

An automated telecom test solution provides comprehensive, consistent testing that can be customized for your specific application. In addition, thorough testing will provide peace-of-mind for you and guaranteed reliability for your customers.

Difference between mobile testing and web testing

Mobile Application Testing:
As Wireless Application Protocol (WAP) is used in mobile
phones for internet connections the browser tested here is
WAP BROWSER.

Testing is done to ensure that only wml languages are
accessed using wap browsers.And also there are automation
tools for checking mobile application testing. 

application is works as per the given
requirements.it is the basic definition of mobile
application testing.
  
to go more details:
                   testing each application in mobile like
phonebook, message, gallery, camera,games etc deeper to make
sure that all the requirements are meets. 

WEB TESTING:

For web application testing,the developed webpage is tested
in various browsers and OS and the protocol used here is IP.

 

Difference between Desktop Testing and Client-Server Testing

Desktop application runs on personal computers and work stations, so when you test the desktop application you are focusing on a specific environment. You will test complete application broadly in categories like GUI, functionality, Load, and backend i.e DB.
In client server application you have two different components to test. Application is loaded on server machine while the application exe on every client machine. You will test broadly in categories like, GUI on both sides, functionality, Load, client-server interaction, backend. This environment is mostly used in Intranet networks. You are aware of number of clients and servers and their locations in the test scenario.

Difference between client-server and web based testing

What is the difference between client-server testing and web based testing and what are things that we need to test in such applications?
Ans:
Projects are broadly divided into two types of:

• 2 tier applications
• 3 tier applications

CLIENT / SERVER TESTING
This type of testing usually done for 2 tier applications (usually developed for LAN)
Here we will be having front-end and backend.
The application launched on front-end will be having forms and reports which will be monitoring and manipulating data
E.g: applications developed in VB, VC++, Core Java, C, C++, D2K, PowerBuilder etc.,
The backend for these applications would be MS Access, SQL Server, Oracle, Sybase, Mysql, Quadbase
The tests performed on these types of applications would be
- User interface testing
- Manual support testing
- Functionality testing
- Compatibility testing & configuration testing
- Intersystem testing
WEB TESTING
This is done for 3 tier applications (developed for Internet / intranet / xtranet)
Here we will be having Browser, web server and DB server.
The applications accessible in browser would be developed in HTML, DHTML, XML, JavaScript etc. (We can monitor through these applications)
Applications for the web server would be developed in Java, ASP, JSP, VBScript, JavaScript, Perl, Cold Fusion, PHP etc. (All the manipulations are done on the web server with the help of these programs developed)
The DBserver would be having oracle, sql server, sybase, mysql etc. (All data is stored in the database available on the DB server)
The tests performed on these types of applications would be
- User interface testing
- Functionality testing
- Security testing
- Browser compatibility testing
- Load / stress testing
- Interoperability testing/intersystem testing
- Storage and data volume testing
A web-application is a three-tier application.
This has a browser (monitors data) [monitoring is done using html, dhtml, xml, javascript]-> webserver (manipulates data) [manipulations are done using programming languages or scripts like adv java, asp, jsp, vbscript, javascript, perl, coldfusion, php] -> database server (stores data) [data storage and retrieval is done using databases like oracle, sql server, sybase, mysql].
The types of tests, which can be applied on this type of applications, are:
1. User interface testing for validation & user friendliness
2. Functionality testing to validate behaviors, i/p, error handling, o/p, manipulations, services levels, order of functionality, links, content of web page & backend coverage’s
3. Security testing
4. Browser compatibility
5. Load / stress testing
6. Interoperability testing
7. Storage & data volume testing
A client-server application is a two tier application.
This has forms & reporting at front-end (monitoring & manipulations are done) [using vb, vc++, core java, c, c++, d2k, power builder etc.,] -> database server at the backend [data storage & retrieval) [using ms access, sql server, oracle, sybase, mysql, quadbase etc.,]
The tests performed on these applications would be
1. User interface testing
2. Manual support testing
3. Functionality testing
4. Compatibility testing
5. Intersystem testing
Some more points to clear the difference between client server, web and desktop applications:
Desktop application:
1. Application runs in single memory (Front end and Back end in one place)
2. Single user only
Client/Server application:
1. Application runs in two or more machines
2. Application is a menu-driven
3. Connected mode (connection exists always until logout)
4. Limited number of users
5. Less number of network issues when compared to web app.
Web application:
1. Application runs in two or more machines
2. URL-driven
3. Disconnected mode (state less)
4. Unlimited number of users
5. Many issues like hardware compatibility, browser compatibility, version compatibility, security issues, performance issues etc.
As per difference in both the applications come where, how to access the resources. In client server once connection is made it will be in state on connected, whereas in case of web testing http protocol is stateless, then there comes logic of cookies, which is not in client server.
For client server application users are well known, whereas for web application any user can login and access the content, he/she will use it as per his intentions.
So, there are always issues of security and compatibility for web application.

Testcases for Mobile Testing

TEST 1 — Installation
TEST STEPS
Before start­ing the test round, use a file man­ager to note the free user space avail­able on the phone. You will need this infor­ma­tion in test 8.
1	Install the appli­ca­tion being tested. The appli­ca­tion must install with­out error.
2	Dur­ing instal­la­tion note the ver­sion num­ber pre­sented to the user. The ver­sion num­ber must match that spec­i­fied dur­ing submission.
3	Ver­ify that the appli­ca­tion has suc­cess­fully installed on the device by nav­i­gat­ing to the area on the phone where new appli­ca­tions are installed. The appli­ca­tion should present one or more icon(s) on the phone.
Notes
For any sub­mis­sions which do not appear obvi­ously once installed, the sub­mit­ter must include details in the sub­mis­sion state­ment of how suc­cess­ful instal­la­tion can be verified. If the con­tent does not appear obvi­ously on the device once installed, and spe­cific instruc­tions are lack­ing in the sub­mis­sion state­ment, then this test will be failed.

TEST 2 — Appli­ca­tion start/stop behaviour
TEST STEPS
1	Start the appli­ca­tion by select­ing the icon or fol­low­ing the steps out­lined in the sub­mis­sion statement Nav­i­gate to the Task Man­ager and check that the appli­ca­tion appears there.
2	Close the appli­ca­tion from the Task Manager. Exit the Task Man­ager, and re-launch the Task Manager. The appli­ca­tion must no longer appear in the Task Manager.
3	Start the appli­ca­tion as in Step 1. Go to the Task Man­ager to ver­ify that the appli­ca­tion is running. The appli­ca­tion must appear in the task manager.
4	Close the appli­ca­tion from within the appli­ca­tion UI and then return to the Task Manager. The appli­ca­tion must no longer be run­ning and must no longer appear in the task manager.
5	Restart the appli­ca­tion as in Step 1. Nav­i­gate to the Task Manager. The appli­ca­tion must once again appear in the Task Manager.
Notes
An appli­ca­tion which must run in the back­ground does not need to appear in the Task Man­ager or present a UI so long as the devel­oper jus­ti­fies this behav­iour dur­ing submission. All appli­ca­tions must have some way of ver­i­fy­ing that they are run­ning on the device, though, and the devel­oper should pro­vide this information.

TEST 3 — Appli­ca­tion credentials
TEST STEPS
1	With the appli­ca­tion run­ning, check the name of the appli­ca­tion dis­played on the phone. The appli­ca­tion must dis­play the same name on the phone as stated dur­ing submission.
2	Note the func­tion­al­ity of the appli­ca­tion as it runs on the device. The basic func­tion­al­ity of the appli­ca­tion must match that declared dur­ing submission.
Notes
Step 1 does not apply to appli­ca­tions which do not have a UI VoIP appli­ca­tions must present a UI in order to pass this test.

TEST 4 — No dis­rup­tion to voice calls
TEST STEPS
1	With the appli­ca­tion installed and run­ning use a sec­ond phone to call the test device. The incom­ing call must be indi­cated to the user on the test device.
2	Answer the call on the test device. You must be able to con­duct a con­ver­sa­tion with the other party with­out inter­fer­ence from the appli­ca­tion being tested.
3	End the call in the nor­mal way on the test device. The voice call must be ended.
4	From the test device, make a call to a sec­ond phone. Answer the call from the other device. The call must be indi­cated on both devices, and you must be able to con­duct a con­ver­sa­tion with the other party with­out inter­fer­ence from the appli­ca­tion being tested.
5	End the voice call from the sec­ond device. The call must be ended on both devices.
6	Place a test call to the emer­gency 112 num­ber from the device. *Please check in your ter­ri­tory for the approved way to make test calls to the emer­gency ser­vices.
Notes
If the appli­ca­tion being tested has the Mul­ti­me­di­aDD capa­bil­ity, and has audio func­tion­al­ity, then that func­tion­al­ity must be in use whilst this test is per­formed. Par­tic­u­larly, it should be checked that the audio from the appli­ca­tion is faded down to allow the user to hear the tele­phone call. VoIP appli­ca­tions will need this test run­ning using both the hand­set held to the user’s ear and using a head­set. The test should be run with a VoIP call in progress, and the incom­ing GSM call should be announced with call wait­ing tones.

TEST 5 — No dis­rup­tion to text messages
TEST STEPS
1	With the appli­ca­tion installed and run­ning, send a text mes­sage to the test device. The incom­ing text mes­sage must be noti­fied to the user as per their alert settings.
2	Read the text mes­sage on the test device and choose to reply. Send the reply. The reply must be received at the sec­ond device.
3	From the standby screen on the test device, nav­i­gate to the “new text mes­sage” option and cre­ate a new mes­sage. Send the mes­sage to the sec­ond device. The mes­sage must be received at the sec­ond device.

TEST 6 — Auto-start behaviour
TEST STEPS
1	With the appli­ca­tion run­ning, find the set­tings for the appli­ca­tion — either within the appli­ca­tion itself or from the set­tings option on the device. There must be an option which allows the user to enable/disable auto-start functionality.
2	Ensure that the set­ting for auto-start behav­iour is dis­abled, and restart the device. The appli­ca­tion must not start on device boot.
3	Now change the set­ting so that auto-start behav­iour is enabled for the appli­ca­tion and restart the phone. The appli­ca­tion must start when the phone boots.
Notes
If the appli­ca­tion does not have auto-start func­tion­al­ity, then this test does not need to be run.

TEST 7– No dis­rup­tion to key device applications
TEST STEPS
1	Ensure that the con­tacts, mes­sag­ing and cal­en­dar appli­ca­tions are pop­u­lated with data and start the appli­ca­tion as in Test 2. After the appli­ca­tion has been installed and used, the data entered into those appli­ca­tions must not be altered in any way with­out the user being aware.
2	With the appli­ca­tion run­ning, nav­i­gate to the mes­sages appli­ca­tion and cre­ate a new message. Save that mes­sage to the drafts folder and then open and edit it. Finally, delete the mes­sage from the drafts folder and delete a mes­sage from the inbox. All of the above actions should be pos­si­ble with­out inter­fer­ence from the installed application.
3	Nav­i­gate to the con­tacts application. Cre­ate a con­tact, then edit that con­tact and then delete it. The appli­ca­tion should not inter­fere with any of the actions above with­out noti­fy­ing the user and giv­ing them option to avoid the change.
4	Nav­i­gate to the cal­en­dar application. Cre­ate an appoint­ment in the cal­en­dar. Edit the appoint­ment and then delete it. The appli­ca­tion should not inter­fere with any of the actions above with­out noti­fy­ing the user and giv­ing them option to avoid the change.
5	Use the web browser on the device to go to a web page which is known to work on the net­work being used. It must be pos­si­ble to cre­ate a data con­nec­tion and to access the web page selected.
Notes
If the appli­ca­tion, as part of stated func­tion­al­ity, makes changes to user data then an excep­tion can be claimed here. The func­tion­al­ity must be described in the doc­u­men­ta­tion with the appli­ca­tion and all data other than that men­tioned in the user guide must remain untouched as described in the test case. The data used in this test case is also needed for Test 8, so leave the data on the device when pro­ceed­ing straight into Test 8.

TEST 8 — Un-install
TEST STEPS
1	Stop the appli­ca­tion as described in Test 2 and unin­stall the appli­ca­tion using the sys­tem installer. The appli­ca­tion must be unin­stalled with­out error.
2	Fol­low­ing the same steps as in Test 1, nav­i­gate to where you would expect to see the appli­ca­tion icon. The appli­ca­tion icon must not longer be present on the device. If you used another method to ver­ify suc­cess­ful instal­la­tion in Test 1 then use this method to ensure that the appli­ca­tion has been uninstalled.
3	Check the con­tacts, mes­sages and cal­en­dar appli­ca­tions to ensure that that the data present in Test 7 is still present in those applications.
4	Using the same file man­ager as at the start of Test 1 check that the amount of user space avail­able on the device is either the same as that found in step 1 or that any dif­fer­ence between the space avail­able before and after ful­fils the fol­low­ing criteria. a) Exclud­ing user-generated and down­loaded con­tent, the appli­ca­tion leaves no more than 100Kb of data on the phone after uninstall b) Any data left on the device after install matches the expla­na­tion given dur­ing the sub­mis­sion process
Notes
You should start this test with the appli­ca­tion data from Test 7 still in place on the device.

TEST 9 — Device adaptation
TEST STEPS
Note: The fol­low­ing test steps should be run on the list of devices cor­re­spond­ing to the UIDs spec­i­fied in the .pkg file. The lead device list can be found at http://tiny.symbian.org/devicetable
1	Install the appli­ca­tion onto the device The appli­ca­tion should install on the device or present an error mes­sage to explain that it can­not install onto that device.
2	Launch the application. The appli­ca­tion should run on the device or present an error mes­sage to explain that it can­not run on that device.
3	Briefly exam­ine the appli­ca­tion whilst running. UI ele­ments should be func­tional and text should be read­able in the main screen of the application.
4	If the device on which the appli­ca­tion is cur­rently being tested sup­ports por­trait and land­scape screen modes, start the appli­ca­tion and then switch between the screen modes. The appli­ca­tion should con­tinue to be func­tional, and usable, in both screen ori­en­ta­tions of the device, whether or not the appli­ca­tion rotates in response to the screen mode change.
5	Close the appli­ca­tion from the appli­ca­tion UI The appli­ca­tion should stop running.
6	Unin­stall the appli­ca­tion from the phone. The un-installation should hap­pen with­out error and the appli­ca­tion must be un-installed.
Notes
Appli­ca­tions which do not present a UI to the user in nor­mal usage do not need to run this test. On the pri­mary device — on which all of the other test cases have been run — only step 4 of this test should be per­formed as all of the other steps of this test case are cov­ered elsewhere.

Addi­tional Tests for VoIP applications

Note that Test 3 and Test 4 both con­tain addi­tional notes which apply to the test­ing of VoIP appli­ca­tions. Please read and apply these notes when run­ning those tests on VoIP applications.

Test 10 — Addi­tional emer­gency call test­ing for VoIP apps
TEST STEPS
Note: These test steps should be per­formed twice — once with a SIM card in the device and once without.
1	With the VoIP appli­ca­tion run­ning in the back­ground, but with no VoIP call in progress, ini­ti­ate an emer­gency call in the usual way. The emer­gency call must be placed over the GSM/CDMA net­work successfully.
2	With the VoIP appli­ca­tion run­ning in the back­ground with a VoIP call in progress, ini­ti­ate an emer­gency call in the usual way. The emer­gency call must be placed over the GSM/CDMA net­work suc­cess­fully and the VoIP call should be ter­mi­nated or placed on hold.
3	With the VoIP appli­ca­tion in the back­ground, and an emer­gency call active make a VoIP call to the device. The incom­ing VoIP must be rejected, and the emer­gency call must not be interrupted.

Testing Checklist for Mobile Applications

No.	Mod­ule	Sub-Module	Test Case Description	Expected Result
1	Instal­la­tion		Ver­ify that appli­ca­tion can be Installed Successfully.	Appli­ca­tion should be able to install successfully.
2	Unin­stal­la­tion		Ver­ify that appli­ca­tion can be unin­stalled successfully.	User should be able to unin­stall the appli­ca­tion successfully.
3	Net­work Test Cases		Ver­ify the behav­ior of appli­ca­tion when there is Net­work prob­lem and user is per­form­ing oper­a­tions for data call.	User should get proper error mes­sage like “Net­work error. Please try after some time”
4			Ver­ify that user is able to estab­lish data call when Net­work is back in action.	User should be able to estab­lish data call when Net­work is back in action.
5	Voice Call Handling	Call Accept	Ver­ify that user can accept Voice call at the time when appli­ca­tion is run­ning and can resume back in appli­ca­tion from the same point.	User should be able to accept Voice call at the time when appli­ca­tion is run­ning and can resume back in appli­ca­tion from the same point.
6		Call Rejec­tion	Ver­ify that user can reject the Voice call at the time when appli­ca­tion is run­ning and can resume back in appli­ca­tion from the same point.	User should be able to reject the Voice call at the time when appli­ca­tion is run­ning and can resume back in appli­ca­tion from the same point.
7		Call Estab­lish	Ver­ify that user can estab­lish a Voice call in case when appli­ca­tion data call is run­ning in background.	User should be able to estab­lish a Voice call in case when appli­ca­tion data call is run­ning in background.
8	SMS Han­dling		Ver­ify that user can get SMS alert when appli­ca­tion is running.	User should be able to get SMS alert when appli­ca­tion is running.
9			Ver­ify that user can resume back from the same point after read­ing the SMS.	User should be able to resume back from the same point after read­ing the SMS.
10	Unmapped keys		Ver­ify that unmapped keys are not work­ing on any screen of application.	Unmapped keys should not work on any screen of application.
11	Appli­ca­tion Logo		Ver­ify that appli­ca­tion logo with Appli­ca­tion Name is present in appli­ca­tion man­ager and user can select it.	Appli­ca­tion logo with Appli­ca­tion name should be present in appli­ca­tion man­ager and user can select it.
12	Splash		Ver­ify that when user selects appli­ca­tion logo in appli­ca­tion man­ager splash is displayed.	When user selects appli­ca­tion logo in appli­ca­tion man­ager splash should be displayed.
13			Note that Splash do not remain for fore than 3 seconds.	Splash should not remain for fore than 3 seconds.
14	Low Mem­ory		Ver­ify that appli­ca­tion dis­plays proper error mes­sage when device mem­ory is low and exits grace­fully from the situation.	Appli­ca­tion should dis­play proper error mes­sage when device mem­ory is low and exits grace­fully from the situation.
15	Clear Key		Ver­ify that clear key should nav­i­gate the user to pre­vi­ous screen.	Clear key should nav­i­gate the user to pre­vi­ous screen.
16	End Key		Ver­ify that End Key should nav­i­gate the user to native OEM screen.	End Key should nav­i­gate the user to native OEM screen.
17	Visual Feed­back		Ver­ify that there is visual feed­back when response to any action takes more than 3 seconds.	There should be visual feed­back given when response time for any action is more than 3 second.
18	Con­tin­ual Key­pad Entry		Ver­ify that con­tin­ual key pad entry do not cause any problem.	Con­tin­ual key pad entry should not cause any prob­lem in application.
19	Exit Appli­ca­tion		Ver­ify that user is able to exit from appli­ca­tion with every form of exit modes like Flap,Slider,End Key or Exit option in appli­ca­tion and from any point.	User should be able to exit with every form of exit modes like Flap,Slider,End Key or Exit option in appli­ca­tion and from any point.
20	Charger Effect		Ver­ify that when appli­ca­tion is run­ning then insert­ing and remov­ing charger do not cause any prob­lem and proper mes­sage is dis­played when charger is inserted in device.	When appli­ca­tion is run­ning then insert­ing and remov­ing charger should not cause any prob­lem and proper mes­sage should be dis­played when charger is inserted in device.
21	Low Bat­tery		Ver­ify that when appli­ca­tion is run­ning and bat­tery is low then proper mes­sage is dis­played to the user.	When appli­ca­tion is run­ning and bat­tery is low then proper mes­sage is dis­played to the user telling user that bat­tery is low.
22	Removal of Battery		Ver­ify that removal of bat­tery at the time of appli­ca­tion data call is going on do not cause inter­rup­tion and data call is com­pleted after bat­tery is inserted back in the device.	Removal of bat­tery at the time of appli­ca­tion data call is going on should not cause inter­rup­tion and data call should be com­pleted after bat­tery is inserted back in the device.
23	Bat­tery Consumption		Ver­ify that appli­ca­tion does not con­sume bat­tery excessively.	The appli­ca­tion should not con­sume bat­tery excessively.
24	Appli­ca­tion Start/ Restart		1. Find the appli­ca­tion icon and select it 2. “Press a but­ton” on the device to launch the app. 3.Observe the appli­ca­tion launch In the time­line defined	Appli­ca­tion must not take more than 25s to start.
25	Appli­ca­tion Side Effects		Make sure that your appli­ca­tion is not caus­ing other appli­ca­tions of device to hamper.	Installed appli­ca­tion should not cause other appli­ca­tions of device to hamper.
26	Exter­nal incom­ing com­mu­ni­ca­tion – infrared		Appli­ca­tion should grace­fully han­dle the con­di­tion when incom­ing com­mu­ni­ca­tion is made via Infra Red [Send a file using Infrared (if applic­a­ble) to the device appli­ca­tion presents the user]	When the incom­ing com­mu­ni­ca­tion enters the device the appli­ca­tion must at least respect one of the fol­low­ing: a) Go into pause state, after the user exits the com­mu­ni­ca­tion, the appli­ca­tion presents the user with a con­tinue option or is con­tin­ued auto­mat­i­cally from the point it was sus­pended at b) Give a visual or audi­ble noti­fi­ca­tion The appli­ca­tion must not crash or hung.