Web Application Testing Checklist - Part 2

Web Application Testing Checklist

I hope you would find the Part 1 of the checklist pretty interesting. Please do share your comments if any. Here is the Part 2 of it.

 

APPLICATION SPECIFIC FUNCTIONAL REQUIREMENTS

1.   DATA INTEGRATION

• Check the maximum field lengths to ensure that there are no truncated characters?
• If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers?
• If a particular set of data is saved to the database check that each value gets saved fully to the database. (i.e.) Beware of truncation (of strings) and rounding of numeric values.

2. DATE FIELD CHECKS

• Assure that leap years are validated correctly & do not cause errors/miscalculations.
• Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations.
• Is copyright for all the sites includes Yahoo co-branded sites are updated

3. NUMERIC FIELDS

• Assure that lowest and highest values are handled correctly.
• Assure that numeric fields with a blank in position 1 are processed or reported as an error.
• Assure that fields with a blank in the last position are processed or reported as an error an error.
• Assure that both + and - values are correctly processed.
• Assure that division by zero does not occur.
• Include value zero in all calculations.
• Assure that upper and lower values in ranges are handled correctly. (Using BVA)

2.4 ALPHANUMERIC FIELD CHECKS

• Use blank and non-blank data.
• Include lowest and highest values.
• Include invalid characters & symbols.
• Include valid characters.
• Include data items with first position blank.
• Include data items with last position blank.

INTERFACE AND ERROR HANDLING

1. SERVER INTERFACE

• Verify that communication is done correctly, web server-application server, application server-database server and vice versa.
• Compatibility of server software, hardware, network connections

2. EXTERNAL INTERFACE

• Have all supported browsers been tested?
• Have all error conditions related to external interfaces been tested when external application is unavailable or server inaccessible?

3. INTERNAL INTERFACE

• If the site uses plug-ins, can the site still be used without them?
• Can all linked documents be supported/opened on all platforms (i.e. can Microsoft Word be opened on Solaris)?
• Are failures handled if there are errors in download?
• Can users use copy/paste functionality? Does it allows in password/CVV/credit card no field?
• Are you able to submit unencrypted form data?

4. INTERNAL INTERFACE

• If the system does crash, are the re-start and recovery mechanisms efficient and reliable?
• If we leave the site in the middle of a task does it cancel?
• If we lose our Internet connection does the transaction cancel?
• Does our solution handle browser crashes?
• Does our solution handle network failures between Web site and application servers?
• Have you implemented intelligent error handling (from disabling cookies, etc.)?

COMPATIBILITY

1. BROWSERS

• Is the HTML version being used compatible with appropriate browser versions?
• Do images display correctly with browsers under test?
• Verify the fonts are usable on any of the browsers
• Is Java Code/Scripts usable by the browsers under test?
• Have you tested Animated GIFs across browsers?

2. VIDEO SETTINGS

• Screen resolution (check that text and graphic alignment still work, font are readable etc.) like 1024 by 768, 600x800, 640 x 480 pixels etc
• Color depth (256, 16-bit, 32-bit)

3 CONNECTION SPEED

• Does the site load quickly enough in the viewer's browser within 8 Seconds?

4 PRINTERS

• Text and image alignment
• Colors of text, foreground and background
• Scalability to fit paper size
• Tables and borders
• Do pages print legibly without cutting off text?

Please do share your comments about the blog and how it helped get a job or how it helped solved the challenges you faced so that everyone could learn and excel together.

Join our community in Facebook and Google+ at the below URL's to stay up to date:

Facebook Page: http://www.facebook.com/SoftwareQaHelp

Google+ : https://plus.google.com/101680718973348361876

Web Application Testing Checklist - Part 1

Basic Web Application Testing Checklist

In order to help the new testers and the tenured testers for a quick review of the application for its readiness, I have put in all the information, which ever I have created the collected information over a period of time. Please do share your comments if any.

USER INTERFACE

1. COLORS

• Are hyperlink colors standard?
• Are the field backgrounds the correct color?
• Are the field prompts the correct color?
• Are the screen and field colors adjusted correctly for non-editable mode?
• Does the site use (approximately) standard link colors?
• Are all the buttons are in standard format and size?
• Is the general screen background the correct color?
• Is the page background (color) distraction free?

