QTP Interview Questions and Answers with

Some Useful Interview Tips

Posted In | Automation Testing, QTP Tutorials, Testing Interview questions
Below are some useful tips to prepare for QTP interview, followed by the most common QTP
interview questions and answers. Actually we had planned this post at the end of our QTP
training article series. But many readers requested to provide interview questions so that you can
prepare for interview while learning QTP.
Note In this post we have covered some useful tips to prepare for QTP interview along with top
20 common and crucial Quick Test Professional questions and answers. Please provide more
questions in comments and well update this post with answers to your questions. You can also
post your questions using this Share Your QTP I nterview Questions page.
We devised a list of pre-requisites or non-technical aspects that every QTP interviewee has to be
familiar with.
Here are some useful tips to prepare for QTP interview:

QTP is merely a tool that facilitates testing. The ultimate goal of QTP- or any other
testing tool for that matter- is efficient and effective testing. So, make sure your testing
fundamentals are solid.
Next undeniably is the knowledge about the QTP tool. Make sure you know all the basic
information about the tool.
QTP predominantly relies on a testers programming skills to design, develop and
maintain tests. That does not mean knowing all the features of the tool or VB Script are
enough. The most important skill the automation tester should have is the ability for logic
building. QTP tool and VB Script are simply vehicles that help you reach a solution.
In the recent days most interviewers are asking questions that either involve writing a
script on paper or coding on a QTP installed machine. If you can code on a machine or
write the code spontaneously, thats great! If not, I suggest you to write the solution to the
problem given to you in simple English statements. This will give a chance to show case
your solution forming ability. Explain that to translate this solution into a program is
simply a matter of referring to the help files of the programming language to find the
equivalent statements.
In an interview, when you are writing code, please do not forget to include comments.
Showcase good programming practices.
Before attending a QTP interview, be sure to know the version of the QTP, the add-ins
that you use, the versions of all the other software you are using etc.
If you have not been using QTP recently but have had past experience, it helps to take a
couple of hours to re-familiarize with the IDE.
The most common but crucial questions that are asked in the QTP interview. The best part of
these questions is that you have time to prepare an answer in advance before even the interview
begins.
1. What are the reasons for choosing to automate your project and why did you choose
QTP?
2. What is the most challenging testing situation you faced and how did you overcome it?
3. Did QTP prove efficient for your project? Yes or No, explain?
4. How did you achieve reusability via QTP?
5. Did you find anything in your project that QTP proved inefficient to perform?
6. Under what conditions would you recommend QTP for future projects?
We suggest you spend some time with these questions and come up with answers based on your
practical experience from using QTP in your respective projects.
Another important question that your interviewer would be interested to know is the statistics.
For example:
1. How many scripts did you have?
2. How often were they executed?
3. How many lines of code in each script?
4. Did you use function libraries and/or shared ORs?
5. How long to develop a script?
6. Did the scripts need lot of maintenance? If yes, why?
Again, be sure to be prepared with the answers to these questions.
Last piece of advice, be honest and straightforward. Keep in mind that not all projects are same
and not everybody follows the same methods. So we recommend that you have clear
understanding of your project and exhibit the potential to learn. Nobody expects you to know
everything; they only expect you to know what you do best.
Lets move on to the technical QTP questions.
QTP Interview Questions and Answered
Top 20 Most Asked QuickTest Professional Interview Questions
1) Different types of QTP test assets and their extensions:

2) Technologies supported by QTP:
Web, Java (Core and Advanced), .Net, WPF, SAP, Oracle, Siebel, PeopleSoft, Delphi, Power
Builder, Stingray 1, Terminal Emulator, Flex, Web Services, Windows Mobile, VisualAge
Smalltalk, Silverlight and mainframe terminal emulator
3) Does QTP run in any environment?
No, QTP works only in the windows environment.
4) Explain the views in the QTP GUI?
Keyword view: This view is a tabular representation of all the objects and the actions that are
performed on them. Every row in the table is a step performed on the AUT and can be modified.
Some of the most common columns displayed are: item, operation, value and documentation.
Expert view: As the name indicates, this view is for more technical users who would want to
tweak the source code as per their requirements.
5) What is QTPs model for test creation?
a) Determine testing needs Define testing environment, Analyse your application and plan
actions
b) Set up repositories Local or Shared OR
c) Define function libraries
d) Generate test steps Add steps, Add checkpoints
e) Data drive your tests
f) Run the tests
6) What are the different kinds of test steps?
5 types of steps:
- Test Object ( Performs actions on a TO)
- Functions
- Utility (Steps to control run session. Eg: Reporter.report)
- Comment
- Programming logic (Loop, conditionsetc)
7) What are the different ways to invoke an application using QTP?
a) SystemUtil.Run
SystemUtil.Run ( FileName, Parameters, Path, Operation )
Example: SystemUtil.Run(iexplorer.exe,http://www.google.com)
SystemUtil.Run(test.txt, ,C:\,1)
b) InvokeApplication
Example: InvokeApplication C:\Program Files\Internet Explorer\IEXPLORE.EXE
http://www.google.com
c) Creating a shell object using VB Script
Example: Create a WScript.shell object.
Dim testshell
Set testshell= CreateObject (Wscript.shell)
testshell.run %windir%\notepad
8) What are the different recording modes and how do they work?
QTP provides 3 modes of recording:
------------

Normal Recording mode The default recording method is always the normal mode.
This method uses the model of Test Objects and Runtime objects to learn and act on the
AUT.
Analog recording mode records the exact mouse and key strokes that the user performs
in relation to either the screen or AUT window. The steps that are recorded using this
method cannot be edited.
The way this usually gets represented in a code is:
Window/app.RunAnalog Track1
One scenario in which this type of recording can be used is when we are trying
to capture a signature.
Low Level recording mode This mode records the co-ordinates in the application where
the operation is performed, irrespective of whether QTP recognizes the specific Object or
Operation.
9) Which recording modes need more memory?
Analog and Low-level recording modes
10) Is it possible to switch between recording modes during a test creation?
Yes, in the middle of recording, we can switch to Analog/Low-level mode, finish the task
required and go back to normal recording. The switch to Analog mode is available only during
recording and not during editing
11) Does Low level recording capture mouse movements?
No. Mouse movements are not captured.
12) How does QTP identify an object?
QTP has a predetermined set of properties that it learns/stores for every class of object it
identifies. There are 3 aspects to this:
Mandatory properties: This is the list of properties for a certain class that QTP always
stores. We could say that this is the object description. It also checks this in conjunction
with the parent object to see if the description is sufficient to identify the object uniquely.
Assistive properties: In case the description of mandatory properties is insufficient to
identify the Object a set of non-mandatory properties will be added to the description one
after the other until there is enough data to identify the object.
Ordinal I dentifier: If the assistive properties also do not result in unique identification of
an object a special ordinal identifier is added by QTP, such as the objects location on the
page or in the source code.
13) What is Smart identification?
If the recorded description does not enable QTP to identify a specific object then QTP uses
Smart identification mechanism. It uses the following additional properties to identify the
object
a) Base Filter Properties (primary) The set of properties that cannot be changed without
changing the object type
b) Optional Filter Properties (secondary) additional properties that help identify the object
uniquely.
14) What is Object Spy?
Object Spy is an extremely helpful tool that QTP has to view the properties and operations of an
object in the AUT. It shows all the properties of the object and the corresponding values. It also
shows the object hierarchy. It also has a provision that lets the users add a certain object to the
OR.
15) What is an object repository?
OR is like a warehouse where all the objects in a test are stored. OR has the list of Objects that
QTP learned during the record process and the class to which they belong. It stores the set of
properties that uniquely identifies the Object (description) and also names the object for the sake
of identification in our test, based on its most prominent feature.
16) What are the two types of repositories available, explain them?
Local and shared repository these are the two kinds of available repositories.
Every action by default has a local repository of its own and has all the objects that are used
within it.
Alternately, the tester can have a common repository for multiple actions so that all of them can
share the objects that it contains. The common repository is called a shared OR.
17) An action has both shared and local OR associated to it and both have the same object
in them. In the test which one will be considered?
If a local OR and Shared OR have an object with the same name, the action will consider the
object in its local OR.
18) Can an action have 2 shared object repositories associated with them? In that case, if
two of them contain the same object, which one will be considered?
There can be more than one Shared ORs associated to the same action. If Shared OR1 and
Shared OR2 have one object named OBJ1 each and if the action calls for OBJ1 then the order in
which the shared ORs were associated will be considered. That means, if Shared OR1 was first
associated then the OBJ1 from Shared OR1 will be taken into account.
19) Can the user toggle between using Local OR and shared OR for the same action?
Yes, it is possible to switch between one or the other types of ORs at any time. To do so, the
menu option is Test->Settings->Resources and choosing the options accordingly.
20) Are Shared ORs read only?
By default, shared ORs open as read only. To open them in order to edit them you will have to
open them from Object Repository Manager.
ORM->File->Enable Editing














