Why Bother to Unit Test?

Why Bother to Unit Test?

Executive Summary

This document addresses a question often posed by developers who are new to the concept of thorough testing: Why bother to unit test? The question is answered by adopting the position of devil’s advocate, presenting some of the common arguments made against unit testing, then proceeding to show how these arguments are worthless.

1. Introduction

The quality and reliability of software is often seen as the weak link in industry’s attempts to develop new products and services. The last decade has seen the issue of software quality and reliability addressed through a growing adoption of design methodologies and supporting CASE tools, to the extent that most software designers have had some training and experience in the use of formalized software design methods. Unfortunately, the same cannot be said of software testing. Many developments applying such design methodologies are still failing to bring the quality and reliability of software under control. It is not unusual for 50% of software maintenance costs to be attributed to fixing bugs left by the initial software development; bugs which should

have been eliminated by thorough and effective software testing. This paper addresses a question often posed by developers who are new to the concept of thorough testing: Why bother to unit test? The question is answered by adopting the position of devil’s advocate, presenting some of the common arguments made against unit testing, then proceeding to show how these arguments are worthless. The case for unit testing is supported by published data.

2. What is Unit Testing?

The unit test is the lowest level of testing performed during software development, where individual units of software are tested in isolation from other parts of a program. In a conventional structured Programming language, such as C, the unit to be tested is traditionally the function or sub-routine. In object oriented languages such as C++, the basic unit to be tested is the class. The principle of unit testing also extends to 4GL development, where the basic unit would typically be a menu or display. Unit level testing is not just intended for one-off development use, to aid bug free coding. Unit tests have to be repeated whenever software is modified or used in a new environment. Consequently, all tests have to be maintained throughout the life of a software system. Other activities which are often associated with unit testing are code reviews, static analysis and dynamic analysis. Static analysis investigates the textual source of software, looking for problems and gathering metrics without actually compiling or executing it. Dynamic analysis looks at the behavior of software while it is executing, to provide information such as execution traces, timing profiles, and test coverage information.

3. Some Popular Misconceptions

Having established what unit testing is, we can now proceed to play the devil’s advocate. In the following subsections, some of the common arguments made against unit testing are presented, together with reasoned cases showing how these arguments are worthless.

3.1. It Consumes Too Much Time

Once code has been written, developers are often keen to get on with integrating the software, so that they can see the actual system starting to work. Activities such as unit testing may be seen to get in the way of this apparent progress, delaying the time when the real fun of debugging the overall system can start. What really happens with this approach to development is that real progress is traded for apparent progress. There is little point in having a system which “sort of” works, but happens to be full of bugs. In practice, such an approach to development will often result in software which will not even run. The net result is that a lot of time will be spent tracking down relatively simple bugs which are wholly contained within particular units. Individually, such bugs may be trivial, but collectively they result in an excessive period of time integrating the software to produce a system which is unlikely to be reliable when it enters use. In practice, properly planned unit tests consume approximately as much effort as writing the actual code. Once completed, many bugs will have been corrected and developers can proceed to a much more efficient integration, knowing that they have reliable components to begin with. Real progress has been made, so properly planned unit testing is a much more efficient use of time. Uncontrolled rambling with a debugger consumes a lot more time for less benefit.

3.2. It Only Proves That the Code Does What the Code Does

This is a common complaint of developers who jump straight into writing code, without first writing a specification for the unit. Having written the code and confronted with the task of testing it, they read the code to find out what it actually does and base their tests upon the code they have written. Of course they will prove nothing. All that such a test will show is that the compiler works. Yes, they will catch the (hopefully) rare compiler bug; but they could be achieving so much more. If they had first written a specification, then tests could be based upon the specification. The code could then be tested against its specification, not against itself. Such a test will continue to catch compiler bugs. It will also find a lot more coding errors and even some

errors in the specification. Better specifications enable better testing, and the corollary is that better testing requires better specifications. In practice, there will be situations where a developer is faced with the thankless task of testing a unit given only the code for the unit and no specification. How can you do more than just find compiler bugs? The first step is to understand what the unit is supposed to do – not what it actually does. In effect, reverse engineer an outline specification. The main input to this process is to read the code and the comments, for the unit, and the units which call it or it calls. This can be supported by drawing flowgraphs, either by hand or using a tool. The outline specification can then be reviewed, to make sure that there are no fundamental flaws in the unit, and then used to design unit tests, with minimal further reference to the code.

3.3. “I’m too Good a Programmer to Need Unit Tests”

There is at least one developer in every organisation who is so good at programming that their software always works first time and consequently does not need to be tested. How often have you heard this excuse?

In the real world, everyone makes mistakes. Even if a developer can muddle through with this attitude for a few simple programs, real software systems are much more complex. Real software systems do not have a hope of working without extensive testing and consequent bug fixing. Coding is not a one pass process. In the real world software has to be maintained to reflect changes in operational requirements and fix bugs left by the original development. Do you want to be dependent upon the original author to make these changes? The chances are that the “expert” programmer who hacked out the original

code without testing it will have moved on to hacking out code elsewhere. With a repeatable unit test the developer making changes will be able to check that there are no undesirable side effects.

3.4. Integration Tests will Catch all the Bugs Anyway

We have already addressed this argument in part as a side issue from some of the preceding discussion. The reason why this will not work is that larger integrations of code are more complex. If units have not been tested first, a developer could easily spend a lot of time just getting the software to run, without actually executing any test cases. Once the software is running, the developer is then faced with the problem of thoroughly testing each unit within the overall complexity of the software. It can be quite difficult to even create a situation where a unit is called, let alone thoroughly exercised once it is called. Thorough testing of unit level functionality during integration is much more complex than testing units in isolation. The consequence is that testing will not be as thorough as it should be. Gaps will be left and bugs will slip through. To create an analogy, try cleaning a fully assembled food processor! No matter how much water and detergent is sprayed around, little scraps of food will remain stuck in awkward corners, only to go rotten and surface in a later recipe. On the other hand, if it is disassembled, the awkward corners either disappear or become much more accessible, and each part can be cleaned without too much trouble.

3.5. It is not Cost Effective

The level of testing appropriate to a particular organisation and software application depends on the potential consequences of undetected bugs. Such consequences can range from a minor inconvenience of having to find a work-round for a bug to multiple deaths. Often overlooked by software developers (but not by customers), is the long term damage to the credibility of an organisation which delivers software to users with bugs in it, and the resulting negative impact on future business. Conversely, a reputation for reliable software will help an organisation to obtain future business. Many studies have shown that efficiency and quality are best served by testing software as early in the life cycle as practical, with full regression testing whenever changes are made. The later a bug is found, the higher the cost of fixing it, so it is sound economics to identify and fix bugs as early as possible. Unit testing is an opportunity to catch bugs early, before the cost of correction escalates too far. Unit tests are simpler to create, easier to maintain and more convenient to repeat than later stages of testing. When all costs are considered, unit tests are cheap compared to the alternative of complex and drawn out integration testing, or unreliable software.

4. Some Figures

Figures from “Applied Software Measurement”, (Capers Jones, McGraw-Hill 1991), for the time taken to prepare tests, execute tests, and fix defects (normalized to one function point), show that unit testing is about twice as cost effective as integration testing and more than three times as cost effective as system testing (see bar chart).

Unit Test 3.25 hours

Integration Test 6.25 hours

System Test 11.5 hours

Field Test 11 hours

