Types of Mobile Application

Mobile Application 'Types' is quite confusing topic. Here is the description of Application 'Types'

1. Browser Access: The applications which we are accessing through native browser. Ex : m.yahoo.com, www.google.com, m.redbus.in

2. Hybrid Apps: We are installing the application in our device and for the functioning of that particular application internet is required. Ex : Social Networking Apps(Facebook, Twitter), Instant Messengers(Skype), E-Commerce(Flipkart), Internet Speed Testing(Speedtest)

3. Hybrid Apps: We are installing the application in our device and if required we are connecting it to internet also. Ex : Few games in which we can play alone and we go online too for playing with different players(multi player). And any medical apps where u want to keep a track record of your health and later want to share with your friends or doctor via internet.

4. Native Apps : The applications which we are installing in our device. Ex : Reminders, Few Games etc.

It can be further understand by the communication medium of the apps:

Native Apps- Which can be installed in the devices and the app does not need any data transfer to the server. With out network these apps work in the device. The data about the app will be stored in the device itself. Example Gaming applications. Here the device memory and configuration is very important as the app completely dependent on this.

Client Server apps- They can be called Semi native apps. Here the app can be installed in the device. But the with out a network it cannot be launched. Because It gets the data from the server. With out the data the app will not proceed further. Example Commercial apps like Banking app. Here you basically can see the form UI but the all the data comes from the server. So the device memory is partially dependent just to install the app as the data comes from the server for every service call.

Mobile Web applications.- They can be called as Mobile browser apps as these are not installed in the device. these can be accessed using the mobile browser by hitting the Url of the web. Here the device memory size is not all important as neither of the from or the app data is stored in the device. It is Completely dependent on the quality of the browser. Every thing comes from the server and rendered in the browser when you hit the url.

Comparison between Native Apps, Hybrid Apps and Mobile Apps:

1.Skills/tools needed for cross-platform apps:

Native: Objective-C, Java, C, C++, C#, VB.net

Hybrid:HTML, CSS, Javascript, Mobile development framework (like PhoneGap)

Mobile web:HTML, CSS, Javascript

2.Distribution:

Native:App Store/Market

Hybrid:App Store/Market

Mobile web:Internet

3.Development Speed:

Native:Slow

Hybrid:Moderate

Mobile web:Fast

4.Number of applications needed to reach major smartphone platforms

Native: 4

Hybrid: 1

Mobile web: 1

5.Ongoing application maintenance

Native: Difficult

Hybrid: Moderate

Mobile web: Low

6.Device access

Native: Full access(Camera, microphone, GPS, gyroscope, accelerometer, file upload, etc

Hybrid: Full access(Camera, microphone, GPS, gyroscope, accelerometer, file upload, etc

Mobile web: Partial access(GPS, gyroscope, accelerometer, file upload

7. Advantages

Native: Lets you create apps with rich user interfaces and/or heavy graphics

Hybrid: Combines the development speed of mobile web apps with the device access and app store distribution of native apps

Mobile web: Offers fast development, simple maintenance, and full application portability. One mobile web app works on any platform.

8. Disadvantages

Native: Development Time, Development Cost, Ongoing Maintenance, No portability (apps cannot be used on other platforms)

Hybrid: handle heavy graphics, Requires familiarity with a mobile framework

Mobile web: handle heavy graphics, Can't access camera or microphone

Difference between Severity and Priority?

Severity	Priority
In simple words, severity depends on the harshness of the bug.	In simple words, priority depends on the urgency with which the bug needs to be fixed.
It is an internal characteristic of the particular bug. Examples of High severity bugs include the application fails to start, the application crashes or causes data loss to the user.	It is an external (that is based on someone's judgment) characteristic of the bug. Examples of high priority bugs are the application does not allow any user to log in, a particular functionality is not working or the client logo is incorrect. As you can see in the above example, a high priority bug can have a high severity, a medium severity or a low severity.
Its value is based more on the needs of the end-users.	Its value is based more on the needs of the business.
Its value takes only the particular bug into account. For example, the bug may be in an obscure area of the application but still have a high severity.	Its value depends on a number of factors (e.g. the likelihood of the bug occurring, the severity of the bug and the priorities of other open bugs).
Its value is (usually) set by the bug reporter.	Its value is initially set up by the bug reporter. However, the value can be changed by someone else (e.g. the management or developer) based on their discretion.
Its value is objective and therefore less likely to change.	Its value is subjective (based on judgment). The value can change over a period of time depending on the change in the project situation.
A high severity bug may be marked for a fix immediately or later.	A high priority bug is marked for a fix immediately.
The team usually needs only a handful of values (e.g. Showstopper, High, Medium and Low) to specify severity.	In practice, new values may be designed (typically by the management) on a fairly constant basis. This may happen if there are too many high priority defects. Instead of a single High value, new values may be designed such as Fix by the end of the day, Fix in next build and Fix in the next release.

How to do exhaustive testing?

Testing a software application (except maybe a very simple program a few lines long) may well be an impossible task due to large number of:

1. All possible inputs

2. All possible input validations

3. All possible logic paths within the application

4. All possible outputs

5. All possible sequences of operations

6. All possible sequences of workflows

7. All possible speeds of execution And the above for just with a single user

8. All combinations of types of users

9. All possible number of users

10. All possible lengths of time each user may operate the application

And so on (we have not even touched the types of test environments on which the tests could be run).

However, it is possible to exhaustively execute your test suite using the following tips:

1. Your test suite should have test cases covering each documented requirement. Here my assumption is that each requirement is documented clearly.

2. The test cases should be specific, concise and efficient. Each test case should have clear and unambiguous steps and expected results.

3. The configuration data, input test data and output test data should be clearly specified.

4. You should have a clean and stable test environment in which to execute your test suite.

5. In a perfectly working application, it should be possible to execute each test case in the suite.

6.. Each confirmed bug (found during testing or found by the client) should result in another test case written or an existing test case updated.

7. Important: You should not assume the correctness and completeness of your test suite by yourself. Review of such test suite by peers, business people, managers, clients and users may provide you valuable inputs to correct your test suite.

8. Discipline in maintaining your test suite and executing it would go a long way in preventing bugs leaked to the clients/ users of your application.

Strategic Issues in Testing

Testing is a very important phase in software development life cycle. But the testing may not be very effective if proper strategy is not used.  For the implementation of successful software testing strategy, the following issues must be taken care of: -

• Before the start of the testing process, all the requirements must be specified in a quantifiable manner.
• Testing objectives must be clarified and stated explicitly.
• A proper testing plan must be developed.
• Build "robust" software that is designed to test itself.
• Use effective formal technical reviews as a filter prior to testing. Formal technical reviews can be as effective as testing in uncovering errors. For this reason, reviews can reduce the amount of testing effort that is required to produce high-quality software.
• Conduct formal technical reviews to assess the test strategy and the cases themselves. Formal technical reviews can uncover inconsistencies, omissions, and outright errors in the testing approach. This saves time and also improves product quality.
•  Develop a continuous improvement approach for the testing process. The test strategy should be measured. The metrics collected during testing should be used as part of a statistical process control approach for software testing.