2. CONTENT

•  All fonts to be the same
• Are all the screen prompts specified in the correct screen font?
• Does content remain if you need to go back to a previous page, or if you move forward to another new page? (Note: This may be altered based on the application and the requirement)
• Is all text properly aligned?
• Is the text in all fields specified in the correct screen font?
• Is all the heading are left aligned
• Does the first letter of the second word appears in lowercase?

3. IMAGES

• Are all graphics properly aligned?
• Are graphics being used the most efficient use of file size?
• Are graphics optimized for quick downloads?
• Assure that command buttons are all of similar size and shape, and same font & font size.
• Banner style & size & display exact same as existing windows
• Does text wrap properly around pictures/graphics?
• Is it visually consistent even without graphics?

4. INSTRUCTIONS

• Is all the error message text spelt correctly on this screen?
• Is all the micro-help text (i.e tool tip) spelt correctly on this screen?
• Micro help text (i.e tool tip) for every enabled field & button
• Progress messages on load of tabbed(active screens) screens

5. NAVIGATION

• Are all disabled fields avoided in the TAB sequence?
• Are all read-only fields avoided in the TAB sequence?
• Can all screens accessible via buttons on this screen be accessed correctly?
• Does a scrollbar appear if required?
• Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.
• Is there a link to home on every single page?
• On open of tab focus will be on first editable field
• When an error message occurs does the focus return to the field in error when the user cancels it?

6. USABILITY

• Are all the field prompts spelt correctly?
• Are fonts too large or too small to read?
• Are names in command button & option box names are not abbreviations.
• Assure that option boxes, option buttons, and command buttons are logically grouped together in clearly demarcated areas "Group Box"
• Can the typical user run the system without frustration?
• Do pages print legibly without cutting off text?
• Does the site convey a clear sense of its intended audience?
• Does the site have a consistent, clearly recognizable "look-&-feel"?
• Does User cab Login Member Area with both UserName/Email ID?
• Does the site look good on 640 x 480, 600x800 etc.?
• Does the system provide or facilitate customer service? i.e. responsive, helpful, accurate?
• Is all terminology understandable for all of the site’s intended users?

7. TEXT BOXES

• Move mouse to textbox and it should be changed to insert bar for editable text field and should remain unchanged for non-editable text field.
• Test overflowing textbox by inserting as many characters as you can in the text field. Also test width of the text field by entering all capital W.
• Enter invalid characters, special characters and make sure that there is no abnormality.
• User should be able to select text using Shift + arrow keys. Selection should be possible using mouse and double click should select entire text in the text box.

8. RADIO BUTTONS

• Only one should be selected from the given option.
• User should be able to select any button using mouse or key board
• Arrow key should set/unset the radio buttons.

9. CHECK BOXES

• User should be able to select any combination of checkboxes
• Clicking mouse on the box should set/unset the checkbox.
• Space bar should also do the same

10. PUSH BUTTONS

• All buttons except OK/Cancel should have a letter access to them. This is indicated by a letter underlined in the button text.  The button should be activated by pressing ALT
• Clicking each button with mouse should activate it and trigger required action.
• Similarly, after giving focus SPACE or RETURN button should also do the same.
• If there is any Cancel button on the screen, pressing Esc should activate it.

11. DROP DOWN LIST BOXES

• Pressing the arrow should give list of options available to the user. List can be scrollable but user should not be able to type in.
• Pressing Ctrl-F4 should open the list box.
• Pressing a letter should bring the first item in the list starting with the same letter.
• Items should be in alphabetical order in any list.
• Selected item should be displayed on the list.
• There should be only one blank space in the dropdown list.

12. COMBO BOX

• Similar to the list mentioned above, but user should be able to enter text in it.

13. LIST BOXES

• Should allow single select, either by mouse or arrow keys.
• Pressing any letter should take you to the first element starting with that letter
• If there are view/open button, double clicking on icon should be mapped to these behavior.
• Make sure that all the data can be seen using scroll bar.

 

FUNCTIONALITY ASPECTS