(The term “field test” refers to any tests made in the field, once the software has entered


This does not mean that developers should not perform the latter stages of testing, they are still necessary. What it does mean is that the expense of later stages of testing can be reduced by eliminating as many bugs as possible as early as possible. Other figures show that up to 50% of maintenance effort is spent fixing bugs which have always been there. This effort could be saved if the bugs were eliminated during development. When it is considered that software maintenance costs can be many times the initial development cost, a potential saving of 50% on software maintenance can make a sizeable impact on overall lifecycle costs.

5. Conclusion

Experience has shown that a conscientious approach to unit testing will detect many bugs at a stage of the software development where they can be corrected economically. In later stages of software development, detection and correction of bugs is much more difficult, time consuming and costly. Efficiency and quality are best served by testing software as early in the lifecycle as practical, with full regression testing whenever changes are made. Given units which have been tested, the integration process is greatly simplified. Developers will be able to concentrate upon the interactions between units and the overall functionality without being swamped by lots of little bugs within the units. The effectiveness of testing effort can be maximised by selection of a testing strategy which includes thorough unit testing and good management of the testing process to support the testing process. The result will be more reliable software at a lower development cost, and there will be further benefits in simplified maintenance and reduced lifecycle costs. Effective unit testing is all part of developing an overall “quality” culture, which can only be beneficial to a software developers business.

Posted in Uncategorized | Leave a comment

Testing Ajax Application using QTP

Testing Ajax Application using QTP

What is Ajax?

Ajax, short for Asynchronous JavaScript and XML, is a web development technique for creating interactive web applications. The intent is to make web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not have to be reloaded each time the user makes a change. This is meant to increase the web page’s interactivity, speed, and usability.

Testing Ajax is different and difficult

In traditional web applications, the HTML elements are already loaded in the web pages which have been fairly easy to test in an automated fashion. Unfortunately, AJAX-based web applications are not as easy or consistent to test as the traditional web applications. The problem with AJAX testing is that the web page under test will be modified asynchronously such as an element will be dynamically added based on a check box click or an element will be removed based on a list element selection, etc.

Synchronization issues are also there. Clicking a link will not cause a page reload; instead the browser will converse with the server and refresh just a part of current page. The time delay between clicking a link and seeing the results is what makes things tricky.

Due to the asynchronous nature of the Ajax the result doesn’t come back from the server immediately. The result from server takes time but the automation tools would check the results immediately. In case of Ajax .sync and WaitProperty also doesn’t provide correct results.

Testing Ajax technology using QTP

QTP 9.5 provides the facility of testing Ajax objects. For testing Ajax objects using QTP 9.5 Web Extensibility toolkit should be installed. This will cause a mini Ajax add-in to show up besides the web add-in in the Add-in manager dialog. After installing WEB Add-in Extensibility kit, check both web and Ajax addins in addin manager and then try recording the scripts.

Still using QTP 9.2 and earlier versions?

QTP 9.2 and previous version doesn’t support Ajax technology. But one can use DOM approach to handle Ajax applications. DOM seems to be the best option available.

Let’s study one example:

There are some text fields on a page, having auto complete feature i.e. as we key-in the characters in the text-box, the application fetches the matching results and displays them in the pop-up area below the field. The required record from the results shown in the pop-up is then selected.

Now at the time of recording these actions, QTP records the step of entering the characters in the field. However it doesn’t record the step of mouse click over a record in the pop-up results or maybe record it as webelement.


Generally such pop-up results are created on the fly as characters are typed in the text-field, using Ajax technique. The best thing that works for such scenarios is DOM. Usually such results are created dynamically within <SPAN>, <DIV> or <TD> elements.

These objects can be identified by an automation script using following four parameters:

1. Name of the page on which the object exists

2. HTML tag of the object e.g. INPUT, TD, DIV, SPAN

3. Name of a property of the object that can be used to identify the object uniquely from among the other objects of same type on the page.

(For hyperlink type of object it can be the “innertext” or “href” property, for table cell, it can innertext, for list-box it can be Id, name or innertext. Some objects can be identified uniquely by their innerHTML, or outerHTML. )

4. Value of the above property i.e. “txt_FirstName” (if Name property is used) or “txt_FirstNameId” (if ID property is used)

The idea is to identify the element TAG in which selected item from the  popup is stored is and displayed, whether it is in DIV tag, SPAN tag TD tag, Font tag etc and check the outerHTML of the element and see if there is any onmouseover/onclick/onchange event declared for the object. Then trigger the OnMouseover event for the result item to be selected, Bring mouse over the result item to be selected and then trigger the onclick event for the result item to be selected.

This approach uses the Document Object Model (DOM) of web-page to recognize objects on the page, access their properties to perform any action/operation on the web-objects. This approach is useful for automation of web-based apps and requires a good understanding of HTML, DOM and VBscript.

The object which can’t be accessed using DOM, for recognizing them use of Descriptive Programming feature of QTP is recommended.

Posted in Uncategorized | Leave a comment



Edit / Question Example
Maximum Value & Minimum Value
  • Edit Picture (z, 9, #, etc.)
  • Field Width
  • Boundaries (Upper Limit, Lower Limit)
  • Positive and Negative Numbers
  • Precision (Whole Numbers and Decimal Places)
  • Signed or Unsigned
Delta – Smallest increment used by system
  • Whole Numbers
  • Fractions
  • Decimal Value
Other Tests
  • Overflow
  • Underflow
  • Rounding
  • Floating Point Errors
  • Currency (Symbol, Separators, Commas & Period)
  • Input
  • Storage
  • Output
  • Display
  • Print
  • Integer (16, 32, 64)
  • Floating Point
  • Binary
  • Packed
  • Hex, Octal, Scientific Notation
  • Placement of Negative Indicator
  • -, CB, ( ) Leading or Trailing
  • Word Boundaries
  • Position (Display or Print)
  • Color (Red for Negative)
  • Intensity
  • Blinking
  • Font Size
  • Italics
  • Leading 0123
  • Trailing 123.0
  • Absent 123.
Spaces Before or After Entry
  • Permitted?
  • Self Correcting?
Alternative Formats
  • Display values in thousands or millions
  • Display as words “One Thousand”
  • Roman numerals
Error Message
  • When displayed
  • Where displayed
  • Should they be acknowledged?
  • Automatic Recovery?
  • Starting Value
  • Null Value
  • Reset Value
Reasonableness Checks .
Entry Format
  • Character
  • Numeric
Match other formats
  • Usage in a calculator
  • Appended to another field
Display Issues
  • Blank on either side of field to prevent touching another field
  • 123 123 vs. 123123
  • Display with leading zero
Will conversion take place? .
Source of Value
  • Will it change?
  • Multiple?
  • Alternative Source
Can value be computed? .
Balancing instructions Audit Issues
Encrypted storage .
Is a check digit required? Check digit computation
  • Table
  • Computation
  • Other report
Does field have other use?
  • SSN, SIN, Employee ID
  • Salary, Speed
  • Date
  • Lookup Key
Naming Conventions
Compiler Requirements

Note the edits that are performed by the programming language, tests that should be handled during unit testing, and checks that should be done via integration or system testing.

Other issues:

  1. Will boundaries and limits change over time?
  2. Are they influenced by something else?
  3. Will field accept operators? +, -, /, *, !, **, ^, %
  4. Will the value change format?
    64 bit to 16 bit
    Character to numeric
    Display to packed
    Display to scientific notation
    Display to words
  5. Will value move across platforms?
  6. Why is the field being treated as numeric?
  7. Will voice recognition be necessary?

Checklist: Additional Testing Concerns

  • * Memory: availability, high, low, virtual, swapping, page size
  • * Resource competition on the system
  • * Processing: batch, on-line, multiple input sources
  • * Conflicts: anti-viral software, automated test tools, TSR’s, security software, IRQs
  • * Backup: disaster recovery, backups, rerun capability
  • * Connectivity: band width, interoperability, modem speed, ISDN lines, distributed applications
  • * Security: passwords, fire walls
  • * CD-Rom access and speed
  • * File conversions
  • * Design of client server architecture
  • * Version Controls
  • * Display issues: graphics, monitor size, graphic cards
  • * Printer: type, speed, color, resolution, paper weight, paper size, envelopes, multiple printers
  • * Platform: mainframe, minicomputer, microcomputer, number of platforms
  • * Multiple operating systems
  • * Transactions: size, quantity, rate
  • * Error processing: message source, location, timing, acknowledgements

The following edits, questions, and checks should be considered for all date fields. Be aware that many programming languages combine date and time into one data type.

Edit / Question Example
Required entry .
Century display 1850, 1999, 2001
Implied century Display last two digits of year (96,02). All dates are assumed to be between 1950 and 2049.
Date display format
  • mm-dd-yy (12/01/96)
  • mm-dd-ccyy (12/01/1996)
  • dd-mm-yy (01/12/96)
  • dd-mm-ccyy (01/12/1996)
  • dd-mmm-yy (01-Jan-96)
  • dd-mmm-ccyy (01-Jan-1996)
  • dd-mm (day and month only)
  • Complete date (December 1, 1996)
  • Date, abbreviated month (Dec 1, 1996)
  • Day included in date (Monday, November 7, 1996)
  • yymmdd (960105)
  • ccyymmdd (20011231)
  • No year, text month and day (May 30th)
  • Financial calculator (12.0196)
  • System format (provided through system)
Date separator
  • Slash (/), dash (-), Period (.), space
  • Enter separator fields
  • Move over separators
  • Automatic skip over separators
Leading zeros in day field 01, 02, 09 (12/05/96 vs 12/5/96)
Leading zeros in month field 01, 02, 09 (05/17/97 vs 5/17/97)
Abbreviate month name Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
Can day numbers exceed actual? May 32, Feb 30 (Accounting systems may use for adjusting transactions.)
Embedded spaces
  • No leading spaces
  • No trailing spaces
  • One space permitted after month and comma
Font attributes
  • Color
  • Italics
  • Bold
  • Size
  • Blink
  • Intensity
Leap year computations Any year number evenly divisible by 4, but not by 100, unless it is also divisible by 400.

  • 1996 leap year
  • 2000 leap year
  • 2004 leap year
  • 2100 not a leap year
Relational edits Compare hire date to birth date.
Use financial calendars
  • 30/360
  • 30 days per month, 360 days per year
  • Actual/360
  • actual days per month, 360 days per year
Entry mechanism
  • Display calendar
  • (+/-) to change day number
  • Function key / PF key
Default date
  • System date
  • Last date entered
  • Other date (order date, closing date, etc.)
Latest / earliest permissible date
  • Actual date
  • Computed date
Authorization / Security required
  • Add
  • Modify
  • Delete
  • View
  • Entry
  • Storage (date, or relative day number)
  • Print
  • Display
Null date
  • 00/00/00 zeros
  • bb/bb/bb spaces
Is the programming responsible for managing dates? .
Are autofill features utilized? .
Will the date field be used again elsewhere? .
Is this a standard date entry routine that is already tested? .
Are there other mechanisms to date stamp fields or records? .
Is the position of the date important?
  • On screen
  • In a report
Are other events triggered by this date? .
Permissible dates
  • Holiday
  • local, regional, national, international
  • Weekend
  • Specific day(s) of week
Is the Julian date required? .
Sorting requirements
  • Normal
  • Relative day number
  • Unusual
  • 9’s compliment, yymmdd, ccyymmdd
Time zone issues .
Is system voice enabled for date entry? .
Is the date encrypted? Encryption technique
Testing Must entry dates correspond to dates in the test bed?
Risk factors What is the risk inherent in not entering the date correctly.
Edit date
  • On entry
  • When screen is complete
  • When record is complete
  • After other event
Are incomplete dates permissible?
  • 12/00/1996
  • 12/??/1996
  • 12/01/????
  • 12/01/??
  • Acceptable fonts
  • Largest font size that will display properly
  • Default font
Correction Can erroneous dates be automatically corrected?
Error messages
  • Content
  • Placement
  • When displayed
  • Can processing continue with bad date?

Note the edits that are performed by the programming language, tests that should be handled during unit testing, and checks that should be done via integration or system testing.

Other issues:

  • Can invalid dates be passed to this routine? Should they be accepted?
  • Is there a standard date entry routine in the library?
  • Can new date formats be easily added and edited?
  • What is the source of the date: input documents, calendar on the wall, or field on another document?
  • Are there other mechanisms to change dates outside of this program?
  • Is this a date and time field?

Checklist: Developing Windows Application

Modal Windows – Often times modal windows which must be acted upon end up hidden behind standard windows. This gives the user the impression that the system has locked up.

Special Characters – Special characters may not be used on some windows entry screens, there also may be some conflicts with converting data or using data from other systems.

Printer Configuration – Although Windows is designed to handle the printer setup for most applications, there are formatting differences between printers and printer types. LaserJet printers do not behave the same as inkjets, nor do 300, 600, or 1200 DPI laser printers behave the same across platforms.

Date Formats – The varying date formats sometimes cause troubles when they are being displayed in windows entry screens. This situation could occur when programs are designed to handle a YY/MM/DD format and the date format being used is YYYY/MMM/DD.

Screen Savers – Some screen savers such as After Dark are memory or resource ‘hogs’ and have been known to cause troubles when running other applications.

Speed Keys – Verify that there are no conflicting speed keys on the various screens. This is especially important on screens where the buttons change.

Virus Protection Software – Some virus protection software can be configured too strictly. This may cause applications to run slowly or incorrectly.

Disk Compression Tools – Some disk compression software may cause our applications to run slowly or incorrectly.

Multiple Open Windows – How does the system handle having multiple open windows, are there any resource errors.

Test Multiple Environments – Programs need to be tested under multiple configurations. The configurations seem to cause various results.

Test Multiple Operating Systems – Programs running under Win 95, Win NT, and Windows 3.11 do not behave the same in all environments.

Corrupted DLL’s – Corrupted DLL’s will sometime cause applications not to execute or more damaging to run sporadically.

Incorrect DLL Versions – Corrupted DLL’s will sometime cause our applications not to execute or more damaging to run sporadically.

Missing DLL’s – Missing DLL’s will usually cause our applications not to execute.

Standard Program Look & Feel – The basic windows look & feel should be consistent across all windows and the entire application. Windows buttons, windows and controls should follow the same standards for sizes.

Tab Order – When pressing the TAB key to change focus from object to object the procession should be logical.

Completion of Edits – The program should force the completion of edits for any screen before users have a change to exit program.

Saving Screen Sizes – Does the user have an opportunity to save the current screen sizes and position?

Operational Speed – Make sure that the system operates at a functional speed, databases, retrieval, and external references.

Testing Under Loaded Environments – Testing system functions when running various software programs “RESOURCE HOGS” (MS Word, MS Excel, WP, etc.).

Resource Monitors – Resource monitors help track Windows resources which when expended will cause GPF’s.

Video Settings – Programmers tend to program at a 800 x 600 or higher resolution, when you run these programs at a default 640 x 480 it tends to overfill the screen. Make sure the application is designed for the resolution used by customers.

Clicking on Objects Multiple Times – Will you get multiple instances of the same object or window with multiple clicks?

Saving Column Orders – Can the user save the orders of columns of the display windows?

Displaying Messages saying that the system is processing – When doing system processing do we display some information stating what the system is doing?

Clicking on Other Objects While the System is Processing – Is processing interrupted? Do unexpected events occur after processing finishes?

Large Fonts / Small Fonts – When switching between windows font sizes mixed results occur when designing in one mode and executing in another.

Maximizing / Minimizing all windows – Do the actual screen elements resize? Do we use all of the available screen space when the screen is maximized.

Setup Program – Does your setup program function correctly across multiple OS’s. Does the program prompt the user before overwriting existing files.

Consistency in Operation – Consistent behavior of the program in all screens and the overall application.

Multiple Copies of the same Window – Can the program handle multiple copies of the same window? Can all of these windows be edited concurrently?

Confirmation of Deletes – All deletes should require confirmations of the process before execution.

Selecting alternative language options – Will your program handle the use of other languages (FRENCH, SPANISH, ITALIAN, etc.)

Test Type Description Purpose Considerations Variations
Transfer Functions Navigate from each different window to all possible windows Test interrelated processing between windows – All Sequences?

– Important Combinations?

– Negative – No Transfers

Menu Bar-Mouseclick
Buttons – Push
Buttons-Hot Key
Menu Bar – Hot Keys
Menu Bar – Keyboard
Data Conditions for Window Transfer Functions Test transfers with general (record level) data conditions Test data row retrieval and transfer functions using data – Different for list windows

vs. one record display


List window with no data
List window one record in list (row)
List window >1 row –

last row

List window >1 row –

not first or last row

One row display window
Select inquiry entity in list window (not from list)
Verify Window Display Data Verify inquiry data displays Tests stored procedure/

GUI retrieval of data

Lists of Columns
Single Row Display


DropDownListBox –

Selection Retrieval

Specific Data Retrieval Conditions- Max, Null, etc.
Field Edit Formats
Field Level Data Entry Test data entry for a single column Test GUI field edits (PBEdit040’s within Data Windows) Required Field – no data
Maximum Data Length
Valid Value
Invalid Value
Invalid data format
Row Data Maintenance Test data row handling from GUI to database Test stored procedure/GUI add/change/delete functions Note: do an inquiry after update to verify database update New
Change to non-key field
Change to key field

(delete and add)

Application Window Controls Test Buttons, Scroll Bars and other windows types of controls Test GUI processing – Controls which do transfers are under transfer functions

– Retrieve or OK which retrieves need to do inquiry to do data check of retrieval

– Link,Unlink, Change, Delete need to do inquiry to check database updates

– New test will be for data entry in field

Transfer Buttons

OK, Miscellaneous


Database Updates


Data Entry – NEW

Radio Buttons

Scroll Bars (Vertical/Horizontal)
Standard Window Controls/Functions Window Control Menu
Max, Min,
Print Functions

(Print, Printer Setup)

Edit Functions

(Cut, Copy, Paste)

Window Functions

(Previous Window, Close All, Open Window List, Tile, Layer, Cascade)

Application HELP Microhelp
Balloon Notes
Help- Index
Help-Table of Contents
Help-Jump Words
Miscellaneous Application Specific Job Status
Online Report/s
Informational Windows – Content

Windows – Button

Fatal Application Errors

1.1. Application

Start Application by Double Clicking on its ICON. The Loading message should show the application name,
version number, and a bigger pictorial representation of the icon (a ‘splash’ screen).

No Login is necessary

The main window of the application should have the same caption as the caption of the icon in Program Manager.

Closing the application should result in an “Are you Sure” message box

Attempt to start application Twice
This should not be allowed – you should be returned to main Window

Try to start the application twice as it is loading.

On each window, if the application is busy, then the hour glass should be displayed. If there is no hour glass
(e.g. alpha access enquiries) then some enquiry in progress message should be displayed.

All screens should have a Help button, F1 should work doing the same.

1.2. For Each Window in the Application

If Window has a Minimise Button, click it.

Window Should return to an icon on the bottom of the screen
This icon should correspond to the Original Icon under Program Manager.

Double Click the Icon to return the Window to its original size.

The window caption for every application should have the name of the application and the window name –
especially the error messages. These should be checked for spelling, English and clarity , especially on the top
of the screen. Check does the title of the window makes sense.
If the screen has an Control menu, then use all ungreyed options. (see below)

Check all text on window for Spelling/Tense and Grammar

Use TAB to move focus around the Window. Use SHIFT+TAB to move focus backwards.

Tab order should be left to right, and Up to Down within a group box on the screen. All controls
should get focus – indicated by dotted box, or cursor. Tabbing to an entry field with text in it should highlight
the entire text in the field.

The text in the Micro Help line should change – Check for spelling, clarity and non-updateable etc.

If a field is disabled (greyed) then it should not get focus. It should not be possible to select them with either
the mouse or by using TAB. Try this for every greyed control.

Never updateable fields should be displayed with black text on a grey background with a black label.

All text should be left-justified, followed by a colon tight to it.

In a field that may or may not be updateable, the label text and contents changes from black to grey depending
on the current status.

List boxes are always white background with black text whether they are disabled or not. All others are grey.

In general, do not use goto screens, use gosub, i.e. if a button causes another screen to be displayed, the
screen should not hide the first screen, with the exception of tab in 2.0

When returning return to the first screen cleanly i.e. no other screens/applications should appear.

In general, double-clicking is not essential. In general, everything can be done using both the mouse and
the keyboard.

All tab buttons should have a distinct letter.

1.3. Text Boxes

Move the Mouse Cursor over all Enterable Text Boxes. Cursor should change from arrow to Insert Bar.
If it doesn’t then the text in the box should be grey or non-updateable. Refer to previous page.

Enter text into Box

Try to overflow the text by typing to many characters – should be stopped Check the field width with capitals W.

Enter invalid characters – Letters in amount fields, try strange characters like + , – * etc. in All fields.

SHIFT and Arrow should Select Characters. Selection should also be possible with mouse. Double Click should
select all text in box.
1.4. Option (Radio Buttons)

Left and Right arrows should move ‘ON’ Selection. So should Up and Down.. Select with mouse by clicking.
1.5. Check Boxes

Clicking with the mouse on the box, or on the text should SET/UNSET the box. SPACE should do the same.

1.6. Command Buttons

If Command Button leads to another Screen, and if the user can enter or change details on the other screen then
the Text on the button should be followed by three dots.

All Buttons except for OK and Cancel should have a letter Access to them. This is indicated by a letter underlined
in the button text. The button should be activated by pressing ALT+Letter. Make sure there is no duplication.

Click each button once with the mouse – This should activate
Tab to each button – Press SPACE – This should activate
Tab to each button – Press RETURN – This should activate
The above are VERY IMPORTANT, and should be done for EVERY command Button.

Tab to another type of control (not a command button). One button on the screen should be default (indicated by
a thick black border). Pressing Return in ANY no command button control should activate it.

If there is a Cancel Button on the screen , then pressing <Esc> should activate it.

If pressing the Command button results in uncorrectable data e.g. closing an action step, there should be a message
phrased positively with Yes/No answers where Yes results in the completion of the action.
1.7. Drop Down List Boxes

Pressing the Arrow should give list of options. This List may be scrollable. You should not be able to type text
in the box.

Pressing a letter should bring you to the first item in the list with that start with that letter. Pressing ‘Ctrl – F4’
should open/drop down the list box.

Spacing should be compatible with the existing windows spacing (word etc.). Items should be in alphabetical
order with the exception of blank/none which is at the top or the bottom of the list box.

Drop down with the item selected should be display the list with the selected item on the top.

Make sure only one space appears, shouldn’t have a blank line at the bottom.
1.8. Combo Boxes

Should allow text to be entered. Clicking Arrow should allow user to choose from list
1.9. List Boxes

Should allow a single selection to be chosen, by clicking with the mouse, or using the Up and Down Arrow keys.

Pressing a letter should take you to the first item in the list starting with that letter.

If there is a ‘View’ or ‘Open’ button beside the list box then double clicking on a line in the List Box, should act in the same way as selecting and item in the list box, then clicking the command button.

Force the scroll bar to appear, make sure all the data can be seen in the box.

Section 2 – Screen Validation Checklist

2.1. Aesthetic Conditions:

  1. Is the general screen background the correct colour?
  2. Are the field prompts the correct colour?
  3. Are the field backgrounds the correct colour?
  4. In read-only mode, are the field prompts the correct colour?
  5. In read-only mode, are the field backgrounds the correct colour?
  6. Are all the screen prompts specified in the correct screen font?
  7. Is the text in all fields specified in the correct screen font?
  8. Are all the field prompts aligned perfectly on the screen?
  9. Are all the field edit boxes aligned perfectly on the screen?

10.  Are all groupboxes aligned correctly on the screen?

11.  Should the screen be resizable?

12.  Should the screen be minimisable?

13.  Are all the field prompts spelt correctly?

14.  Are all character or alpha-numeric fields left justified? This is the default unless otherwise specified.

15.  Are all numeric fields right justified? This is the default unless otherwise specified.

16.  Is all the microhelp text spelt correctly on this screen?

17.  Is all the error message text spelt correctly on this screen?

18.  Is all user input captured in UPPER case or lower case consistently?

19.  Where the database requires a value (other than null) then this should be defaulted into fields. The
user must either enter an alternative valid value or leave the default value intact.

20.  Assure that all windows have a consistent look and feel.

21.  Assure that all dialog boxes have a consistent look and feel.

2.2. Validation Conditions:

  1. Does a failure of validation on every field cause a sensible user error message?
  2. Is the user required to fix entries which have failed validation tests?
  3. Have any fields got multiple validation rules and if so are all rules being applied?
  4. If the user enters an invalid value and clicks on the OK button (i.e. does not TAB off the field) is the invalid entry identified and highlighted correctly with an error message.?
  5. Is validation consistently applied at screen level unless specifically required at field level?
  6. For all numeric fields check whether negative numbers can and should be able to be entered.
  7. For all numeric fields check the minimum and maximum values and also some mid-range values allowable?
  8. For all character/alphanumeric fields check the field to ensure that there is a character limit specified and that this limit is exactly correct for the specified database size?
  9. Do all mandatory fields require user input?

10.  If any of the database columns don’t allow null values then the corresponding screen fields must be mandatory. (If any field which initially was mandatory has become optional then check whether null values are allowed in this field.)

2.3. Navigation Conditions:

  1. Can the screen be accessed correctly from the menu?
  2. Can the screen be accessed correctly from the toolbar?
  3. Can the screen be accessed correctly by double clicking on a list control on the previous screen?
  4. Can all screens accessible via buttons on this screen be accessed correctly?
  5. Can all screens accessible by double clicking on a list control be accessed correctly?
  6. Is the screen modal. i.e. Is the user prevented from accessing other functions when this screen is active and is this correct?
  7. Can a number of instances of this screen be opened at the same time and is this correct?

2.4. Usability Conditions:

  1. Are all the dropdowns on this screen sorted correctly? Alphabetic sorting is the default unless otherwise specified.
  2. Is all date entry required in the correct format?
  3. Have all pushbuttons on the screen been given appropriate Shortcut keys?
  4. Do the Shortcut keys work correctly?
  5. Have the menu options which apply to your screen got fast keys associated and should they have?
  6. Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.
  7. Are all read-only fields avoided in the TAB sequence?
  8. Are all disabled fields avoided in the TAB sequence?
  9. Can the cursor be placed in the microhelp text box by clicking on the text box with the mouse?

10.  Can the cursor be placed in read-only fields by clicking in the field with the mouse?

11.  Is the cursor positioned in the first input field or control when the screen is opened?

12.  Is there a default button specified on the screen?

13.  Does the default button work correctly?

14.  When an error message occurs does the focus return to the field in error when the user cancels it?

15.  When the user Alt+Tab’s to another application does this have any impact on the screen upon return to The application?

16.  Do all the fields edit boxes indicate the number of characters they will hold by there length? e.g. a 30 character field should be a lot longer

2.5. Data Integrity Conditions:

  1. Is the data saved when the window is closed by double clicking on the close box?
  2. Check the maximum field lengths to ensure that there are no truncated characters?
  3. Where the database requires a value (other than null) then this should be defaulted into fields. The user must either enter an alternative valid value or leave the default value intact.
  4. Check maximum and minimum field values for numeric fields?
  5. If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers?
  6. If a set of radio buttons represent a fixed set of values such as A, B and C then what happens if a blank value is retrieved from the database? (In some situations rows can be created on the database by other functions which are not screen based and thus the required initial values can be incorrect.)
  7. If a particular set of data is saved to the database check that each value gets saved fully to the database. i.e. Beware of truncation (of strings) and rounding of numeric values.

2.6. Modes (Editable Read-only) Conditions:

  1. Are the screen and field colours adjusted correctly for read-only mode?
  2. Should a read-only mode be provided for this screen?
  3. Are all fields and controls disabled in read-only mode?
  4. Can the screen be accessed from the previous screen/menu/toolbar in read-only mode?
  5. Can all screens available from this screen be accessed in read-only mode?
  6. Check that no validation is performed in read-only mode.
  7. Assure the existence of the “Help” menu.
  8. Assure that the proper commands and options are in each menu.
  9. Assure that all buttons on all tool bars have a corresponding key commands.

2.7. General Conditions:

10.  Assure that each menu command has an alternative(hot-key) key sequence which will invoke it where appropriate.

11.  In drop down list boxes, ensure that the names are not abbreviations / cut short

12.  In drop down list boxes, assure that the list and each entry in the list can be accessed via appropriate key / hot key combinations.

13.  Ensure that duplicate hot keys do not exist on each screen

14.  Ensure the proper usage of the escape key (which is to undo any changes that have been made) and generates a caution message “Changes will be lost – Continue yes/no”

15.  Assure that the cancel button functions the same as the escape key.

16.  Assure that the Cancel button operates as a Close button when changes have be made that cannot be undone.

17.  Assure that only command buttons which are used by a particular window, or in a particular dialog box, are present. – i.e make sure they don’t work on the screen behind the current screen.

18.  When a command button is used sometimes and not at other times, assure that it is grayed out when it should not be used.

19.  Assure that OK and Cancel buttons are grouped separately from other command buttons.

20.  Assure that command button names are not abbreviations.

21.  Assure that all field labels/names are not technical labels, but rather are names meaningful to system users.

22.  Assure that command buttons are all of similar size and shape, and same font & font size.

23.  Assure that each command button can be accessed via a hot key combination.

24.  Assure that command buttons in the same window/dialog box do not have duplicate hot keys.

25.  Assure that each window/dialog box has a clearly marked default value (command button, or other object) which is invoked when the Enter key is pressed – and NOT the Cancel or Close button

26.  Assure that focus is set to an object/button which makes sense according to the function of the window/dialog box.

27.  Assure that all option buttons (and radio buttons) names are not abbreviations.

28.  Assure that option button names are not technical labels, but rather are names meaningful to system users.

29.  If hot keys are used to access option buttons, assure that duplicate hot keys do not exist in the same window/dialog box.

30.  Assure that option box names are not abbreviations.

31.  Assure that option boxes, option buttons, and command buttons are logically grouped together in clearly demarcated areas “Group Box”

32.  Assure that the Tab key sequence which traverses the screens does so in a logical way.

33.  Assure consistency of mouse actions across windows.

34.  Assure that the color red is not used to highlight active objects (many individuals are red-green color blind).

35.  Assure that the user will have control of the desktop with respect to general color and highlighting (the application should not dictate the desktop background characteristics).

36.  Assure that the screen/window does not have a cluttered appearance

37.  Ctrl + F6 opens next tab within tabbed window

38.  Shift + Ctrl + F6 opens previous tab within tabbed window

39.  Tabbing will open next tab within tabbed window if on last field of current tab

40.  Tabbing will go onto the ‘Continue’ button if on last field of last tab within tabbed window

41.  Tabbing will go onto the next editable field in the window

42.  Banner style & size & display exact same as existing windows

43.  If 8 or less options in a list box, display all options on open of list box – should be no need to scroll

44.  Errors on continue will cause user to be returned to the tab and the focus should be on the field causing the error. (i.e the tab is opened, highlighting the field with the error on it)

45.  Pressing continue while on the first tab of a tabbed window (assuming all fields filled correctly) will not open all the tabs.

46.  On open of tab focus will be on first editable field

47.  All fonts to be the same

48.  Alt+F4 will close the tabbed window and return you to main screen or previous screen (as appropriate), generating “changes will be lost” message if necessary.

49.  Microhelp text for every enabled field & button

50.  Ensure all fields are disabled in read-only mode

51.  Progress messages on load of tabbed screens

52.  Return operates continue

53.  If retrieve on load of tabbed window fails window should not open

2.8. Specific Field Tests

2.8.1. Date Field Checks
  • Assure that leap years are validated correctly & do not cause errors/miscalculations
  • Assure that month code 00 and 13 are validated correctly & do not cause errors/miscalculations
  • Assure that 00 and 13 are reported as errors
  • Assure that day values 00 and 32 are validated correctly & do not cause errors/miscalculations
  • Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations
  • Assure that Feb. 30 is reported as an error
  • Assure that century change is validated correctly & does not cause errors/ miscalculations
  • Assure that out of cycle dates are validated correctly & do not cause errors/miscalculations
2.8.2. Numeric Fields
  • Assure that lowest and highest values are handled correctly
  • Assure that invalid values are logged and reported
  • Assure that valid values are handles by the correct procedure
  • Assure that numeric fields with a blank in position 1 are processed or reported as an error
  • Assure that fields with a blank in the last position are processed or reported as an error an error
  • Assure that both + and – values are correctly processed
  • Assure that division by zero does not occur
  • Include value zero in all calculations
  • Include at least one in-range value
  • Include maximum and minimum range values
  • Include out of range values above the maximum and below the minimum
  • Assure that upper and lower values in ranges are handled correctly
2.8.3. Alpha Field Checks
  • Use blank and non-blank data
  • Include lowest and highest values
  • Include invalid characters & symbols
  • Include valid characters
  • Include data items with first position blank
  • Include data items with last position blank

Section 3 – Validation Testing – Standard Actions

3.1. Examples of Standard Actions – Substitute your specific commands

Continue – (i.e. continue saving changes or additions)

Cancel – (i.e. abandon changes or additions)

Fill each field – Valid data
Fill each field – Invalid data

Different Check Box / Radio Box combinations

Scroll Lists / Drop Down List Boxes


Fill Lists and Scroll


Tab Sequence

Shift Tab

3.2. Shortcut keys / Hot Keys

Note: The following keys are used in some windows applications, and are included as a guide.

Key No Modifier Shift CTRL ALT
F1 Help Enter Help Mode n\a n\a
F2 n\a n\a n\a n\a
F3 n\a n\a n\a n\a
F4 n\a n\a Close Document / Child window. Close Application.
F5 n\a n\a n\a n\a
F6 n\a n\a n\a n\a
F7 n\a n\a n\a n\a
F8 Toggle extend mode, if supported. Toggle Add mode, if supported. n\a n\a
F9 n\a n\a n\a n\a
F10 Toggle menu bar activation. n\a n\a n\a
F11, F12 n\a n\a n\a n\a
Tab Move to next active/editable field. Move to previous active/editable field. Move to next open Document or Child window. (Adding SHIFT reverses the order of movement). Switch to previously used application. (Holding down the ALT key displays all open applications).
Alt Puts focus on first menu command (e.g. ‘File’). n\a n\a n\a

3.3. Control Shortcut Keys

Key Function
CTRL + Z Undo
CTRL + X Cut
CTRL + C Copy
CTRL + V Paste
CTRL + N New
CTRL + O Open
CTRL + P Print
CTRL + S Save
CTRL + B Bold*
CTRL + I Italic*
CTRL + U Underline*

* These shortcuts are suggested for text formatting applications, in the context for
which they make sense. Applications may use other modifiers for these operations.

Web Testing Checklist about Usability

1. Is terminology consistent?
2. Are navigation buttons consistently located?
3. Is navigation to the correct/intended destination?
4. Is the flow to destination (page to page) logical?
5. Is the flow to destination the page top-bottom left to right?
6. Is there a logical way to return?
7. Are the business steps within the process clear or mapped?
8. Are navigation standards followed?

Ease of Use
1. Are help facilities provided as appropriate?
2. Are selection options clear?
3. Are ADA standards followed?
4. Is the terminology appropriate to the intended audience?
5. Is there minimal scrolling and resizeable screens?
6. Do menus load first?
7. Do graphics have reasonable load times?
8. Are there multiple paths through site (search options) that are user chosen?
9. Are messages understandable?
10. Are confirmation messages available as appropriate?

Presentation of Information
1. Are fonts consistent within functionality?
2. Are the company display standards followed?
– Logos
– Font size
– Colors
– Scrolling
– Object use
3. Are legal requirements met?
4. Is content sequenced properly?
5. Are web-based colors used?
6. Is there appropriate use of white space?
7. Are tools provided (as needed) in order to access the information?
8. Are attachments provided in a static format?
9. Is spelling and grammar correct?
10. Are alternative presentation options available (for limited browsers or performance issues)?

How to interpret/Use Info
1. Is terminology appropriate to the intended audience?
2. Are clear instructions provided?
3. Are there help facilities?
4. Are there appropriate external links?
5. Is expanded information provided on services and products? (why and how)
6. Are multiple views/layouts available?

Web Testing Checklist about Compatibility and Portability

1. Are requirements driven by business needs and not technology?

1. Has the audience been defined?
2. Is there a process for identifying the audience?
3. Is the process for identifying the audience current?
4. Is the process reviewed periodically?
5. Is there appropriate use of audience segmentation?
6. Is the application compatible with the audience experience level?
7. Where possible, has the audience readiness been ensured?
8. Are text version and/or upgrade links present?

Testing Process
1. Does the testing process include appropriate verifications? (e.g., reviews, inspections and walkthroughs)
2. Is the testing environment compatible with the operating systems of the audience?
3. Does the testing process and environment legitimately simulate the real world?

Operating systems Environment/ Platform
1. Has the operating environments and platforms been defined?
2. Have the most critical platforms been identified?
3. Have audience expectations been properly managed?
4. Have the business users/marketing been adequately prepared for what will be tested?
5. Have sign-offs been obtained?

1. Has the risk tolerance been assessed to identify the vital few platforms to test?

1. Is the test hardware compatible with all screen types, sizes, resolution of the audience?
2. Is the test hardware compatible with all means of access, modems, etc of the audience?
3. Is the test hardware compatible will all languages of the audience?
4. Is the test hardware compatible with all databases of the audience?
5. Does the test hardware contain the compatible plug-ins and DLLs of the audience?

1. Is the application compatible with standards and conventions of the audience?
2. Is the application compatible with copyright laws and licenses?

Web Testing Checklist about Security (1)

Access Control
1. Is there a defined standard for login names/passwords?
2. Are good aging procedures in place for passwords?
3. Are users locked out after a given number of password failures?
4. Is there a link for help (e.g., forgotten passwords?)
5. Is there a process for password administration?
6. Have authorization levels been defined?
7. Is management sign-off in place for authorizations?

Disaster Recovery
1. Have service levels been defined. (e.g., how long should recovery take?)
2. Are fail-over solutions needed?
3. Is there a way to reroute to another server in the event of a site crash?
4. Are executables, data, and content backed up on a defined interval appropriate for the level of risk?
5. Are disaster recovery process & procedures defined in writing? If so, are they current?
6. Have recovery procedures been tested?
7. Are site assets adequately Insured?
8. Is a third party “hot-site’ available for emergency recovery?
9. Has a Business Contingency Plan been developed to maintain the business while the site is being restored?
10. Have all levels in organization gone through the needed training & drills?
11. Do support notification procedures exist & are they followed?
12. Do support notification procedures support a 24/7 operation?
13. Have criteria been defined to evaluation recovery completion / correctness?

1. Was the software installed correctly?
2. Are firewalls installed at adequate levels in the organization and architecture? (e.g., corporate data, human resources data, customer transaction files, etc.)
3. Have firewalls been tested? (e.g., to allow & deny access).
4. Is the security administrator aware of known firewall defects?
5. Is there a link to access control?
6. Are firewalls installed in effective locations in the architecture? (e.g., proxy servers, data servers, etc.)

Proxy Servers
1. Have undesirable / unauthorized external sites been defined and screened out? (e.g. gaming sites, etc.)
2. Is traffic logged?
3. Is user access defined?

1. Is sensitive data restricted to be viewed by unauthorized users?
2. Is proprietary content copyrighted?
3. Is information about company employees limited on public web site?
4. Is the privacy policy communicated to users and customers?
5. Is there adequate legal support and accountability of privacy practices?

Web Testing Checklist about Security (2)

Data Security
1. Are data inputs adequately filtered?
2. Are data access privileges identified? (e.g., read, write, update and query)
3. Are data access privileges enforced?
4. Have data backup and restore processes been defined?
5. Have data backup and restore processes been tested?
6. Have file permissions been established?
7. Have file permissions been tested?
8. Have sensitive and critical data been allocated to secure locations?
9. Have date archival and retrieval procedures been defined?
10. Have date archival and retrieval procedures been tested?

1. Are network monitoring tools in place?
2. Are network monitoring tool working effectively?
3. Do monitors detect
– Network time-outs?
– Network concurrent usage?
– IP spoofing?
4. Is personnel access control monitored?
5. Is personnel internet activity monitored?
– Sites visited
– Transactions created
– Links accessed

Security Administration
1. Have security administration procedures been defined?
2. Is there a way to verify that security administration procedures are followed?
3. Are security audits performed?
4. Is there a person or team responsible for security administration?
5. Are checks & balances in place?
6. Is there an adequate backup for the security administrator?

1. Are encryption systems/levels defined?
2. Is there a standard of what is to be encrypted?
3. Are customers compatible in terms of encryption levels and protocols?
4. Are encryption techniques for transactions being used for secured transactions?
– Secure socket layer (SSL)
– Virtual Private Networks (VPNs)
5. Have the encryption processes and standards been documented?

1. Are virus detection tools in place?
2. Have the virus data files been updated on a current basis?
3. Are virus updates scheduled?
4. Is a response procedure for virus attacks in place?
5. Are notification of updates to virus files obtained from anti-virus software vendor?
6. Does the security administrator maintain an informational partnership with the anti-virus software vendor?
7. Does the security administrator subscribe to early warning e-mail services? (e.g., http://www.fooorg or http://www.bar.net)
8. Has a key contact been defined for the notification of a virus presence?
9. Has an automated response been developed to respond to a virus presence?
10. Is the communication & training of virus prevention and response procedures to users adequate?

Web Testing Checklist about Performance (1)

1. Are virus detection tools in place?
2. Have the virus data files been updated on a current basis?
3. Are virus updates scheduled?
4. Is a response procedure for virus attacks in place?
5. Are notification of updates to virus files obtained from anti-virus software vendor?
6. Does the security administrator maintain an informational partnership with the anti-virus software vendor?
7. Does the security administrator subscribe to early warning e-mail services? (e.g., http://www.foo.org or http://www.bar.net)
8. Has a key contact been defined for the notification of a virus presence?
9. Has an automated response been developed to respond to a virus presence?
10. Is the communication & training of virus prevention and response procedures to users adequate?

1. Has a load testing tool been identified?
2. Is the tool compatible with the environment?
3. Has licensing been identified?
4. Have external and internal support been identified?
5. Have employees been trained?

Number of Users
1. Have the maximum number of users been identified?
2. Has the complexity of the system been analyzed?
3. Has the user profile been identified?
4. Have user peaks been identified?
5. Have languages been identified?, i.e. English, Spanish, French, etc. for global wide sites
6. Have the length of sessions been identified by the number of users?
7. Have the number of users configurations been identified?

1. Have the response time been identified?
2. Has the client response time been identified?
3. Has the expected vendor response time been identified?
4. Have the maximum and acceptable response times been defined?
5. Has response time been met at the various thresholds?
6. Has the break point been identified been identified for capacity planning?
7. Do you know what caused the crash if the application was taken to the breaking point?
8. How many transactions for a given period of time have been identified (bottlenecks)?
9. Have availability of service levels been defined?

1. Has the database campacity been identified?
2. Has anticipated growth data been obtained?
3. Is the database self-contained?
4. Is the system architecture defined?
” Tiers
” Servers
” Network
5. Has the anticipated volume for initial test been defined – with allowance for future growth?
6. Has plan for vertical growth been identified?
7. Have the various environments been created?
8. Has historical experience with the databases and equipment been documented?
9. Has the current system diagram been developed?
10.Is load balancing available?
11.Have the types of programming languages been identified?
12.Can back end processes be accessed?

Web Testing Checklist about Performance (2)

1. Are people with skill sets available?
2. Have the following skill sets been acquired?
” Doc
” BA
” QA
” Tool Experts
” Internal and external support
” Project manager
” Training

Time Frame
1. When will the application be ready for performance testing?
2. How much time is available for performance testing?
3. How many iterations of testing will take place?

Test Environment
1. Does the test environment exist?
2. Is the environment self-contained?
3. Can one iteration of testing be performed in production?
4. Is a copy of production data available for testing?
5. Are end-users available for testing and analysis?
6. Will the test use virtual users?
7. Does the test environment mirror production?
8. Have the differences documented? (constraints)
9. Is the test available after production?
10. Have version control processes been used to ensure the correct versions of applications and data in the test environment?
11. Have the times been identified when you will receive the test data (globally) time frame?
12. Are there considerations for fail-over recovery? Disaster recovery?
13. Are replacement servers available?
14. Have back-up procedures been written?

Web Testing Checklist about Correctness (1)

1. Does the application write to the database properly?
2. Does the application record from the database correctly?
3. Is transient data retained?
4. Does the application follow concurrency rules?
5. Are text fields storing information correctly?
6. Is inventory or out of stock being tracked properly?
7. Is there redundant info within web site?
8. Is forward/backward cashing working correctly?
9. Are requirements for timing out of session met?

1. Are the field data properly displayed?
2. Is the spelling correct?
3. Are the page layouts and format based on requirements?
(e.g., visual highlighting, etc.)
4. Does the URL show you are in secure page?
5. Is the tab order correct on all screens?
6. Do the interfaces meet specific visual standards(internal)?
7. Do the interfaces meet current GUI standards?
8. Do the print functions work correctly?

1. Can you navigate to the links correctly?
2. Do Email links work correctly?

1. Is the application recording the number of hits correctly?
2. Are calculations correct?
3. Are edits rules being consistently applied?
4. Is the site listed on search engines properly?
5. Is the help information correct?
6. Do internal searches return correct results?
7. Are follow-up confirmations sent correctly?
8. Are errors being handled correctly?
9. Does the application properly interface with other applications?


  • Pages fit within the resolution(800×600)
  • Design works with liquid tables to fill the user’s window size.
  • Separate print versions provided for long documents (liquid tables may negate this necessity). Accommodates A4 size paper.
  • Site doesn’t use frames.
  • Complex tables are minimized.
  • Newer technologies are generally avoided for 1-2 years from release, or if used alternative traditional forms of content are easily available.

Home vs. Subsequent Pages & Sections

  • Home page logo is larger and more centrally placed than on other pages.
  • Home page includes navigation, summary of news/promotions, and a search feature.
  • Home page answers: Where am I; What does this site do; How do I find what I want?
  • Larger navigation space on home page, smaller on subsequent pages.
  • Logo is present and consistently placed on all subsequent pages (towards upper left hand corner).
  • “Home” link is present on all subsequent pages (but not home page).
  • If subsites are present, each has a home page, and includes a link back to the global home page.


  • Navigation supports user scenarios gathered in the User Task Assessment phase (prior to design).
  • Users can see all levels of navigation leading to any page.
  • Breadcrumb navigation is present (for larger and some smaller sites).
  • Site uses DHTML pop-up to show alternative destinations for that navigation level.
  • Navigation can be easily learned.
  • Navigation is consistently placed and changes in response to rollover or selection.
  • Navigation is available when needed (especially when the user is finished doing something).
  • Supplimental navigation is offered appropriately (links on each page, a site map/index, a search engine).
  • Navigation uses visual hierarchies like movement, color, position, size, etc., to differentiate it from other page elements.
  • Navigation uses precise, descriptive labels in the user’s language. Icon navigation is accompanied by text descriptors.
  • Navigation answers: Where am I (relative to site structure); Where have I been (obvious visited links); Where can I go (embedded, structural, and associative links)?
  • Redundant navigation is avoided.
  • Functional Items
  • Terms like “previous/back” and “next” are replaced by more descriptive labels indicating the information to be found.
  • Pull-down menus include a go button.
  • Logins are brief.
  • Forms are short and on one page (or demonstrate step X of Y, and why collecting a larger amount of data is important and how the user will benefit).
  • Documentation pages are searchable and have an abundance of examples. Instructions are task-oriented and step-by-step. A short conceptual model of the system is available, including a diagram that explains how the different parts work together. Terms or difficult concepts are linked to a glossary.


  • Links are underlined.
  • Size of large pages and multi-media files is indicated next to the link, with estimated dowload times.
  • Important links are above the fold.
  • Links to releated information appear at bottom of content or above/near the top.
  • Linked titles make sense out of context.
  • If site requires registration or subscription, provides special URLs for free linking. Indicates the pages are freely linkable, and includes and easy method to discover the URL.
  • If site is running an ad, it links to a page with the relevant content, not the corporate home page.
  • Keeps linked phrases short to aid scanning (2-4 words).
  • Links on meaningful words and phrases. Avoids phrases like, “click here.”
  • Includs a brief description of what the user should expect on the linked page. In code:
  • Uses relative links when linking between pages in a site. Uses absolute links to pages on unrelated sites.
  • Uses link titles in the code for IE users (preferably less than 60 characters, no more than 80).

Search Capabilities

  • A search feature appears on every page (exceptions include pop-up forms and the like).
  • Search box is wide to allow for visible search parameters.
  • Advanced Search, if included, is named just that (to scare off novices).
  • Search system performs a spelling check and offers synonym expansion.
  • Site avoids scoped searching. If included it indicates scope at top of both query and results pages, and additionally offers an automatic extended site search immediately with the same parameters.
  • Results do not include a visible scoring system.
  • Eliminates duplicate occurances of the same results (e.g., foo.com/bar vs. foo.com/bar/ vs. foo.com/bar/index.html).

Page Design

  • Content accounts for 50% to 80% of a page’s design (what’s left over after logos, navigation, non-content imagery, ads, white space, footers, etc.).
  • Page elements are consistent, and important information is above the fold.
  • Pages load in 10 seconds or less on users bandwidth.
  • Pages degrade adequately on older browsers.
  • Text is over plain background, and there is high contrast between the two.
  • Link styles are minimal (generally one each of link, visited, hover, and active states). Additional link styles are used only if necessary.
  • Specified the layout of any liquid areas (usually content) in terms of percentages.

Fonts and Graphics

  • Graphics are properly optimized.
  • Text in graphics is generally avoided.
  • Preferred fonts are used: Verdana, Arial, Geneva, sans-serif.
  • Fonts, when enlarged, don’t destroy layout.
  • Images are reused rather than rotated.
  • Page still works with graphics turned off.
  • Graphics included are necessary to support the message.
  • Fonts are large enough and scalable.
  • Browser chrome is removed from screen shots.
  • Animation and 3D graphics are generally avoided.

Content Design

  • Uses bullets, lists, very short paragraphs, etc. to make content scannable.
  • Articles are structured with scannable nested headings.
  • Content is formatted in chunks targeted to user interest, not just broken into multiple pages.
  • No moving text; most is left-justified; sans-serif for small text; no upper-case sentences/paragraphs; italics and bold are used sparingly.
  • Dates follow the international format (year-month-day) or are written out (August 30, 2001).


  • Writing is brief, concise, and well edited.
  • Information has persistent value.
  • Avoids vanity pages.
  • Starts each page with the conclusion, and only gradually added the detail supporting that conclusion.
  • One idea per paragraph.
  • Uses simple sentence structures and words.
  • Gives users just the facts. Uses humor with caution.
  • Uses objective language.

Folder Structure

  • Folder names are all lower-case and follow the alpha-numeric rules found under “Naming Conventions” below.
  • Segmented the site sections according to:
    Root directory (the “images” folder usually goes at the top level within the root folder)
    Sub-directories (usually one for each area of the site, plus an images folder at the top level within the root directory)
    Images are restricted to one folder (“images”) at the top level within the root directory (for global images) and then if a great number of images are going to be used only section-specifically, those are stored in local “images” folders

Naming Conventions

  • Uses clients preferred naming method. If possible, uses longer descriptive names (like “content_design.htm” vs. “contdesi.htm”).
  • Uses alphanumeric characters (a-z, 0-9) and – (dash) or _ (underscore)
  • Doesn’t use spaces in file names.
  • Avoids characters which require a shift key to create, or any punctuation other than a period.
  • Uses only lower-case letters.
  • Ends filenames in .htm (not .html).


  • Any files taking longer than 10 seconds to download include a size warning (> 50kb on a 56kbps modem, > 200kb on fast connections). Also includes the running time of video clips or animations, and indicate any non-standard formats.
  • Includes a short summary (and a still clip) of the linked object.
  • If appropriate to the content, includes links to helper applications, like Adobe Acrobat Reader if the file is a .pdf.

Page Titles

  • Follows title strategy … Page Content Descriptor : Site Name, Site section (E.g.: Content Implementation Guidelines : CDG Solutions, Usability Process )
  • Tries to use only two to six words, and makes their meaning clear when taken out of context.
  • The first word(s) are important information-carrying one(s).
  • Avoids making several page titles start with the same word.


  • Describes the article in terms that relate to the user.
  • Uses plain language.
  • Avoids enticing teasers that don’t describe.


  • Uses CSS to format content appearance (as supported by browsers), rather than older HTML methods.
  • Uses a browser detect and serve the visitor a CSS file that is appropriate for their browser/platform combination.
  • Uses linked style sheets.

Documentation and Help Pages

  • When using screen shots, browser chrome was cropped out.
  • Hired a professional to write help sections (a technical writer).
  • Documentation pages are searchable.
  • Documentation section has an abundance of examples.
  • Instructions are task-oriented and step-by-step.
  • A short conceptual model of the system is provided, including a diagram that explains how the different parts work together.
  • Terms or difficult concepts are linked to a glossary.

Content Management

Site has procedures in place to remove outdated information immediately (such as calendar events which have passed).

Localization testing

What is localization (L10N)

* Adapting a (software) product to a local or regional market.
* Goal: Appropriate linguistic and cultural aspects
* Performed by translators, localizers, language engineers


The aspect of development and testing relating to the translation of the software and ite prsentation to the end user. This includes translating the program, choosing appropriate icons and graphics, and other cultural considerations. It also may include translating the program’s help files and the documentation. You could think of localization as pertaining to the presentation of your program; the things the user sees.

Internationalization (I18N)

* Developing a (software) product in such a way that it will be easy to adapt it to other markets (languages and cultures)
* Goal: eliminate the need to reprogram or recompile the original program
* Carried out by SW-Development in conjunction with Localization
* Handing foreign text and data within a program
* Sorting, importing and exporting text and data, correct handing of currency and data and time formats, string parsing, upper and lower case handling.
* Separating strings from the source code, and making sure that the foreign language string have enough space in your user interface to be displayed correctly


The aspect of development and testing relating to handling foreign text and data within a program. This would include sorting, importing and exporting text and data, correct handling of currency and date and time formats, string parsing, upper and lower case handling, and so forth. It also includes the task of separating strings (or user interface text) from the source code, and making sure that the foreign language strings have enough space in your user interface to be displayed correctly. You could think of internationalization as pertaining ot the underlying functionality and workings of your program.

What is I18N/L10N stand for ?

These two abbreviations mean internationalization and localization respectively. Using the word “internationalization” as an example; here is how these abbreviations are derived. First, you take the first letter of the word you want to abbreviate; in this case the letter “I”. Next, you take the last letter in the word; in this case the letter “N”. These become the first and last letters in the abbreviation. Finally, you count the remaining letters in the word between the first and last letter. In this case. “nternationalizatio” has 18 characters in it. se we will plug the number 18 between the “I” and “N”; thus I18N.

I18N and L10N

* I18N and L10N comprise the whole of the offort involved in enabling a product.
* I18N is “Stuff” you have to do once.
* L10N is “stuff you have to do over and over again.
* The more stuff you push into I18N out of L10N, the less complicated and expensive the process becomes.

Globalization (G11N)

* Activities performed for the purpose of marketing a (software) product in regional marketing a (software) product in regional markets
* Goal: Global marketing that accounts for economic and legal factors.
* Focus on marketing; total enterprise solutions and to management support

Aspects of Localization

* Terminology
The selection and definition as well as the correct and consistent usage of terms are preconditions for successful localition:
o laymen and expert users
o in most cases innovative domains and topics
o huge projects with many persons involved
o consistent terminology throughout all products
o no synonyms allowed
o prededined terminology(environment, laws, specifications, guidelines, corporate language)
* Symbols
o Symbols are culture-dependant, but often they cannot be modified by the localizer.
o Symbols are often adopted from other (common) spheres of life.
o Symbols often use allusions (concrete for abstract); in some cases, homonyms or even homophones are used.
* Illustrations and Graphics
o Illustrations and graphics are very often culture dependant, not only in content but also in the way they are presented
o Illustrations and graphics should be adopted to the (technical) needs of the target market (screen shots, manuals)
o Illustrations and graphics often contain textual elements that must be localized, but cannnot be isolated.
* Colors have different meanings in different cultures
* Character sets
o Languages are based on different character sets (“alphabets”)
o the localized product must be able to handle(display, process, sort etc) the needed character set
o “US English” character sets (1 byte, 7 bit or 8 bit)
o Product development for internationalization should be based on UNICODE (2 byte or 4 byte)
* Fonts and typography
o Font types and font families are used in different cultures with varying frequency and for different text types and parts of text
o Example: In English manuals fonts with serifs(Times Roman) are preferred; In German manuals fonts without serifs(Helvetica) are preferred
o Example: English uses capitalization more frequently(e.g. CAUTION) for headers and parts of text
* Language and style
o In addition to the language specific features of grammar, syntax and style, there are cultural conventions that must be taken into account for localization.
o In (US_English) an informal style is preferred, the reader is addressed directly, “simple” verbs are used, repetition of parts of text is accepted etc.
o Formulating headers (L10N)
o Long compound words (L10N)
o Elements of the user interface
Open the File menu
The Open dialog box appears
Click the copy command
* Formats
o Date, currency, units of measurement
o Paper format
o Different length of text
1. Consequences for the volume of documents, number of pages, page number (table of contents, index)etc.
2. Also for the size of buttons (IT, machines etc.)

What we need consider in localization testing?

  • testing resource files [separate strings from the code] Solution: create a pseudo build
  • string expansion: String size change breaking layout and aligment. when words or sentatences are translated into other languages, most of the time the resulting string will be either longer or shorter than the native language version of the string. Two solutions to this problem:
  1. Account the space needed for string expansion, adjusting the layout of your dialog accordingly
  2. Separate your dialog resources into separate dynamic libraries.
  • Data format localization:
    European style:DD/MM/YY
    North American style: MM/DD/YY
    Currency, time and number formate, address.
  • Charater sets: ASCII or Non ASCII
    Single byte character 16bit (US) 256 charaters
    Double byte character 32bit(chinese) 65535 code ponits
  • Encoding: Unicode: Unicode supports many different written languages in the world all in a single character encoding. Note: For double character set, it is better to convert from Unicode to UTF8 for chinese, because UTF8 is a variable length encoding of Unicode that can be easily sent through the network via single byte streams.
  • Builds and installer : Creating an environment that supports a single version of your code, and multiple version of the language files.
  • program’s installation, uninstallation in the foreign machines.
  • Tesing with foreign characters :
    enter foreign text for username and password.
    For entering European or Latin characters on Windows
    1. Using Character Map tool
    Search: star-program-accessories-accessibility-system tool-
    2. escape sequences. EXP: ALT + 128
    For Asia languages use what is usually called an IME (input method editor)
    Chinese: I use GB encoding with pin yin inputer mode
  • Foreign Keyboards or On-Screen keyboard
  • Text filters: Program that are used to collect and manipulate data usually provide the user with a mechanism for searching and filtering that data. As a global software tester, you need to make sure that the filtering and searching capabilities of your program work correctly with foreign text. Problem; ignore the accent marks used in foreign text.
  • Loading, saving, importing,and exporting high and low ASCII
  • Asian text in program: how double charater set work
  • Watch the style
  • Two environment to test for the program in chinese
    1. In Chinese window system. (in China)
    2. In English Window system with chinese language support (in USA)
    Microsoft language codes:
    CHS – Chinese Simplified
    CHT – Chinese Traditional(Taiwan)
    ENU – English (United States)
    FRA – French (France)
    Java Languages codes
    zh_CN – Chinese Simplified
    zh_TW – Chinese Traditional(Taiwan)
    Fr or fr_FR – English (United States)
    en or en_US – French (France)
  • More need consider in localization testing:
    • Hot key.
    • Garbled in translation
    • Error message identifiers
    • Hyphenation rules
    • Spelling rules
    • Sorting rules
    • Uppercase and lowercase conversion
  • Testing for Localizable Strings — separate string from code

Localizable string are strings that are no longer hard coded and compiled directly into the programs executable files. To do so for tester is to create a pseudo build automaticaly or manually. A pseudo language build means is that the native language string files are run through a parser that changes them in some way so they can easily be identified by testing department. Next a build is created using these strings so they show up in the user interface instead of the English strings. This helps find strings that haven’t been put into separate string files. problems with displaying foreign text, and problems with string expansion where foreign strings will be truncated.
Two environment to test for the program in chinese
1. In Chinese window system. (in China)
2. In English Window system with chinese language support (in USA)

Online help

    • Accuracy
    • Good reading
    • Help is a combination of writing and programming
    • Test hypertext links
    • Test the index
    • Watch the style

Some specific testing recommendations

  • Make your own list of localization requirements
  • Automated testing

The documentation tester’s objectives

  • Checking the technical accurancy of every word.
  • Lookout for confusions in the writing.
  • Lookout for missing features.
  • Give suggections without justifying.
Last Updated ( Monday, 24 September 2007 )
Posted in Uncategorized | Leave a comment

How to hire the right candidates for software testing positions?

How to hire the right candidates for software testing positions?

Money making, software testing career and secrets of a richest tester

Top 20 practical software testing tips you should read before testing any application.

Posted In | Testing best practices, Testing Skill Improvement, Testing Tips and resources

// I wish all testers read these software testing good practices. Read all points carefully and try to implement them in your day-to-day testing activities. This is what I expect from this article. If you don’t understand any testing practice, ask for more clarification in comments below. After all you will learn all these testing practices by experience. But then why not to learn all these things before making any mistake?

Here are some of the best testing practices I learned by experience:

1) Learn to analyze your test results thoroughly. Do not ignore the test result. The final test result may be ‘pass’ or ‘fail’ but troubleshooting the root cause of ‘fail’ will lead you to the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions.

2) Learn to maximize the test coverage every time you test any application. Though 100 percent test coverage might not be possible still you can always try to reach near it.

3) To ensure maximum test coverage break your application under test (AUT) into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts.
E.g: Lets assume you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing test cases: Parts like UI testing, security testing, functional testing of the ‘User information’ form etc. Apply all form field type and size tests, negative and validation tests on input fields and write all such test cases for maximum coverage.

4) While writing test cases, write test cases for intended functionality first i.e. for valid conditions according to requirements. Then write test cases for invalid conditions. This will cover expected as well unexpected behavior of application under test.