QTP Interview Questions and Answers (Part 2)
1) What are advantages of test automation?
Time It produces quick results
No Manual intervention
Cost effective
Not prone to human errors
2) If the objects hierarchy is changing from build to build, then how you will handle that
condition?
In this case descriptive programming can be used instead of having an OR. Even while
descriptive programming try to use regular expressions to identify the unique property of the
objects.
3) I have developed and executed a script successfully, and saved the same to QC. When I
tried to execute the script from QC, the script is not executing. What are the possible
reasons?
1) Firstly, QuickTest Add-In for Quality Center has to be installed.
2) In the QTP Tools > Options >run tab you should have Allow other Mercury products to run
tests and components selected.
3) Make sure you are running QTP as an Admin
4) All the test resources have to be in the correct path
4) What is the extension of QTP local Repository? If it is .mtr then what is .bdb extension
stands for?
.bdb is the local OR. .mtr is a binary file that contains other information about checkpoints and
all. To re-verify the .bdb is the OR, try to rename the file with the extension as .tsr and open it
from ORM. The same objects in the OR will be displayed here. The same will not work if you
try it on .mtr file.
5) What is virtual object?
A virtual object is a non-standard object that is instructed by the tester via QTP to behave like a
standard one. More details in the tutorial #23
6) How do you capture tool tip using QTP?
Tool Tip capture method varies depending on the type of object this tool tip appears for. It could
be for links, images or any other web elements.
For web elements use: Object.title property.
For image: Image(some name).GetROProperty(alt)..etc.
7) How can you close the second opened browser?
You can know which browser instance was opened after another can be known by using the
creation time property. In simple terms, this is nothing but a counter for each browser instance
that gets launched. For the first one, it is 0 and gets incremented from then on. To close the
second opened browser, you can use the following code:
Browser(creationtime:=1).Close
8) How do know the number of browsers opened?
To do this you will have to check how many child objects of the type browser are present on
the desktop. The following is the code that explains it:
Set ObjectBrowser = Description.Create
ObjectBrowser(micclass).Value = Browser
Set BObj = Desktop.ChildObjects(ObjectBrowser)
Msgbox Obj.Count
9) What is synchronization point in QTP?
It is a feature that QTP provides to make your test wait until a certain property on a certain object
becomes an expected value before proceeding with the next steps. More information in tutorial
#24.
10) What is reusable action?
An action that can be called multiple times within or outside the same test is called reusable
action. By default all actions are reusable. More information in tutorial #21.
11) Why do we use breakpoints in QTP?
This is to stop the execution of your test at a certain point while its running. Typically it is used
to observe the state of your application or to understand how a certain feature works at a certain
phase at runtime. (The checking is of course a manual step.)
12) What is throw object?
VB Script does not have any specific throw object. (At least to the best of my knowledge) This
question will not come up unless a specific add-in that supports this feature is explored.
13) How do you know the location Id of an object if you know its index id?
Location is the position of the object from left to right and top to bottom within the parent
window, frame, or dialog box relative to other similar objects.
Index Id: is the order in which the object appears in your AUT relative to other similar objects.
E.g if you have 2 links, then index id=0 will be first link and index id=1 will be the second link.
The answer to this question is entirely dependent on where the object lies, whether it is within
the same parent or not.
14) What test cases you can automate using QTP?
As an automation enthusiast I would say, you can automate anything. It is only limited by your
imagination and expertise. However, in case you need to understand the look, feel or human
reaction to a certain feature, then that is not possible. This is the case with any tool, not specific
to QTP.
15) How to handle Java tree in QTP?
You will need to select and load the Java Add-in. Then you can record and work on a Java Tree
object just like you would with any other object.
16) How to give call to another action from one action?
Calling one action from the other can be done by Inserting a call to an existing action or by
creating a new action. Please refer tutorial #21 for detailed explanation.
17) How to find Operating system information using QTP script?
You can do that with the help of environment variable. The exact variable is, OS and OSVersion
is for the version information.
18) How you can identify browser and its information using QTP script?
You can identify and act on any browser that you opened again by referring to its creationtime
property and use it like you would with a browser object in your OR.
19) How are actions and functions different in QTP?
Actions have their own Datatables and OR, but functions dont. More importantly, Functions are
a VB Scripting element, not only applicable to QTP. Please refer article 21 a detailed explanation
of these.
20) Explain how to use QTP to check broken links on a page?
Page checkpoint. You can incorporate this page checkpoint on every page to check for broken
links. To do so, you can go to Tools->options->Web->Advanced and choosing the option to
check for broken links automatically on every page QTP accesses. More information in the
tutorial #15.
21) Can we run multiple QTP scripts one after the other without manual intervention?
How?
Yes. To do so, you will have to create a batch file using the batch runner tool and information
about the same is available in tutorial #23.
22) Explain process of smart Identification in QTP
If the recorded description does not enable QTP to identify the specified object in a step, and a
smart identification definition is defined (and enabled) for the object, QTP tries to identify the
object using Smart identification. For more information please refer to the article number: 23
23) When to use shared and local object repository?
The decision is completely up to you. Shared OR will make more sense when you have multiple
scripts referring to the same objects.
24) What are the advantages of Object Repository?
OR is an inbuilt feature provided by QTP to store your test objects. There are many advantages
and the most important one is that it is a mandatory element unless you are going for descriptive
programming.
More information on OR in tutorial #22.
25) In Hybrid framework, data can accessed through database, excel file, XML etc. Is it
true?
Yes. Any of the mentioned data sources are permissible.
26) How to associate function library at run time?
1. You can do so by using the LoadFunctionLibrary method. LoadFunctionLibrary
Completepath
2. You can also use the ExecuteFile method. ExecuteFile Completepath
27) Hybrid framework can be implemented for any application. Is it true?
Yes
28) Hybrid framework supports Descriptive programming. Is it true?
Yes. Frameworks are mostly based on how and where you want your test assets to be placed and
how they are to be accessed for maximum efficiency. They do not restrict how you write you test
itself.
29) What are the advantages of Hybrid framework?
Hybrid framework is nothing but a combination of frameworks that make you arrive at a solution
for your testing needs by taking what works best for your scenario. The obvious advantage is the
versatility. It can be tailored to meet any testing projects need.
30) What is Procedure or Subroutine in VB Script?
Sub procedure is a series of VB Script statements (enclosed by Sub and End Sub statements)
that perform actions but dont return a value. A Sub procedure can take arguments (constants,
variables, or expressions that are passed by a calling procedure). If a Sub procedure has no
arguments, its Sub statement must include an empty set of parentheses ().
31) Is VB Script Case sensitive or Case insensitive?
It is not case sensitive with respect to command and variable names. Everything else, like strings
(text) is.
32) How to record application running on Virtual machine?
You can access and record QTP script as long as the application is available to you via a browser
and not by using remote connecting software.
33) What are the factors on which script execution time is dependent?
1. Network and computer speeds. The response time from the app, the database etc. This is true
even if you are manually executing the test.
2. It also depends on the wait statements you have included.
3. Not loading the add-ins that your test does not use helps too.
4. Descriptive programming steps take longer than regular ones to execute
5. Capturing screenshots at run time through QTP also consumes time
6. Disabling smart identification also speeds up the QTP script running time
34) What is Test Fusion Report in QTP?
Test Fusion report as the name indicates is a detailed test results that QTP provides in a tree
format. It has all the iteration information, data used for each of them along with the standard
information.
35) Both Static and dynamic arrays are handled by VB script. Is it true?
Yes. A static array is declared as Dim A(10). This means its an array of 11 items. If the tester
needs to modify it to contain 20 items he can do so by using redim.
redim A(19). There is a Preserve statement that can be used in conjunction with the redim
statement. When preserve is used all the previous values are not erased.
36) What is the difference between keyword view and expert view?
They are two ways QTP shows your test. Each one has their own features and caters to users of
different levels of expertise.
Keyword view: This is a tabular representation of your test that has the information like the Item,
Operation,Data and Comments.
Expert view: This displays your test in terms of the actual lines of code. It is more like a VB
Script editor and is used by advanced users.
More information is available in the tutorial #2 and #12.
37) In website, protocol has been changed http: to https what you will do? Tell me your
approach?
Since the protocol change does not necessarily affect the UI change, except may be for a warning
message about certificates, there are not many changes. All you need to do is provide the new
URL and make sure you handle the security related pop-ups.















A Complete Guide to Usability Testing

Todays article is going to be a complete guide to usability testing. Does it sound too ambitious that we
say it is a complete guide? In this case it truly is.
Usability Testing is a realm of the IT world that tries incorporating how people would like their
applications to be which is never easy. It is like trying to read minds. What sounds like common sense,
is a profound science when it comes to usability testing.




180+ Sample Test Cases for Testing Web and
Desktop Applications Comprehensive
Testing Checklist
This is a testing checklist for web and desktop applications.
Note This article is little long (over 2700 words). My goal is to share one of the most
comprehensive testing checklist ever written and this is not yet done. Ill keep updating this post
in future with more scenarios. If you dont have time to read it now, please feel free to share with
your friends and bookmark it for later.
Make testing checklist as an integral part of test cases writing process. Using this
checklist you can easily create hundreds of test cases for testing web or desktop applications.
These are all general test cases and should be applicable for almost all kind of applications. Refer
these tests while writing test cases for your project and Im sure you will cover most testing
types except the application specific business rules provided in your SRS documents.

