Explore topic-wise InterviewSolutions in .

The steps INVOLVED in data driven testing are:

1.  CREATING a test
2.  Converting to a data-driven test and preparing a database
3.  Running the test
4.  ANALYZING the test RESULTS.

The steps involved in data driven testing are:

Limitations of WINRUNNER in testing:

1. It should not SUPPORT Dot net applications.
2. It should not support XML.
3. It should not support Multimedia.

Limitations of winrunner in testing:

You can use the Data Driver Wizard to CONVERT your entire SCRIPT or a part of your script into a data-driven test. For example, your test script may include recorded operations, CHECKPOINTS, and other STATEMENTS that do not need to be repeated for multiple sets of data.

You can use the Data Driver Wizard to convert your entire script or a part of your script into a data-driven test. For example, your test script may include recorded operations, checkpoints, and other statements that do not need to be repeated for multiple sets of data.

The dos_system function EXECUTES a DOS system command from WITHIN a WinRunner TEST script.

dos_system (expression);

The dos_system function executes a DOS system command from within a WinRunner test script.

dos_system (expression);

Yes you can TEST As400 applications USING Winrunner. I have used it for REGRESSION TESTING.

Yes you can test As400 applications using Winrunner. I have used it for regression testing.

Wait : It is a general STATEMENT used to wait till the TIME is elapsed(wait(X)) --> x is the amount of time winrunner stops execution of the next statement against the default timeout of the winrunner between statement executions.
Synchronization: an advanced form of wait that wait for the properties to be enabled or disabled etc. used mostly in order to avoid timing PROBLEMS.

Wait : It is a general statement used to wait till the time is elapsed(wait(x)) --> x is the amount of time winrunner stops execution of the next statement against the default timeout of the winrunner between statement executions.
Synchronization: an advanced form of wait that wait for the properties to be enabled or disabled etc. used mostly in order to avoid timing problems.

When we load a GUI MAP file, the information about the windows and the objects with their logical names and PHYSICAL description are LOADED into memory. So when the WinRunner executes a script on a particular WINDOW, it can identify the objects USING this information loaded in the memory.

When we load a GUI Map file, the information about the windows and the objects with their logical names and physical description are loaded into memory. So when the WinRunner executes a script on a particular window, it can identify the objects using this information loaded in the memory.

db_connect();
It is a database checkpoint FUNCTION, which is used to connect a specified database.
Syntax: db_connect(FILENAME, DSN connection);
db_connect("msqr1","DSN=Flight32");
Here, msqr1 is the filename that has been CREATED by you, during writing the sql query and Flight32 is the database on which you are working.

db_connect();
It is a database checkpoint function, which is used to connect a specified database.
Syntax: db_connect(filename, DSN connection);
db_connect("msqr1","DSN=Flight32");
Here, msqr1 is the filename that has been created by you, during writing the sql query and Flight32 is the database on which you are working.

You can go for Winrunner 7.5 because compare to other functional testing TOOLS this is BIT CHEAP.

You can go for Winrunner 7.5 because compare to other functional testing tools this is bit cheap.

The ADVANTAGE of toggle break point is to identify the flaws (faults) in the Winrunner script during the debugging mode, the meaning toggle means "hold ONTO".
By setting the break points in the script one can stop( suspend ) the TEST run at a specified place in the test script to inspect the state of the APPLICATION under test.

The advantage of toggle break point is to identify the flaws (faults) in the Winrunner script during the debugging mode, the meaning toggle means "hold onto".
By setting the break points in the script one can stop( suspend ) the test run at a specified place in the test script to inspect the state of the application under test.

QUICKTEST enables you to call WinRunner-based scripts, user-defined functions, and their parameters. You may access Call to WinRunner utility by selecting Insert > Call to WinRunner > and select either Call to WinRunner Test or Call to WinRunner Function from QTP tool bar.You may use Step Generator > Utility OBJECTS and select appropriate method Alternatively, you can use QTP TSLTest OBJECT and its RunTestEx and RunFuncEx methods to call WinRunner scripts.

QuickTest enables you to call WinRunner-based scripts, user-defined functions, and their parameters. You may access Call to WinRunner utility by selecting Insert > Call to WinRunner > and select either Call to WinRunner Test or Call to WinRunner Function from QTP tool bar.You may use Step Generator > Utility Objects and select appropriate method Alternatively, you can use QTP TSLTest object and its RunTestEx and RunFuncEx methods to call WinRunner scripts.