5) Think positive. Start testing the application by intend of finding bugs/errors. Don’t think beforehand that there will not be any bugs in the application. If you test the application by intention of finding bugs you will definitely succeed to find those subtle bugs also.

6) Write your test cases in requirement analysis and design phase itself. This way you can ensure all the requirements are testable.

7) Make your test cases available to developers prior to coding. Don’t keep your test cases with you waiting to get final application release for testing, thinking that you can log more bugs. Let developers analyze your test cases thoroughly to develop quality application. This will also save the re-work time.

8 ) If possible identify and group your test cases for regression testing. This will ensure quick and effective manual regression testing.

9) Applications requiring critical response time should be thoroughly tested for performance. Performance testing is the critical part of many applications. In manual testing this is mostly ignored part by testers due to lack of required performance testing large data volume. Find out ways to test your application for performance. If not possible to create test data manually then write some basic scripts to create test data for performance test or ask developers to write one for you.

10) Programmers should not test their own code. As discussed in our previous post, basic unit testing of developed application should be enough for developers to release the application for testers. But you (testers) should not force developers to release the product for testing. Let them take their own time. Everyone from lead to manger know when the module/update is released for testing and they can estimate the testing time accordingly. This is a typical situation in agile project environment.

11) Go beyond requirement testing. Test application for what it is not supposed to do.