Though this is a common checklist, I recommend preparing a standard testing checklist tailored
to your specific needs using below test cases in addition with application specific tests.
Importance of Using Checklist for Testing:
- Maintaining a standard repository of reusable test cases for your application will ensure the
most common bugs will be caught more quickly.
- Checklist helps to quickly complete writing test cases for new versions of the application.
- Reusing test cases help to save money on resources to write repetitive tests.
- Important test cases will be covered always making it almost impossible to forget.
- Testing checklist can be referred by developers to ensure most common issues are fixed in
development phase itself.
Few notes to remember:
1) Execute these scenarios with different user roles e.g. admin user, guest user etc.
2) For web applications these scenarios should be tested on multiple browsers like IE, FF,
Chrome, and Safari with versions approved by client.
3) Test with different screen resolutions like 1024 x 768, 1280 x 1024, etc.
4) Application should be tested on variety of displays like LCD, CRT, Notebooks, Tablets, and
Mobile phones.
4) Test application on different platforms like Windows, Mac, Linux operating systems.
Comprehensive Testing Checklist for Testing Web and Desktop Applications:
Assumptions: Assuming that your application supports following functionality
- Forms with various fields
- Child windows
- Application interacts with database
- Various search filter criteria and display results
- Image upload
- Send email functionality
- Data export functionality
General Test Scenarios
1. All mandatory fields should be validated and indicated by asterisk (*) symbol
2. Validation error messages should be displayed properly at correct position
3. All error messages should be displayed in same CSS style (e.g. using red color)
4. General confirmation messages should be displayed using CSS style other than error messages
style (e.g. using green color)
5. Tool tips text should be meaningful
6. Dropdown fields should have first entry as blank or text like Select
7. Delete functionality for any record on page should ask for confirmation
8. Select/deselect all records options should be provided if page supports record
add/delete/update functionality
9. Amount values should be displayed with correct currency symbols
10. Default page sorting should be provided
11. Reset button functionality should set default values for all fields
12. All numeric values should be formatted properly
13. Input fields should be checked for max field value. Input values greater than specified max
limit should not be accepted or stored in database
14. Check all input fields for special characters
15. Field labels should be standard e.g. field accepting users first name should be labeled
properly as First Name
16. Check page sorting functionality after add/edit/delete operations on any record
17. Check for timeout functionality. Timeout values should be configurable. Check application
behavior after operation timeout
18. Check cookies used in an application
19. Check if downloadable files are pointing to correct file paths
20. All resource keys should be configurable in config files or database instead of hard coding
21. Standard conventions should be followed throughout for naming resource keys
22. Validate markup for all web pages (validate HTML and CSS for syntax errors) to make sure
it is compliant with the standards
23. Application crash or unavailable pages should be redirected to error page
24. Check text on all pages for spelling and grammatical errors
25. Check numeric input fields with character input values. Proper validation message should
appear
26. Check for negative numbers if allowed for numeric fields
27. Check amount fields with decimal number values
28. Check functionality of buttons available on all pages
29. User should not be able to submit page twice by pressing submit button in quick succession.
30. Divide by zero errors should be handled for any calculations
31. Input data with first and last position blank should be handled correctly
GUI and Usability Test Scenarios
1. All fields on page (e.g. text box, radio options, dropdown lists) should be aligned properly
2. Numeric values should be right justified unless specified otherwise
3. Enough space should be provided between field labels, columns, rows, error messages etc.
4. Scroll bar should be enabled only when necessary
5. Font size, style and color for headline, description text, labels, infield data, and grid info
should be standard as specified in SRS
6. Description text box should be multi-line
7. Disabled fields should be grayed out and user should not be able to set focus on these fields
8. Upon click of any input text field, mouse arrow pointer should get changed to cursor
9. User should not be able to type in drop down select lists
10. Information filled by users should remain intact when there is error message on page submit.
User should be able to submit the form again by correcting the errors
11. Check if proper field labels are used in error messages
12. Dropdown field values should be displayed in defined sort order
13. Tab and Shift+Tab order should work properly
14. Default radio options should be pre-selected on page load
15. Field specific and page level help messages should be available
16. Check if correct fields are highlighted in case of errors
17. Check if dropdown list options are readable and not truncated due to field size limit
18. All buttons on page should be accessible by keyboard shortcuts and user should be able to
perform all operations using keyboard
19. Check all pages for broken images
20. Check all pages for broken links
21. All pages should have title
22. Confirmation messages should be displayed before performing any update or delete
operation
23. Hour glass should be displayed when application is busy
24. Page text should be left justified
25. User should be able to select only one radio option and any combination for check boxes.
Test Scenarios for Filter Criteria
1. User should be able to filter results using all parameters on the page
2. Refine search functionality should load search page with all user selected search parameters
3. When there is at least one filter criteria is required to perform search operation, make sure
proper error message is displayed when user submits the page without selecting any filter
criteria.
4. When at least one filter criteria selection is not compulsory user should be able to submit page
and default search criteria should get used to query results
5. Proper validation messages should be displayed for invalid values for filter criteria
Test Scenarios for Result Grid
1. Page loading symbol should be displayed when its taking more than default time to load the
result page
2. Check if all search parameters are used to fetch data shown on result grid
3. Total number of results should be displayed on result grid
4. Search criteria used for searching should be displayed on result grid
5. Result grid values should be sorted by default column.
6. Sorted columns should be displayed with sorting icon
7. Result grids should include all specified columns with correct values
8. Ascending and descending sorting functionality should work for columns supported with data
sorting
9. Result grids should be displayed with proper column and row spacing
10. Pagination should be enabled when there are more results than the default result count per
page
11. Check for Next, Previous, First and Last page pagination functionality
12. Duplicate records should not be displayed in result grid
13. Check if all columns are visible and horizontal scroll bar is enabled if necessary
14. Check data for dynamic columns (columns whose values are calculated dynamically based
on the other column values)
15. For result grids showing reports check Totals row and verify total for every column
16. For result grids showing reports check Totals row data when pagination is enabled and user
navigates to next page
17. Check if proper symbols are used for displaying column values e.g. % symbol should be
displayed for percentage calculation
18. Check result grid data if date range is enabled

Test Scenarios for a Window
1. Check if default window size is correct
2. Check if child window size is correct
3. Check if there is any field on page with default focus (in general, the focus should be set on
first input field of the screen)
4. Check if child windows are getting closed on closing parent/opener window
5. If child window is opened, user should not be able to use or update any field on background or
parent window
6. Check window minimize, maximize and close functionality
7. Check if window is re-sizable
8. Check scroll bar functionality for parent and child windows
9. Check cancel button functionality for child window

Database Testing
1. Check if correct data is getting saved in database upon successful page submit
2. Check values for columns which are not accepting null values
3. Check for data integrity. Data should be stored in single or multiple tables based on design
4. Index names should be given as per the standards e.g. IND_<Tablename>_<ColumnName>
5. Tables should have primary key column
6. Table columns should have description information available (except for audit columns like
created date, created by etc.)
7. For every database add/update operation log should be added
8. Required table indexes should be created
9. Check if data is committed to database only when the operation is successfully completed
10. Data should be rolled back in case of failed transactions
11. Database name should be given as per the application type i.e. test, UAT, sandbox, live
(though this is not a standard it is helpful for database maintenance)
12. Database logical names should be given according to database name (again this is not
standard but helpful for DB maintenance)
13. Stored procedures should not be named with prefix sp_
14. Check is values for table audit columns (like createddate, createdby, updatedate, updatedby,
isdeleted, deleteddate, deletedby etc.) are populated properly
15. Check if input data is not truncated while saving. Field length shown to user on page and in
database schema should be same
16. Check numeric fields with minimum, maximum, and float values
17. Check numeric fields with negative values (for both acceptance and non-acceptance)
18. Check if radio button and dropdown list options are saved correctly in database
19. Check if database fields are designed with correct data type and data length
20. Check if all table constraints like Primary key, Foreign key etc. are implemented correctly
21. Test stored procedures and triggers with sample input data
22. Input field leading and trailing spaces should be truncated before committing data to database
23. Null values should not be allowed for Primary key column
Test Scenarios for Image Upload Functionality
(Also applicable for other file upload functionality)
1. Check for uploaded image path
2. Check image upload and change functionality
3. Check image upload functionality with image files of different extensions (e.g. JPEG, PNG,
BMP etc.)
4. Check image upload functionality with images having space or any other allowed special
character in file name
5. Check duplicate name image upload
6. Check image upload with image size greater than the max allowed size. Proper error message
should be displayed.
7. Check image upload functionality with file types other than images (e.g. txt, doc, pdf, exe
etc.). Proper error message should be displayed
8. Check if images of specified height and width (if defined) are accepted otherwise rejected
9. Image upload progress bar should appear for large size images
10. Check if cancel button functionality is working in between upload process
11. Check if file selection dialog shows only supported files listed
12. Check multiple images upload functionality
13. Check image quality after upload. Image quality should not be changed after upload
14. Check if user is able to use/view the uploaded images
Test Scenarios for Sending Emails
(Test cases for composing or validating emails are not included)
(Make sure to use dummy email addresses before executing email related tests)
1. Email template should use standard CSS for all emails
2. Email addresses should be validated before sending emails
3. Special characters in email body template should be handled properly
4. Language specific characters (e.g. Russian, Chinese or German language characters) should be
handled properly in email body template
5. Email subject should not be blank
6. Placeholder fields used in email template should be replaced with actual values e.g.
{Firstname} {Lastname} should be replaced with individuals first and last name properly for all
recipients
7. If reports with dynamic values are included in email body, report data should be calculated
correctly
8. Email sender name should not be blank
9. Emails should be checked in different email clients like Outlook, Gmail, Hotmail, Yahoo!
mail etc.
10. Check send email functionality using TO, CC and BCC fields
11. Check plain text emails
12. Check HTML format emails
13. Check email header and footer for company logo, privacy policy and other links
14. Check emails with attachments
15. Check send email functionality to single, multiple or distribution list recipients
16. Check if reply to email address is correct
17. Check sending high volume of emails
Test Scenarios for Excel Export Functionality
1. File should get exported in proper file extension
2. File name for the exported Excel file should be as per the standards e.g. if file name is using
timestamp, it should get replaced properly with actual timestamp at the time of exporting the file
3. Check for date format if exported Excel file contains date columns
4. Check number formatting for numeric or currency values. Formatting should be same as
shown on page
5. Exported file should have columns with proper column names
6. Default page sorting should be carried in exported file as well
7. Excel file data should be formatted properly with header and footer text, date, page numbers
etc. values for all pages
8. Check if data displayed on page and exported Excel file is same
9. Check export functionality when pagination is enabled
10. Check if export button is showing proper icon according to exported file type e.g. Excel file
icon for xls files
11. Check export functionality for files with very large size
12. Check export functionality for pages containing special characters. Check if these special
characters are exported properly in Excel file
Performance Testing Test Scenarios
1. Check if page load time is within acceptable range
2. Check page load on slow connections
3. Check response time for any action under light, normal, moderate and heavy load conditions
4. Check performance of database stored procedures and triggers
5. Check database query execution time
6. Check for load testing of application
7. Check for stress testing of application
8. Check CPU and memory usage under peak load condition
Security Testing Test Scenarios
1. Check for SQL injection attacks
2. Secure pages should use HTTPS protocol
3. Page crash should not reveal application or server info. Error page should be displayed for this
4. Escape special characters in input
5. Error messages should not reveal any sensitive information
6. All credentials should be transferred over an encrypted channel
7. Test password security and password policy enforcement
8. Check application logout functionality
9. Check for Brute Force Attacks
10. Cookie information should be stored in encrypted format only
11. Check session cookie duration and session termination after timeout or logout
11. Session tokens should be transmitted over secured channel
13. Password should not be stored in cookies
14. Test for Denial of Service attacks
15. Test for memory leakage
16. Test unauthorized application access by manipulating variable values in browser address bar
17. Test file extension handing so that exe files are not uploaded and executed on server
18. Sensitive fields like passwords and credit card information should not have auto complete
enabled
19. File upload functionality should use file type restrictions and also anti-virus for scanning
uploaded files
20. Check if directory listing is prohibited
21. Password and other sensitive fields should be masked while typing
22. Check if forgot password functionality is secured with features like temporary password
expiry after specified hours and security question is asked before changing or requesting new
password
23. Verify CAPTCHA functionality
24. Check if important events are logged in log files
25. Check if access privileges are implemented correctly
Penetration testing test cases Ive listed around 41 test cases for penetration testing on this
page.
I d really like to thank Devanshu Lavaniya (Sr. QA Engineer working for I-link Infosoft) for
helping me to prepare this comprehensive testing checklist.
Ive tried to cover all standard test scenarios for web and desktop application functionality. But
still I know this is not a compete checklist. Testers on different projects have their own testing
checklist based on their experience.







How to Test Banking Applications
Banking applications are considered to be one of the most complex applications in todays
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 todays scenario majority of Banking Projects are using: Agile/Scrum, RUP and
Continuous Integration methodologies, and Tools packages like Microsofts 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.