1. win runner support .NET applications(QTP supports.net)
2. Audio and video moving objects applications (MULTIMEDIA).
3. we need to install approiated add in to test the APPLICATION. For example (we need to have web adding to test web application) java adding for TESTING java applications.

The major purpose of the data driven test is to test the application with different types of inputs which helps us in avoiding HECTIC and repetitive work that one should do in manual, which is time consuming task.

If you want to know the ALTERNATIVE, in a for loop or any other loop that you are comfortable with, USE create_input_dialog command and take the value every time from the user and then PASS the value to the function.

The major purpose of the data driven test is to test the application with different types of inputs which helps us in avoiding hectic and repetitive work that one should do in manual, which is time consuming task.

If you want to know the alternative, in a for loop or any other loop that you are comfortable with, use create_input_dialog command and take the value every time from the user and then pass the value to the function.

Object Repository:
It is a storage place which is used for storing the objects information and it also ACTS as an INTERFACE between the test script and APPLICATION in order to identify the objects while execution or during execution.

Object Spy:
It is a handy feature Provided by QTP to display the complete object information like METHODS, properties, syntax for methods, description of methods of both text and RUNTIME objects then and there immediately.

Object Repository:
It is a storage place which is used for storing the objects information and it also acts as an interface between the test script and application in order to identify the objects while execution or during execution.

Object Spy:
It is a handy feature Provided by QTP to display the complete object information like methods, properties, syntax for methods, description of methods of both text and runtime objects then and there immediately.

To connect to the database by using Winrunner SCRIPT is, at first we have to find out the DSN NAME

db_connect ("session name","data source name");
db_execute_query("session name","query",COUNT);
generate for loop for(i=1;i<=count;i++)
db_get_row("session name",variable);
printf(variable);
db_disconnect("session name");
Through this script we can connect to the database and also we can FETCH the records.

To connect to the database by using Winrunner script is, at first we have to find out the DSN name

db_connect ("session name","data source name");
db_execute_query("session name","query",count);
generate for loop for(i=1;i<=count;i++)
db_get_row("session name",variable);
printf(variable);
db_disconnect("session name");
Through this script we can connect to the database and also we can fetch the records.

• auto: An auto variable can be declared only within a FUNCTION and is local to that function. It exists only for as long as the function is running. A new copy of the variable is created each time the function is called.
•  STATIC: A static variable is local to the function, test, or compiled module in which it is declared. The variable retains its value until the test is TERMINATED by an ABORT COMMAND. This variable is initialized each time the definition of the function is executed.
•  public: A public variable can be declared only within a test or module, and is available for all functions, tests, and compiled modules.
•  extern: An extern declaration indicates a reference to a public variable declared outside of the current test or module.

The batch mode will use when we need continuous execution of the SCRIPTS without break if any ERRORS in the SCRIPT even THOUGH its CONTINUE the execution and at last the errors will display in the report.

The batch mode will use when we need continuous execution of the scripts without break if any errors in the script even though its continue the execution and at last the errors will display in the report.

Database Checkpoints:
When you create database checkpoints, you define a query on your database, and your database CHECKPOINT checks the values CONTAINED in the result set. The result set is a set of values RETRIEVED from the results of the query.
There are several ways to define the query that will be used in your database checkpoints:

•  You can use Microsoft Query to create a query on a database. The results of a query on a database are known as a result set. You can INSTALL Microsoft Query from the custom installation of Microsoft Office.
•  You can define an ODBC query manually, by creating its SQL statement.
•  You can use Data JUNCTION to create a conversion file that converts a database to a target text file. (For standard database checkpoints only). Note that Data Junction is not automatically included in your WinRunner package.

There are 4 DB checkpoints:

1. Runtime DB Checkpoint
2. Default Checkpoint
3. Custom Check
4. Standard Check

Database Checkpoints:
When you create database checkpoints, you define a query on your database, and your database checkpoint checks the values contained in the result set. The result set is a set of values retrieved from the results of the query.
There are several ways to define the query that will be used in your database checkpoints:

There are 4 DB checkpoints:

To define a virtual object using the Virtual Object wizard:

1.  Choose Tools > Virtual Object Wizard. The Virtual Object wizard opens. Click Next.
2.  In the Class list, select a class for the new virtual object. If rows that are displayed in the window. For a table class, select the number of visible rows and columns. Click Next.
3.  Click Mark Object. Use the crosshairs pointer to select the area of the virtual object. You can use the ARROW keys to MAKE precise adjustments to the area you define with the crosshairs. Press Enter or click the right MOUSE button to display the virtual objects coordinates in the wizard. If the object MARKED is visible on the screen, you can click the Highlight button to view it. Click Next.
4.  Assign a logical name to the virtual object. This is the name that appears in the test script when you record on the virtual object. If the object contains text that WinRunner can read, the wizard suggests using this text for the logical name. Otherwise, WinRunner suggests virtual_object, virtual_push_button, virtual_list, etc.
5.  You can ACCEPT the wizards suggestion or type in a different name. WinRunner checks that there are no other objects in the GUI map with the same name before confirming your choice. Click Next.

To define a virtual object using the Virtual Object wizard:

YES we can TEST windows calculator through winrunner. Here below follow the navigation Steps:

1. Open WinRunner
2. open calculator, Make to WinRunner to see calculator.
3. Click on create menu and select Record-Context Sensitive and do your OPERATIONS on calculator.
4. Click on create menu and select Stop RECORDING.
5. Click on Run Menu and select Run from TOP

yes we can test windows calculator through winrunner. Here below follow the navigation Steps:

Regular Expression is NORMALLY used for the handled the run time changing object in the application.
The Data Driver wizard finds all fixed values in selected checkpoints and recorded statements, but it does not CHECK for things such as object LABELS that also may VARY based on EXTERNAL input.

Regular Expression is normally used for the handled the run time changing object in the application.
The Data Driver wizard finds all fixed values in selected checkpoints and recorded statements, but it does not check for things such as object labels that also may vary based on external input.

Using the GUI Spy, you can VIEW the PROPERTIES of any GUI object on your desktop. You use the Spy pointer to point to an object, and the GUI Spy displays the properties and their values in the GUI Spy DIALOG BOX. You can choose to view all the properties of an object, or only the selected SET of properties that WinRunner learns.

Using the GUI Spy, you can view the properties of any GUI object on your desktop. You use the Spy pointer to point to an object, and the GUI Spy displays the properties and their values in the GUI Spy dialog box. You can choose to view all the properties of an object, or only the selected set of properties that WinRunner learns.

Disadvantages are :

1. cannot USE CHECK POINTS
2. cannot use Sync Points
3. Non EXECUTABLE

Disadvantages are :

This statement passes control BACK to the calling function or TEST. It ALSO returns the value of the evaluated expression to the calling function or test. If no expression is assigned to the return statement, an empty string is RETURNED.
Syntax: return [( expression )];

This statement passes control back to the calling function or test. It also returns the value of the evaluated expression to the calling function or test. If no expression is assigned to the return statement, an empty string is returned.
Syntax: return [( expression )];

The test script NAME in the Startup Test box in the ENVIRONMENT tab in the GENERAL Options DIALOG box is the start up file in WinRunner.

The test script name in the Startup Test box in the Environment tab in the General Options dialog box is the start up file in WinRunner.

The checklist FILE CONTAINS information about the objects and the properties of the object we are verifying.
The gui*.CHK file contains the expected results which is STORED in the exp folder.

The checklist file contains information about the objects and the properties of the object we are verifying.
The gui*.chk file contains the expected results which is stored in the exp folder.

The DIFFERENCE between bitmaps option in the Run Tab of the GENERAL OPTIONS defines the minimum number of pixels that constitute a BITMAP mismatch.

The difference between bitmaps option in the Run Tab of the general options defines the minimum number of pixels that constitute a bitmap mismatch.

The GUI MAP Editor is been provided with a Find and Show Buttons.

To find a particular OBJECT in the GUI Map file in the application, select the object and click the Show WINDOW. This blinks the selected object.

To find a particular object in a GUI Map file click the Find button, which GIVES the option to select the object When the object is selected, if the object has been LEARNED to the GUI Map file it will be focused in the GUI Map file.

The GUI Map Editor is been provided with a Find and Show Buttons.

To find a particular object in the GUI Map file in the application, select the object and click the Show window. This blinks the selected object.

To find a particular object in a GUI Map file click the Find button, which gives the option to select the object When the object is selected, if the object has been learned to the GUI Map file it will be focused in the GUI Map file.