12) While doing regression testing use previous bug graph (Bug graph – number of bugs found against time for different modules). This module-wise bug graph can be useful to predict the most probable bug part of the application.

13) Note down the new terms, concepts you learn while testing. Keep a text file open while testing an application. Note down the testing progress, observations in it. Use these notepad observations while preparing final test release report. This good habit will help you to provide the complete unambiguous test report and release details.

14) Many times testers or developers make changes in code base for application under test. This is required step in development or testing environment to avoid execution of live transaction processing like in banking projects. Note down all such code changes done for testing purpose and at the time of final release make sure you have removed all these changes from final client side deployment file resources.

15) Keep developers away from test environment. This is required step to detect any configuration changes missing in release or deployment document. Some times developers do some system or application configuration changes but forget to mention those in deployment steps. If developers don’t have access to testing environment they will not do any such changes accidentally on test environment and these missing things can be captured at the right place.

16) It’s a good practice to involve testers right from software requirement and design phase. These way testers can get knowledge of application dependability resulting in detailed test coverage. If you are not being asked to be part of this development cycle then make request to your lead or manager to involve your testing team in all decision making processes or meetings.

17) Testing teams should share best testing practices, experience with other teams in their organization.

18) Increase your conversation with developers to know more about the product. Whenever possible make face-to-face communication for resolving disputes quickly and to avoid any misunderstandings. But also when you understand the requirement or resolve any dispute – make sure to communicate the same over written communication ways like emails. Do not keep any thing verbal.