DATABASE TESTING
Database Testing Guide:
Computer applications are more complex these days with technologies like android and also with lots of
smart phone apps. The more complex the front ends, the back ends are even more intricate. So, it is all
the more important to learn about DB testing and be able to validate the databases effectively to ensure
secure and quality databases.
In this article you will learn all about Database Testing. Why to test- How to test- What to test :
These are some of the aspects we will cover.
Why do we test a database?
Below, we will briefly see why the following aspects of a DB should be validated:
1) Data Mapping: In the software systems, data often travels back and forth from the UI (user
interface) to the backend DB and vice versa. So following are the aspects to look for:
To check whether the fields in the UI/Front end forms and mapped consistently with the
corresponding DB table (and also the fields within). Typically this mapping information
is defined in the requirements documents.
Whenever a certain action is performed in the front end of an application, a
corresponding CRUD (Create, Retrieve, Update and delete) action gets invoked at the
back end. A tester will have to check if the right action is invoked and the invoked action
in itself is successful or not.
2) ACID properties validation: atomicity, consistency, isolation and durability. Every
transaction a DB performs has to adhere to these four properties. (image credit)

Atomicity means that a transaction either fails or passes. This means that even if a single
part of transaction fails- it means that the entire transaction has failed. Usually this is
called the all-or nothing rule.
Consistency: A transaction will always result in a valid state of the DB
Isolation: If there are multiple transactions and they are executed all at once, the
result/state of the DB should be the same as if they were executed one after the other.
Durability: Once a transaction is done and committed, no external factors like power loss
or crash should be able to change it
3) Data integrity:
This means that following any of the CRUD operations, the updated and most recent
values/Status of shared data should appear on all the forms and screens. A value should not be
updated on one screen and display an older value on another one. So devise your DB test cases in
a way to include checking the data in all the places it appears to see if it is consistently the same.

4) Business rule conformity: More complex databases means more complicated components
like relational constraints, triggers, stored procedures, etc. So testers will have to come up with
appropriate SQL queries in order to validate these complex objects.
How to test Database Testing Process
The general test process for DB testing is not very different from any other application. The
following are the steps:
Step #1) Prepare the environment
Step #2) Run a test
Step #3) Check test result
Step #4) Validate according to the expected results
Step #5) Report the findings to the respective stakeholders

Usually SQL queries are used to develop the tests. The most commonly used command is the
Select.
Select * from <tablename> where <condition>
Apart from select, SQL has 3 important types of commands:
1. DDL : Data definition language
2. DML: Data manipulation language
3. DCL: data control language
Let us see the syntax for the most commonly used statements.
Data Definition language: Uses CREATE, ALTER, RENAME, DROP and TRUNCATE to
handle tables (and indexes).
Create table: Create table<tablename> (field1 datatype(field size) ,..fieldn
datatype(field size))
Delete entire table: Drop table <tablename>. this command cannot be rolled back
Data Manipulation language: Includes statements to add, update and delete records.
To insert a row into a DB: INSERT INTO <table name> (field1, field2, field3)
VALUES (val1, val2valn);
Delete specific row/rows from a table: DELETE FROM TABLENAME WHERE
<required condition>.
Update rows: UPDATE <tablename> SET field1 = updated value WHERE field2 =
N;
Data control language: Deals with giving the authorization to users for manipulation and access
to the data. Grant and Revoke are the two statements used.
Grant syntax:
Grant select/update
On <table name>
To <user id1, user id2useridn>;
Revoke syntax:
Revokeselect/update
on <table name>
from<user id1, user id2useridn>;
What to test different components
1) Transactions:
When testing transactions it is important to make sure that they satisfy the ACID properties.
The following are the statements commonly used:
BEGIN TRANSACTION TRANSACTION#
END TRANSACTION TRANSACTION#
Rollback statement ensures that the database lies in a consistent state.
ROLLBACK TRANSACTION#
After these statements are executed, use a select to make sure if the changes have been reflected.
SELECT * FROM TABLENAME <tables which involve the transactions>
2) Database schema:
Database schema is nothing but a formal definition of the how the data is going to be organized
into a DB. To test it:
Identify the requirements based on which the database operates. Sample requirements:
Primary keys to be created before any other fields are created.
Foreign keys should be completely indexed for easy retrieval and searching.
Field names starting or ending with certain characters.

o Fields with a constraint that certain values can or cannot be inserted.
Use one of the following ways according to the relevance:
o SQL Query DESC<table name> to validate the schema.
o Regular expressions for validating the names of the individual fields and their
values
o Tools like SchemaCrawler
3) Trigger:
When a certain event takes places on a certain table, a piece of code (a trigger) can be auto-
instructed to be executed.
For example, a new student joined a school. The student is taking 2 classes; math and science.
The student is added to the student table. A trigger could be adding the student to the
corresponding subject tables once he is added to the student table.
The common method to test is to execute SQL query embedded in the trigger independently first
and record the result. Follow this up with executing the trigger as a whole. Compare the results.
These are tested during both the black box and white box testing phases.
White box testing: Stubs and drivers are to insert or update or delete data that would
result in the trigger being invoked. The basic idea is to just test the DB alone even before
the integration with the front end (UI) is made.
Black box testing:
a) Since the UI and DB integration is now available; we can insert/delete/update data from the
front end in a way that the trigger gets invoked. Following that select statements can be used to
retrieve the DB data to see if the trigger was successful in performing the intended operation.
b) Second way to test this is to directly load the data that would invoke the trigger and see if it
works as intended.
4) Stored Procedures:
Stored procedures are more or less similar to user defined functions. These can be invoked by a
call procedure/execute procedure statements and the output is usually in the form of result sets.
These are stored in the RDBMS and are available for applications.
These are also tested during:
White box testing: Stubs are used to invoke the stored procedures and then the results
are validated against the expected values.
Black box testing: Perform an operation from the frontend(UI) of the application and
check for the execution of the stored procedure and its results.
5. Field constraints Default value, unique value and foreign key:
Perform a front end operation which overruns the database object condition
Validate the results with a SQL Query.
Checking the default value for a certain field is quite simple. It is a part of business rule
validation. You can do it manually or you can use tools like QTP to do so. Manually, you can
perform an action that will add a value other than the default value into the field from the front
end and see if it results in an error.
The following is a sample VBScript code:
<i>Function VBScriptRegularexpressionvlaidation(pattern ,
string_to_match)</i>
<i>Set newregexp = new RegExp</i>
<i>newregexp.Pattern = <Default value as required by the business
requirements></i>
<i>newregexp.Ignorecase = True</i>
<i>newregexp.Global = True</i>
<i>VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match)</i>
<i>End Function</i>
<i>Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match)</i>
The result to the above code is true if the default value exists or false if it doesnt.
Checking the unique value can be done exactly the way we did for the default values. Try
entering values from the UI that will violate this rule and see if an error gets displayed.
Automation VB script code can be:
<i>Function VBScriptRegularexpressionvlaidation(pattern ,
string_to_match)</i>
<i>Set newregexp = new RegExp</i>
<i>newregexp.Pattern = <Unique value as required by the business
requirements></i>
<i>newregexp.Ignorecase = True</i>
<i>newregexp.Global = True</i>
<i>VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match)</i>
<i>End Function</i>
<i>Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match)</i>
For the foreign key constraint validation use data loads that directly input data that violates the
constraint and see if the application restricts the same or not. Along with the back end data load,
perform the front end UI operations too in a way that are going to violate the constraints and see
if the relevant error is displayed.

Conclusion:
With all these features, factors and processes to test on a database, there is an increasing demand
on the tester to be technically strong with the key DB concepts. Despite some of negative beliefs
that the DB testing creates new bottlenecks and is a lot of additional expenditure this is a realm
of testing that is gaining obvious attention and demand.
I hope this article has helped to focus on why that is so and also has provided you with the basic
details of what goes into testing a database.

Database Testing Properties of a Good Test
Data and Test Data Preparation Techniques

A couple of months ago, I wrote about database testing strategies. It covered the aspect that is
entirely related to the execution of test cases. It was all about black-box testing of a database.
There is another important aspect of DB testing activity which we will cover in this article.
As a tester, you have to test the Examination Results module of the website of a university.
Consider the whole application has been integrated and it is in Ready for Testing state.
Examination Module is linked with Registration, Courses and Finance modules. Assume
that you have adequate information of the application and you created a comprehensive list of
test scenarios. Now you have to design, document and execute these test cases. In
Actions/Steps section of the test cases, you must mention the acceptable data as input for the
test. The data mentioned in test cases must be selected properly. The accuracy of Actual
Results column of TC Document is primarily dependent upon the test data. So, step to prepare
the input test data is significantly important. Thus, here is my rundown on DB Testing Test
Data Preparation Strategies.
Properties of Test Data:

The test data should be selected precisely and it must possess the following four qualities:
1. Realistic: By realistic, it means the data should be accurate in the context of real life e.g. in
order to test Age field, all the values should be positive and 18 or above. It is quite obvious that
the candidates for an admission in the university are usually 18 years old (this might be defined
in requirements).
2. Practically valid: This is similar to realistic but not the same. This property is more related to
the business logic of AUT e.g. value 60 is realistic in age field but practically invalid for a
candidate of Graduation or even Masters Programs. In this case, a valid range would be 18-25
years (this might be defined in requirements).
3. Versatile to cover scenarios: There may be several subsequent conditions in a single
scenario, so choose the data shrewdly to cover maximum aspects of a single scenario with
minimum set of data, e.g. while creating test data for result module, do not only consider the case
of regular students who are smoothly completing their program. Give attention to the students
who are repeating the same course and belong to different semesters or even different programs.
The data set may look like this:
Sr# Student_ID Program_ID Course_ID Grade
1 BCS-Fall2011-Morning-01 BCS-F11 CS-401 A
2 BCS-Spring2011-Evening-14 BCS-S11 CS-401 B+
3 MIT-Fall2010-Afternoon-09 MIT-F10 CS-401 A-