1. LINKS

• Check that the link takes you to the page it said it would.
• Ensure to have no orphan pages (a page that has no links to it)
• Check all of your links to other websites
• Are all referenced web sites or email addresses hyperlinked?
• If we have removed some of the pages from our own site, set up a custom 404 page that redirects your visitors to your home page (or a search page) when the user try to access a page that no longer exists.
• Check all mailto links and whether it reaches properly

2. FORMS

• Acceptance of invalid input
• Optional versus mandatory fields
• Input longer than field allows
• Radio buttons
• Default values on page load/reload(Also terms and conditions should be disabled)
• Is Command Button can be used for Hyperlinks and Continue Links ?
• Is all the data inside combo/list box are arranged in chronological order?
• Are all of the parts of a table or form present? Correctly laid out? Can you confirm that selected texts are in the "right place?
• Does a scrollbar appear if required?

3. DATA VERIFICATION AND VALIDATION

• Is the Privacy Policy clearly defined and available for user access?
• At no point of time the system should behave awkwardly when an invalid data is fed
• Check to see what happens if a user deletes cookies while in site
• Check to see what happens if a user deletes cookies after visiting a site

Click here to move on to the next part.

Please do share your comments about the blog and how it helped get a job or how it helped solved the challenges you faced so that everyone could learn and excel together.

Join our community in Facebook and Google+ at the below URL's to stay up to date:

Facebook Page: http://www.facebook.com/SoftwareQaHelp

Google+ : https://plus.google.com/101680718973348361876

 

Basic concept of localization testing

Basic concept of localization testing on mobile application.

Localization testing checks how well the build has been localized into a particular target language. For example, if a web/mobile application is built in English and if the company wants to use the same application in other languages like Hindi, Chinese, Japanese, etc. instead of creating the different application for different languages or regions. Then at this juncture localization testing comes into play. The developers would make the same application run on different languages. But with the localization process exceedingly difficult to verify, without knowing the native language of the region.  If the product is not globalized enough to support a given language then your application is regional and run and get popularity in target area. Localization testing requires both source and target language versions of the product installed on the environment that a typical user would use. Therefore attention must be paid to the correct version of the operating system, language, regional settings and more.

Most of them would get really confused with localization testing and the linguistic testing. Localization testing focuses only on the following parameters:

1) Correct functionality
2) Appearance
3) Completeness of the localized product.


whereas linguistic testing takes care of ensuring the correct language rules are being used and focuses on correct in-context linguistic usage.

Testing teams should pay attention to the tiniest details and differences. They should look for truncations, misalignment's, un-translated strings. The testers should also be noted that the localization bug differs from the core product bug. The localization bug is specific to the language under test and it may be specific to the group of languages. For example: Most of you would have noticed some websites offering country specific, however the content of the website would be the same but the language would change. Hence it is enough to regress once or twice because it is done by tester. But should be verified by technical writer or language expert. Tester can only compare the text and observe the truncation and overlap issue generally.

Three stages of Localization are given below:

Stage 1: The product is not translated, but it must work on foreign language operating system.

Stage 2: The product user interface, release notes and installation guide only translated on targeted language.

Stage 3: The product user interface, online help, and printed documentations are translation


The following needs to be considered in localization testing:
• Upper and Lower case conversions (general rules for any language)
• Video Content (if implement).
• Keyboards is mandatory (pre defined key for app handling)
• Things that are often altered during localization, such as the User Interface and content files.
• Operating System (rex,android,iPhone OS)
• Text Filters if applicable (searching based on alphabet)
• Hot keys(before release the build)
• Spelling Rules (general rules for any language)
• Sorting Rules (general rules for searching and sorting)
• Date formats and currencies of country like dollar sign, pound and other format(special character).
• Rulers and Measurements(if implements)
• Memory Availability
• Local market complies with the local laws and regulations
• Help and about (how to install, play, mouse key function etc...) 


Learning some of the advanced concepts in the testing industry could make you eligible and choose your desired jobs. I'm a person who would always love to learn new technologies and concepts and would be sharing my experience in this blog.


Please do share your comments about the blog and how it helped get a job or how it helped solved the challenges you faced so that everyone could learn and excel together.