19) Don’t run out of time to do high priority testing tasks. Prioritize your testing work from high to low priority and plan your work accordingly. Analyze all associated risks to prioritize your work.

20) Write clear, descriptive, unambiguous bug report. Do not only provide the bug symptoms but also provide the effect of the bug and all possible solutions.

Don’t forget testing is a creative and challenging task. Finally it depends on your skill and experience, how you handle this challenge.

Over to you:

Sharing your own testing experience, tips or testing secrets in comments below will definitely make this article more interesting and helpful!!

If you are not regular reader of this website then highly recommend you to sign up for our free email newsletter! Sign up just providing your email address below:

Posted in Uncategorized | Leave a comment


  1. What is the file extension of the code file & object repository file in QTP?

Ans) for object repositories file the extension is .tsr

for code file the extension is .vbs

  1. Explain the concept of object repository & how QTP recognises objects?

Ans) Object Repository: displays a tree of all objects in the current component or in the current action or entire test (depending on the object repository mode you selected).
we can view or modify the test object description of any test object in the repository or to add new objects to the repository.
Quicktest learns the default property values and determines in which test object class it fits. If it is not enough it adds assistive properties, one by one to the description until it has compiled the unique description. If no assistive properties are available, then it adds a special Ordinal identifier such as objects location on the page or in the source code.

  1. What are the properties you would use for identifying a browser & page when using descriptive programming?