There might be several other interesting and tricky sub-conditions. E.g. the limitation of years to
complete a degree program, passing a prerequisite course for registering a course, maximum no.
of courses a student may enroll in a single semester etc. etc. Make sure to cover all these
scenarios wisely with finite set of data.
4. Exceptional data (if applicable/required): There may be certain exceptional scenarios that are
less frequent but demand high importance when occur, e.g. disabled students related issues.
Test data preparation techniques:
We have briefly discussed the important properties of test data and it also elaborates how test
data selection is important while database testing. Now lets discuss the techniques to prepare
test data.
There are only two ways to prepare test data:
Method 1. Insert New Data:
Get a clean DB and insert all the data as specified in your test cases. Once, all your required and
desired data has been entered, start executing your test cases and fill Pass/Fail columns by
comparing the Actual Output with Expected Output. Sounds simple, right? But wait, its not
that simple.
Few essential and critical concerns are as follows:
1. Empty instance of database may not be available
2. Inserted test data may be insufficient for testing some cases like performance and load
testing.
3. Inserting the required test data into blank DB is not an easy job due to the database table
dependencies. Because of this inevitable restriction, data insertion can become difficult
task for tester.
4. Insertion of limited test data (just according to the test cases needs) may hide some issues
that could be found only with the large data set.
5. For data insertion, complex queries and/or procedures may be required, and for this
sufficient assistance or help from the DB developer(s) would be necessary.
Above mentioned five issues are the most important and the most obvious drawbacks of this
technique for test data preparation. But if there are some advantages as well:
1. Execution of TCs becomes more efficient as the DB has the required data only.
2. Bugs isolation requires no time as only the data specified in test cases present in the DB.
3. Less time required for testing and results comparison.
4. Clutter-free test process
Method 2. Choose sample data subset from actual DB data:
This is the feasible and more practical technique for test data preparation. However it requires
sound technical skills and demands detailed knowledge of DB Schema and SQL. In this method
you need to copy and use production data by replacing some field values by dummy values. This
is the best data subset for your testing as it represents the production data. But this may not be
feasible all the time due to data security and privacy issues.
This strategy deserves one separate post which well discuss in next article Database gray-box
testing and precautions to take while testing database.
Database Testing Practical Tips and Insight
on How to Test Database
Database is one of the inevitable parts of a software application these days. It does not matter at
all whether it is web or desktop, client server or peer to peer, enterprise or individual business,
database is working at backend. Similarly, whether it is healthcare of finance, leasing or retail,
mailing application or controlling spaceship, behind the scene a database is always in action.
Moreover, as the complexity of application increases the need of stronger and secure database
emerges. In the same way, for the applications with high frequency of transactions (e.g. banking
or finance application), necessity of fully featured DB Tool is coupled.
Currently, several database tools are available in the market e.g. MS-Access2010, MS SQL
Server 2008 r2, Oracle 10g, Oracle Financial, MySQL, PostgreSQL, DB2 etc. All of these vary
in cost, robustness, features and security. Each of these DBs possesses its own benefits and
drawbacks. One thing is certain; a business application must be built using one of these or other
DB Tools.
Before I start digging into the topic, let me comprehend the foreword. When the application is
under execution, the end user mainly utilizes the CRUD operations facilitated by the DB
Tool.
C: Create When user Save any new transaction, Create operation is performed.
R: Retrieve When user Search or View any saved transaction, Retrieve operation is
performed.
U: Update when user Edit or Modify an existing record, the Update operation of DB is
performed.
D: Delete when user Remove any record from the system, Delete operation of DB is
performed.
It does not matter at all, which DB is used and how the operation is preformed. End user has no
concern if any join or sub-query, trigger or stored-procedure, query or function was used to do
what he wanted. But, the interesting thing is that all DB operations performed by user, from UI
of any application, is one of the above four, acronym as CRUD.

As a database tester one should be focusing on following DB testing activities:
What to test in database testing:
1) Ensure data mapping:
Make sure that the mapping between different forms or screens of AUT and the Relations of its
DB is not only accurate but is also according to design documents. For all CRUD operations,
verify that respective tables and records are updated when user clicks Save, Update, Search
or Delete from GUI of the application.
2) Ensure ACID Properties of Transactions:
ACID properties of DB Transactions refer to the Atomicity, Consistency, Isolation and
Durability. Proper testing of these four properties must be done during the DB testing activity.
This area demands more rigorous, thorough and keen testing when the database is distributed.
3) Ensure Data Integrity:
Consider that different modules (i.e. screens or forms) of application use the same data in
different ways and perform all the CRUD operations on the data. In that case, make it sure that
the latest state of data is reflected everywhere. System must show the updated and most recent
values or the status of such shared data on all the forms and screens. This is called the Data
Integrity.
4) Ensure Accuracy of implemented Business Rules:
Today, databases are not meant only to store the records. In fact, DBs have been evolved into
extremely powerful tools that provide ample support to the developers in order to implement the
business logic at DB level. Some simple examples of powerful features of DBs are Referential
Integrity, relational constrains, triggers and stored procedures. So, using these and many other
features offered by DBs, developers implement the business logic on DB level. Tester must
ensure that the implemented business logic is correct and works accurately.
Above points describe the four most important What Tos of database testing. Now, I will put
some light on How Tos of DB Testing. But, first of all I feel it better to explicitly mention an
important point. DB Testing is a business critical task, and it should never be assigned to a fresh
or inexperienced resource without proper training.
How To Test Database:
1. Create your own Queries
In order to test the DB properly and accurately, first of all a tester should have very good
knowledge of SQL and specially DML (Data Manipulation Language) statements. Secondly, the
tester should acquire good understanding of internal DB structure of AUT. If these two pre-
requisites are fulfilled, then the tester is ready to test DB with complete confidence. (S)He will
perform any CRUD operation from the UI of application, and will verify the result using SQL
query.
This is the best and robust way of DB testing especially for applications with small to medium
level of complexity. Yet, the two pre-requisites described are necessary. Otherwise, this way of
DB testing cannot be adopted by the tester.
Moreover, if the application is very complex then it may be hard or impossible for the tester to
write all of the needed SQL queries himself or herself. However, for some complex queries,
tester may get help from the developer too. I always recommend this method for the testers
because it does not only give them the confidence on the testing they have performed but, also
enhance their SQL skill.
2. Observe data table by table
If the tester is not good in SQL, then he or she may verify the result of CRUD operation,
performed using GUI of the application, by viewing the tables (relations) of DB. Yet, this way
may be a bit tedious and cumbersome especially when the DB and tables have large amount of
data.
Similarly, this way of DB testing may be extremely difficult for tester if the data to be verified
belongs to multiple tables. This way of DB testing also requires at least good knowledge of
Table structure of AUT.
3. Get query from developer
This is the simplest way for the tester to test the DB. Perform any CRUD operation from GUI
and verify its impacts by executing the respective SQL query obtained from the developer. It
requires neither good knowledge of SQL nor good knowledge of applications DB structure.
So, this method seems easy and good choice for testing DB. But, its drawback is havoc. What if
the query given by the developer is semantically wrong or does not fulfill the users requirement
correctly? In this situation, the client will report the issue and will demand its fix as the best case.
While, the worst case is that client may refuse to accept the application.

Conclusion:
Database is the core and critical part of almost every software application. So DB testing of an
application demands keen attention, good SQL skills, proper knowledge of DB structure of AUT
and proper training.
In order to have the confident test report of this activity, this task should be assigned to a
resource with all the four qualities stated above. Otherwise, shipment time surprises, bugs
identification by the client, improper or unintended applications behavior or even wrong outputs
of business critical tasks are more likely to be observed. Get this task done by most suitable
resources and pay it the well-deserved attention.


ETL Testing / Data Warehouse Testing Tips,
Techniques, Process and Challenges

Today let me take a moment and explain my testing fraternity about one of the much in demand
and upcoming skills for my tester friends i.e. ETL testing (Extract, Transform, and Load). This
article will present you with a complete idea about ETL testing and what we do to test ETL
process.
It has been observed that Independent Verification and Validation is gaining huge market
potential and many companies are now seeing this as prospective business gain. Customers have
been offered different range of products in terms of service offerings, distributed in many areas
based on technology, process and solutions. ETL or data warehouse is one of the offerings which
are developing rapidly and successfully.

Why do organizations need Data Warehouse?
Organizations with organized IT practices are looking forward to create a next level of
technology transformation. They are now trying to make themselves much more operational with
easy-to-interoperate data. Having said that data is most important part of any organization, it may
be everyday data or historical data. Data is backbone of any report and reports are the baseline on
which all the vital management decisions are taken.
Most of the companies are taking a step forward for constructing their data warehouse to store
and monitor real time data as well as historical data. Crafting an efficient data warehouse is not
an easy job. Many organizations have distributed departments with different applications running
on distributed technology. ETL tool is employed in order to make a flawless integration between
different data sources from different departments. ETL tool will work as an integrator, extracting
data from different sources; transforming it in preferred format based on the business
transformation rules and loading it in cohesive DB known are Data Warehouse.
Well planned, well defined and effective testing scope guarantees smooth conversion of the
project to the production. A business gains the real buoyancy once the ETL processes are
verified and validated by independent group of experts to make sure that data warehouse is
concrete and robust.
ETL or Data warehouse testing is categorized into four different engagements irrespective
of technology or ETL tools used:
New Data Warehouse Testing New DW is built and verified from scratch. Data input
is taken from customer requirements and different data sources and new data warehouse
is build and verified with the help of ETL tools.
Migration Testing In this type of project customer will have an existing DW and ETL
performing the job but they are looking to bag new tool in order to improve efficiency.
Change Request In this type of project new data is added from different sources to an
existing DW. Also, there might be a condition where customer needs to change their
existing business rule or they might integrate the new rule.
Report Testing Report are the end result of any Data Warehouse and the basic propose
for which DW is build. Report must be tested by validating layout, data in the report and
calculation.
ETL Testing Techniques:
1) Verify that data is transformed correctly according to various business requirements and rules.
2) Make sure that all projected data is loaded into the data warehouse without any data loss and
truncation.
3) Make sure that ETL application appropriately rejects, replaces with default values and reports
invalid data.
4) Make sure that data is loaded in data warehouse within prescribed and expected time frames to
confirm improved performance and scalability.
Apart from these 4 main ETL testing methods other testing methods like integration testing and
user acceptance testing is also carried out to make sure everything is smooth and reliable.
ETL Testing Process:
Similar to any other testing that lies under Independent Verification and Validation, ETL also go
through the same phase.
Business and requirement understanding
Validating
Test Estimation
Test planning based on the inputs from test estimation and business requirement
Designing test cases and test scenarios from all the available inputs
Once all the test cases are ready and are approved, testing team proceed to perform pre-
execution check and test data preparation for testing
Lastly execution is performed till exit criteria are met
Upon successful completion summary report is prepared and closure process is done.
It is necessary to define test strategy which should be mutually accepted by stakeholders before
starting actual testing. A well defined test strategy will make sure that correct approach has been
followed meeting the testing aspiration. ETL testing might require writing SQL statements
extensively by testing team or may be tailoring the SQL provided by development team. In any
case testing team must be aware of the results they are trying to get using those SQL statements.
Difference between Database and Data Warehouse Testing
There is a popular misunderstanding that database testing and data warehouse is similar while the
fact is that both hold different direction in testing.
Database testing is done using smaller scale of data normally with OLTP (Online
transaction processing) type of databases while data warehouse testing is done with large
volume with data involving OLAP (online analytical processing) databases.
In database testing normally data is consistently injected from uniform sources while in
data warehouse testing most of the data comes from different kind of data sources which
are sequentially inconsistent.
We generally perform only CRUD (Create, read, update and delete) operation in database
testing while in data warehouse testing we use read-only (Select) operation.
Normalized databases are used in DB testing while demoralized DB is used in data
warehouse testing.
There are number of universal verifications that have to be carried out for any kind of data
warehouse testing. Below is the list of objects that are treated as essential for validation in ETL
testing:
- Verify that data transformation from source to destination works as expected
- Verify that expected data is added in target system
- Verify that all DB fields and field data is loaded without any truncation
- Verify data checksum for record count match
- Verify that for rejected data proper error logs are generated with all details
- Verify NULL value fields
- Verify that duplicate data is not loaded
- Verify data integrity
ETL Testing Challenges:
ETL testing is quite different from conventional testing. There are many challenges we faced
while performing data warehouse testing. Here is the list of few ETL testing challenges I
experienced on my project:
- Incompatible and duplicate data.
- Loss of data during ETL process.
- Unavailability of inclusive test bed.
- Testers have no privileges to execute ETL jobs by their own.
- Volume and complexity of data is very huge.
- Fault in business process and procedures.
- Trouble acquiring and building test data.
- Missing business flow information.
Data is important for businesses to make the critical business decisions. ETL testing plays a
significant role validating and ensuring that the business information is exact, consistent and
reliable. Also, it minimizes hazard of data loss in production.
Hope these tips will help ensure your ETL process is accurate and the data warehouse build by
this is a competitive advantage for your business.