Boundary tests are designed to check a program’s response to extreme input values. Extreme output values are generated by the input values. It is important to check that a program handles input values and output results correctly at the lower and UPPER boundaries. KEEP in mind that you can CREATE extreme boundary results from non-extreme input values. It is essential to analyze how to generate extremes of both types. In addition sometime you know that there is an intermediate variable involved in processing. If so, it is useful to DETERMINE how to drive that ONE through the extremes and special conditions such as zero or overflow condition.

Boundary tests are designed to check a program’s response to extreme input values. Extreme output values are generated by the input values. It is important to check that a program handles input values and output results correctly at the lower and upper boundaries. Keep in mind that you can create extreme boundary results from non-extreme input values. It is essential to analyze how to generate extremes of both types. In addition sometime you know that there is an intermediate variable involved in processing. If so, it is useful to determine how to drive that one through the extremes and special conditions such as zero or overflow condition.

MSW_Id’s will CONTINUE to change as long as your developers are modifying your application. Having dealt with this, I determined that each MSW_Id shifted by the same amount and I was able to modify the entries in the GUI map rather easily and continue testing.

INSTEAD of using the MSW_id use the “location”. If you use your GUI spy it will GIVE you every detail it can. Then add or remove what you don’t want.

MSW_Id’s will continue to change as long as your developers are modifying your application. Having dealt with this, I determined that each MSW_Id shifted by the same amount and I was able to modify the entries in the gui map rather easily and continue testing.

Instead of using the MSW_id use the “location”. If you use your GUI spy it will give you every detail it can. Then add or remove what you don’t want.

You could try embedding it in an if statement. If/when it fails use a t1_step statement to indicate massage and then do a EXIT to LEAVE the TEST. ANOTHER idea would be to use win_get text or web_frame_get_text to capture the text of the OBJECT and the do a comparison (using the match function) to determine it’s existance.

You could try embedding it in an if statement. If/when it fails use a t1_step statement to indicate massage and then do a exit to leave the test. Another idea would be to use win_get text or web_frame_get_text to capture the text of the object and the do a comparison (using the match function) to determine it’s existance.

ANSWER : FUNCTION writelog(in strMessage){
file_open(”C:\FILEPATH\...”);
file_printf(strMessage);
PRINTF(strMessage);
}