Ans) Title is the property we use.ex: Browser(“Title:=”xxx”).page(“Title:=”xxxx”)…..

“Name” would be another property apart from “title” that we can use.
Ex: Browser (“name:=”xxx””).page(“name:=”xxxx””)…..

  1. What are the different scripting languages you could use when working with QTP?

Ans) Visual Basic Script,XML,JavaScript,Java,HTML

  1. Give me an example where you have used a COM interface in your QTP project?

6. Few basic questions on commonly used Excel VBA functions.

7        Explain the keyword createobject with an example.

Ans) Creates and returns a reference to an Automation object . create object creates handle to the instance of the specified object so that we program can use the methods on the specified object. It is used for implementing Automation(as defined by microsoft).

8. Explain in brief about the QTP Automation Object Model.

Ans) Essentially all configuration and run functionality provided via the QuickTest interface is in some way represented in the QuickTest automation object model via objects, methods, and properties. Although a one-on-one comparison cannot always be made, most dialog boxes in QuickTest have a corresponding automation object, most options in dialog boxes can be set and/or retrieved using the corresponding object property, and most menu commands and other operations have corresponding automation methods.
You can use the objects, methods, and properties exposed by the QuickTest automation object model, along with standard programming elements such as loops and conditional statements to design your program

9. What are the Features & Benefits of Quick Test Pro(QTP)..?