A Complete Guide to Usability Testing Its
Like Trying to Read Minds!
Todays article is going to be a complete guide to usability testing. Does it sound too ambitious
that we say it is a complete guide? In this case it truly is.
Usability Testing is a realm of the IT world that tries incorporating how people would like
their applications to be which is never easy. It is like trying to read minds. What sounds like
common sense, is a profound science when it comes to usability testing.
However, we will try to address the key aspects of Usability Testing the what, who, why, when
and how- to the best of our abilities below.
What is Usability Testing?

Image credit: blog.templatemonster.com
A usability test makes sure that the interface of an AUT is built in a way that fits the users
expectations with respect to meeting requirements (effectiveness) easily (efficiently) in a
simplistic satisfying manner.
The primary focus is on:
1. Ease of use
2. Ease of Learning or familiarizing with the system
3. Satisfaction of the user with the entire experience
Usability has many dimensions to it. It is all about the users experience during their interaction
with an application and their feeling towards it. A structured Usability Test translates this
experience/feeling into a Validation Process.
Why is usability testing performed?
Web and mobile applications rule the business world in recent times. These apps being efficient,
effective, easy, simple, appealing, engaging etc. is very critical for them to be embraced by the
customers. Usability testing is all about determining if a site is what the user would want to use
and come back to or not.
This not only applies to software systems. Any machine/interface that has a human interaction
has got to satisfy these rules. How, you ask? Democracy would suffer if the voting machines
were not usable. I wouldnt vote if I had to click more than one button to choose my candidate,
would you? Exactly!
For a more software specific example, check out this 300 million dollar article by Jared Spool
that will clearly explain how the placement of a button has caused the business to be impacted.
When is Usability Testing conducted?
As testers we know that the earlier a defect is found in the SDLC the cheaper it is to fix it. The
same concept holds true for Usability Testing also.
Usability testing results effect the design of the product. So, ideally, usability testing should start
at the design level. But that is not all; software undergoes many
changes/interpretations/implementations throughout the SDLC process. To make sure that we do
not make usability related mistakes at any of these steps usability testing should be conducted
often and continuously for maximum results.
Who performs usability testing?
It can be done as an internal process, when the designers, developers and anyone else can sit
down and analyze their system and get the results. Based on these results, the design and/or code
can be modified to be in accordance with the changes they all agree on.
A more advanced approach is to hire real time users and give them particular tasks. A
facilitator/s can devise these tasks and get the results from the users.
The users can then provide information, on whether:
1. the task was successful or not
2. the task could be performed easily
3. Was the experience interesting, engaging or annoying their feeling towards the software
How is usability Testing conducted?
Testing is validation of software against its requirements. Usability testing is not different The
only requirement in this case is to validate if the software is as per a mental map of how a user
would want the software to be like, what makes it comfortable for them to use, what kind of
holistic experience is the user going to take away from the interaction etc.
These are just a few of the ways in which usability testing is carried out.
Method #1) During the design phase, you could just take draw your website/application design
on a piece of paper and evaluate whether it is going to work or not.
Method #2) An exploratory method would be to build the site and perform some random tests
(by the development/design/QA- any or all internal teams) to determine usability factors.
Method #3) Hire a set of real time users to work on the site and report results
Method #4) Use a tool that would provide statistics based on the input wireframes and designs
submitted
Method #5) Hire a third-party usability team that specialize in this field
Method #6) Submit your site design and wireframes to an external evaluator and get results from
them
The structured Usability testing process contains the following steps:
Step #1) Identifying the users to perform the usability test it helps to choose the set of users
that is close to how the real time users are going to be. Care has to be taken not to pick experts or
complete newbies . The experts are going to simply run through the entire process and the
novices need lots of background training to even get started- neither situation is optimum.
Step #2) Designing the tasks that the users are going to perform on the application A list
of situations that the users are going to use the application for are to be made prior to starting the
test. This can include something like: Search for an X-box and buy it or submit a customer
care question etc. on an eCommerce site. The tasks should closely represent the real
transactions the users would use the site for.
Step #3) Facilitating the testing - The usability team will have the users perform the tasks on
the site and are going to gather information regarding the test progress and results. It really
makes a huge difference when the design team participates while the users are working on the
application. It gives them a better picture about how the app was used and where it did not
deliver what the user wanted etc, firsthand.
Step #4) Analyze results At the end of the test, we might end up with the time it took to
perform tasks, whether the task was successful or not etc, so basically raw data. The results have
to be presented to all the stakeholders and analyzed for identification of potential problem areas.
Usability Testing Tools
There are also many tools that help this process along. All these tools can be roughly
categorized as follows:
Category 1: Create tasks/tests and give them to users (finding the users and giving them tasks is
a manual activity, outside of the tool). While they are performing these tasks, the facilitator could
watch their screen and interact with them. This could be in the lines of how you would Skype.
Category 2: Tool provides users or you can pick your own users. You can submit your
page/design and the tasks to be performed. The tool in turn will provide you the videos of the
user interaction plus the users comments. You can make your own analysis.
Category 3: Tools that use eye tracking and heat map methods to determine which part of the
page the user has spent most time on. Some of the tools in this category also record the users
clicks, scrolls, mouse moves etc.
Category 4: Tools that provide you with a feedback based on the website, page or wireframe
that you submit as input. Some tools of this type also provide surveys that help in giving
conclusive evidence regarding usability issues.
Category 5: Tools that recruit users for your usability test.
The above is a very broad classification. There are many other tools. And also, the division into a
certain category is not always so clean. Sometimes the tools employ multiple methods at the
same time.
Here is a list of tools category wise and the link to find more info about them. (I have not
listed the features of each tool because all of them in a certain category have similar features and
it would be redundant to write each one of it. The pricing information is also not included
because the latest info can only be obtained from the tools home site, hence the link.)

Well, there you have it -the most basic information about usability testing. This is like trying to
capture an ocean into a jar.
From what we have discussed so far, these are my impressions:
#1. Usability testing is not an out and out QA task. A role that traditional QA teams could play in
this context is that of a facilitator who would create tasks, conduct the test and interpret the
result. The tester in this case is actually the user.
#2. The end results or outcome of a usability testing is not defects. It is simple information on
how the user felt, what they liked, what they did not basically raw data. Usability testers job
does not end with reporting the results (in case of traditional QA jobs, we report bugs and do not
get involved in fixing them), it includes providing suggestions on how to make the software
more conducive for a user interaction.
#3. By understanding these concepts, we can actually make a difference as functional testers. To
add more value to our role as QAs we can apply these usability concepts and provide insightful
suggestions on how to improve the usability of an application.
100+ Ready-to-Execute Test Cases
(Checklists) You Can Use to Test the Most
Common Components of AUT


How to test the most common components of your AUT effectively, every single time
This article is a list of common validations on most widely found elements of AUT that is put
together for the convenience of testers (especially in agile environment where frequent short
term releases happen).
Every AUT (Application Under Test) is unique and has a very specific business purpose. The
individual aspects (modules) of the AUT cater to different operations/actions that are crucial for
the success of the business that the AUT supports. Though each AUT is designed differently,
individual components/fields that we encounter on most pages/screens/applications are same
with more or less similar behavior.
Some Common Components of AUT:
Save, Update, Delete, Reset, Cancel, OK links/buttons- whose functionality is as the
label of the object indicates.
Text box, drop downs, checkboxes, radio buttons, date control fields that work the same
way every time.
Data grids, impacted areas, etc. to facilitate reports.
The way these individual elements contribute to the overall functionality of the application might
be different but the steps to validate them are always the same.
Lets continue with the list of most common validations for web or desktop application
pages/forms.
Note: The actual result, expected result, test data and other parameters that are typically a part of
a test case are omitted for the sake of simplicity A general checklist approach is employed.
Purpose of this comprehensive checklist:
The primary purpose of these checklists (or test cases) is to ensure maximum test coverage on
field level validations without spending too much time, at the same time not compromise the
quality of testing them.
After all, confidence in a product can only be attained by testing every single element to the best
extent possible.
The Complete Checklist (Test Cases) for Most Common Components of AUT
Note: You can use these checklists as it is in Microsoft Excel format (download provided at the
end of the article). You can even track the test execution in same file with pass/fail result and
status.
This could be an all-in-one resource for QA teams to test and track the most common
components of AUT. You can add or update test cases specific to your application and make it
even more comprehensive list.
Checklist #1: For a module, we have to check the below points:
Module Name:
Module Functionality:
Module Impact over the application:
Module Flow:
Menu & Submenu:
Spellings and Order & Suitability:
Control for each sub menu:
Checklist #2: For each screen, we have to verify the below points
Form Functionality:
Form Impact over the application:
Form Flow:
Designing:
Alignments:
Title:
Field Names:
Spellings:
Mandatory Marks:
Alerts of Mandatory fields:
Buttons:
Default Cursor Position:
Tab Sequence:
Page before entering any data:
Page after entering data:
Checklist #3: For each text box in the screen we have to verify the below points
Text Box:
ADD(In add screen) EDIT (in Edit screen)
Characters
Special Characters
Numbers
Limit
Alert
Spelling & Grammar in Alert
message:

BVA (Size) for Text Box:
Min >> Pass
Min-1 > > Fail
Min+1 > > Pass
Max-1 > > Pass
Max+1 > > Fail
Max > > Pass
ECP for Text Box:
Valid In Valid
- -
- -
Checklist #4: For each list box/drop down in the screen we have to verify the
below points
List Box/Dropdown:
ADD(In add screen) EDIT (in Edit screen)
Header
Correctness of Existed
Data

Order of Data
Selection and Deselect ion
Alert:
Spelling and Grammar of
Alert message

Cursor after alert
Reflection of Selection
and De selection in
remaining fields

Checklist #5: For each Check box in the screen we have to verify the below
points
Check Box:
ADD(In add screen) EDIT (in Edit screen)
Default Selection
Action after selection
Action after de-selection
Selection and Deselect ion
Alert:
Spelling and Grammar of
Alert message

Cursor after alert
Reflection of Selection and
De selection in remaining
fields

Checklist #6: For each Radio button in the screen we have to verify the below
points
Radio button:
ADD(In add screen) EDIT (in Edit screen)
Default Selection
Action after selection
Action after de-selection
Selection and Deselect ion
Alert:
Spelling and Grammar of
Alert message

Cursor after alert
Reflection of Selection
and De selection in
remaining fields


Checklist #7: For each date field in the screen we have to verify the below points
Date field:
Practical Software Testing New FREE eBook [Download]
How to Improve Your Testing Skills and Beat the Competition!
100+ Ready-to-Execute Test Cases
(Checklists) You Can Use to Test the Most
Common Components of AUT
How to test the most common components of your AUT effectively, every single time
This article is a list of common validations on most widely found elements of AUT that is put
together for the convenience of testers (especially in agile environment where frequent short
term releases happen).
Every AUT (Application Under Test) is unique and has a very specific business purpose. The
individual aspects (modules) of the AUT cater to different operations/actions that are crucial for
the success of the business that the AUT supports. Though each AUT is designed differently,
individual components/fields that we encounter on most pages/screens/applications are same
with more or less similar behavior.

Some Common Components of AUT:
Save, Update, Delete, Reset, Cancel, OK links/buttons- whose functionality is as the
label of the object indicates.
Text box, drop downs, checkboxes, radio buttons, date control fields that work the same
way every time.
Data grids, impacted areas, etc. to facilitate reports.
The way these individual elements contribute to the overall functionality of the application might
be different but the steps to validate them are always the same.
Lets continue with the list of most common validations for web or desktop application
pages/forms.
Note: The actual result, expected result, test data and other parameters that are typically a part of
a test case are omitted for the sake of simplicity A general checklist approach is employed.
Purpose of this comprehensive checklist:
The primary purpose of these checklists (or test cases) is to ensure maximum test coverage on
field level validations without spending too much time, at the same time not compromise the
quality of testing them.
After all, confidence in a product can only be attained by testing every single element to the best
extent possible.
The Complete Checklist (Test Cases) for Most Common Components of AUT
Note: You can use these checklists as it is in Microsoft Excel format (download provided at the
end of the article). You can even track the test execution in same file with pass/fail result and
status.
This could be an all-in-one resource for QA teams to test and track the most common
components of AUT. You can add or update test cases specific to your application and make it
even more comprehensive list.
Checklist #1: For a module, we have to check the below points:
Module Name:
Module Functionality:
Module Impact over the application:
Module Flow:
Menu & Submenu:
Spellings and Order & Suitability:
Control for each sub menu:
Checklist #2: For each screen, we have to verify the below points
Form Functionality:
Form Impact over the application:
Form Flow:
Designing:
Alignments:
Title:
Field Names:
Spellings:
Mandatory Marks:
Alerts of Mandatory fields:
Buttons:
Default Cursor Position:
Tab Sequence:
Page before entering any data:
Page after entering data:
Checklist #3: For each text box in the screen we have to verify the below points
Text Box:
ADD(In add screen) EDIT (in Edit screen)
Characters
Special Characters
Numbers
Limit
Alert
Spelling & Grammar in Alert
message:

BVA (Size) for Text Box:
Min >> Pass
Min-1 > > Fail
Min+1 > > Pass
Max-1 > > Pass
Max+1 > > Fail
Max > > Pass
ECP for Text Box:
Valid In Valid
- -
- -
Checklist #4: For each list box/drop down in the screen we have to verify the
below points
List Box/Dropdown:
ADD(In add screen) EDIT (in Edit screen)
Header
Correctness of Existed
Data

Order of Data
Selection and Deselect ion
Alert:
Spelling and Grammar of
Alert message

Cursor after alert
Reflection of Selection
and De selection in
remaining fields

Checklist #5: For each Check box in the screen we have to verify the below
points
Check Box:
ADD(In add screen) EDIT (in Edit screen)
Default Selection
Action after selection
Action after de-selection
Selection and Deselect ion
Alert:
Spelling and Grammar of
Alert message

Cursor after alert
Reflection of Selection and
De selection in remaining
fields

Checklist #6: For each Radio button in the screen we have to verify the below
points
Radio button:
ADD(In add screen) EDIT (in Edit screen)
Default Selection
Action after selection
Action after de-selection
Selection and Deselect ion
Alert:
Spelling and Grammar of
Alert message

Cursor after alert
Reflection of Selection
and De selection in
remaining fields


------------

Checklist #7: For each date field in the screen we have to verify the below points
Date field:
ADD(In add screen) EDIT (in Edit screen)
Default date display
Design of calendar
Navigation for different
months and years in date
control

Manual Entry in date text
box

Date format and
uniformity with overall
application

Alert:
Spelling and Grammar of
Alert message

Cursor after alert
Reflection of Selection
and De selection in
remaining fields


Checklist #8: For each save button in the screen we have to verify the below
points
Save/update:
ADD(In add screen) EDIT (in Edit screen)
Without giving any data:
With only mandatory fields:
With All fields:
With Max limit:
With min limit
Spelling & Grammar in
Confirmation Alert message:

Cursor
Duplication of Unique fields:
Spelling & Grammar in
duplication Alert message:

Cursor
Checklist #9: For each Cancel button in the screen we have to verify the below
points
Cancel:
With data in all fields
With only mandatory fields:
With All fields:
Checklist #10: For each Delete button in the screen we have to verify the below
points
Delete:
EDIT (in Edit screen)
Delete the record which is not
used anywhere in the application

Delete the record which has
dependency

Add the new record with same
deleted details again

Checklist #11: To verify impacted areas after saving/updating
After Saving/updating:
Display in View
Reflection in impacted forms in
the application

Checklist #12: For each data grid in the screen we have to verify the below points
Data Grid:
Grid Title and spelling
Form Before giving any data
Message Before giving any data
Spellings
Alignments
S No
Field Names & Order
Correctness of Existed data
Order of Existed data
Alignment of Existed data
Page navigators
Data when navigating with
different pages

Edit Link Functionality
Page after Edit:
Title and spellings
Existed data of Selected record
in each field

Buttons
Points to note:
1. Depending on your need, additional tests under each category/for each field can be added
or existing fields can be removed. In other words, these lists are completely customizable.
2. When in need to include field level validations to your test suites, all you have to do is
pick up the respective list and use it for the screen/page that you would like to test.
3. Maintain the checklist by updating the pass/fail status to make this a one-stop-shop for
listing features, validating them and recording the test results.









GUI Testing on Smart Devices Testing
Guidelines

As First impression is the last, so GUI (Graphical User Interface) does matter and creates a lot of
difference. Importance of decent and attractive GUI can be felt more significantly in smart devices
environment where screen size is much small.
GUI testing can be toughest part especially while testing on smart device. You should pay
full attention to the GUI while testing on smart devices and surely it is an important task that
deserves significant time and resource allocation.
Practical Tips for Testing GUI on Smart Devices:
For me, while testing GUI, all the controls are accused. I raise questions why they are there on
the screen and I try to answer these questions. I argue in opposition and favor of the controls
one by one and I do all this without discussing with someone else. It is the time when Im
wearing multiple hats, Controls are accused and Im the Prosecutor , Im the Defense Lawyer
and Im the Judge and during all this process a control must have valid and solid reasons in its
favor to be there on screen and consume space. I suggest you to try it and it will help you to
decide which controls to display on the screen.
There also come the situations where you are given an already built GUI to test. In such
situations also think about the missing controls, the controls that will add value to the screen
and compare their importance with the current ones. If you think you need to make a change go
ahead.
Once you have decided which controls will be shown on the screen, think thoroughly about size,
style and location of the controls on the screen and more important how user will interact with
them?
3 important factors to be considered while testing GUI on Smart Devices:

Size:
There are too many variations in screen sizes and available resolutions. In smart devices
especially, controls sizes are not static, they have relation to the available screen size.
While testing, make sure that controls size looks esthetically good and control is completely
visible on the screen without any scrolling. Test the GUI on different devices with different
screen sizes and resolutions.
Emulators are good for this purpose but nothing matches the real device. So make sure that you
test on at least two or three real devices. Also dont forget to test on landscape and portrait
orientations if the device supports it.
Style:
Definitely your application has a specific design. And style of the controls should match with
that design. You might have seen many applications where some controls e.g. panels have round
edges and text boxes in them have sharp edges. Although this type of issues dont affect the
usability or functionality but still a consistent look of the application helps to build a friendly
relation between the application and the user.
Relatively more important thing in style is font on the different pages. Most of the times, we
focus the text that is visible in normal situations and ignore the text that appears in specific
situations. Success and Failure messages are an example of such type of text
Another factor, important in style is relation between the font color and the situation in which
text is displayed. For example Red color is used for Error messages, Green for success, Yellow
for warnings and Blue (now a day occasionally) for hyperlinks.
Location:
Location and position are the two words that are used alternatively and it is interesting that they
are further used to convey two different concepts that are explained below.
1. Sometimes it is the area on the screen where a control appears. For example Header is located
on Top of the page, Labels are Left Aligned, and Text boxes are Right Aligned etc. Here text in
bold are relative positions of the controls
2. Sometimes it is the order of a control among the other controls. For example while getting
personal info, First Name is followed by the last name or format of controls to ask for a US
address should be in order ZIP, City, State.
For both these situations, make sure that everything is logical and shows a good aesthetic sense.
Forgot something even more important. There are situations where one or more controls appear
on more than one screen, in this situation make sure that they appear on same location and in the
same order on all the pages.