Answer : set_window(” Browser Main Window”, 1);
text="",
start = get_time();
while(text!=”DONE”)
{
statusbar_get_text("STATUS Bar”,O,text);
now = get_time();
if( (now-start) == 60)
# SPECIFY no of SECONDS after which you want
break
{
break;
}
}

Need to VALIDATE text fields against

1. Null
2. Not Null
3. whether it allows any SPECIAL Characters.
4. whether it allows numeric contents.
5. Maximum length of the field etc.

From the requirements find Out what the behaviour of the text field in question should be. Things you need to know are: what should HAPPEN if field left blank what special characters are allowedvis it an alpha, numeric or ALPHANUMERIC field etc.

Write manual tests for doing what you want. This will create a structure to form the basis of your WR tests.

Now create your WR scripts. I suggest that you use data driven tests and use EXCEL spreadsheets for your inputs instead of having user input. For example the following structure will test whether the text field will accept special characters

Need to validate text fields against

From the requirements find Out what the behaviour of the text field in question should be. Things you need to know are: what should happen if field left blank what special characters are allowedvis it an alpha, numeric or alphanumeric field etc.

Write manual tests for doing what you want. This will create a structure to form the basis of your WR tests.

Now create your WR scripts. I suggest that you use data driven tests and use Excel spreadsheets for your inputs instead of having user input. For example the following structure will test whether the text field will accept special characters

You can USE the

function “text” variable CONTAINS the status bar STATEMENT.
or

link the NAME of the link.
x,y the x- and y-coordinates of the mouse pointer when moved to a link, relative to the upper left CORNER of the link.

You can use the

function “text” variable contains the status bar statement.
or

link the name of the link.
x,y the x- and y-coordinates of the mouse pointer when moved to a link, relative to the upper left corner of the link.

Do Not use BitMap or GUI CHECKPOINTS for DYNAMIC VERIFICATION. These checkpoints are PURELY for static verifications. There are ofcourse, work-arounds, but mostly not worth the effort.

Do Not use BitMap or GUI Checkpoints for dynamic verification. These checkpoints are purely for static verifications. There are ofcourse, work-arounds, but mostly not worth the effort.

ANSWER : set_window(“Name of the window”);
obj_check_info("Name of the OBJECT“,“FOCUSED”,Out_value)

Check for out_value &AMP; proceed further.

Check for out_value & proceed further.

If WR is not LEARNING sub-items then the easy way id to add manually those sub items in to GUI map. Of course you need to STUDY the menu DESCRIPTION and always add the PARENT menu name for that particular sub-menu.

If WR is not learning sub-items then the easy way id to add manually those sub items in to GUI map. Of course you need to study the menu description and always add the PARENT menu name for that particular sub-menu.

Actually, you can have scripts that run for DIFFERENT locales.I have a set of scripts that run for Japanese as well as English locales. Idea is to have objects recorded in GUI Map with a locale independent physical description. This can be achieved in two ways.

• After recording the object in the GUI Map, INSPECT the description and ENSURE that no language specific properties are used. For ex: html_name property for an object of class: HTML text link could be based on the text. You can either remove these language dependent properties if it doesnt really affect your object recognition. If it does affect, you need to find another property for the object that is locale independent. This new property may be something thats already there or you need to create them, This leads to the next option.
• Have developers assign a locale independent property like ‘objname’ or something to all objects that you use in your automated scripts. Now, modify your GUI Map description for the particular object to look for this property INSTEAD of the standard locale dependent properties recorded by WR (these default properties are in GUI Map Configuration).

Actually, you can have scripts that run for different locales.I have a set of scripts that run for Japanese as well as English locales. Idea is to have objects recorded in GUI Map with a locale independent physical description. This can be achieved in two ways.

1. Use get-time to get the PC system time in seconds since 01/01/1970
2. Subtract 86400 (no seconds in a DAY) from it.
3. Use time_str to convert the result into a date format.
4. If format of returned date is not CORRECT use STRING manipulations to get the format you require.
5. INSERT the date into your application.

Alternatively you could try the following:

1. In an Excel datasheet create a column with an appropriate name, and in the first cell of the column use the excel formula 'today() - 1'.
2. Format the cell to give you the required date format.
3. Use the ddt- functions to read the date from the excel datasheet.
4. insert the received date into your application.

Alternatively you could try the following:

USE get_screen_res(X,y) to GET the SCREEN RESOLUTION in WR7.5.

or

Use get_resolution (Vert_Pix_int, Horz_Pix_int, Frequency_int) in WR7.01

Use get_screen_res(x,y) to get the screen resolution in WR7.5.

or

Use get_resolution (Vert_Pix_int, Horz_Pix_int, Frequency_int) in WR7.01

It's easy, just take the DESCRIPTION straight out of the GUI map squigglies and all, put it into a variable (or pass it as a string) and use that in place of the OBJECT name.

becomes

It's easy, just take the description straight out of the GUI map squigglies and all, put it into a variable (or pass it as a string) and use that in place of the object name.

becomes

WinRunner provides three modes in which to RUN tests: Verify, Debug, and Update. You use each MODE during a different phase of the TESTING process.

Verify
Use the Verify mode to check your APPLICATION.

Debug
Use the Debug mode to help you identify bugs in a test script.

Update
Use the Update mode to update the expected results of a test or to create a NEW expected results folder.

WinRunner provides three modes in which to run tests: Verify, Debug, and Update. You use each mode during a different phase of the testing process.

Verify
Use the Verify mode to check your application.

Debug
Use the Debug mode to help you identify bugs in a test script.

Update
Use the Update mode to update the expected results of a test or to create a new expected results folder.

WinRunner USES exception handling to detect an unexpected event when it occurs and act to recover the TEST run.

WinRunner enables you to handle the following types of exceptions:

• Pop-up exceptions: Instruct WinRunner to detect and handle the appearance of a specific window.
• TSL exceptions: Instruct WinRunner to detect and handle TSL functions that return a specific ERROR code.
• Object exceptions: Instruct WinRunner to detect and handle a change in a PROPERTY for a specific GUI object.
• Web exceptions: When the WebTest add-in is loaded, you can instruct WinRunner to handle unexpected events and errors that occur in your web site during a test run.

WinRunner uses exception handling to detect an unexpected event when it occurs and act to recover the test run.

WinRunner enables you to handle the following types of exceptions:

A pop-up EXCEPTION Handler handles the pop-up messages that COME up during the execution of the script in the AUT. TO handle this type of exception we make WinRunner learn the window and also specify a handler to the exception. It could be Default ACTIONS; Win Runner clicks the OK or Cancel button in the pop-up window, or presses Enter on the keyboard. To select a default handler, click the appropriate button in the dialog box.

User-DEFINED handler:If you prefer, specify the NAME of your own handler. Click User Defined Function Name and type in a name in the User Defined Function Name box.

A pop-up exception Handler handles the pop-up messages that come up during the execution of the script in the AUT. TO handle this type of exception we make WinRunner learn the window and also specify a handler to the exception. It could be Default actions; Win Runner clicks the OK or Cancel button in the pop-up window, or presses Enter on the keyboard. To select a default handler, click the appropriate button in the dialog box.

User-defined handler:If you prefer, specify the name of your own handler. Click User Defined Function Name and type in a name in the User Defined Function Name box.

Suppose you are running a batch test on an UNSTABLE version of your APPLICATION. If your application crashes, you want WinRunner to recover test execution. A TSL exception can instruct WinRunner to recover test execution by exiting the current test, restarting the application, and continuing with the next test in the batch.

The handler function is responsible for recovering test execution. When WinRunner detects a specific error code, it calls the handler function. You IMPLEMENT this function to respond to the unexpected error in the WAY that meets your specific testing needs.

Suppose you are running a batch test on an unstable version of your application. If your application crashes, you want WinRunner to recover test execution. A TSL exception can instruct WinRunner to recover test execution by exiting the current test, restarting the application, and continuing with the next test in the batch.

The handler function is responsible for recovering test execution. When WinRunner detects a specific error code, it calls the handler function. You implement this function to respond to the unexpected error in the way that meets your specific testing needs.

TWO type of recording in WinRunner.
1. Context Sensitive recording records the operations you PERFORM on your application by IDENTIFYING Graphical User Interface (GUI) objects. Winrunner identifies all the objects in your window you click like menus, windows, lists, buttons and the type of operation you perform such as enable, move, select etc.
2. Analog recording records keyboard input, MOUSE clicks, and the precise x- and y-coordinates traveled by the mouse pointer across the screen i.e Winrunner records exact co-ordinates traveled by mouse.

Two type of recording in WinRunner.
1. Context Sensitive recording records the operations you perform on your application by identifying Graphical User Interface (GUI) objects. Winrunner identifies all the objects in your window you click like menus, windows, lists, buttons and the type of operation you perform such as enable, move, select etc.
2. Analog recording records keyboard input, mouse clicks, and the precise x- and y-coordinates traveled by the mouse pointer across the screen i.e Winrunner records exact co-ordinates traveled by mouse.

When you work in WinRunner and CREATE any test script you have option to save it directly to Test DIRECTOR test repository. Or while creating a test case in the TestDirector we can specify whether the script in automated or manual. And if it is automated script then TestDirector will build a skeleton for the script like TSL(Test Script language) of winrunner that can be later modified into one which COULD be USED to test the application.

When you work in WinRunner and create any test script you have option to save it directly to Test Director test repository. Or while creating a test case in the TestDirector we can specify whether the script in automated or manual. And if it is automated script then TestDirector will build a skeleton for the script like TSL(Test Script language) of winrunner that can be later modified into one which could be used to test the application.

TESTDIRECTOR is Mercury Interactive’s software test management tool. It helps quality assurance personnel plan and organize the testing process. With TestDirector you can create a database of manual and automated tests, BUILD test CYCLES, run tests, and REPORT and track defects. You can also create reports and graphs to help review the progress of planning tests, running tests, and tracking defects before a software RELEASE.

TestDirector is Mercury Interactive’s software test management tool. It helps quality assurance personnel plan and organize the testing process. With TestDirector you can create a database of manual and automated tests, build test cycles, run tests, and report and track defects. You can also create reports and graphs to help review the progress of planning tests, running tests, and tracking defects before a software release.

When you finish any test in WinRunner, WinRunner displays the results in a report format. The report logs the general INFORMATION about the test run I.e date, operator mode and TOTAL run time. Also the report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. MISMATCH can be found in the report panel by seeing the actual result and the expected result. If a test run fails due to a defect in the application being TESTED, you can report information about the defect directly from the Test Results window. This information is SENT via e-mail to the quality assurance manager, who tracks the defect until it is fixed.

When you finish any test in WinRunner, WinRunner displays the results in a report format. The report logs the general information about the test run I.e date, operator mode and total run time. Also the report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. Mismatch can be found in the report panel by seeing the actual result and the expected result. If a test run fails due to a defect in the application being tested, you can report information about the defect directly from the Test Results window. This information is sent via e-mail to the quality assurance manager, who tracks the defect until it is fixed.