Ans) Operates stand-alone, or integrated into Mercury Business Process Testing and Mercury Quality Center.
Introduces next-generation “zero-configuration” Keyword Driven testing technology in QuickTest Professional 8.0 — allowing for fast test creation, easier maintenance, and more powerful data-driving capability
Identifies objects with Unique Smart Object Recognition, even if they change from build to build, enabling reliable unattended script execution
Collapses test documentation and test creation to a single step with Auto-documentation technology
Enables thorough validation of applications through a full complement of checkpoints

10) How to handle the exceptions using recovery secnario manager in QTP?

Ans) You can instruct QTP to recover unexpected events or errors that occured in your testing environment during test run. Recovery scenario manager provides a wizard that guides you through the defining recovery scenario. Recovery scenario has three steps
1. Triggered Events
2. Recovery steps
3. Post Recovery Test-Run

11) what is the use of Text output value in QTP?

Ans) Output values enable to view the values that the application takes during run time. When parameterized, the values change for each iteration.Thus by creating output values, we can capture the values that the application takes for each run and output them to the data table.

12) How to use the Object spy in QTP 8.0 version?

Ans) There are two ways to Spy the objects in QTP
1) Thru file toolbar
—In the File Tool Bar click on the last toolbar button (an icon showing a person with hat).

2) Through Object repository Dialog
—In Object repository dialog click on the button “object spy…”

In the Object spy Dialog click on the button showing hand symbol.
The pointer now changes in to a hand symbol and we have to point out the object to spy the state of the object

if at all the object is not visible or window is minimized then Hold the Ctrl button and activate the required window to and release the Ctrl button

13) QTP pros and cons

Ans) Pros:

  • Will be getting the initial focus on development of all new features and supported technologies.
  • Ease of use.
  • Simple interface.
  • Presents the test case as a business workflow to the tester (simpler to understand).
  • Numerous features.
  • Uses a real programming language (Microsoft’s VBScript) with numerous resources available.
  • QuickTest Pro is significantly easier for a non-technical person to adapt to and create working test cases, compared to WinRunner.
  • Data table integration better and easier to use than WinRunner.
  • Test Run Iterations/Data driving a test is easier and better implement with QuickTest.
  • Parameterization easier than WinRunner.
  • Can enhance existing QuickTest scripts without the “Application Under Test” being available; by using the ActiveScreen.
  • Can create and implement the Microsoft Object Model (Outlook objects, ADO objects, FileSystem objects, supports DOM, WSH, etc.).
  • Better object identification mechanism.
  • Numerous existing functions available for implementation – both from within QuickTest Pro and VBScript.
  • QTP supports .NET development environment (currently WinRunner 7.5 does not).
  • XML support (currently WinRunner 7.5 does not).
  • The Test Report is more robust in QuickTest compared to WinRunner.
  • Integrates with TestDirector and WinRunner (can kick off WinRunner scripts from QuickTest).


  • Currently there are fewer resources (consultants and expertise) available due to QTP being a newer product on the market and because there is a greater Demand than Supply, thus fewer employee/consulting resources.
  • Must know VBScript in order to program at all.
  • Must be able to program in VBScript in order to implement the real advance testing tasks and to handle very dynamic situations.
  • Need training to implement properly.
  • The Object Repository (OR) and “testing environment” (paths, folders, function libraries, OR) can be difficult to understand and implement initially.

14) what is the difference between test plan and test strategy?

Ans) This is answer to Test strategy. The testing strategy should define the objectives of all test stages and the techniques that apply. The testing strategy also forms the basis for the creation of a standardized documentation set, and facilitates communication of the test process and its implications outside of the test discipline. Any test support tools introduced should be aligned with, and in support of, the test strategy. Whereas the test plan is the requirements definition and design specifications facilitate in the identification of major test items and these may necessitate the test strategy to be updated. A detailed test plan and schedule is prepared with key test responsibilities being indicated

15) Can test automation improve test effectiveness?

Ans) Yes, Automating a test makes the test process:
3. Repeatable

16) How will you choose a tool for test automation?

Ans) choosing of a tool depends on many things …

1. Application to be tested
2. Test environment
3. Scope and limitation of the tool.
4. Feature of the tool.
5. Cost of the tool.
6. Whether the tool is compatible with your application which means tool should be able to interact with your application
7. Ease of use


Posted in Uncategorized | Comments Off on QTP_INTERVIEW_QUESTIONS.doc

Challenges in Testing Web Based Applications

Challenges in Testing Web Based Applications


Web based Applications are increasingly becoming more feature rich, important and also the most popular means for developing commercial systems. Most companies opt for developing web based software wherever possible. This helps in catering to large number of end users. The deployment of the apps (once the infrastructure is in place) is fairly easy.

The web based applications are powerful and have the ability to provide feature rich content to a wide audience spread across the globe at an economical cost.

Hence it is a daunting task to test these applications and with more and more features testing these apps is becoming even more complex.

Why testing Web Applications is different?

  1. Testing web applications is different because of many factors scenarios affecting the performance and user experience.
  2. Web applications can typically cater to a large and a diverse audience. Web Applications can also be exposed to wide range of security threats. Web applications may open up illegal points of entry to the databases and other systems holding sensitive information.
  3. To ensure that the web application works reliably and correctly under different situations these factors need to be accounted for and tested.
  4. Hence a lot of effort needs to put in for Test Planning and Test Design.
  5. Test Cases should be written covering the different scenarios not only of functional usage but also technical considerations such as Network speeds, Screen Resolution, etc.
  6. For example an application may work fine on Broad Band internet users but may perform miserably for users with dial up internet connections.
  7. Web Applications are known to give errors on slow networks, whereas they perform well on high speed connections.
  8. Web pages don’t render correctly for certain situations but work okay with others.
  9. Images may take longer to download for slower networks and the end user perception of the application may not be good.

Factors effecting Testing of Web Applications:

As mentioned above Web Applications can have a lot of variables affecting them such as:

Numerous Application Usage (Entry – Exit) Paths are possible:

Due to the design and nature of the web applications it is possible that different users follow different application usage paths.

For example in an online banking application a user may directly go to “Bill Pay” page and other users may check account balances, view previous transactions and then “Pay the Bills”.
Generally a large number of usage paths are possible and all are supposed to work well.
All these Permutations and Combinations need to be tested thoroughly

People with varying backgrounds & technical skills may use the application:

Not all applications are self explanatory to all people. People have varying backgrounds and may find the application hard to use. For instance a Business Intelligence application with “Drill-Down-Reports” may work out for certain users but not for others.

Although this affects the design of the applications, but these factors should be tested in usability testing of the applications.

Intranet versus Internet based Applications:

  • Intranet based applications generally cater to a controlled audience. The developers and architects can make accurate assumptions about the people accessing the apps and the hardware / software / technical specifications of the client machines.
  • While it may be difficult to make similar assumptions for Internet Based Applications Also the intranet users can generally access the app from ‘trusted’ sources whereas for internet applications the users may need to be authenticated and the security measures may have to be much more stringent.
  • Test Cases need to be designed to test the various scenarios and risks involved.

The end users may use different types of browsers to access the app

Typically for internet based applications users may have different Browsers when accessing the apps. This aspect also needs to be tested. If we test the app only on IE then we cannot ensure if works well on Netscape or Fire-Fox. Because these browsers may not only render pages differently but also have varying levels of support for client side scripting languages such as java-script.

Even on similar browsers application may be rendered differently based on the Screen resolution/Hardware/Software Configuration

Network speeds:

  • Slow Network speeds may cause the various components of a Webpage to be downloaded with a time lag. This may cause errors to be thrown up.
  • The testing process needs to consider this as important factor specially for Internet based Applications

ADA (Americans with Disabilities Act):

It may be required that the applications be compliant with ADA. Due certain disabilities, some of the users may have difficulty in accessing the Web Applications unless the applications are ADA compliant. The Application may need to be tested for compliance and usability.

Other Regulatory Compliance/Standards:

Depending on the nature of the application and sensitivity of the data captured the applications may have to be tested for relevant Compliance Standards. This is more crucial for Web Based Applications because of their possible exposure to a wide audience.


As mentioned earlier Applications may behave differently across firewalls. Applications may have certain web services or may operate on different ports that may have been blocked. So the apps need to be tested for these aspects as well.

Security Aspects:

If the Application captures certain personal or sensitive information, it may be crucial to test the security strength of the application. Sufficient care needs to be taken that the security of the data is not compromised.

Why technology platforms affect testing?

Technology platform upon which the Web Application was built also creates different strengths and weaknesses. Different Test Automation tools & packages are available for different Technology Platforms. This can influence the Test Strategy and the way in which Test Execution is done.

Challenges in Testing Web Based Web Applications:

To ensure that sufficient Test Coverage is provided for Web Based Applications and to provide a secure, reliable application to the user the above factors need to be considered.

For internet based applications accessibility and security can be important issues.
On one hand Organizations would like to cater to their users around the world on the other hand they could end up exposing their security holes all over.

Testing could be the last chance to ensure the safety of the data and the organization.

Posted in Uncategorized | Comments Off on Challenges in Testing Web Based Applications


I rarely meet a tester that has never heard of the V-Model. It’s one of the parts of the software testing body of knowledge that every tester seems to know about, even if it is just by name. I’ve added a picture that summaries the model below (Source: Wikipedia).

I’ve seen the V-Model used in two different ways. One approach is to use the V-Model as an extension to a waterfall software development lifecycle, where the “V” is perform just once. The other approach is to use the V-Model as an extension to an iterative software development lifecycle where lots of mini-”V”s are performed, one per iteration.

Regardless of how you apply the V-Model (just once or iteratively) the prescribed sequence of testing levels on the right-and-side of the “V” (Unit Testing -> Integration Testing -> System Testing -> Acceptance Testing) can encourage a project to work in a way that may not be in their best interest. This is easiest to explain if we just look at two of the testing levels, System and Acceptance. I’ve added definitions (taken from the ISTQB Glossary) for each term below.

System Testing: The process of testing an integrated system to verify that it meets specified requirements.

Acceptance Testing: Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.

My own interpretation of these terms and how they relate to the V-Model is that a group of testers perform system testing to checks that the application doesn’t contain any bugs, before one or more users perform acceptance testing to check they like the application and it’s going to truly help them accomplish one or more tasks quicker, more accurately, with more confidence, etc.

This always sounds sensible to me until I remember how much time most people spend system testing, how much users love to change their mind and how changing anything tends to introduce more bugs and the need for more testing. In a fairly extreme example, but a team could write some software, system test it to make sure it’s free of bugs, get a group of users to acceptance test it, who ask for 95% of the system to be changed… And then we’re back to square one!

This would, of course, be much more of a tear-jerking moment if you had chosen only to follow the “V” once in a waterfall style, compared to if you were performing many mini-”V” in an iterative pattern. However, even with many mini-”V” the team could still have wasted precious time and money system testing something that will never see the light of day.

So here’s the Catch-22 with the V-Model… Nobody wants to put a buggy piece of software in front of their users, but who wants to spend precious time and money system testings a feature that may be changed or removed?

If you interpret the V-Model as all system testing must be completed before acceptance testing can be started then the project is likely to run into problems. Either the application will be changed and the tester may feel like their original work was for nothing, or the application will remain unchanged and the users may feel like they didn’t get the solution they wanted. Neither of which are good.

Like with many Catch-22 situations, a compromise can be found if the rules of the game are loosened. The problem stems for trying to complete system testing and gold-plating the application before allowing users to perform acceptance testing. This is never going to work as the team will always end up changing something (even if it’s just something small) which need to be system tested again.

For me, the solution is not to try to finish system testing before acceptance testing begins, but instead perform as much system testing as necessary (no more, no less) to be confident that the application is of sufficient quality to be acceptance tested by the user(s). Once the application is then stable in terms of its features and how those features are realised the team can then focus on completing any outstanding system testing necessary to be confident that the application is of sufficient quality to release.

This means that a team should get into the habit of thinking about two different thresholds when it comes to an application being fit-for-purpose. (1) Is it fit-for-acceptance testing, and then (2) Is it fit-for-release.

The V-model is a software development process which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.

The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase. Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time.



[edit]The Phases of the V-model

The V-model consists of a number of phases. The Verification Phases are on the left hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the right hand side of the V.

[edit]Verification Phases

[edit]Requirements analysis

In the Requirements analysis phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated.

The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase. See also Functional requirements, and Non-functional requirements

[edit]System Design

Systems design is the phase where system engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly.

The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.

[edit]Architecture Design

The phase of the design of computer architecture and software architecture can also be referred to as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, theirinterface relationships, dependenciesdatabase tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase.

[edit]Module Design