Join our community in Facebook and Google+ at the below URL's to stay up to date:


Facebook Page: http://www.facebook.com/SoftwareQaHelp
Google+ : https://plus.google.com/101680718973348361876

 

Security Testing on Mobile Application

 Mobile Application Security Testing

Normally security testing is not done by the normal testers and it is done by a small team of security auditors before the product or the application is launched in the market. I just came across some of the security aspects that a normal tester should be aware of to enhance the prospect of landing into a good job. Hence I am sharing my experience in the security testing (may be very little for few).


In the world of hackers and large scale online scams looming across the world. It is necessary to learn some of the basics of security testing. It is not necessary that you need to be a hacker or you need to get your self trained in some training institutes to understand the basic concepts of security.


Normally people would think about taking a ethical hacker course or online security tool to keep their information secured. However, it is not necessarily needed doing certain basic test would ensure that you are most probably staying away from the sight of the hackers. Here I would explain you about some of the basic concepts of Mobile application security testing.

I have been seriously thinking for a long time to undergo a training on the mobile application security (which some training institutes are charging thousands of dollars) and have searched on the internet for almost a year. Here is my collective outcome of the long research.

According to the McAfee Threats Report: Fourth Quarter 2010, a growing number of security threats to mobile platforms are emerging as pieces of new mobile malware increased by 46 percent from 2009 to 2010. The report notes that as more consumers use mobile devices and tablets for personal uses and business, cyber criminals have caught on. McAfee Labs said it's seen a steady incline in the number of mobile device security threats.

"The reason mobile devices have become such a big attack space is because they're being used for so much," Adam Wosotowsky, principal engineer at McAfee Labs, told CRN. (Source URL: http://www.crn.com/news/security/229208360/mobile-device-security-threats-attract-cybercriminals.htm;jsessionid=zUBN2W4VKnyANZZutVZ7IQ**.ecappj01).

This has created a necessity for the companies to concentrate on the security aspects of the application being developed for the smartphones to safeguard the user data. In this situation the security auditors and the testers find it as a tedious task to test the applications developed for the mobile devices. Here I'm going to provide you basic insight of top security concerns of the Mobile application and the steps to identify it.

Lets first discuss about the Top 10 security treats in mobile applications, which was provided by OWASP:

1) Insecure Data Storage
2) Weak Server Side Controls
3) Insufficient Transport Layer Protection
4) Client Side Injection
5) Poor Authorization and Authentication
6) Improper Session Handling
7) Security Decisions Via Untrusted Inputs
8) Side Channel Data Leakage
9) Broken Cryptography
10) Sensitive Information Disclosure

Techies would be able to grasp the basic ideas on the above topics with ease. If you are not a techie no issues, I'm going to walk through each and every treat so that people would be able to understand it with ease.

Insecure Data Storage:

Mobility apps should be server side, data should be primarily server side, and the control should be kept in the hands of the folks that know how to secure computing assets. Most of the applications on the app stores that are downloaded by the users are stored in the internal or external memory of the mobile device. It is easy for the hackers to targert the contents stored in the memory and capture it. Leaving a high chances for the hackers. I do accept that it is not possible to run the application without storing some of the components in the device. However, it is necessary that the data stored in the device should be analyzed properly before the application is launched. The sensitive information about the user or the application should not be stored in the device. The sensitive information should be stored in the server, which could be controlled and monitored with ease. If the sensitive information is to be stored on the device, it should be properly encrypted. 

Weak Server Side Control:

Weak Server Side controls, for example, is by definition not a risk specific to the mobile platform, because it’s at the server. It’s important, true. However, it’s equally important to get right for any application, regardless of the target endpoint. 

Insufficient Transport Layer Protection:

Insufficient Transport Layer protection is another category. The fundamental programmatic flaw is one that’s endemic to application programming regardless of endpoint. The data transferred should be safe and properly encrypted to avoid risks. Ensuring all the sensitive data are encrypted. This includes the data over carrier, WiFi and other NFCs.

Client Side Injection:

As like the web based applications treats, browser side attacks, XSS (the web feature), and SQL injection are basic problems. The twist isn’t the problem, it’s the impact – more direct ability to access phone functions for fraud as opposed to identity theft. This would create a negative impact on the end user of the application when his/her data is stolen. 

Poor Authorization and Authentication:

Poor authentication and authorization is definitely a mobile platform application challenge. The authorization and authentication process should be more stringent in the mobile applications before the users are being allowed to edit/view/submit the sensitive information's over the internet. Some apps soley on immutable, potentially compromised values (IMEI, IMSI and UDID) Adding contextual information is useful but could be foolproof.

Improper Session Handling:

One of OWASP’s contentions is that mobile application sessions are much longer. The sessions should be terminated properly once the user closes the application. In case the user has missed to terminate the session properly it should be automatically terminated by the system after a predefined time to avoid risk of data theft. Dont be afraid to re-authenticate every often to reduce the risk. Using device identifier as a session token is a bad idea.

Security Decisions Via Untrusted Inputs:

Consuming paid resources are often considered as safe by the users, however they could also harness the security risks. Security decisions could be leveraged to by-pass permissions and security models. Similarly depending on the platform (iOS- Abusing URL schema, Android - Abusing intents). Testers should check the caller permissions at input boundaries, Prompt the users for additional authorization before allowing. 

Side Channel Data Leakage:

Side channel data leakage is nothing but the mix of not disabling the platform features and the programmatic flaws. Which could end up sensitive information in the unintended places like web caches, keystroke logging, screenshots in the back-end (iOS devices), Crash logs, temp directories. Testers should always confirm that the credentials are not stored in the logs. Remove sensitive information before screen shots are taken. Debug the app before it is released is also necessary task for the testers to observe the files created, written or modified.

Broken Cryptography:

Broken cryptography would create a very high impact. The confidentiality of the data is lost, privilege escalation and circumvent business data. Hence the testers should verify where the data encryption starts and where it ends. Should do a stringent test on as many platforms as possible and see the encryption strength.
 

Sensitive Information Disclosure:

Apps could be reverse engineered with relative ease. Hence the testers should do a complete review of the information stored and transferred over the network before storing or passing the sensitive information like credit card numbers, SSN, etc. The sensitive and proprietary information should be stored on the server instead of storing in the device. Never allow the passwords to be hard-coded to avoid intruders.

In my next blog, will explain in detail about the best ways the testers should follow to ensure the quality of the mobile application. Also, please feel free to add your comments about the security concepts and other threats in this blog.

Join our community in Facebook and Google+ at the below URL's to stay up to date:


Facebook Page: http://www.facebook.com/SoftwareQaHelp
Google+ : https://plus.google.com/101680718973348361876

How to get the Device ID

The developers and the testers are increasingly finding it difficult to develop and test secure mobile applications. With the recent growth in the mobile space people are prone to lose their private data due to security loop homes in the hand held devices. Hence the use of device ID's are vital to reduce the impact of the security concerns.

All the major smart phone device manufacturers like Apple, Samsung, HTC, Motorolla are using the device ID's to track it.

What is a Device ID?

The Device ID is unique to your handheld device. The Device ID is not the serial number of your Device. While downloading the applications from the app stores device ID plays a major role it.

How to find the device ID in a hand help device?

Here are some of the ways to find out your devices ID on various devices.

1) Using third party applications to find the device ID

There are several third party applications, which are available on the app stores (Android Play, iTunes, etc..), which can be downloaded for free. The actual purpose of the application may be different, however they could be used to view the device ID of the application. Please find below the steps to get the device ID of your device.

Device ID on iPhone/iPad/iPod Touch or Blackberry Device:

• Download and install Skyscape application on your devices
• Open Skyscape on your new device
• Tap on Tools --> About

 Device ID on an Android Device:

• Download and install Skyscape application on your devices
• Open Skyscape on your new device
• Tap on the Tools tab
• Choose About

 Device id on a Palm:

• Download and install Skyscape application on your devices
• Open the product.
• Go to the main index of the product.
• Tap on the product title in the upper left of the screen.
• Choose Register - the device ID is listed on this screen.

 Device ID on a Pocket PC OS device:

    Download and install Skyscape application on your devices
    Open the product.
    Go to the main index of the product - Tap on the Yellow index icon.
    Tap on Help.
    Tap on Register - the Device ID is listed on this screen.

