Dear Readers, Welcome to Win Runner Interview Questions and Answers have been designed specially to get you acquainted with the nature of questions you may encounter during your Job interview for the subject of Win Runner. These Win Runner Questions are very important for campus placement test and job interviews. As per my experience good interviewers hardly plan to ask any particular questions during your Job interview and these model questions are asked in the online technical test and interview of many IT companies.
Yes, I have been WinRunner for creating automates scripts for GUI, functional and regression testing of the AUT.
WinRunner testing process involves six main stages:
i. Create GUI Map File so that WinRunner can recognize the GUI objects in the application being tested
ii. Create test scripts by recording, programming, or a combination of both. While recording tests, insert checkpoints where you want to check the response of the application being tested.
iii. Debug Test: run tests in Debug mode to make sure they run smoothly
iv. Run Tests: run tests in Verify mode to test your application.
v. View Results: determines the success or failure of the tests.
vi. Report Defects: 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.
WinRunner stores information it learns about a window or object in a GUI Map. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same properties in the application being tested. Each of these objects in the GUI Map file will be having a logical name and a physical description. There are 2 types of GUI Map files.
i. Global GUI Map file: a single GUI Map file for the entire application
ii. GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.
WinRunner uses the GUI Map file to recognize objects on the application. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same properties in the application being tested.
Yes I have created test scripts. It contains the statement in Mercury Interactive’s Test Script Language (TSL). These statements appear as a test script in a test window. You can then enhance your recorded test script, either by typing in additional TSL functions and programming elements or by using WinRunner’s visual programming tool, the Function Generator.
Following each test run, WinRunner displays the results in a report. The report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. If mismatches are detected at checkpoints during the test run, you can view the expected results and the actual results from the Test Results window.
Yes, I have performed debugging of scripts. We can debug the script by executing the script in the debug mode. We can also debug script using the Step, Step Into, Step out functionalities provided by the WinRunner.
We run tests in Verify mode to test your application. Each time WinRunner encounters a checkpoint in the test script, it compares the current data of the application being tested to the expected data captured earlier. If any mismatches are found, WinRunner captures them as actual results.
Following each test run, WinRunner displays the results in a report. The report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. If mismatches are detected at checkpoints during the test run, you can view the expected results and the actual results from the Test Results window. 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.
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.
There are 2 modes of recording in WinRunner
• Context Sensitive recording records the operations you perform on your application by identifying Graphical User Interface (GUI) objects.
• Analog recording records keyboard input, mouse clicks, and the precise x- and y-coordinates traveled by the mouse pointer across the screen.
Checkpoints allow you to compare the current behavior of the application being tested to its behavior in an earlier version.
You can add four types of checkpoints to your test scripts:
1. GUI checkpoints verify information about GUI objects. For example, you can check that a button is enabled or see which item is selected in a list.
2. Bitmap checkpoints take a snapshot of a window or area of your application and compare this to an image captured in an earlier version.
3. Text checkpoints read text in GUI objects and in bitmaps and enable you to verify their contents.
4. Database checkpoints check the contents and the number of rows and columns of a result set, which is based on a query you create on your database.
5. How do you analyze test results in Winrunner tool and report the defects?
6. 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.
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 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.
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.
Add-Ins are used in WinRunner to load functions specific to the particular add-in to the memory. While creating a script only those functions in the add-in selected will be listed in the function generator and while executing the script only those functions in the loaded add-in will be executed else WinRunner will give an error message saying it does not recognize the function.
WinRunner fails to identify an object in a GUI due to various reasons.
1. The object is not a standard windows object.
2. If the browser used is not compatible with the WinRunner version, GUI Map Editor will not be able to learn any of the objects displayed in the browser window.
When you click an object, WinRunner assigns the object a logical name, which is usually the object’s text label. The logical name makes it easy for you to read the
test script. For example, when you selected the Order No. check box, WinRunner recorded the following statement in WinRunner TSL:
button_set (“Order No.”, ON);
“Order No.” is the object’s logical name.
An object’s logical name is determined by its class. In most cases, the logical name is the label that appears on an object.
If the object does not have a name then the logical name could be the attached text.
The GUI map is actually the sum of one or more GUI map files. There are two modes for organizing GUI map files.
i. Global GUI Map file: a single GUI Map file for the entire application
ii. GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.
GUI Map file is a file which contains the windows and the objects learned by the WinRunner with its logical name and their physical description.
WinRunner testing process involves six main stages
i. Create GUI Map File so that WinRunner can recognize the GUI objects in the application being tested
ii. Create test scripts by recording, programming, or a combination of both. While recording tests, insert checkpoints where you want to check the response of the application being tested.
iii. Debug Test: run tests in Debug mode to make sure they run smoothly
iv. Run Tests: run tests in Verify mode to test your application.
v. View Results: determines the success or failure of the tests.
vi. Report Defects: 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.
- WinRunner stores information it learns about a window or object in a GUI Map. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same properties in the application being tested. Each of these objects in the GUI Map file will be having a logical name and a physical description.
i. Global GUI Map file: a single GUI Map file for the entire application
ii. GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.
WinRunner uses the GUI Map file to recognize objects on the application. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same properties in the application being tested.
Yes I have created test scripts. It contains the statement in Mercury Interactive’s Test Script Language (TSL). These statements appear as a test script in a test window. You can then enhance your recorded test script, either by typing in additional TSL functions and programming elements or by using WinRunner’s visual programming tool, the Function Generator.
Following each test run, WinRunner displays the results in a report. The report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. If mismatches are detected at checkpoints during the test run, you can view the expected results and the actual results from the Test Results window.
Yes, I have performed debugging of scripts. We can debug the script by executing the script in the debug mode. We can also debug script using the Step, Step Into, Step out functionalities provided by the WinRunner.
We run tests in Verify mode to test your application. Each time WinRunner encounters a checkpoint in the test script, it compares the current data of the application being tested to the expected data captured earlier. If any mismatches are found, WinRunner captures them as actual results.
If they say it was in a mercury class, ask if they can show you their certificate of completion. If they say no, let them know you will verify it with Mercury.
If they answer “yes”, ask them what was in it and how they got WR to execute the start-up script when WR is invoked.
They should answer something like this, “In the start-up script, we loaded all the gui maps for the application, any library files we needed, and any custom
gui object mapping we have to do. We also loaded global variables and system variables here. The startup script location is added to the WR .ini file,
wrun.ini located under the windows or winnt directory as wrun.ini”.
They should mention some of these things:
1. A function goes into a “compiled module”, a script does not.
2. A function follows strict “c” syntax. For instance, you have to declare all variables created and used in the function. In a script you do not.
When would you use “set_window” and when would you use “win_activate”?
win_activate has the format win_activate(window);. The win_activate function makes the specified window the active window by bringing it into focus and
raising it to the top of the display. (It is the equivalent to clicking on the window banner)
Set_window has the following format: set_window(window,[time]);
The set_window function directs input to the correct application window. This directs the GUI map to this window. It also sets the scope for object
identification in the GUI map.
The most important difference is that set_window has a timing option.
WinRunner will wait a maximum of the number used in the function, PLUS the system set timeout, to wait for the window to appear. Win_activate assumes the
window is already on the desktop and has no timing option.
Basics of WinRunner:
“WinRunner handles automation test scripts TestDirector manages test scripts, defects and test plan”
“Test Script Language, TSL C++”