The module design phase can also be referred to as low-level design and low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudocode – database tables, with all elements, including their type and size – all interface details with complete API references- all dependency issues- error message listings- complete input and outputs for a module. The unit test design is developed in this stage.

[edit]Validation Phases

[edit]Unit Testing

In the V-model of software development, unit testing implies the first stage of dynamic testing process. According to software development expert Barry Boehm, a fault discovered and corrected in the unit testing phase is more than a hundred times cheaper than if it is done after delivery to the customer.

It involves analysis of the written code with the intention of eliminating errors. It also verifies that the codes are efficient and adheres to the adopted coding standards. Testing is usually white box. It is done using the Unit test design prepared during the module design phase. This may be carried out by software developers.

[edit]Integration Testing

In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components. Testing is usually black box as the code is not directly checked for errors.

[edit]System Testing

System testing will compare the system specifications against the actual system. The system test design is derived from the system design documents and is used in this phase. Sometimes system testing is automated using testing tools. Once all the modules are integrated several errors may arise. Testing done at this stage is called system testing.

[edit]User Acceptance Testing

Acceptance testing is the phase of testing used to determine whether a system satisfies the requirements specified in the requirements analysis phase. The acceptance test design is derived from the requirements document. The acceptance test phase is the phase used by the customer to determine whether to accept the system or not.

Posted in Uncategorized | Comments Off on V-Model

The Psychology of Testing!.doc

A software tester is any human being who tests the software. So, what do you answer if anybody asks you ‘Does software testing need a specialized skill’? It looks very simple to answer this question, isn’t it? But ofcourse not. Software Testing is not as easy as you might think of. Needless to say, It’s one of the most important and difficult tasks in the entire gamut of software development life cycle process.

Human beings reaction in this complex world of happenings varies widely with respect to situations, surroundings, emotions, need, requirements, time frame, money, visualization, belief, education, knowledge, expertise, intuition and so on. Such complex is the nature of human being and certainly there’s no exception at work place too. Therefore it’s cynical to say that the job being done (software testing) by a software tester is simple & complete.

Nevertheless, the quality of the job done by the software tester is directly proportional to his or her psychological maturity and profoundness acquired, adopted and developed with age and experience.

“The psychology of the persons carrying out the testing will have an impact on the testing process [Meyer 1979].”

Let’s examine the psychology of the person under discussion (tester) by describing the definition of software testing under three circumstances.

1. “Software testing is the process to prove that the software works correctly”

The above definition sounds good. If the person under discussion (software tester) is the one who has developed the software he/she will try to use the above definition. This person’s intentions would mostly revolve around the point to prove the software works. He/She will only give those inputs for which correct results are obtained.

This above explanation is the typical psychology of testing by a software developer.

2. “Testing is the process to prove that the software doesn’t work”

This definition sounds very good especially if the aim of the tester is to prove that the software doesn’t work for what it’s supposed to do. This type of psychology would bring out the most of the defects in the software. A software tester should therefore have such a psychology to push the software beyond its boundaries.

Nevertheless, this definition involves a practical difficulty � If you question “how many days does the software should be tested to conclude that the software works perfectly?”, perhaps the answer would again recur to be a question in itself.

It’s never a right conclusion to infer that there are no bugs in the software if one says that “the software has no bugs even after testing for more than a week or a month or an year” nor it is wise to say that the software is completely reliable.

Testing does not guarantee defect less or zero bug software at all times but can only reduce or minimize known defects because the very nature of a bug can be volatile. If the above definition is to be strictly implemented, then perhaps the most Operating Systems & other Commercial Software packages which we use today would not have been in the market yet. If so, then the above definition would seem to be unrealistic.

3. “Testing is the process to detect the defects and minimize the risks associated with the residual defects”

This definition appears to sound realistic. Practically, if at any point, the software product development starts, the testing process should start and keep in track the number of bugs being detected while correcting them.

At some stage of a planned testing, there would be a stage where no bugs are identified after many days or weeks or sometimes months of testing which statistically allows you to conclude that the software is “good enough” to be released into the market. i.e there may still exist some bugs undetected, but the risk associated with the residual defects is not very high or are tolerable.

The decision to release a software may thus vary based on many other factors like business value, time constraint, client requirements & satisfaction, company’s quality policies etc.

From the above three definitions, we can understand that the psychology of a software tester plays a vital role through out the software development cycle & the quality processes of software testing.

“The objective of testing is to uncover as many bugs as possible. The testing has to be done without any emotional attachment to the software. If someone points out the bugs, it is only to improve the quality of the software rather than to find fault with you.”

Role & Characteristics of a Software Tester

Software Development & Software Testing go hand in hand. Both aim at meeting the predefined requirements and purpose. Both are highly creative jobs in nature but the general outlook towards these two individuals is psychological rather than distinctive classification.

If success is perceived as achieving something constructive or creative, like the job of developing a software to work, software testing in contrast is perceived as destructive job or negative job by majority of the masses. Nevertheless, software testing itself has to be perceived as an equally creative job on par with the development job, but this perception can only be practically possible with a different outlook and mindset.

Software Testers require technical skills similar to their development counterparts, but software testers need to acquire other skills, as well.

Keen Observation

Detective Skills

Destructive Creativity

Understanding Product as integration of its parts

Customer Oriented Perspective

Cynical but Affable Attitude

Organized, Flexible & Patience at job

Objective & Neutral attitude

Keen Observation The software tester must possess the qualities of an ‘eye for detail’. A keen observation is the prime quality any software tester must possess. Not all bugs are visible clearly to the naked eye in a software. With keen observation, the tester can easily identify or detect many critical bugs. Observing the software for established parameters like ‘look & feel’ of GUI, incorrect data representation, user friendliness etc needs this type of characteristics.

Detective Skills Ideally the software under development would be documented before, after and throughout the development process. Unfortunately, there is every chance of not updating the documentation (specification, defect reports etc) due to time and resource constraints.

The software under testing would be completely described in a well defined set library of functions and design specifications in documents called specs or SRS etc. which needs constant update. The tester should therefore apply his knowledge of rationalization in knowing about the product from formal system like system specifications, design & functional specifications. From this information, the tester should look for researching more analytical information through other sources called non-formal sources of information like developers, support personnel, bugs and related product documents, reviews of related and (seemingly) unrelated documents.

A tester should therefore possess the quality of a ‘detective’ to explore the product under test, more rationally.

Destructive Creativity The Tester need to develop destructive skills � means skills to perturb and crash the software workflow and its functionality. In other words, the tester should ‘not hesitate to break the software’ fearing to buy it or being empathetic to the creation of developers. In software testing, boundaries are meant to be crossed not obeyed.

A creative oriented but destructive approach is necessary while testing a software by the tester to make the software evolve more robustly and reliably.

“The Software under test should be tested like a Mercedes-Benz car. ”

Understanding the Product as an integration of its parts The software(read as product) is a culmination of lines of code interacting with data through user interface and database.

It is an integration of separate group of code interacting with other groups assembled together to function as a whole product. The developers might be working on a respective piece of code module focusing more on those modules under work, at a time.

It is no wonder if the developer sometimes may not even know the complete workflow of the product and not necessary too. Where as, in the case of a tester, being the rider of the software under test, should understand and know about the complete specifications (operational and workflow requirements) of the product.

The tester may not be the best expert on any one module of the software but definitely he/she should gain expertise on the overall operation of the product. In fact, the tester should possess a ‘Systems’ view of the product because they are the only people to see and test the complete functionality of interdependent modules and compatibility between the software and hardware specifications laid down by the client before it is sent to the customer.

Customer Oriented Perspective Testers need to possess a customer oriented perspective. Customers (read as users) need not be as wise as software engineers or testers. As the number of computer users are growing every day (need not be as wise as engineers or testers), the end-users may neither be comfortable nor tolerate any bugs, explanations, or frequent upgrades to fix the bugs. As any customer would simply be interested in consuming the product (software) by deriving its value the software tester must adopt a customer oriented perspective while testing the software product.

Hence the tester must develop his abilities to suffice himself/herself in the place of the customer, testing the product as a mere end-user.

Cynical but Affable Attitude Irrespective of the nature of the project, the tester need to be tenacious in questioning even the smallest ambiguity until it is proved. In other words ,the tester must chant the words “In God we Trust- Everything Else gets Tested” throughout the testing cycle.

There may arise some situations during the course of testing � large number of bugs might be encountered unusually which might compel to further delay in shipping of the product. This may lead to heat up the relation between the testers and other development teams. The tester should balance this relationship not at the cost of the bugs but by convincing and upholding their intentions to “assault the software but not the software developers”.

Organized, Flexible and Patience at Job: Software testers must remember the fact that as the world is shrinking since the advent of internet and web, so, change is very dynamic and no exception for modern software. Not all the tests planned are performed completely and some tests dependent on other tests has to be blocked for later testing.

This needs an organized approach by the tester in attempting to phase out the bugs. Sometimes, significant tests has to be rerun which would change the fundamental functionality of the software. The tester should therefore have patience to retest the planned bugs and any new bugs that may arise.

It is even more important to the testers to be patient and keep prepared in the event of a dynamic development and test model. Development keeps changing continuously as requirements and technology keeps changing rapidly and so should testing. The testers must take these changes into account and plan to perform tests while maintaining the control of test environment to ensure valid test results.

Objective and Neutral Attitude Nobody would like to hear and believe bad news, right? Well, testers are sometimes viewed as messengers of bad news in a software project team. No wonder, how good the tester is (meaning very negative) and brilliant in doing his job (identifying bugs-no one likes to do it but most human beings are taken for granted to be naturally very good at it, at least from childhood), he/she might always be a messenger of communicating the bad part of the software, which, the creators (developers) doesn’t like it.

“Nobody who builds the houses likes to have them burned.”

The tester must be able to deal with the situation where he/she is blamed for doing his/her job (detecting bugs) too good. The tester’s jobs must be appreciated and the bugs should be welcomed by the development team because every potential bug found by the tester would mean a reduction of one bug that would potentially might have been encountered by the customer.

Irrespective of the negative aspects of doing such a highly skillful job, the role of a tester is to report honestly every known bug encountered in the product with always an objective and a neutral attitude.

Posted in Uncategorized | Leave a comment

10 steps to become QTP guru

10 steps to become QTP guru

Would you like to know how to become QTP guru?
The recipe is simple. You should learn the following:

  1. VBScript
    QTP uses VBScript language. That’s why strong knowledge of VBScript is ‘must have’.

  1. Software Testing Automation Frameworks
    To write good automated tests, you should know how to write them.
    There are different approaches and solution. There is not a silver bullet.

  1. HP QuickTest Professional Tutorial
    This QTP tutorial cames with QTP.
    It’s quite clean and informative. Its main goal is to show and explain basic concepts of QuickTest Professional. It provides knowledge on:

    • creating a test
    • working with Object Repository (OR)
    • running and analyzing tests
    • verifying tests
    • parameterizing, etc

Sources: ‘\help\QTTutorial.pdf’ or ‘\help\Tutorial.chm’ in QTP Install folder.

  1. HP QuickTest Professional User’s Guide
    As previous tutorial, the present User’s Guide come with QTP install too.
    This guide is intended for QuickTest Professional users at all levels. It gives a deeper knowledge on:

    • working with QTP Object Repositoies
    • designing tests
    • enhancing tests (checkpoints, parameterizing, etc)
    • maintaining anf debugging tests
    • advanced testing features, etc

Sources: ‘\help\QTUsersGuide.pdf’ or ‘\help\MainUsersGuide.chm’ in QTP Install folder.

  1. COM/DCOM Technologies
    When working with QTP, you will be closely linked with such Microsoft’s applications, as: Excel, Word, Outlook. So, I recommend to get familiar with COM, COM Technologies, and COM objects of:

  1. SQL
    SQL is so important in programming, that I strongly recommend to spend time to learn SQL:

    • concepts of RDBM
    • selecting/updating/deleting data
    • SQL queries optimizations
    • databases administration


  1. XML
    XML is an extremely popular and useful format. I’m sure that нou will have to deal with data, stored in XML-files.

  1. HTML, DOM
    Since QuickTest Professional works perfectly with web applications, you should be expert in related fields – HTML, HTTP, DHTML, DOM, etc. They will simplify your future QTP script and make them more reliable and maintenable.

  1. HP QTP Knowledge Base
    It contains a lot of practical articles about QuickTest Professional.
    You can find there QTP webinars, QTP FAQs, documentations, solutions of your problems or different ways how to improve your QTP automated tests.

  1. Useful sites
    Sure, it’s impossible to know all information on QTP.
    That’s why I recommend to use these two sites to search answers to your QTP questions:

Posted in 10 steps to become QTP guru | Tagged | Comments Off on 10 steps to become QTP guru

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

Posted in Uncategorized | 1 Comment