2) Programatically get device ID for Android devices:

Here is sample Code to get UDID

public class DemoActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
    TelephonyManager tm = (TelephonyManager)           this.getSystemService(Context.TELEPHONY_SERVICE);
    Log.d("ID", "Android ID: " + Secure.getString(getContentResolver(), Secure.ANDROID_ID));
    Log.d("ID", "Device ID : " + tm.getDeviceId());
}
}

For getting Device ID you have to set following permission in AndroidMenifest.xml

   

For getting ANDROID_ID you don't need to set any permission.

Join our community in Facebook and Google+ at the below URL's to stay up to date:


Facebook Page: http://www.facebook.com/SoftwareQaHelp
Google+ : https://plus.google.com/101680718973348361876

Testing Techniques

The test development process is the key parameter that the mangers and the testers should consider before starting to test the application. Most of you would have been learned about the testing techniques in your basic software testing training course in your college or other training institutes. However, I would like to explain more in detail about it for everyone to understand it easily. The technique used by the QA leads directly impact the quality of the application. Hence ample time should be taken by the QA Leads before initiating the testing.

Some of the categories of test design techniques are as follows:

• Black-box test design technique
• Specification-based test design technique
• White-box test design technique
• Structure-based test design technique
• Experience-based test design technique

Lets see the most common test design technique which is followed in the software industry.

Specification-based/Black-box techniques: 

1. Equivalence partitioning
2. Boundary value analysis
3. Decision table testing
4. State transition testing
5. Use case testing

 

Equivalence partitioning:

o Inputs to the software or system are divided in to groups that are expected to exhibit similar behavior
o Equivalence partitions or classes can be found for both valid data and invalid data
o Partitions can also be identified for outputs, internal values, time related values and for interface values.
o Equivalence partitioning is applicable all levels of testing

Example: 

The equivalence partitions are usually derived from the requirements specification for input attributes that influence the processing of the test object. An input has certain ranges which are valid and other ranges which are invalid. Invalid data here does not mean that the data is incorrect, it means that this data lies outside of specific partition. This may be best explained by the example of a function which takes a parameter "month". The valid range for the month is 1 to 12, representing January to December. This valid range is called a partition. In this example there are two further partitions of invalid ranges. The first invalid partition would be <= 0 and the second invalid partition would be >= 13.

        ... -2 -1  0 1 .............. 12 13  14  15 .....
      --------------|-------------------|---------------------
 invalid partition 1     valid partition    invalid partition 2

Boundary value analysis:

o Behavior at the edge of each equivalence partition is more likely to be incorrect. The maximum and minimum values of a partition are its boundary values.
o A boundary value for a valid partition is a valid boundary value; the boundary of an invalid partition is an invalid boundary value.
o Boundary value analysis can be applied at all test levels
o It is relatively easy to apply and its defect-finding capability is high
o This technique is often considered as an extension of equivalence partitioning. 

Boundary value analysis is a next part of Equivalence partitioning for designing test cases where test cases are selected at the edges of the equivalence classes.

Example:  

Test cases for input box accepting numbers between 1 and 500 using Boundary value analysis:
1) Test cases with test data exactly as the input boundaries of input domain i.e. values 1 and 500 in our case.
2) Test data with values just below the extreme edges of input domains i.e. values 0 and 499.
3) Test data with values just above the extreme edges of input domain i.e. values 2 and 501.

Boundary value analysis is often called as a part of stress and negative testing.

 

Decision table testing:

o In Decision table testing test cases are designed to execute the combination of inputs
o Decision tables are good way to capture system requirements that contain logical conditions.
o The decision table contains triggering conditions, often combinations of true and false for all input conditions
o It maybe applied to all situations when the action of the software depends on several logical decisions 

The limited-entry decision table is the simplest to describe. The condition alternatives are simple Boolean values, and the action entries are check-marks, representing which of the actions in a given column are to be performed.

Example: 

A technical support company writes a decision table to diagnose scanner problems based upon symptoms described to them over the phone from their clients.