12 Best Cross Browser Testing Tools to Ease
Your Browser Compatibility Testing Efforts
Cross Browser Testing can be the biggest pain for Software testers. But thanks to all cross
browser testing tools available online which help to minimize testing efforts.
Ive written this post mainly for software testers but designers can also refer crossbrowser testing
methods and tools mentioned in this post.
Heres a handy cross browser testing checklist you can refer while testing your web project
on different browsers and operating systems:
1) CSS validation
2) HTML or XHTML validation
3) Page validations with and without JavaScript enabled
4) Ajax and JQeury functionality
5) Font size validation
6) Page layout in different resolutions
7) All images and alignment
8 ) Header and footer sections
9) Page content alignment to center, LHS or RHS
10) Page styles
11) Date formats
12) Special characters with HTML character encoding
13) Page zoom-in and zoom-out functionality
And obviously you will have to repeat these tests on:
14) Different Operating Systems like Windows, Linux and Mac
15) Different browsers (with different versions) like Internet explorer, Firefox, Google Chrome,
Safari and Opera.
There are many free and paid cross browser testing tools available in the market. You need to
select the browser compatibility tool depending on your needs. If cross browser testing is critical
part of your web project then you must allocate considerable time, resources and budget testing
your website on different web browsers. Paid cross browser testing tools can be also a good
option for projects having browser dependent functionality. But for most of the projects, free
cross browser testing tools are sufficient to verify cross browser functionality
Check out below list of all cross browser testing tools available online for testing
website in multiple browsers:
Free Cross Browser Testing Tools:


1) Spoon Browser Sandbox:



The Spoon Browser Sandbox allows you to use almost all web browsers without installing on
your machine. You can run all popular browsers including Internet Explorer, Firefox, Chrome,
and Opera on your machine directly from the web. (Note: Currently Internet Explorer is removed
temporary from the list of this sandbox)
Spoon Browser Sandbox is a free service currently supporting following browsers:
Mozilla Firefox versions:
Firefox 2, Firefox 3, Firefox 3.5, Firefox 3.6, Firefox 4 beta
Internet Explorer versions:
IE6, IE7, IE8
Google Chrome versions:
Chrome, Chrome 5 and Chrome 6 beta
Opera versions:
Opera 9 and Opera 10


2) Browsershots



Browsershots allow you to test website in any browser and operating system. This is widely
used cross browser testing tool because of its features and available customizations.
You can run cross browser compatibility tests with great customization options like browser
type, operating system, screen size, color depth, JavaScript status and Flash enable/disable
settings. Just put your website url, select compatibility test parameters and submit the test
request.
You need to repeat the steps for every test. This free browser compatibility test service can be
used for taking website screen-shots almost in 61 browsers and various operating systems.
Main drawback of this service is the time taken to display the result when you select many
browsers and many times it shows timeout error.
Supported browsers:
IE, Firefox, Google Chrome, Opera, Safari, Minefield, Netscape and many more browsers with
all versions.


3) IE NetRenderer



This is a free online browser compatibility check tool to test website on almost all versions of
Microsoft Internet Explorer. Just select the Internet Explorer version from drop down list and put
your url to start rendering website. You can instantly verify the screen-shot of the page under
test.
There is also a IE NetRenderer Firefox add-on available that allows you to render the web
page that you are currently reading.


4) IE Tab



A Firefox and Chrome add on to simulate IE browse with a single click of a button. This is a best
tool for software testers and developers, since you can easily view how your web page displayed
in Internet Explorer with just one click using Firefox or Chrome browsers. Unfortunately this
add-on is not available for Firefox 6.0 and above versions. But again a good tool to quickly start
your testing on Internet explorer when you have either Firefox or Google Chrome browsers.


5) IE Tester



There are many options available online if you want to check browser compatibility on Internet
Explorer versions. IE tester is one of those options that allows you to test your website on
multiple Internet Explorer versions at the same time using one application.
IETester, a free cross browser testing tool can be used to test website on IE 5.5, IE6, IE7, IE8
and IE9 preview browsers on Windows 7, Vista and XP operating systems.
6) Microsoft SuperPreview
How to Write a Killer Software Testing QA Resume That Will Turn Into an Interview Call
18 Tips to Handle Any Job Interview Successfully
12 Best Cross Browser Testing Tools to Ease
Your Browser Compatibility Testing Efforts
Posted In | GUI Testing, Software Testing Tools, Web Testing
Cross Browser Testing can be the biggest pain for Software testers. But thanks to all cross
browser testing tools available online which help to minimize testing efforts.
Ive written this post mainly for software testers but designers can also refer crossbrowser testing
methods and tools mentioned in this post.
Heres a handy cross browser testing checklist you can refer while testing your web project
on different browsers and operating systems:
1) CSS validation
2) HTML or XHTML validation
3) Page validations with and without JavaScript enabled
4) Ajax and JQeury functionality
5) Font size validation
6) Page layout in different resolutions
7) All images and alignment
8 ) Header and footer sections
9) Page content alignment to center, LHS or RHS
10) Page styles
11) Date formats
12) Special characters with HTML character encoding
13) Page zoom-in and zoom-out functionality
And obviously you will have to repeat these tests on:
14) Different Operating Systems like Windows, Linux and Mac
15) Different browsers (with different versions) like Internet explorer, Firefox, Google Chrome,
Safari and Opera.
There are many free and paid cross browser testing tools available in the market. You need to
select the browser compatibility tool depending on your needs. If cross browser testing is critical
part of your web project then you must allocate considerable time, resources and budget testing
your website on different web browsers. Paid cross browser testing tools can be also a good
option for projects having browser dependent functionality. But for most of the projects, free
cross browser testing tools are sufficient to verify cross browser functionality
Check out below list of all cross browser testing tools available online for testing
website in multiple browsers:
Free Cross Browser Testing Tools:


1) Spoon Browser Sandbox:



The Spoon Browser Sandbox allows you to use almost all web browsers without installing on
your machine. You can run all popular browsers including Internet Explorer, Firefox, Chrome,
and Opera on your machine directly from the web. (Note: Currently Internet Explorer is removed
temporary from the list of this sandbox)
Spoon Browser Sandbox is a free service currently supporting following browsers:
Mozilla Firefox versions:
Firefox 2, Firefox 3, Firefox 3.5, Firefox 3.6, Firefox 4 beta
Internet Explorer versions:
IE6, IE7, IE8
Google Chrome versions:
Chrome, Chrome 5 and Chrome 6 beta
Opera versions:
Opera 9 and Opera 10










2) Browsershots



Browsershots allow you to test website in any browser and operating system. This is widely
used cross browser testing tool because of its features and available customizations.
You can run cross browser compatibility tests with great customization options like browser
type, operating system, screen size, color depth, JavaScript status and Flash enable/disable
settings. Just put your website url, select compatibility test parameters and submit the test
request.
You need to repeat the steps for every test. This free browser compatibility test service can be
used for taking website screen-shots almost in 61 browsers and various operating systems.
Main drawback of this service is the time taken to display the result when you select many
browsers and many times it shows timeout error.
Supported browsers:
IE, Firefox, Google Chrome, Opera, Safari, Minefield, Netscape and many more browsers with
all versions.







3) IE NetRenderer



This is a free online browser compatibility check tool to test website on almost all versions of
Microsoft Internet Explorer. Just select the Internet Explorer version from drop down list and put
your url to start rendering website. You can instantly verify the screen-shot of the page under
test.
There is also a IE NetRenderer Firefox add-on available that allows you to render the web
page that you are currently reading.
4) IE Tab


A Firefox and Chrome add on to simulate IE browse with a single click of a button. This is a best
tool for software testers and developers, since you can easily view how your web page displayed
in Internet Explorer with just one click using Firefox or Chrome browsers. Unfortunately this
add-on is not available for Firefox 6.0 and above versions. But again a good tool to quickly start
your testing on Internet explorer when you have either Firefox or Google Chrome browsers.


5) IE Tester



There are many options available online if you want to check browser compatibility on Internet
Explorer versions. IE tester is one of those options that allows you to test your website on
multiple Internet Explorer versions at the same time using one application.
IETester, a free cross browser testing tool can be used to test website on IE 5.5, IE6, IE7, IE8
and IE9 preview browsers on Windows 7, Vista and XP operating systems.

6) Microsoft SuperPreview



Microsoft Expression Web SuperPreview free cross browser testing software allows you to test
and debug layout issues across different IE browsers and platforms. You can check websites in
different browsers simultaneously. Also check how a page renders in a browser and compare it
with other standard screen-shots you have.
Expression Web SuperPreview for Internet Explorer shows your web pages rendered in Internet
Explorer 6 and either Internet Explorer 7 or Internet Explorer 8, depending on which version you
have installed on your machine.
Currently beta version of SuperPreview for Internet Explorer is available for free for download.
If you cant rely on these free online cross browser testing tools then using Virtual Desktop is
the best solution for you. Using Virtual machine you can simulate live environment for multiple
browsers and different operating systems. You can use virtual machine software or can setup a
virtual machine in your office network with different operating system images and browsers
which can be accessed remotely for browser compatibility testing.
Paid Cross Browser Testing Tools:

7) Browsera
This is an automated browser compatibility testing tool used to test website and its elements in
multiple browsers. You can use this service to test website and all web pages for layout and
scripting errors.
8 ) Adobe BrowserLab
You can preview web pages across multiple versions of Internet Explorer (Windows), Firefox
(Windows and Mac OS X), Safari (Mac OS X), and Chrome (Windows). You can quickly view
full screen-shots with multiple view options and customizable test settings. You can also test
web page content by zooming particular sections and comparing those with different browser
screen-shots for alignment and other layout issues.
9) BrowserCam
BrowserCam is a paid online service that allows you to view your web pages across different
platforms and browsers, either by automatically taking the screen-shot or manually navigating
web pages in different browsers. Free trial is available for 200 screen captures in a day.
10) Browserseal
BrowserSeal cross browser testing tool allows you to capture an image of your website under
different browsers with a single click of a mouse. You can navigate images to spot layout and UI
issues. Browserseal tool support almost all major versions of Internet Explorer, Firefox, Google
Chrome, Opera and Safari.
Free Trial version of Browserseal is also available, limited to two browsers (Firefox and Internet
Explorer) and one screen-shot per session.
11) Cross Browser Testing
Test your website live on different operating systems and browsers. You just need to login to
Cross Browser Testing platform, select operating system, browser and start testing your website
for Ajax, JavaScript and flash functionality. You can also check your website design using
automated screen-shot tool to view websites design across every browser. Free trial of this cross
browser testing software is available for one week.
12) Cloud Testing
Cloud Testing tool allows you to check website look and feel and the functionality on Internet
Explorer, Firefox, Safari. Opera and Google Chrome browsers on real operating systems in the
cloud.
Over to you!
As of now you should have clear idea of many free and paid cross-browser testing tools
available online. Obviously selection of a good cross browser testing tool depends on your
requirements as each browser compatibility checking tool comes with its own advantages and
disadvantages.