The following is a balanced decision table.

Scanner troubleshooter
		Rules
Conditions	Scanner does not print	Y	Y	Y	Y	N	N	N	N
	A red light is flashing	Y	Y	N	N	Y	Y	N	N
	Scanner is unrecognized	Y	N	Y	N	Y	N	Y	N
Actions	Check the power cable			X
	Check the Scanner-computer cable	X		X
	Ensure scanner software is installed	X		X		X		X
	Check/replace ink	X	X			X	X

Of course, this is just a simple example (and it does not necessarily correspond to the reality of scanner troubleshooting), but even so, it demonstrates how decision tables can scale to several conditions with many possibilities.

 

State transition testing:

o In state transition testing test cases are designed to execute  valid and invalid state transitions
o A system may exhibit a deferent response on current conditions or previous history. In this case, that aspect of the system can be shown as a state transition diagram.
o State transition testing is much used in embedded software and technical automation.

Example:

Suppose you want to withdraw $500 from a bank ATM, you may be given cash. After some time you again try to withdraw $500 but you may be refused the money (because your account balance is insufficient). This refusal is because your bank account state has changed from having sufficient funds to cover withdrawal to having insufficient funds. The transaction that caused your account to change its state was probably the earlier withdrawal. A state diagram can represent a model from the point of view of the system or the customer.

A state transition model has four basic parts:

1. The states that the software may occupy (funded/insufficient funds)
2. The transitions from one state to another (all transitions are not allowed)
3. The events that cause a transition (like withdrawing money)
4. The actions that result from a transition (an error message or being given your cash)

 Please note that in any given state, one event can cause only one action, but that the same event from a different state may cause a different action and a different end state.

 

Use case testing:

o In use case testing test cases are designed to execute user scenarios
o A use case describes interactions between actors, including users and the system
o Each use case has preconditions, which need to be met for a use case to work successfully.
o A use case usually has a mainstream scenario and some times alternative branches.
o Use cases, often referred  to as scenarios, are very useful for designing acceptance tests with customer/user participation   

This is the simplest testing technique, the whole testing is carried out using the use case.

Join our community in Facebook and Google+ at the below URL's to stay up to date:


Facebook Page: http://www.facebook.com/SoftwareQaHelp
Google+ : https://plus.google.com/101680718973348361876

Mobile Application Testing Checklist

Mobile application testing has started to grow as a separate stream in the software industry.  With the substantial growth in the mobile market businesses are forced to leverage additional services to attract new customers and maintain repeat business. Worldwide mobile phone sales to end users totaled 314.7 million units in the first quarter of 2010, a 17 per cent increase from the same period in 2009, according to Gartner, Inc. Smarpthone sales to end users reached 54.3 million units, an increase of 48.7 per cent from the first quarter of 2009.(Source: Gartner URL: http://www.gartner.com/it/page.jsp?id=1372013)

These sources have already began a new marketing channel for the businesses.

Software companies which offer application development support and services to the business are finding it difficult to build, test and deploy the application across the various platforms or the operating systems available in the market. While the application plays a unique role in building new customers the quality of the application plays a major role in retaining the customers.

Hence the role of testers becomes more complicated to test the applications across platforms. The testers should be focusing on several factors to test the smartphone application. As I am into Mobile application testing, I have encountered various obstacles in testing and certifying the application to perform its actual operation in the smartphones and tablets. I have also came to know that several other fellow testers are also facing the same issue and I decided to post all my learning's in this blog.

After a long research and collecting the testing experience from all my friends, I have put together all the information and composed this checklist. Please feel free to download and use this spreadsheet for your testing needs. Also, if I have missed something, please post it in this blog, so that I will update the checklist for all the mobile application testing community.

You could download the spread sheet at URL: https://docs.google.com/spreadsheet/pub?key=0AjO1D__-p0updG5yQVNSd0JaLUVCcFZtX2p6dmNBbnc&output=html

Join our community in Facebook and Google+ at the below URL's to stay up to date:


Facebook Page: http://www.facebook.com/SoftwareQaHelp
Google+ : https://plus.google.com/101680718973348361876