Automation Testing

Difference Between Smoke Testing and Sanity Testing

2008-07-01T09:47:00.000-07:00

There are two types of test types, Smoke and Sanity. What they are exactly? Here we go.....The general definition (related to Hardware) of Smoke Testing is: Smoke testing is a safe harmless procedure of blowing smoke into parts of the sewer and drain lines to detect sources of unwanted leaks and sources of sewer odors.It is related to s/w, the definition is Smoke testing is non-exhaustive software testing, ascertaining that the most crucial functions of a program work, but not bothering with finer details. Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc. Smoke Testing and Sanity Testing In greater details... Smoke Test: When a build is received, a smoke test is run to ascertain if the build is stable and it can be considered for further testing. Smoke testing can be done for testing the stability of any interim build. Smoke testing can be executed for platform qualification tests. Sanity testing: Once a new build is obtained with minor revisions, instead of doing a through regression, sanity is performed so as to ascertain the build has indeed rectified the issues and no further issue has been introduced by the fixes. Its generally a subset of regression testing and a group of test cases are executed that are related with the changes made to the app.Generally, when multiple cycles of testing are executed, sanity testing may be done during the later cycles after through regression cycles. Difference between Smoke Testing and Sanity Testing:
· Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested. A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep.
· A smoke test is scripted--either using a written set of tests or an automated test. A sanity test is usually unscripted.
· A Smoke test is designed to touch every part of the application in a cursory way. It's is shallow and wide. A Sanity test is used to determine a small section of the application is still working after a minor change.
· Smoke testing will be conducted to ensure whether the most crucial functions of a program work, but not bothering with finer details. (Such as build verification). Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing.
· Smoke testing is normal health check up to a build of an application before taking it to testing in depth. Sanity testing is to verify whether requirements are met or not, checking all features breadth-first.

Simple VB Script to check if Application is already running

2008-06-16T09:24:00.000-07:00

There are certain situations where you can't run two instances of same application OR before starting a test with QTP, you want out find out whether a particular process is already running. Ex: In case of Siebel Automation . To find the process, the workflow is, Go to "Windows Task Manager"[Ctrl-Shift-Esc] > Process tab > strain your eyes to sift the required process from the 100's of already running processes.
We can do this job with a simple VBScript. This will reduce the duration of workflow to < 2 sec and you get the result instantly at the click of a button.

Code:
Dim AllProcess
Dim Process
Dim strFoundProcess
strFoundProcess = False
Set AllProcess = getobject("winmgmts:") 'create object
For Each Process In AllProcess.InstancesOf("Win32_process") 'Get all the processes running in your PC
If (Instr (Ucase(Process.Name),"TASKMGR.EXE") = 1) Then 'Made all uppercase to remove ambiguity. Replace TASKMGR.EXE with your application name in CAPS.
msgbox "Application is already running!" 'You can replace this with Reporter.ReportEvent
strFoundProcess = True
Exit for
End If
Next
If strFoundProcess = False Then
msgbox "Go ahead!Application is not running" 'You can replace this with Reporter.ReportEvent
End If
Set AllProcess = nothing

To check whether this is working:
1) Copy the above code to a notepad and save file as test.vbs on your desktop.
2) Open the Windows Task Manager[Ctrl-Shift-Esc].
3) Double click on file created above(test.vbs)
4) You should get a message "Application is already running!"
5) Done...Enjoy!

QTP with windows vista

2008-04-30T02:33:00.000-07:00

QuickTest Professional 9.2:
QuickTest Professional 9.2 supports Windows Vista 32-bit Edition.Working with Windows Vista:* The security settings in Microsoft Windows Vista may prevent you from performing a QuickTest Professional-related installation, such as a patch installation, or connecting to a Quality Center project (either directly or from QuickTest Professional). This can occur when the User Account Control (UAC) option in Windows Vista is set to ON, and you have not yet connected to a Quality Center project (if relevant).Workaround: To work with Quality Center, temporarily turn off the User Account Control (UAC) option, as follows:1. Log in to Windows Vista as an administrator.2. From the Control Panel, choose User Accounts > Change Security Settings.3. Clear the Use User Account Control (UAC) to help protect your computer check box and click OK.4. Connect to Quality Center as usual. After connecting to Quality Center, you can turn the User Account Control (UAC) option on again. Hereafter, you should be able to connect to Quality Center, as needed.* Due to a problem opening DCOM permissions on Windows Vista, QuickTest does not run properly on a remote Windows Vista host from Quality Center.Workaround: Run RmtAgentFix.exe from the \bin folder.* On Windows Vista, QuickTest Professional seat licenses may not work correctly if you are not logged on as an administrator. (Note that concurrent licenses work as usual.)Workaround: On Windows Vista, install QuickTest Professional and any QuickTest add-ins as an administrator. To do this, right-click setup.exe from the root folder of the QuickTest Professional installation CD and choose Run as administrator.Then, every time you open QuickTest, open it as an administrator. To do this, right-click the QuickTest Professional icon on your desktop and choose Run as administrator.* On Windows Vista 32-bit, QuickTest Professional text recognition features (such as text checkpoints and output values, GetVisibleText and GetTextLocation test object methods, and TextUtil.GetText and TextUtil.GetTextLocation reserved object methods) are limited and are not always reliable.Workaround: On Windows Vista, you can improve text recognition by applying the Classic Windows theme and by setting the mode key in the Windows Registry Editor to 3 - OCR only (described above).* When using the Mercury Screen Recorder on Windows Vista, setting the Window's display settings to the Classic Windows theme may improve performance.* Record and run session performance may be affected adversely when using the Mercury Screen Recorder on a computer running Windows Vista 32-bit or any 64-bit operating system. This is because some capture drivers (such as Blueberry or ASUS' Enhanced Display Driver) cannot be installed on these operating systems. Note that if you try to install the capture driver from the Screen Recorder Options dialog box while working on one of these operating systems, an error message is displayed.
QuickTest Professional 9.1:
QuickTest Professional 9.1 supports 'Windows Vista Beta 2-build 5384'.Working with Windows Vista:* When installing QuickTest Professional on Windows Vista Beta 2, the QuickTest icon is not installed on your desktop or in the Start menu. (A default icon is installed instead.)Work-around: Modify the icon manually.* QuickTest Professional does not support the recording of operations on the Start menu of Windows Vista Beta 2.* The security settings in Windows Vista Beta 2 may prevent you from connecting to a Quality Center project (either directly or from QuickTest Professional). This can occur when the User Account Control (UAC) option in Windows Vista is set to ON, and you have not yet connected to a Quality Center project.Work-around: To work with Quality Center, temporarily turn off the User Account Control (UAC) option, as follows:1. Log in to Windows Vista as an administrator.2. From the Control Panel, choose User Accounts -> Change Security Settings.3. Clear the Use User Account Control (UAC) to help protect your computer check box and click OK.4. Connect to Quality Center as usual. After connecting to Quality Center, you can turn the User Account Control (UAC) option on again. Hereafter, you should be able to connect to Quality Center, as needed.* When working with Internet Explorer 7.0 Beta 3, QuickTest Professional may not recognize Web objects, even though the Web Add-in is installed and loaded.Work-around: In Internet Explorer 7.0 Beta 3, choose Tools -> Internet Options. In the Security tab, clear the Enable Protected Mode check box and click OK.* Due to a problem opening DCOM permissions on Windows Vista Beta 2, QuickTest does not run properly on a remote Windows Vista Beta 2 host from Quality Center.Work-around: Run RmtAgentFix.exe from the \bin folder.
QuickTest Professional 9.0 and below:
QuickTest Professional 9.0 (and below) does not support Windows Vista.

QTP and File Handling

2008-04-21T09:34:00.000-07:00

Many a times you may need to interact with text files using QTP. Interaction can be(but not limited to) in the form of reading input from a file, writing output to a file. This post describe in detail "File handling using QTP".
We use FSO object to do this.
What is FSO?
FSO stands for File System Object. This is used to support text file creation and manipulation through the TextStream object and is contained in the Scripting type library (Scrrun.dll)
The FSO Object Model has a rich set of properties, methods and events to process folders and files.
How to create a file?
We first create a FSO object using CreateObject and then create a text file using CreateTextFile.
For Example: Suppose you want to create a file called "test.txt" located in C:
Dim fso, file, file_location
file_location = "C:\file_location"
Set fso = CreateObject(“Scripting.FileSystemObject”)
Set file = fso.CreateTextFile(file_location, True) // True--> file is to be overwritten if it already exists else false
We would use the same example for the rest of this post.
How to open a file?
Set file= fso.OpenTextFile("C:\file_location", ForWriting, True)
//2nd argument can be ForReading, ForWriting, ForAppending
//3rd argument is "True" if new file has to be created if the specified file doesn’t exist else false, blank signify false.
How to read content from a file?
Use ReadLine() method
For example:
Set file= fso.OpenTextFile("C:\file_location", ForReading, True) //2nd argument should always be "ForReading" in order to read contents from a file
Do while file.AtEndofStream <> True
data = file.ReadLine()
msgbox data
Loop
How to write content to a file?
You can use Write() or WriteLine() Methods to write text into a file. The difference between the Write() and WriteLine() Method is that the latter automatically inserts a new line character while the former doesn’t insert a new line character.
For example:
Set file= fso.OpenTextFile("C:\file_location", ForWriting, True) //2nd argument should always be "ForWriting" in order to write contents to a file
file.Write("This is a place to get all your qtp")
file.Write("questions and answers solved.")
//Output will be:
This is a place to get all your qtp questions and answers solved.
while
file.WriteLine("This is a place to get all your qtp")
file.Write("questions and answers solved.")
//Output will be:
This is a place to get all your qtp
questions and answers solved.
How to delete content?
Use DeleteFile() method to delete a file from a particular location
Foe Example:
file_location = "C:\file_location"
Set fso = CreateObject(“Scripting.FileSystemObject”)
fso.DeleteFile(file_location)

QTP FAQs

2008-03-28T10:57:00.000-07:00

Explain the need to use analog recording in qtp?
This mode records exact mouse and Key Board operations you perform in relation to the screen /Application Window. This mode is useful for the operation which you can record at Object Level, such as drawing a picture, recording signature. The steps recorded using Analog Mode is saved in separated data file, Quick Tests add to your Test a Run Analog File statement that calls the recorded analog File. This file is stored with your action in which these Analog Steps are created. The Step recorded in Analog mode can not be edited within QT.

how to execute qtp script from command prompt?
You need to create a vbs file... then create a batch file....that's it
i think this is possible by the using CScript.exe "filename" in the command prompt.

how do we record a pop up window in QTP
we can record a pop up window through Recovery Management

I am facing one problem in my .net qtp application.In one page My script has to select order menu item from Add dropdown menu ex:Add->order.There is a bug in the page which opens up a pop up dialog box saying \
Hi Your question is not very clear ?What do u mean by "Add dropdown box" ? is that a combo box ? what exactly u want ?Kaps

How to make QTP to recognise the activeX controls
In the Expert View, you can use the Object property to activate the method for an ActiveX control. The list of available methods depends on the ActiveX control.
QuickTest records and runs steps on ActiveX controls as it does on any other object. Using the Insert>Step Option , we can activate ActiveX control methods, retrieve and set the values of properties and check the object exists. It is recommended that to begin recording session before opening the application containing the ActiveX controls on which you want to record.

what is keyword driventest ?
Keyword driven test has been introduced in QTP 8.0. Its like tree view.

How you write scripts in QTP? What's the main proc...
Main process in QTP is Recording, stores the properties in object repository then Running the script and then Test Results. Recording: QTP 'looks' at the object on which we are recording and stores it as a test object, determining in which test object class it fits like standard window dialog box or web button etc. Then for each test object class, QTP has list of mandatory properties that it always learns. When we record an object, QTP learns these default property values, and then 'looks' at the rest of the objects in the page , to distinguish and identify the object uniquely.If not it adds assistive properties , one ny one, to the description, until it has compiled a unique description.If no assistive properties are not available , it adds a special 'ordinal identifier' such as objects location on the screen.Running the scripts: While running the script, QTP searches for a run time object that exactly matches the description of the test object it learned while recording. If it is not matching, QTP uses ' smart identification' mechanism to identify the object.
What is the command in QTP to invoke IE Brow?
InvokeApplication "The path of the browser EXE file"
The following example uses the InvokeApplication function to open Internet Explorer.
InvokeApplication "E:\Program Files\Plus!\Microsoft Internet\IEXPLORE.EXE"
SystemUtil.Run "iexplore"
Well SystemUtil.Run "iexplorer.exe","","","" command can be used for this purpose. The other alternative can be choose the menu item record from Test --> Record which opens up a Run and record settings dialog , Choose web tab from that dialog . Select the radio button "Open the following browser when a record/run session begins" Type the required URL to be opened in address field of the dialog and click ok This open the required url in the browser every time in the run/record sessions
I am going to tell you all one another way of invoking IE.
Set IE1=CreateObject("InternetExplorer.Application")IE1.visible=TrueSet IE1=nothing

To invoke the IE browser we can use- Systemutil.Run"C:\Program Files\Internet Explorer\IExplore.exe"
The above statement would take you to the about:blank webpage where you navigate to the URL required
SystemUtil.Run"C:\Program Files\Internet Explorer\IExplore.exe"
The above statement would take you to the about:blank webpage and you can navigate to any URL as required.

I am new to QTP, please tell me how.. I am new to QTP, please tell me how to invoke an application in QTP. Forexample: In winrunner we use syntax's like "web_url_valid, web_browser_invoke", like the same way i want in QTP. Else please let me know where can i find these syntaxs in QTP..
Use SytemUtil Object's Run Method ex:SystemUtil.Run "iexplore" will open the IE Browser.
How would u manipulate the script so that when the...
External datatable can be used for the login name so that it takes a new login name whenever the test is run.

How would u manipulate the script so that when the...
You can parameterize the values in the Gobal data table sheet, whatever the number of rows you enter in this data table will instruct QuickTest to run same number of new login name you've enter.

The answer is very easy .you need to do only parameterize the login window object in object repository and there you need to specify datatable parameter name or else qtp specify default papramter name

How can i add a action (external action) programatically?
if action is reusable then only u can call only in other test with "runaction" command and in folder option u hv to gv information regarding test from where u r takin action.u can do it programatically also.
You can add an external Action programatically using the Command RunAction ActionName, [IterationMode , IterationRange] Before you can use the RunAction statement in the Expert View for an external action, you must first call or copy the external action into your test by choosing Insert > Copy of Action or Call to Action. If the external action does not exist in your test, the RunAction statement is not recognized. Example
The following example calls the SearchFlight action, and runs all iterations of the action. Call RunAction "SearchFlight", rngIterations, rngAll
How can i call a external action which is not added external action of an action. Means I want to call ActionC from ActionA. but ActionC is not an exteranl action of ActionA.
Yes u can do it by copying the Action c to Action A...In QTP 8.2 there is an menu called insert-Copy of Action...

what is meant by SOURCE CONTROL ?
It is used to hold all the bulids of diff versions

how and what kind of Vb functions do u use in qtp?...
You can use all kinds of VBScript functionalities...and also VBAYou can use The following functions
Asc Function====,CBool Function===,CByte Function===,CCur Function===,CDate Function===,CDbl Function===,,Chr Function===,,CInt Function===,,CLng Function, CSng Function, CLng Function CSng Function, CStr Function, Hex Function, Oct Function===etc
ther r 2 types of functions in QTP 1.User Defined 2.Pre defined
how can u discribe the basic flow of automation with conditional and programatic logic?
I think ur Question is Executing of operators flow in the automation code if the question is that then my answer is For example Z = 78 * (96 + 3 +45)
There are five operators in this expression: =, *, (), +, and another +. According to the rules of operator precedence, they are evaluated in the following order: (), +, +, *, =.
Evaluation of the expression within the parentheses occurs first. Within the parentheses, there are two addition operators. Since the addition operators both have the same precedence, they are evaluated from left to right. 96 and 3 are added together first, then 45 is added to this total, resulting in a value of 144.
Multiplication occurs next. 78 is multiplied by 144, resulting in a value of 11232.
Assignment occurs last. 11232 is assigned to z.

How to recall a function in QTP
Assume that U are calling a funtion in QTP Script, & if u want to recall that same fuction in some other part of the same script..... What would u do ?
There also u follow the same procedure. See the sample code
Function addition(x,y) z= x+y msgbox zEnd Function
Call addition(1,2)Call addition(2,2)
Give one example where you have used Regular Expression
for the date format "dd/mm/yyyy" the equivalent regular expression would be
Set regExp_Term = New RegExpregExp_Term.pattern = "11/11/1981"validation=regExp_Term.test("date to be validated")
if validation="True" Then
-----------------
End If
We can use Regular Expression where ever required, like in my Web Testing, my browser name changes oftnely, so I used Regular expression in Name property like... Set Browser= (Title:=Browser.*)
generaly regular expressions r used when the data is dynamically changing .for example take a flights application in the QTP samples. we can use regular expression for the Date field ,FaxOrder no,etc
How can I implement error handling in QTP, I know with Recovery Mangaer but how please give me detailed execution to how to handle giving an example?
By Using Recovery Scenario MAnager it has the following things1.Trigger Event 1.Pop-Up Window 2.Object State 3.TestRun Error 4.Application Crash2.Recovery Operation 1.Keyboard/mouse input 2.Function Call 3. 4.Restart Windows3.Post Recovary Operation4.Scenario Nameuse the Scenario Name in Resourcesmay this infor is helpful to u.
Record the 7 test objects (dropdown boxs) and there will be many 70 properties ( and their associated bvalues) Drop Down Box 1

If you have the same application screen with 7 dro...
record the 7 test objects and parameterize them with the 70 values either by using data table option if all 70 has to be executed or by choosing random variable option if it needs to be cjhecked by random values

When there is a task that gets repeated in multiple scripts, what do you do in QTP?

Split the action related to that task, make it Reusable & then call that Action as many times as needed.

How to instruct QTP to display errors and ther description in the test results instead of halting execution by throwing error in the mid of execution due to an error(for example Object not found)?
Use Recovery senarios to accomplish that.
Use Exception Handling technique of QTP: can be achieved by any one of the following two methods:1. Using Recovery Scenario Manager2. scripting by using :if-else-then OR Select Case

I have the same problem. However, My issue deals with waiting for an object. I'm not a programmer. How can I manipulate the Wait function to wait without me having to specify the seconds. For instance in Rational Functional Tester, I used to use wait.untilExistence.
Make use of Reporter.Reportevent eg.
var=statement
if var="True" Then
Reporter.Reportevent 0,"Step Name","Description of the Passed step"
else
Reporter.Reportevent 1,"Step Name","Description for the failed step"
End If
I hope thats it :)
How you write scripts in qtp?what's the main process in qtp?How do you run scripts in Qtp?Please anyone can answer my questions.......
In Qtp we have to use script language Vb-script.
mainly QTP hepls us to test .net applications & we have more check points also we have automatic recovery manager
We can scripts in VB ,Java Script,Visual Studio n etc..
Key Word Driven Approach
There is an RUN command button...
How to add run-time parameter to a datasheet?
HI use the following code Datatable..addparameter ,
example, datatable.localsheet.addparameter "Col1","Column" hope this will work
Try using this line of code. DataTable("Col Name",dtGlobalSheet/LocalSheet)="Col Value"
The only disadvantage with tihs code is, u will be able to see the parameter till the script is running, once stopped the parameter will vanish from the data table.
1. enter the data in data sheet(global/action).2.right click on actionbutton it showing all possible codition.
3. choose run all Iteration row by row. in Qtp8.2 just choose optiones and run
how to load the *.vbs or test generating script in a new machine?
You can use the any one of the following two methods:1. goto : Tools --->settings --->Resources and add the .vbs file2. in the QTP script u can write : Dim App 'As ApplicationSet App = CreateObject("QuickTest.Application")App.LaunchApp.Test.Settings.Resources.Libraries.Add("")
Execute File statement can be included as part of the test script inorder to execute the vbs files.

how can u write a script without using a GUI in QTP?
GUI in Qtp?do you mean to say Object repository?without OR,tester need to write descriptive tests,where you would directly assign property values and write methods.you do not need to save OR.
by descriptive programming

Using BRD ans functional and Design docs we Build the test scripts,which should be able to find the deffects on AUT at the time of Test Run

QTP provides the Active Screen Technology i.e it will take snapshots of the Application when u r going thru' the appl. by using the snapshots u can able to write the script for that particular appl.

Can we update the database though Qtp.
Ofcourse u can if u have authority to do so.
set ObjConn=CreateObject("ADODB.Connection")
set ObjRec=CreateObject("ADODB.Recordset")
ObjConn.open "DriverName","UserId","Password","Server"
set ObjRec.activeConnection=ObjConn
ObjRec.source="SQL Query"
ObjRec.open
yes u can but it will be done thru scripting.

I am using the QTPlus Repositories Merge Utility to merge all my different repositories into a single one. After having merged some repositories, I notice that, from the test, you can't see the web objects that were merged into the reposotory.If you open the merged repository in the Merge Utility, the web objects appear there.Has anyone encountered this problem? Am I missing something obvious? Does anyone have a solution?
Merge Utility have a lot of problems, try don't use this for file biggest the 8 MB
What is the procedure to test flash applications using QTP?
By using multimedia plug in we can test animation or flash applications
QuickTest supports Macromedia Flash 4 or 5 objects that are ActiveX controls in Internet Explorer. You can also test Macromedia Flash 6 clips containing Flash 4 or 5 commands
You can use the test object methods and properties associated with the FlashControl object to test Flash objects in your multimedia application.
how to fetch test data from Database by using QTP
right click ont he database table. sheet->import->database create the connection write the sql
how to handle java tree in QTP
first of all we need to have a java add-in to handle a java tree.In tools option we have the "object identification" drop down list.There we have the java option to recognise the objects there select the tree option.Add the properties to be recognised.Then the QTP will start recognising the tree.
If not use the DOM to detect the tree.Here select code from the back ground and manipulate accordingly
what if storage limit of shared object repository exceeds its limit(2 MB).how this kind of situation can be handled?
One can use advanced object repository Editor from Sirus SQA
how many types of recording modes in QTP?describe each type with an example where we use them?
There are three types of recording modes available in QuickTest Pro.1.Normal mode2.Analog mode3.Low-level recording modeNormal mode: This is the default mode of recording in QTP ,Object and the Operation associated/performed with Object can be recorded.This mode takes full advantage of QuickTest's test object model,recognizing the objects in AUT regardless of their location on the screen.Analog mode:This mode records exact mouse and keyboard operations you perform in relation to the screen / application window.This mode is useful for the operation which you can record at object level,such as drawing a picture,recording signature.the steps recoded using Analog mode are saved in seperate data-file,Quick tests adds to your test a Run Analog file statement that calls the recorded Analog file.This file is stored with your action in which these Analog steps are created.The steps recorded in Analog mode can not be edited within QuickTest.Low-level recording mode:enables you to record any object or operation in your AUT whether or not QuickTest recognizes the it.This Low-level recording is useful when the exact location of an Object/operation in your AUT is important for your test.This mode records in terms of X,Y co-ordinates.Unlike in Analog mode,the steps can be seen in Test script,as well in Keyword view.
What is the file extension of the code file & object repository file in QTP?

.vbs is the extension of the code file, for object repository file the extension is .tsr , The code file extension: script.MTS ,

File extension of -- Per test object rep :- filename.mtr ,-- Shared Oject rep :- filename.tsr ,Code file extension id script.mts
User Defined Libary File Extension -- .VBS
QTP Script File Extension -- .MTS
Object Repository File Extension -- .TSR
Test Batch Runner File Extension -- MTB
QTP Recovery Scenarion File Extension -- QRS
I want to open a Notepad window without recording a test and I do not want to use SystemUtil.Run command as well How do I do this?
U can still make the notepad open without using the record or System utility script, just by mentioning the path of the notepad "( i.e., where the notepad.exe is stored in the system) in the "Windows Applications Tab" of the "Record and Run Settings window. Try it out. All the Best.
1. insert->step->step generator->select a function invokeapplication,mention the path to notepad.exe file.
Run. 2.otherwise in Expert view write a builtin function invokeapplication"c:/whatever the path" Run
Another alternative to open a notepad is to use ShellObject. Check out with the following example:
Dim aSet a = WScript.CreateObject ("WSCript.shell")a.run "notepad.exe"
How many types of Actions are there in QTP?
There are three kinds of actions: non-reusable action—an action that can be called only in the test with which it is stored, and can be called only once. reusable action—an action that can be called multiple times by the test with which it is stored (the local test) as well as by other tests. external action—a reusable action stored with another test. External actions are read-only in the calling test, but you can choose to use a local, editable copy of the Data Table information for the external action
How to do the scripting. Is there any inbuilt functions in QTP as in QTP-S. Whatz the difference between them? how to handle script issues?
Yes, there's an in-built functionality called "Step Generator" in Insert->Step->Step Generator -F7, which will generate the scripts as u enter the appropriate steps.
Explain the concept of object repository & how QTP recognises objects?
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 Ordianl identifier such as objects location onthe page or in the source code.
How do you data drive an external spreadsheet?
Import from External Spreadsheet File by selecting Import then From File . Which imports a tabbed text file or a single sheet from an existing Microsoft Excel file into the table. The sheet you import replaces all data in the currently selected sheet of the table, and the first row in the Excel sheet replaces the column headers in the corresponding Data Table sheet. It is therefore essential that the first row of your Microsoft Excel sheet exactly matches the parameter names in your test.
If it is a Database instead of Spreadsheet by selecting Import then From Database. It imports data from the specified database to the current sheet
Can anyone please let me know how exactly we record the script n use external datatable...i got from Anna's answer that we need to use import from file...but can anyone please let me know how to start and go about recording..and calling xls data table..
IF we use batch testing.the result shown for last action only.in that how can i get result for every action.
u can click on the icon in the tree view to view the result of every action
How to handle the exceptions using recovery secnario manager in Qtp?
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
There are 4 trigger events during which a recovery scenario should be activated. They are A pop up window appears in an opened application during the test run. A property of an object changes its state or value. A step in the test does not run successfully. An open application fails during the test run. These triggers are considered as exceptions and more details regarding how to use Recovery Manager is given in the QTP User Guide. Since there is hardly any space to put up snapshots
What are the Features & Benefits of Quick Test Pro(QTP)..?
1. Key word driven testing 2. Suitable for both client server and web based application 3. Vb script as the scriot language 4. Better error handling mechanism 5. Excellent data driven testing features
1.how to handle the exceptions using recovery secnario manager in Qtp? 2.what is the use of Text output value in Qtp?
QTp has got so many benefits compared to Winrunner.It enables evn an inexperienced tester to work with as it is GUI based.Major advantages it has are active screen which allows user to insert cheskpoints when the application is closed,testers job is made simple with different features it has,debug viewer where in we can see wht values variables carry when the test is running,and many features made simple
check point means inserting code to verify something existing in the application or not. output value means getting some information from the application and plasing in the output datatable(internal excel sheet). you can see the output data by opening the results file after the script execution. example: suppose if u want to check some text "QTP" existing in your application or not use checkpoint. suppose if you want get some text "QTP" from your application and to place that in some file use output values.
qtp is mainly used for functionality testing.qtp is user friendly both technical and non technical users can easily access.qtp has two views keyword view and expert view in keyword view when u record a test it genarates the script in tree format.it is very easy to understand.if u want to view the vbScript use the expert view. qtp has active screen using that u can enhance the script with out navigating to the application.like u can insert checkpoints and synchonization points. qtp has automated documentation.when u start recording it genarates the autodocumentation in plain english. using qtp we can parametarize objects,checkpoints,datadriventables.this will give more flexibility
QuickTest Pro offers a “Tree View” which is an icon-based view of the script. This is very easy to get used to and non-technical people adapt to it quicker and feel more comfortable working with it. For the technical user, they can always switch over to the “Expert View” in QuickTest and look directly at code, and program away using VBScript.
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 QuickTe
What are the different scripting languages you could use when working with QTP ?
Visual Basic (VB),XML,JavaScript,Java,HTML
How do you test siebel application using qtp?
This answer is relevant to Siebel 7.7, and QTP 8.0. To test Siebel using QTP, you will need two components.
1. The Siebel Addin from Mercury for QTP (install this on the system with QTP on it).
2. The Test Automation Framework license keys from Siebel (install the license key on the Siebel server).
Now you will need to enable the automation API on the Siebel server. To do this,
The [SWE] section of the server .cfg file needs to be updated with the entries below
In SWE section u need to add
AutomationEnable = TRUE and
at the same time you need to use SWECmd= AutoOn in the URL
How the exception handling can be done using QTP
It can be done Using the Recovery Scenario Manager which provides a wizard that gudies you through the process of defining a recovery scenario. FYI.. The wizard could be accesed in QTP> Tools-> Recovery Scenario Manager .......

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
What is the difference between check point and output value.
Check point is a verification point that compares a current value for a specified property with the expected value for that property. An outPut value is a value captured during the test run and entered in the run-time

I would like to add some stuff to Kalpana's comments. It is as follows:- An outPut value is a value captured during the test run and entered in the run-time but to a specified location. EX:-Location in Data Table[Global sheet / local sheet]

additional comment on Above comment:An output value is a value retrieved during the runsession and entered into runtime table or data table subsequently it can be used as input value in your test.
What are the properties you would use for identifying a browser & page when using descriptive programming ?
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"")..... We can also use the property "micClass". ex: Browser("micClass:=browser").page("micClass:=page")....
For Browser : Name For Page : Title
Differentiate the two Object Repository Types of QTP.
Object repository is used to store all the objects in the application being tested.2 types of oject repositoy per action and shared. In shared repository only one centralised repository for all the tests. where as in per action.for each test a separate per action repostory is created.

In Qtp there are 2 object repositories, they are1.Shared Object Repository2.Per Action Mode,by default it's per action mode.we will use shared OR for calling a particular action,it's like calling external libraries.we will use per action for a particular action ie, for one action only.
Explain the concept of how QTP identifies object.
During recording qtp looks at the object and stores it as test object.For each test object QT learns a set of default properties called mandatory properties,and look at the rest of the objects to check whether this properties are enough to uniquely identify the object. During test run,QT searches for the run time obkects that matches with the test object it learned while recording.

QTP uses the Object Repository file to recognize objects on the application. When QTP runs a action, it uses the Object Repository to locate objects. It reads an object’s description in the Object Repository and then looks for an object with the same properties in the application being tested
What is the difference between Call to Action and Copy Action.?
Call to Action : The changes made in Call to Action , will be reflected in the orginal action( from where the script is called).But where as in Copy Action , the changes made in the script ,will not effect the original script(Action)

when u insert a call to action,they r read only in the calling test.It can be modified in the original test.where as come to copy action,you can make changes to the copied action,your changes will not effect the original action where it created
have you ever written a compiled module? If yes tell me about some of the functions that you wrote.
in qtp the compiled modules are called library files .so write different files in a file extention with .vbs and call this in qtp test scipt file
Few basic questions on commonly used Excel VBA functions
common functions are: Coloring the cell Auto fit cell setting navigation from link in one cell to other saving

Explain the keyword createobject with an example
Creates and returns a reference to an Automation object syntax: CreateObject(servername.typename [, location]) Arguments servername:Required. The name of the application providing the object. typename : Required. The type or class of the object to create. location : Optional. The name of the network server where the object is to be created.
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). ex: set oDesc= createobject(Excel.application) odesc.activeworksheet=1
Createobject:Creates and returns a reference to an Automation object.Example:Dim ExcelSheetSet ExcelSheet = CreateObject("Excel.Sheet")
How to use the Object spy in QTP 8.0 version?
There are two ways to Spy the objects in QTP 1) Thru file toolbar ---In the File ToolBar click on the last toolbar button (an icon showing a person with hat). 2) Tru Object repository Dialog ---In Objectrepository 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 minimised then Hold the Ctrl button and activate the required window to and release the Ctrl button. 1. How Does Run time data (Parameterization) is handled in QTP? A) You can then enter test data into the Data Table, an integrated spreadsheet with the full functionality of Excel, to manipulate data sets and create multiple test iterations, without programming, to expand test case coverage. Data can be typed in or imported from databases, spreadsheets, or text files. 2) What is keyword view and Expert view in QTP? A) QuickTest’s Keyword Driven approach, test automation experts have full access to the underlying test and object properties, via an integrated scripting and debugging environment that is round-trip synchronized with the Keyword View. Advanced testers can view and edit their tests in the Expert View, which reveals the underlying industry-standard VBScript that QuickTest Professional automatically generates. Any changes made in the Expert View are automatically synchronized with the Keyword View. 3) Explain about the Test Fusion Report of QTP ? A) Once a tester has run a test, a TestFusion report displays all aspects of the test run: a high-level results overview, an expandable Tree View of the test specifying exactly where application failures occurred, the test data used, application screen shots for every step that highlight any discrepancies, and detailed explanations of each checkpoint pass and failure. By combining TestFusion reports with QuickTest Professional, you can share reports across an entire QA and development team. 4) To which environments does QTP supports ? A) QuickTest Professional supports functional testing of all enterprise environments, including Windows, Web, ..NET, Java/J2EE, SAP, Siebel, Oracle, PeopleSoft, Visual Basic, ActiveX, mainframe terminal emulators, and Web services. 5) What is QTP ? A) QuickTest is a graphical interface record-playback automation tool. It is able to work with any web, java or windows client application. Quick Test enables you to test standard web objects and ActiveX controls. In addition to these environments, QuickTest Professional also enables you to test Java applets and applications and multimedia objects on Applications as well as standard Windows applications, Visual Basic 6 applications and .NET framework applications...
6) Explain QTP Testing process ? A) The QuickTest testing process consists of 6 main phases: Create your test plan Prior to automating there should be a detailed description of the test including the exact steps to follow, data to be input, and all items to be verified by the test. The verification information should include both data validations and existence or state verifications of objects in the application. Recording a session on your application As you navigate through your application, QuickTest graphically displays each step you perform in the form of a collapsible icon-based test tree. A step is any user action that causes or makes a change in your site, such as clicking a link or image, or entering data in a form. Enhancing your test Inserting checkpoints into your test lets you search for a specific value of a page, object or text string, which helps you identify whether or not your application is functioning correctly. NOTE: Checkpoints can be added to a test as you record it or after the fact via the Active Screen. It is much easier and faster to add the checkpoints during the recording process. Broadening the scope of your test by replacing fixed values with parameters lets you check how your application performs the same operations with multiple sets of data. Adding logic and conditional statements to your test enables you to add sophisticated checks to your test. Debugging your test If changes were made to the script, you need to debug it to check that it operates smoothly and without interruption. Running your test on a new version of your application You run a test to check the behavior of your application. While running, QuickTest connects to your application and performs each step in your test. Analyzing the test results You examine the test results to pinpoint defects in your application. Reporting defects As you encounter failures in the application when analyzing test results, you will create defect reports in Defect Reporting Tool. 7) Explain the QTP Tool interface. A) It contains the following key elements: Title bar, displaying the name of the currently open test Menu bar, displaying menus of QuickTest commands File toolbar, containing buttons to assist you in managing tests Test toolbar, containing buttons used while creating and maintaining tests Debug toolbar, containing buttons used while debugging tests. Note: The Debug toolbar is not displayed when you open QuickTest for the first time. You can display the Debug toolbar by choosing View > Toolbars > Debug. Note that this tutorial does not describe how to debug a test. For additional information, refer to the QuickTest Professional User's Guide. Action toolbar, containing buttons and a list of actions, enabling you to view the details of an individual action or the entire test flow. Note: The Action toolbar is not displayed when you open QuickTest for the first time. You can display the Action toolbar by choosing View > Toolbars > Action. If you insert a reusable or external action in a test, the Action toolbar is displayed automatically. For additional information, refer to the QuickTest Professional User's Guide. Test pane, containing two tabs to view your test-the Tree View and the Expert View Test Details pane, containing the Active Screen Data Table, containing two tabs, Global and Action, to assist you in parameterizing your test Debug Viewer pane, containing three tabs to assist you in debugging your test-Watch Expressions, Variables, and Command. (The Debug Viewer pane can be opened only when a test run pauses at a breakpoint.) Status bar, displaying the status of the test
8) How QTP recognizes Objects in AUT? A) QuickTest stores the definitions for application objects in a file called the Object Repository. As you record your test, QuickTest will add an entry for each item you interact with. Each Object Repository entry will be identified by a logical name (determined automatically by QuickTest), and will contain a set of properties (type, name, etc) that uniquely identify each object. Each line in the QuickTest script will contain a reference to the object that you interacted with, a call to the appropriate method (set, click, check) and any parameters for that method (such as the value for a call to the set method). The references to objects in the script will all be identified by the logical name, rather than any physical, descriptive properties. 9) What are the types of Object Repositorys in QTP? A) QuickTest has two types of object repositories for storing object information: shared object repositories and action object repositories. You can choose which type of object repository you want to use as the default type for new tests, and you can change the default as necessary for each new test. The object repository per-action mode is the default setting. In this mode, QuickTest automatically creates an object repository file for each action in your test so that you can create and run tests without creating, choosing, or modifying object repository files. However, if you do modify values in an action object repository, your changes do not have any effect on other actions. Therefore, if the same test object exists in more than one action and you modify an object's property values in one action, you may need to make the same change in every action (and any test) containing the object. 10) Explain the check points in QTP? A) . A checkpoint verifies that expected information is displayed in a Application while the test is running. You can add eight types of checkpoints to your test for standard web objects using QTP. A page checkpoint checks the characteristics of a Application A text checkpoint checks that a text string is displayed in the appropriate place on a Application. An object checkpoint (Standard) checks the values of an object on a Application. An image checkpoint checks the values of an image on a Application. A table checkpoint checks information within a table on a Application An Accessiblity checkpoint checks the web page for Section 508 compliance. An XML checkpoint checks the contents of individual XML data files or XML documents that are part of your Web application. A database checkpoint checks the contents of databases accessed by your web site 11) In how many ways we can add check points to an application using QTP. A) We can add checkpoints while recording the application or we can add after recording is completed using Active screen (Note : To perform the second one The Active screen must be enabled while recording). 12) How does QTP identifes the object in the application A) QTP identifies the object in the application by LogicalName and Class. For example : The Edit box is identified by Logical Name : PSOPTIONS_BSE_TIME20 Class: WebEdit 13) If an application name is changes frequently i.e while recording it has name “Window1” and then while running its “Windows2” in this case how does QTP handles? A) QTP handles those situations using “Regular Expressions”. 14) What is Parameterizing Tests? A) When you test your application, you may want to check how it performs the same operations with multiple sets of data. For example, suppose you want to check how your application responds to ten separate sets of data. You could record ten separate tests, each with its own set of data. Alternatively, you can create a parameterized test that runs ten times: each time the test runs, it uses a different set of data. 15) What is test object model in QTP ? A) The test object model is a large set of object types or classes that QuickTest uses to represent the objects in your application. Each test object class has a list of properties that can uniquely identify objects of that class and a set of relevant methods that QuickTest can record for it. A test object is an object that QuickTest creates in the test or component to represent the actual object in your application. QuickTest stores information about the object that will help it identify and check the object during the run session. A run-time object is the actual object in your Web site or application on which methods are performed during the run session. When you perform an operation on your application while recording, QuickTest: ➤ identifies the QuickTest test object class that represents the object on which you performed the operation and creates the appropriate test object ➤ reads the current value of the object’s properties in your application and stores the list of properties and values with the test object ➤ chooses a unique name for the object, generally using the value of one of its prominent properties ➤ records the operation that you performed on the object using the appropriate QuickTest test object method For example, suppose you click on a Find button with the following HTML source code: QuickTest identifies the object that you clicked as a WebButton test object. It creates a WebButton object with the name Find, and records the following properties and values for the Find WebButton: It also records that you performed a Click method on the WebButton. QuickTest displays your step in the Keyword View like this: QuickTest displays your step in the Expert View like this: Browser("Mercury Interactive").Page("Mercury Interactive"). WebButton("Find").Click 16) What is Object Spy in QTP? A) Using the Object Spy, you can view the properties of any object in an open application. You use the Object Spy pointer to point to an object. The Object Spy displays the selected object’s hierarchy tree and its properties and values in the Properties tab of the Object Spy dialog box. 17) What is the Diff between Image check-point and Bit map Check point? A) Image checkpoints enable you to check the properties of a Web image. You can check an area of a Web page or application as a bitmap. While creating a test or component, you specify the area you want to check by selecting an object. You can check an entire object or any area within an object. QuickTest captures the specified object as a bitmap, and inserts a checkpoint in the test or component. You can also choose to save only the selected area of the object with your test or component in order to save disk Space For example, suppose you have a Web site that can display a map of a city the user specifies. The map has control keys for zooming. You can record the new map that is displayed after one click on the control key that zooms in the map. Using the bitmap checkpoint, you can check that the map zooms in correctly. You can create bitmap checkpoints for all supported testing environments (as long as the appropriate add-ins are loaded). Note: The results of bitmap checkpoints may be affected by factors such as operating system, screen resolution, and color settings. 18) How many ways we can parameterize data in QTP ? A) There are four types of parameters: Test, action or component parameters enable you to use values passed from your test or component, or values from other actions in your test. Data Table parameters enable you to create a data-driven test (or action) that runs several times using the data you supply. In each repetition, or iteration, QuickTest uses a different value from the Data Table. Environment variable parameters enable you to use variable values from other sources during the run session. These may be values you supply, or values that QuickTest generates for you based on conditions and options you choose. Random number parameters enable you to insert random numbers as values in your test or component. For example, to check how your application handles small and large ticket orders, you can have QuickTest generate a random number and insert it in a number of tickets edit field. 20. How do u do batch testing in WR & is it possible to do in QTP, if so explain? Ans: Batch Testing in WR is nothing but running the whole test set by selecting "Run Testset" from the "Execution Grid".The same is possible with QTP also. If our test cases are automated then by selecting "Run Testset" all the test scripts can be executed. In this process the Scripts get executed one by one by keeping all the remaining scripts in "Waiting" mode.
21. if i give some thousand tests to execute in 2 days what do u do? Ans : Adhoc testing is done. It Covers the least basic functionalities to verify that the system is working fine. 22. what does it mean when a check point is in red color? what do u do? Ans : A red color indicates failure. Here we analyze the the cause for failure whether it is a Script Issue or Envronment Issue or a Application issue. 23. what do you call the window testdirector-testlab? Ans : "Execution Grid". It is place from where we Run all Manual / Automated Scripts 24. how do u create new test sets in TD Ans : Login to TD. Click on "Test Lab" tab.
Give me an example where you have used a COM interface in your QTP project?
com inteface appears in the scenario of front end and back end.for eg:if you r using oracle as back end and front end as VB or any language then for better compatibility we will go for an interface.of which COM wil be one among those intefaces.

QTP concepts

2007-07-13T20:07:00.000-07:00

How to add a constant number in a datatable?
This is more to do with MS excel then QTP!! but useful to know because at times it becomes frustrating to the novices.
Just append ' to the number
Ex: if you wish to enter 1234567 in datatable then write it as '1234567

How can i check if a parameter exists in DataTable or not?
The best way would be to use the below code:
on error resume next
val=DataTable("ParamName",dtGlobalSheet)
if err.number<> 0 then
'Parameter does not exist
else
'Parameter exists
end if

How can i check if a checkpoint passes or not?
chk_PassFail = Browser(...).Page(...).WebEdit(...).Check (Checkpoint("Check1"))
if chk_PassFail then
MsgBox "Check Point passed"
else MsgBox "Check Point failed"
end if

My test fails due to checkpoint failing, Can i validate a checkpoint without my test failing due to checpoint failure?
Reporter.Filter = rfDisableAll 'Disables all the reporting stuff
chk_PassFail = Browser(...).Page(...).WebEdit(...).Check (Checkpoint("Check1"))
Reporter.Filter = rfEnableAll 'Enable all the reporting stuff
if chk_PassFail then
MsgBox "Check Point passed"
else
MsgBox "Check Point failed"
end if

What is the difference between an Action and a function?
Action is a thing specific to QTP while functions are a generic thing which is a feature of VB Scripting. Action can have a object repository associated with it while a function can't. A function is just lines of code with some/none parameters and a single return value while an action can have more than one output parameters.

Where to use function or action?
Well answer depends on the scenario. If you want to use the OR feature then you have to go for Action only. If the functionality is not about any automation script i.e. a function like getting a string between to specific characters, now this is something not specific to QTP and can be done on pure VB Script, so this should be done in a function and not an action. Code specific to QTP can also be put into an function using DP. Decision of using function/action depends on what any one would be comfortable using in a given situation.

When to use a Recovery Scenario and when to us on error resume next?
Recovery scenarios are used when you cannot predict at what step the error can occur or when you know that error won't occur in your QTP script but could occur in the world outside QTP, again the example would be "out of paper", as this error is caused by printer device driver. "On error resume next" should be used when you know if an error is expected and dont want to raise it, you may want to have different actions depending upon the error that occurred. Use err.number & err.description to get more details about the error.

How to use environment variable?
A simple defintion could be... it is a variable which can be used across the reusable actions and is not limited to one reusable action.
There are two types of environment variables:
1. User-defined
2. Built-in
We can retrieve the value of any environment variable. But we can set the value of only user-defined environment variables.

To set the value of a user-defined environment variable:
Environment (VariableName) = NewValue

To retrieve the value of a loaded environment variable:
CurrValue = Environment (VariableName)

Example
The following example creates a new internal user-defined variable named MyVariable with a value of 10, and then retrieves the variable value and stores it in the MyValue variable.

Environment.Value("MyVariable")=10
MyValue=Environment.Value("MyVariable")

What are the files and subfolders of a QuickTest Professional test?
The files and folders hold binary and text data that are required for the test to run successfully.
The following table provides a description, the type, and comments regarding the files that make up a QuickTest Professional test.

File Name	Description	Type	Comments Regarding File
Test.tsp	Test settings	Binary	Do not edit
Default.xls	Data table parameters	Excel similar	Can be edited using Excel
Parameters.mtr	Parameterization information	Binary	Do not edit
Action	Action folder (See other table)
Default.cfg	Load test configuration file	Text	Do not edit
Default.prm	Load test configuration file	Text	Do not edit
Default.usp	Load test configuration file	Text	Do not edit
.usr	Load test configuration file	Text	Do not edit
Thick_usr.dat	Load test configuration file	Text	Do not edit
Thin_usr.dat	Load test configuration file	Text	Do not edit

Files within Action folder:

File Name	Description	Type	Comments Regarding File
Script.mts	Action script	Text	Edit text preceding the @@ sign only
Resource.mtr	Object Repository	Binary	Do not edit
Snapshots	Active screen files	Folder	Do not edit

There are few more files extensions like

.MTB Batch File
.LCK Locked

How to rename a checkpoint (QTP 9.0)?
Example:
Window("Notepad").WinEditor("Edit").Check CheckPoint("Edit")
In the above example, the user would like to change the name of the CheckPoint object from "Edit" to something more meaningful.
Note:
This functionality is new to QuickTest Professional 9.0.This is not available for QTP 8.2 and below.
1. Right-click on the Checkpoint step in the Keyword View or on the Checkpoint object in Expert View.
2. Select "Checkpoint Properties" from the pop-up menu.
3. In the Name field, enter the new checkpoint name.
4. Click . The name of the checkpoint object will be updated within the script.
Example:
Window("Notepad").WinEditor("Edit").Check CheckPoint("NewCheckPointName")
Note:
You must use the QuickTest Professional user interface to change the name of the checkpoint. If you manually change the name of the checkpoint in the script, QuickTest Professional will generate an error during replay. The error message will be similar to the following:

"The "" CheckPoint object was not found in the Object Repository. Check the Object Repository to confirm that the object exists or to find the correct name for the object."

The CheckPoint object is not a visible object within the object repository, so if you manually modify the name, you may need to recreate the checkpoint to resolve the error.

Does QuickTest Professional support Internet Explorer 7.0?
QuickTest Professional 9.1
QuickTest Professional 9.1 supports Microsoft Internet Explorer 7.0 Beta 3. Internet Explorer version 7.0 is now certified to work and to be tested with QuickTest Professional version 9.1.
QuickTest Professional 9.0
QuickTest Professional 9.0 supports Internet Explorer 7.0 Beta 2.
QuickTest Professional 8.2 and below
QuickTest Professional 8.2 and below do not include support for Internet Explorer 7.0.

Does QuickTest Professional support Firefox?
QuickTest Professional 9.1
QuickTest Professional 9.1 provides replay support for Mozilla Firefox 1.5 and Mozilla Firefox 2.0 Alpha 3 (Alpha-level support for Bon Echo 2.0a3).
Notes:

QuickTest Professional 9.1 will not record on FireFox. You can record a test on Microsoft Internet Explorer and run it on any other supported browser, such as FireFox.
The .Object property for web objects is not supported in FireFox.

QuickTest Professional 9.0
QuickTest Professional 9.0 provides replay support for Mozilla FireFox 1.5.
Notes:

QuickTest Professional 9.0 will not record on FireFox. You can record a test on Microsoft Internet Explorer and run it on any other supported browser, such as FireFox.
The .Object property for web objects is not supported in FireFox.

QuickTest Professional 8.2 and below

QuickTest Professional 8.2 and below do not have support for Firefox.

Six Levels Testing

2007-07-13T00:23:00.000-07:00

The Workgroup for Electronic Data Interchange (WEDI) published a Strategic National Implementation Process (SNIP) Testing recommendations on the levels of testing that need to comply with the HIPAA transaction sets.

1.	Integrity Testing	According to the WEDI/SNIP White Paper, this involves testing "for valid segments, segment order, element attributes, testing for numeric values in numeric data elements, validation of X12 syntax and compliance with X12 rules."
2.	Requirement Testing	Testing for HIPAA implementation-guide-specific requirements, such as repeat counts, used and not used codes, elements and segments, required or intra-segment situational data elements- non-medical code sets as laid out in the implementation guide - and values noted in the implementation guide via an X12 code list or table.
3.	Balancing Testing	Testing the transaction for balanced field totals, record or segment counts, financial balancing of claims or remittance advice, and balancing of summary fields.
4.	Situation Testing	Testing of specific inter-segment situations described in the HIPAA implementation guides such that: If A occurs then B must be populated. This is considered to include the validation of situational fields given values or situations present elsewhere in the file. A typical situation testing: there is a dependent loop but no subscriber loop in a transaction.
5.	Code Set Testing	Testing for valid implementation-guide-specific code set values.
6.	Line-of- Business Testing	Specialized testing required by certain healthcare specialties. For example Hospice Care, Home Oxygen Treatment, and Ambulance Service all have unique data requirements when submitting health care claims to a payor.

Software Testing Techniques

2007-07-13T00:12:00.000-07:00

Overview

Companies rely on software more than ever to provide and manage information with strategic and operational importance and to provide key decision support. Rising customer expectations for fault-free, requirements-exact software have increased awareness of the importance of software testing as a critical activity.

This seminar provides proven, practical solutions to real-world software testing issues and problems. You will review a complete life cycle approach for systematically performing the testing process. The seminar also gives you the opportunity to apply the testing techniques discussed in practical in-class exercises. You will take home numerous phase-by-phase checklists to ensure your ability to apply methods back on the job. You will also use a sample software test plan exercise to prepare an action plan for implementing key elements of the seminar approach in your own organization.

What You Will Learn

Understand the importance of adopting a life cycle approach to software testing
Define specific testing tasks in a phase-by-phase examination of the development life cycle, building testing efforts into every phase at critical points
Learn to avoid the three common, and costly, misconceptions about software testing efforts
Review and discuss "The Ten Proven Principles of Software Testing" and see how each will impact your testing efforts
Examine the six factors that affect software testability and define testability metrics for each important factor
Learn to define responsibilities in testing - Who is responsible for what at what levels? Review sample ways to organize test teams
Define "Black-Box" and "White-Box" test case design
Define these testing techniques and know when and how to use each: equivalence class testing, cause-effect graphing, basis path/flowgraph, state and event testing, notation/cyclomating complexity, boundary testing and syntax testing
Define the seven key components of effective test documentation
Walk through the eight steps of test plan preparation and receive valuable worksheets for each step

Who Should Attend

This seminar is intended for any software professional with an interest in learning how to improve the quality and effectiveness of their organization's existing software testing efforts. It is also valuable for those who are in initial start-up stages of formal testing efforts. The seminar material is not technology-specific or confined to any one operating environment. The testing methodology presented is appropriate for software professionals in all computing situations -- from PC-based to network-based to mainframe-based systems. Appropriate audiences include I/S managers, software testing and quality assurance staff, systems analysts, programmer analysts, business analysts, I/S project managers, I/S audit professionals and other software development project team members.

Agenda

INTRODUCTION TO SOFTWARE TESTING

Why testing is important
Life cycle approach to testing
Testing economics
Factors that influence error correction costs
Testing and quality assurance

THE LIFE CYCLE APPROACH TO SOFTWARE TESTING

Traditional approach to software testing versus a life cycle approach
Definition of the life cycle approach
Critical elements of life cycle testing and quality assurance
Benefits of the life cycle approach: quality, cost, error reduction
Typical requirements phase errors and how to avoid them
Typical design phase errors and how to avoid them
Tester tasks conducted during the requirements phase and during the design phase
Typical coding phase errors and how to avoid them
Coding through implementation issues and tester tasks
Maintenance phase issues, tools and techniques and tester tasks

PRINCIPLES OF SOFTWARE TESTING

Software testing misconceptions
Testing definitions and a model for software testing
White box testing
Black box testing
Testing levels, objectives, responsibilities and techniques
Sample ways to organize independent test teams
10 Principles of software testing
Goals for a systematic testing process
Limitations of software testing

TEST CASE DESIGN TECHNIQUES -- PART ONE

Black box test case design techniques
Equivalence class testing
Guidelines for identifying equivalence classes
Guidelines for writing equivalence class tests
Boundary testing
Guidelines for writing boundary tests
Decision tables as a testing tool
General decision table format
Sample decision tables
Steps in developing decision tables
Simplifying and verifying decision tables
Decision trees as a testing tool
Decision tree structure
Steps in building and testing decision trees
Sample decision tree
Cause-effect graphing and cause-effect graphing symbols
Steps in building a cause-effect graph
State and Event Testing
Guidelines for state and event testing

TEST CASE DESIGN TECHNIQUES -- PART TWO

Things developers can do to make software testing easier
Things that make software testing easier
Software testability indicators
Guidelines for designers
Design and code metrics
Coupling
Module coupling concepts
Types of module coupling: Content coupling, Common coupling, External coupling, Control coupling, Stamp coupling, Data coupling
Comparison of coupling attributes
Cohesion
Module cohesion concepts
Types of module cohesion: Coincidental cohesion, Logical cohesion, Temporal cohesion, Procedural cohesion, Communication cohesion, Informational cohesion, Functional cohesion
Comparison of cohesion attributes
Control Flow Complexity
Module Structure
White Box Testing Coverage Criteria
Basis Path Testing
Representing programs as flowgraphs
Flowgraph notation and terminology
Calculating cyclomatic complexity
Steps in basis path testing method

SOFTWARE TEST PLANNING AND DOCUMENTATION

Components of test documentation
Sample test plan formats
Steps in test plan preparation
Determine test plan requirements
Determine requirements to test
Define test sets
Evaluate test traceability
Define resource requirements
Define testing schedules
Prepare and refine test plan
Publish and maintain test plan

Sanity testing:

2007-07-10T09:46:00.000-07:00

Once a new build is obtained with minor revisions, instead of doing a through regression, a sanity is performed so as to ascertain the build has indeed rectified the issues and no further issue has been introduced by the fixes. Its generally a subset of regression testing and a group of test cases are executed that are related with the changes made to the app.

Generally, when multiple cycles of testing are executed, sanity testing may be done during the later cycles after through regression cycles.

A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep.

A Sanity test is used to determine a small section of the application is still working after a minor change.

Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing.

sanity testing is to verify whether requirements are met or not,

checking all features breadth-first.

Smoke Testing

2007-07-10T09:07:00.000-07:00

In software, the term smoke testing describes the process of validating code changes before the changes are checked into the product’s source tree. After code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software. Smoke tests are designed to confirm that changes in the code function as expected and do not destabilize an entire build.

Note
The term smoke testing originated in the hardware industry. The term derived from this practice: After a piece of hardware or a hardware component was changed or repaired, the equipment was simply powered up. If there was no smoke, the component passed the test.

The following guidelines describe best practices for smoke testing. The effects of following the guidelines will vary widely, ranging from improving communication among team members to developing specific ways to use testing and debugging tools.

Work with the Developer

Because smoke testing focuses on changed code, you must work with the developer who wrote the code. You will have to understand:

What changed in the code. To understand the change, you will also have to understand the technology used; the developer can help explain it.
How the change affects the functionality.
How the change affects the interdependencies of various components.

Conduct a Code Review Before Smoke Testing

Before you run a smoke test, conduct a code review that focuses on any changes in the code. Code reviews are the most effective and efficient method to validate code quality and ensure against code defects and faults of commission. Smoke tests ensure that the primary critical or weak area identified either by code review or risk assessment is primarily validated, because if it fails the testing cannot continue.

Install Private Binaries on a Clean Debug Build

Because a smoke test must focus on validating only the functional changes in updated binaries, the test must run on a clean test environment by using the debug binaries for the files being tested.

Note
Testing with mismatched binaries is a common mistake in smoke testing. To avoid this mistake, when there is a dependency between two or more updated binaries, include all the updated binaries in the test build. Otherwise, the results of the test might not be valid.

Create Daily Builds

Daily builds require the team members to work together and encourage the developers to stay in sync. If iterations of new builds are delayed, the delay can easily cause products with multiple dependencies to get out of sync. Following a process of building daily and smoke testing any changed or new binaries ensures high quality.


Make a quality daily build the team’s top priority. If the build is broken because a code check-in has not been smoke-tested, require the developer and tester to stop all other work until the problem is resolved. The penalty for breaking the build should not be harsh, but the penalty should emphasize that a proper daily build is the team’s top priority.

You need not perform exhaustive tests. The purpose of smoke testing is not to ensure that the binary is 100% error-free. This would require too much time. You perform smoke tests to validate the build at a high level. You want to ensure that changes in a binary do not destabilize the general build or cause catastrophic errors in functionality.

Web and Load Testing

When you build your Web tests and load tests, it is a good practice to run a smoke test before running any long, heavy test. In Web and in load testing, smoke testing is short, light test. You use a smoke test to validate that everything is correctly configured and running as expected before running your tests for performance or stress testing.

How to: Run a Build on a Build Type

You can use build types in Team Foundation Build to define the settings under which a team project is built. Before running a build on a build type, you must first create one, for more information,

Running a Build on Build Type

All files located in the Team Build Types folder for a build are downloaded to the build computer (build directory) folder. Ensure that no unnecessary confidential information is stored in this folder.

To run a build on a build type

In Team Explorer, select the appropriate team project.
On the Build menu, click Build {Team Project Name} to display the Build dialog box.
Under the Build type drop-down list, select the build type that you want to run.
Under Build Location, retain the default computer configured to use the build type or select a Build machine from the drop-down list.
Under Build directory, retain the default directory configured for the build type or change the default directory that the build uses.
Click Build to start the build.

Daily Build and Smoke Test

If you want to create a simple computer program consisting of only one file, you merely need to compile and link that one file. On a typical team project involving dozens, hundreds, or even thousands of files, however, the process of creating an executable program becomes more complicated and time consuming. You must "build" the program from its various components.

A common practice at Microsoft and some other shrink-wrap software companies is the "daily build and smoke test" process. Every file is compiled, linked, and combined into an executable program every day, and the program is then put through a "smoke test," a relatively simple check to see whether the product "smokes" when it runs.

BENEFITS. This simple process produces several significant benefits.

It minimizes integration risk. One of the greatest risks that a team project faces is that, when the different team members combine or "integrate" the code they have been working on separately, the resulting composite code does not work well. Depending on how late in the project the incompatibility is discovered, debugging might take longer than it would have if integration had occurred earlier, program interfaces might have to be changed, or major parts of the system might have to be redesigned and reimplemented. In extreme cases, integration errors have caused projects to be cancelled. The daily build and smoke test process keeps integration errors small and manageable, and it prevents runaway integration problems.

It reduces the risk of low quality. Related to the risk of unsuccessful or problematic integration is the risk of low quality. By minimally smoke-testing all the code daily, quality problems are prevented from taking control of the project. You bring the system to a known, good state, and then you keep it there. You simply don't allow it to deteriorate to the point where time-consuming quality problems can occur.

It supports easier defect diagnosis. When the product is built and tested every day, it's easy to pinpoint why the product is broken on any given day. If the product worked on Day 17 and is broken on Day 18, something that happened between the two builds broke the product.

It improves morale. Seeing a product work provides an incredible boost to morale. It almost doesn't matter what the product does. Developers can be excited just to see it display a rectangle! With daily builds, a bit more of the product works every day, and that keeps morale high.

USING THE DAILY BUILD AND SMOKE TEST. The idea behind this process is simply to build the product and test it every day. Here are some of the ins and outs of this simple idea.

Build daily. The most fundamental part of the daily build is the "daily" part. As Jim McCarthy says (Dynamics of Software Development, Microsoft Press, 1995), treat the daily build as the heartbeat of the project. If there's no heartbeat, the project is dead. A little less metaphorically, Michael Cusumano and Richard W. Selby describe the daily build as the sync pulse of a project (Microsoft Secrets, The Free Press, 1995). Different developers' code is allowed to get a little out of sync between these pulses, but every time there's a sync pulse, the code has to come back into alignment. When you insist on keeping the pulses close together, you prevent developers from getting out of sync entirely.

Some organizations build every week, rather than every day. The problem with this is that if the build is broken one week, you might go for several weeks before the next good build. When that happens, you lose virtually all of the benefit of frequent builds.

Check for broken builds. For the daily-build process to work, the software that's built has to work. If the software isn't usable, the build is considered to be broken and fixing it becomes top priority.

Each project sets its own standard for what constitutes "breaking the build." The standard needs to set a quality level that's strict enough to keep showstopper defects out but lenient enough to dis-regard trivial defects, an undue attention to which could paralyze progress.

At a minimum, a "good" build should

compile all files, libraries, and other components successfully;
link all files, libraries, and other components successfully;
not contain any showstopper bugs that prevent the program from being launched or that make it hazardous to operate; and
pass the smoke test.

Smoke test daily. The smoke test should exercise the entire system from end to end. It does not have to be exhaustive, but it should be capable of exposing major problems. The smoke test should be thorough enough that if the build passes, you can assume that it is stable enough to be tested more thoroughly.

The daily build has little value without the smoke test. The smoke test is the sentry that guards against deteriorating product quality and creeping integration problems. Without it, the daily build becomes just a time-wasting exercise in ensuring that you have a clean compile every day.

The smoke test must evolve as the system evolves. At first, the smoke test will probably test something simple, such as whether the system can say, "Hello, World." As the system develops, the smoke test will become more thorough. The first test might take a matter of seconds to run; as the system grows, the smoke test can grow to 30 minutes, an hour, or more.

Establish a build group. On most projects, tending the daily build and keeping the smoke test up to date becomes a big enough task to be an explicit part of someone's job. On large projects, it can become a full-time job for more than one person. On Windows NT 3.0, for example, there were four full-time people in the build group (Pascal Zachary, Showstopper!, The Free Press, 1994).

Add revisions to the build only when it makes sense to do so. Individual developers usually don't write code quickly enough to add meaningful increments to the system on a daily basis. They should work on a chunk of code and then integrate it when they have a collection of code in a consistent state-usually once every few days.

Create a penalty for breaking the build. Most groups that use daily builds create a penalty for breaking the build. Make it clear from the beginning that keeping the build healthy is the project's top priority. A broken build should be the exception, not the rule. Insist that developers who have broken the build stop all other work until they've fixed it. If the build is broken too often, it's hard to take seriously the job of not breaking the build.

A light-hearted penalty can help to emphasize this priority. Some groups give out lollipops to each "sucker" who breaks the build. This developer then has to tape the sucker to his office door until he fixes the problem. Other groups have guilty developers wear goat horns or contribute $5 to a morale fund.

Some projects establish a penalty with more bite. Microsoft developers on high-profile projects such as Windows NT, Windows 95, and Excel have taken to wearing beepers in the late stages of their projects. If they break the build, they get called in to fix it even if their defect is discovered at 3 a.m.

Customer Support

2007-07-09T11:47:00.001-07:00

Technical support for QuickTest Professional is provided via our award-winning Customer Support Web Site. From this Web site, customers are able to review Frequently Asked Questions, submit and check the status of support requests, and access online documentation, patches, and other downloads. Please visit the Customer Support Web Site at:

http://support.mercury.com.

Customer Support contact numbers all over the world are available at:

http://support.mercury.com/cgi-bin/portal/CSO/contacts.jsp.

Customer Support

2007-07-09T11:47:00.000-07:00

http://support.mercury.com.

Customer Support contact numbers all over the world are available at:

http://support.mercury.com/cgi-bin/portal/CSO/contacts.jsp.

TEST AUTOMATION FRAMEWORKS

2007-07-07T21:49:00.000-07:00

Problems with Test Automation

Historically, test automation has not met with the level of success that it could. Time and again test automation efforts are born, stumble, and die. Most often this is the result of misconceived perceptions of the effort and resources necessary to implement a successful, long-lasting automation framework. Why is this, we might ask? Well, there are several reasons.

Foremost among this list is that automation tool vendors do not provide completely forthright demonstrations when showcasing the "simplicity" of their tools. We have seen the vendor’s sample applications. We have seen the tools play nice with those applications. And we try to get the tools to play nice with our applications just as fluently. Inherently, project after project, we do not achieve the same level of success.

This usually boils down to the fact that our applications most often contain elements that are not compatible with the tools we use to test them. Consequently, we must often mastermind technically creative solutions to make these automation tools work with our applications. Yet, this is rarely ever mentioned in the literature or the sales pitch.

The commercial automation tools have been chiefly marketed for use as solutions for testing an application. They should instead be sought as the cornerstone for an enterprise-wide test automation framework. And, while virtually all of the automation tools contain some scripting language allowing us to get past each tool’s failings, testers have typically neither held the development experience nor received the training necessary to exploit these programming environments.

"For the most part, testers have been testers, not programmers. Consequently, the ‘simple’ commercial solutions have been far too complex to implement and maintain; and they become shelfware."

Most unfortunate of all, otherwise fully capable testers are seldom given the time required to gain the appropriate software development skills. For the most part, testers have been testers, not programmers. Consequently, the "simple" commercial solutions have been far too complex to implement and maintain; and they become shelfware.

Test automation must be approached as a full-blown software development effort in its own right. Without this, it is most likely destined to failure in the long term.

Case Study: Costly Automation Failures

In 1996, one large corporation set out evaluating the various commercial automation tools that were available at that time. They brought in eager technical sales staff from the various vendors, watched demonstrations, and performed some fairly thorough internal evaluations of each tool.

By 1998, they had chosen one particular vendor and placed an initial order for over $250,000 worth of product licensing, maintenance contracts, and onsite training. The tools and training were distributed throughout the company into various test departments--each working on their own projects.

None of these test projects had anything in common. The applications were vastly different. The projects each had individual schedules and deadlines to meet. Yet, every one of these departments began separately coding functionally identical common libraries. They made routines for setting up the Windows test environment. They each made routines for accessing the Windows programming interface. They made file-handling routines, string utilities, database access routines--the list of code duplication was disheartening!

For their test designs, they each captured application specific interactive tests using the capture\replay tools. Some groups went the next step and modularized key reusable sections, creating reusable libraries of application-specific test functions or scenarios. This was to reduce the amount of code duplication and maintenance that so profusely occurs in pure captured test scripts. For some of the projects, this might have been appropriate if done with sufficient planning and an appropriate automation framework. But this was seldom the case.

With all these modularized libraries testers could create functional automated tests in the automation tool’s proprietary scripting language via a combination of interactive test capture, manual editing, and manual scripting.

One problem was, as separate test teams they did not think past their own individual projects. And although they were each setting up something of a reusable framework, each was completely unique--even where the common library functions were the same! This meant duplicate development, duplicate debugging, and duplicate maintenance. Understandably, each separate project still had looming deadlines, and each was forced to limit their automation efforts in order to get real testing done.

As changes to the various applications began breaking automated tests, script maintenance and debugging became a significant challenge. Additionally, upgrades in the automation tools themselves caused significant and unexpected script failures. In some cases, the necessity to revert back (downgrade) to older versions of the automation tools was indicated. Resource allocation for continued test development and test code maintenance became a difficult issue.

Eventually, most of these automation projects were put on hold. By the end of 1999--less than two years from the inception of this large-scale automation effort--over 75% of the test automation tools were back on the shelves waiting for a new chance to try again at some later date.

1.1.2 Some Test Strategy Guidelines

Past failings like these have been lessons for the entire testing community. Realizing that we must develop reusable test strategies is no different than the reusability concerns of any good application development project. As we set out on our task of automating test, we must keep these past lessons forefront.

In order to make the most of our test strategy, we need to make it reusable and manageable. To that end, there are some essential guiding principles we should follow when developing our overall test strategy:

Test automation is a fulltime effort, not a sideline.
The test design and the test framework are totally separate entities.
The test framework should be application-independent.
The test framework must be easy to expand, maintain, and perpetuate.
The test strategy/design vocabulary should be framework independent.
The test strategy/design should remove most testers from the complexities of the test framework.

These ideals are not earth shattering. They are not relatively new. Yet, it is seldom these principles are fully understood and instrumented.

So what do they mean?

1.1.3 Test automation is a fulltime effort, not a sideline.

While not necessarily typical design criteria, it bears repeating. The test framework design and the coding of that design together require significant front-loaded time and effort. These are not things that someone can do when they have a little extra time here, or there, or between projects. The test framework must be well thought out. It must be documented. It should be reviewed. It should be tested. It is a full software development project like any other. This bears repeating--again.

Will our test framework development have all of these wonderful documentation, design, review, and test processes? Does our application development team?

We should continuously push for both endeavors to implement all these critical practices.

1.1.4 The test design and the test framework are totally separate entities.

The test design details how the particular functions and features of our application will be tested. It will tell us what to do, how and when to do it, what data to use as input, and what results we expect to find. All of this is specific to the particular application or item being tested. Little of this requires any knowledge or care of whether the application will be tested automatically or manually. It is, essentially, the "how to" of what needs to be tested in the application.

On the other hand, the test framework, or specifically, the test automation framework is an execution environment for automated tests. It is the overall system in which our tests will be automated. The development of this framework requires completely different technical skills than those needed for test design.

1.1.5 The test framework should be application-independent.

Although applications are relatively unique, the components that comprise them, in general, are not. Thus, we should focus our automation framework to deal with the common components that make up our unique applications. By doing this, we can remove all application-specific context from our framework and reuse virtually everything we develop for every application that comes through the automated test process.

"We should focus our automation framework to deal with the common components that make up our unique applications."

Nearly all applications come with some form of menu system. They also have buttons to push, boxes to check, lists to view, and so on. In a typical automation tool script there is, generally, a very small number of component functions for each type of component. These functions work with the component objects independent of the applications that contain them.

Traditional, captured automation scripts are filled with thousands of calls to these component functions. So the tools already exist to achieve application independence. The problem is, most of these scripts construct the function calls using application-specific, hard coded values. This immediately reduces their effectiveness as application-independent constructs. Furthermore, the functions by themselves are prone to failure unless a very specific application state or synchronization exists at the time they are executed. There is little error correction or prevention built-in to these functions.

To deal with this in traditional scripts we must place additional code before and\or after the command, or a set of commands, to insure the proper application state and synchronization is maintained. We need to make sure our window has the current focus. We need to make sure the component we want to select, or press, or edit exists and is in the proper state. Only then can we perform the desired operation and separately verify the result of our actions.

For maximum robustness, we would have to code these state and synchronization tests for every component function call in our scripts. Realistically, we could never afford to do this. It would make the scripts huge, nearly unreadable, and difficult to maintain. Yet, where we forego this extra effort, we increase the possibility of script failure.

What we must do is develop a truly application-independent framework for these component functions. This will allow us to implement that extra effort just once, and execute it for every call to any component function. This framework should handle all the details of insuring we have the correct window, verifying the element of interest is in the proper state, doing something with that element, and logging the success or failure of the entire activity.

We do this by using variables, and providing application-specific data to our application-independent framework. In essence, we will provide our completed test designs as executable input into our automation framework.

Does this mean that we will never have to develop application-specific test scripts? Of course not. However, if we can limit our application-specific test scripts to some small percentage, while reusing the best features of our automation framework, we will reap the rewards project after project.

1.1.6 The test framework must be easy to expand, maintain, and perpetuate.

One of our goals should be a highly modular and maintainable framework. Generally, each module should be independent and separate from all the other modules. What happens inside one is of no concern to the others.

With this modular black-box approach, the functionality available within each module can be readily expanded without affecting any other part of the system. This makes code maintenance much simpler. Additionally, the complexity of any one module will likely be quite minimal.

However, modularity alone will not be enough to ensure a highly maintainable framework. Like any good software project, our design must be fully documented and published. Without adequate, published documentation it will be very difficult for anyone to decipher what it is the framework is designed to do. Any hope of maintenance will not last far beyond the departure of the original framework designers. Our test automation efforts will eventually become another negative statistic.

To prevent this, we should define documentation standards and templates. Wherever possible, module documentation should be developed "in-context". That is, directly in the source code itself. Tools should be retained, or designed and developed, so that we can automatically extract and publish the documentation. This will eliminate the task of maintaining two separate sets of files: the source code, and its documentation. It will also provide those doing the code maintenance quite a ready reference. Nearly everything they need to know should exist right there in the code.

"We must always remember: our ultimate goal is to simplify and perpetuate a successful automation framework."

We must always remember: our ultimate goal is to simplify and perpetuate a successful test automation framework. To put something in place that people will use and reuse for as long as it is technically viable and productive.

1.1.7 The test strategy/design vocabulary should be framework independent.

As noted before, the framework refers to the overall environment we construct to execute our tests. The centerpiece is usually one of many commercially available automation tools. In good time, it may be more than one. In some rare circumstances, it might even be a proprietary tool developed or contracted specifically for our test automation needs.

The point is, different tools exist and some will work better for us than others in certain situations. While one tool might have worked best with our Visual Basic or C/C++ applications, we may need to use a different tool for our web clients. By keeping a specific tool consideration out of our test designs, we avoid limiting our tests to that tool alone.

The overall test strategy will define the format and low-level vocabulary we use to test all applications much like an automation tool defines the format and syntax of the scripting language it provides. Our vocabulary, however, will be independent of any particular test framework employed. The same vocabulary will migrate with us from framework to framework, and application to application. This means, for example, the syntax used to click a button will be the same regardless of the tool we use to execute the instruction or the application that contains the button.

The test design for a particular application, however, will define a high-level vocabulary that is specific to that application. While this high-level vocabulary will be application specific, it is still independent of the test framework used to execute it. This means that the high-level instruction to login to our website with a particular user ID and password will be the same regardless of the tool we use to execute it.

When we provide all the instructions necessary to test a particular application, we should be able to use the exact same instructions on any number of different framework implementations capable of testing that application. We must also consider the very likely scenario that some or all of this testing may, at one time or another, be manual testing. This means that our overall test strategy should not only facilitate test automation, it should also support manual testing.

Consequently, the format and vocabulary we use to test our applications should be intuitive enough for mere mortals to comprehend and execute. We should be able to hand our test over to a person, point to an area that failed, and that person should be able to manually reproduce the steps necessary to duplicate the failure.

"A good test strategy can remove the necessity for both manual and automated test scripts. The same ‘script’ should suffice for both."

A good test strategy, comprised of our test designs and our test framework, can remove the necessity for both manual and automated test scripts for the same test. The same "script" should suffice for both. The important thing is that the vocabulary is independent of the framework used to execute it. And the test strategy must also accommodate manual testing.

1.1.8 The test strategy/design should remove most testers from the complexities of the test framework.

In practice, we cannot expect all our test personnel to become proficient in the use of the automation tools we use in our test framework. In some cases, this is not even an option worth considering. Remember, generally, testers are testers--they are not programmers. Sometimes our testers are not even professional testers. Sometimes they are application domain experts with little or no use for the technical skills needed for software development.

Sometimes testers are application developers splitting time between development and test. And when application developers step in to perform testing roles, they do not want or need a complex test scripting language to learn. That is what you get with commercial automation tools. And that may even be counter-productive and promote confusion since some of these scripting languages are modified subsets of standard programming languages. Others are completely unique and proprietary.

Yet, with the appropriate test strategy and vocabulary as discussed in the previous section, there is no reason we should not be able to use all our test resources to design tests suitable for automation without knowing anything about the automation tools we plan to deploy.

The bulk of our testers can concentrate on test design, and test design only. It is the automation framework folks who will focus on the tools and utilities to automate those tests.

1.2 Data Driven Automation Frameworks

Over the past several years there have been numerous articles done on various approaches to test automation. Anyone who has read a fair, unbiased sampling of these knows that we cannot and must not expect pure capture and replay of test scripts to be successful for the life of a product. We will find nothing but frustration there.

Sometimes this manifesto is hard to explain to people who have not yet performed significant test automation with these capture\replay tools. But it usually takes less than a week, often less than a day, to hear the most repeated phrase: "It worked when I recorded it, but now it fails when I play it back!"

Obviously, we are not going to get there from here.

1.2.1 Data Driven Scripts

Data driven scripts are those application-specific scripts captured or manually coded in the automation tool’s proprietary language and then modified to accommodate variable data. Variables will be used for key application input fields and program selections allowing the script to drive the application with external data supplied by the calling routine or the shell that invoked the test script.

Variable Data, Hard Coded Component Identification:
These data driven scripts often still contain the hard coded and sometimes very fragile recognition strings for the window components they navigate. When this is the case, the scripts are easily broken when an application change or revision occurs. And when these scripts start breaking, we are not necessarily talking about just a few. We are sometimes talking about a great many, if not all the scripts, for the entire application.

Figure 1 is an example of activating a server-side image map link in a web application with an automation tool scripting language:

Image Click "DocumentTitle=Welcome;\;ImageIndex=1" "Coords=25,20"

Figure 1

This particular scenario of clicking on the image map might exist thousands of times throughout all the scripts that test this application. The preceding example identifies the image by the title given to the document and the index of the image on the page. The hard coded image identification might work successfully all the way through the production release of that version of the application. Consequently, testers responsible for the automated test scripts may gain a false sense of security and satisfaction with these results.

However, the next release cycle may find some or all of these scripts broken because either the title of the document or the index of the image has changed. Sometimes, with the right tools, this might not be too hard to fix. Sometimes, no matter what tools, it will be frustratingly difficult.

Remember, we are potentially talking about thousands of broken lines of test script code. And this is just one particular change. Where there is one, there will likely be others.

Highly Technical or Duplicate Test Designs:
Another common feature of data driven scripts is that virtually all of the test design effort for the application is developed in the scripting language of the automation tool. Either that, or it is duplicated in both manual and automated script versions. This means that everyone involved with automated test development or automated test execution for the application must likely become proficient in the environment and programming language of the automation tool.

Findings:
A test automation framework relying on data driven scripts is definitely the easiest and quickest to implement if you have and keep the technical staff to maintain it. But it is the hardest of the data driven approaches to maintain and perpetuate and very often leads to long-term failure.

1.2.2 Keyword or Table Driven Test Automation

Nearly everything discussed so far defining our ideal automation framework has been describing the best features of "keyword driven" test automation. Sometimes this is also called "table driven" test automation. It is typically an application-independent automation framework designed to process our tests. These tests are developed as data tables using a keyword vocabulary that is independent of the test automation tool used to execute them. This keyword vocabulary should also be suitable for manual testing, as you will soon see.

Action, Input Data, and Expected Result ALL in One Record:
The data table records contain the keywords that describe the actions we want to perform. They also provide any additional data needed as input to the application, and where appropriate, the benchmark information we use to verify the state of our components and the application in general.

For example, to verify the value of a user ID textbox on a login page, we might have a data table record as seen in Table 1:

WINDOW

COMPONENT

ACTION

EXPECTED

VALUE

LoginPage

UserIDTextbox

VerifyValue

"MyUserID"

Table 1

Reusable Code, Error Correction and Synchronization:
Application-independent component functions are developed that accept application-specific variable data. Once these component functions exist, they can be used on each and every application we choose to test with the framework.

Figure 2 presents pseudo-code that would interpret the data table record from Table 1 and Table 2. In our design, the primary loop reads a record from the data table, performs some high-level validation on it, sets focus on the proper object for the instruction, and then routes the complete record to the appropriate component function for full processing. The component function is responsible for determining what action is being requested, and to further route the record based on the action.

Framework Pseudo-Code

Primary Record Processor Module:

Verify "LoginPage" Exists. (Attempt recovery if not)
Set focus to "LoginPage".
Verify "UserIDTextbox" Exists. (Attempt recovery if not)
Find "Type" of component "UserIDTextbox". (It is a Textbox)
Call the module that processes ALL Textbox components.

Textbox Component Module:

Validate the action keyword "VerifyValue".
Call the Textbox.VerifyValue function.

Textbox.VerifyValue Function:

Get the text stored in the "UserIDTextbox" Textbox.
Compare the retrieved text to "MyUserID".
Record our success or failure.

Figure 2

Test Design for Man and Machine, With or Without the Application:
Table 2 reiterates the actual data table record run by the automation framework above:

WINDOW

COMPONENT

ACTION

EXPECTED

VALUE

LoginPage

UserIDTextbox

VerifyValue

"MyUserID"

Table 2

Note how the record uses a vocabulary that can be processed by both man and machine. With minimal training, a human tester can be made to understand the record instruction as deciphered in Figure 3:

On the LoginPage, in the UserIDTextbox,
Verify the Value is "MyUserID".

Figure 3

Once they learn or can reference this simple vocabulary, testers can start designing tests without knowing anything about the automation tool used to execute them.

Another advantage of the keyword driven approach is that testers can develop tests without a functioning application as long as preliminary requirements or designs can be determined. All the tester needs is a fairly reliable definition of what the interface and functional flow is expected to be like. From this they can write most, if not all, of the data table test records.

Sometimes it is hard to convince people that this advantage is realizable. Yet, take our login example from Table 2 and Figure 3. We do not need the application to construct any login tests. All we have to know is that we will have a login form of some kind that will accept a user ID, a password, and contain a button or two to submit or cancel the request. A quick discussion with development can confirm or modify our determinations. We can then complete the test table and move on to another.

We can develop other tests similarly for any part of the product we can receive or deduce reliable information. In fact, if in such a position, testers can actually help guide the development of the UI and flow, providing developers with upfront input on how users might expect the product to function. And since the test vocabulary we use is suitable for both manual and automated execution, designed testing can commence immediately once the application becomes available.

It is, perhaps, important to note that this does not suggest that these tests can be executed automatically as soon as the application becomes available. The test record in Table 2 may be perfectly understood and executable by a person, but the automation framework knows nothing about the objects in this record until we can provide that additional information. That is a separate piece of the framework we will learn about when we discuss application mapping.

Findings:
The keyword driven automation framework is initially the hardest and most time-consuming data driven approach to implement. After all, we are trying to fully insulate our tests from both the many failings of the automation tools, as well as changes to the application itself.

To accomplish this, we are essentially writing enhancements to many of the component functions already provided by the automation tool: such as error correction, prevention, and enhanced synchronization.

Fortunately, this heavy, initial investment is mostly a one-shot deal. Once in place, keyword driven automation is arguably the easiest of the data driven frameworks to maintain and perpetuate providing the greatest potential for long-term success.

Additionally, there may now be commercial products suitable for your needs to decrease, but not eliminate, much of the up-front technical burden of implementing such a framework. This was not the case just a few years ago. We will briefly discuss a couple of these in Section 1.2.4

1.2.3 Hybrid Test Automation (or, "All of the Above")

The most successful automation frameworks generally accommodate both keyword driven testing as well as data driven scripts. This allows data driven scripts to take advantage of the powerful libraries and utilities that usually accompany a keyword driven architecture.

The framework utilities can make the data driven scripts more compact and less prone to failure than they otherwise would have been. The utilities can also facilitate the gradual and manageable conversion of existing scripts to keyword driven equivalents when and where that appears desirable.

On the other hand, the framework can use scripts to perform some tasks that might be too difficult to re-implement in a pure keyword driven approach, or where the keyword driven capabilities are not yet in place.

1.2.4 Commercial Keyword Driven Frameworks

Some commercially available keyword driven frameworks are making inroads in the test automation markets. These generally come from 3^rd party companies as a bridge between your application and the automation tools you intend to deploy. They are not out-of-the-box, turnkey automation solutions just as the capture\replay tools are not turnkey solutions.

They still require some up-front investment of time and personnel to complete the bridge between the application and the automation tools, but they can give some automation departments and professionals a huge jumpstart in the right direction for successful long-term test automation.

Two particular products to note are the TestFrameä product led by Hans Buwalda of CMG Corp, and the Certifyä product developed with Linda Hayes of WorkSoft Inc. These products each implement their own version of a keyword driven framework and have served as models for the subject at international software testing conferences, training courses, and user-group discussions worldwide. I’m sure there are others.

It really is up to the individual enterprise to evaluate if any of the commercial solutions are suitable for their needs. This will be based not only on the capabilities of the tools evaluated, but also on how readily they can be modified and expanded to accommodate your current and projected capability requirements.

1.3 Keyword Driven Automation Framework Model

The following automation framework model is the result of over 18 months of planning, design, coding, and sometimes trial and error. That is not to say that it took 18 months to get it working--it was actually a working prototype at around 3 person-months. Specifically, one person working on it for 3 months!

The model focuses on implementing a keyword driven automation framework. It does not include any additional features like tracking requirements or providing traceability between automated test results and any other function of the test process. It merely provides a model for a keyword driven execution engine for automated tests.

The commercially available frameworks generally have many more features and much broader scope. Of course, they also have the price tag to reflect this.

1.3.1 Project Guidelines

The project was informally tasked to follow the guidelines or practices below:

Implement a test strategy that will allow reasonably intuitive tests to be developed and executed both manually and via the automation framework.
The test strategy will allow each test to include the step to perform, the input data to use, and the expected result all together in one line or record of the input source.
Implement a framework that will integrate keyword driven testing and traditional scripts, allowing both to benefit from the implementation.
Implement the framework to be completely application-independent since it will need to test at least 4 or 5 different applications once deployed.
The framework will be fully documented and published.
The framework will be publicly shared on the intranet for others to use and eventually (hopefully) co-develop.

1.3.2 Code and Documentation Standards

The first thing we did was to define standards for source code files and headers that would provide for in-context documentation intended for publication. This included standards for how we would use headers and what type of information would go into them.

Each source file would start with a structured block of documentation describing the purpose of the module. Each function or subroutine would likewise have a leading documentation block describing the routine, its arguments, possible return codes, and any errors it might generate. Similar standards were developed for documenting the constants, variables, dependencies, and other features of the modules.

We then developed a tool that would extract and publish the documentation in HTML format directly from the source and header files. We did this to minimize synchronization problems between the source code and the documentation, and it has worked very well.

It is beyond the scope of this work to illustrate how this is done. In order to produce a single HTML document we parse the source file and that source file’s primary headers. We format and link public declarations from the headers to the detailed documentation in the source as well as link to any external references for other documentation. We also format and group public constants, properties or variables, and user-defined types into the appropriate sections of the HTML publication.

One nice feature about this is that the HTML publishing tool is made to identify the appropriate documentation blocks and include them pretty much "as is". This enables the inclusion of HTML tags within the source documentation blocks that will be properly interpreted by a browser. Thus, for publication purposes, we can include images or other HTML elements by embedding the proper tags.

Automation Framework

Figure 4 is a diagram representing the design of our automation framework. It is followed by a description of each of the elements within the framework and how they interact. Some readers may recognize portions of this design. It is a compilation of keyword driven automation concepts from several sources. These include Linda Hayes with WorkSoft, Ed Kit from Software Development Technolgies, Hans Buwalda from CMG Corp, myself, and a few others.

Figure 4

In brief, the framework itself is really defined by the Core Data Driven Engine, the Component Functions, and the Support Libraries. While the Support Libraries provide generic routines useful even outside the context of a keyword driven framework, the core engine and Component Functions are highly dependent on the existence of all three elements.

The test execution starts with the LAUNCH TEST(1) script. This script invokes the Core Data Driven Engine by providing one or more High-Level Test Tables to CycleDriver(2). CycleDriver processes these test tables invoking the SuiteDriver(3) for each Intermediate-Level Test Table it encounters. SuiteDriver processes these intermediate-level tables invoking StepDriver(4) for each Low-Level Test Table it encounters. As StepDriver processes these low-level tables it attempts to keep the application in synch with the test. When StepDriver encounters a low-level command for a specific component, it determines what Type of component is involved and invokes the corresponding Component Function(5) module to handle the task.

All of these elements rely on the information provided in the App Map to interface or bridge the automation framework with the application being tested. Each of these elements will be described in more detail in the following sections.

1.3.4 The Application Map:
The Application Map is one of the most critical items in our framework. It is how we map our objects from names we humans can recognize to a data format useful for the automation tool. The testers for a given project will define a naming convention or specific names for each component in each window as well as a name for the window itself. We then use the Application Map to associate that name to the identification method needed by the automation tool to locate and properly manipulate the correct object in the window.

Not only does it give us the ability to provide useful names for our objects, it also enables our scripts and keyword driven tests to have a single point of maintenance on our object identification strings. Thus, if a new version of an application changes the title of our web page or the index of an image element within it, they should not affect our test tables. The changes will require only a quick modification in one place--inside the Application Map.

Figure 5 shows a simple HTML page used in one frame of a HTML frameset. Table 3 shows the object identification methods for this page for an automation tool. This illustrates how the tool’s recorded scripts might identify multiple images in the header frame or top frame of a multi-frame web page. This top frame contains the HTML document with four images used to navigate the site. Notice that these identification methods are literal strings and potentially appear many times in traditional scripts (a maintenance nightmare!):

Simple HTML Document With Four Images

Figure 5

Script referencing HTML Document Components with Literal Strings
OBJECT	IDENTIFICATION METHOD
Window	"WindowTag=WebBrowser"
Frame	"FrameID=top"
Image	"FrameID=top;\;DocumentTitle=topFrame"
Image	"FrameID=top;\;DocumentTitle=topFrame;\;ImageIndex=1"
Image	"FrameID=top;\;DocumentTitle=topFrame;\;ImageIndex=2"
Image	"FrameID=top;\;DocumentTitle=topFrame;\;ImageIndex=3"
Image	"FrameID=top;\;DocumentTitle=topFrame;\;ImageIndex=4"

Table 3

This particular web page is simple enough. It contains only four images. However, when we look at Table 3, how do we determine which image is for Product information, and which is for Services? We should not assume they are in any particular order based upon how they are presented visually. Consequently, someone trying to decipher or maintain scripts containing these identification strings can easily get confused.

An Application Map will give these elements useful names, and provide our single point of maintenance for the identification strings as shown in Table 4. The Application Map can be implemented in text files, spreadsheet tables, or your favorite database table format. The Support Libraries just have to be able to extract and cache the information for when it is needed.

An Application Map Provides Named References for Components
REFERENCE	IDENTIFICATION METHOD
Browser	"WindowTag=WebBrowser"
TopFrame	"FrameID=top"
TopPage	"FrameID=top;\;DocumentTitle=topFrame"
CompInfoImage	"FrameID=top;\;DocumentTitle=topFrame;\;ImageIndex=1"
ProductsImage	"FrameID=top;\;DocumentTitle=topFrame;\;ImageIndex=2"
ServicesImage	"FrameID=top;\;DocumentTitle=topFrame;\;ImageIndex=3"
SiteMapImage	"FrameID=top;\;DocumentTitle=topFrame;\;ImageIndex=4"

Table 4

With the preceding definitions in place, the same scripts can use variables with values from the Application Map instead of those string literals. Our scripts can now reference these image elements as shown in Table 5. This reduces the chance of failure caused by changes in the application and provides a single point of maintenance in the Application Map for the identification strings used throughout our tests. It can also make our scripts easier to read and understand.

Script Using Variable References Instead of Literal Strings
OBJECT	IDENTIFICATION METHOD
Window	Browser
Frame	TopFrame
Document	TopPage
Image	CompInfoImage
Image	ProductsImage
Image	ServicesImage
Image	SiteMapImage

Table 5

1.3.5 Component Functions:
Component Functions are those functions that actively manipulate or interrogate component objects. In our automation framework we will have a different Component Function module for each Type of component we encounter (Window, CheckBox, TextBox, Image, Link, etc..).

Our Component Function modules are the application-independent extensions we apply to the functions already provided by the automation tool. However, unlike those provided by the tool, we add the extra code to help with error detection, error correction, and synchronization. We also write these modules to readily use our application-specific data stored in the Application Map and test tables as necessary. In this way, we only have to develop these Component Functions once, and they will be used again and again by every application we test.

Another benefit from Component Functions is that they provide a layer of insulation between our application and the automation tool. Without this extra layer, changes or "enhancements" in the automation tool itself can break existing scripts and our table driven tests. With these Component Functions, however, we can insert a "fix"--the code necessary to accommodate these changes that will avert breaking our tests.

Component Function Keywords Define Our Low-Level Vocabulary:
Each of these Component Function modules will define the keywords or "action words" that are valid for the particular component type it handles. For example, the Textbox Component Function module would define and implement the actions or keywords that are valid on a Textbox. These keywords would describe actions like those in Table 6:

Some Component Function Keywords for a Textbox
KEYWORD	ACTION PERFORMED
InputText	Enter new value into the Textbox
VerifyValue	Verify the current value of the Textbox
VerifyProperty	Verify some other attribute of the Textbox

Table 6

Each action embodied by a keyword may require more information in order to complete its function. The InputText action needs an additional argument that tells the function what text it is suppose to input. The VerifyProperty action needs two additional arguments, (1) the name of the property we want to verify, and (2) the value we expect to find. And, while we need no additional information to Click a Pushbutton, a Click action for an Image map needs to know where we want the click on the image to occur.

These Component Function keywords and their arguments define the low-level vocabulary and individual record formats we will use to develop our test tables. With this vocabulary and the Application Map object references, we can begin to build test tables that our automation framework and our human testers can understand and properly execute.

1.3.6 Test Tables:
Low-level Test Tables or Step Tables contain the detailed step-by-step instructions of our tests. Using the object names found in the Application Map, and the vocabulary defined by the Component Functions; these tables specify what document, what component, and what action to take on the component. The following three tables are examples of Step Tables comprised of instructions to be processed by the StepDriver module. The StepDriver module is the one that initially parses and routes all low-level instructions that ultimately drive our application.

Step Table: LaunchSite
COMMAND/DOCUMENT	PARAMETER/ACTION	PARAMETER
LaunchBrowser	Default.htm
Browser	VerifyCaption	"Login"

Table 7

Step Table: Login
DOCUMENT	COMPONENT	ACTION	PARAMETER
LoginPage	UserIDField	InputText	"MyUserID"
LoginPage	PasswordField	InputText	"MyPassword"
LoginPage	SubmitButton	Click

Table 8

Step Table: LogOffSite
DOCUMENT	COMPONENT	ACTION
TOCPage	LogOffButton	Click

Table 9

Note:
In Table 7 we used a System-Level keyword, LaunchBrowser. This is also called a Driver Command. A Driver Command is a command for the framework itself and not tied to any particular document or component. Also notice that test tables often consist of records with varying numbers of fields.

Intermediate-Level Test Tables or Suite Tables do not normally contain such low-level instructions. Instead, these tables typically combine Step Tables into Suites in order to perform more useful tasks. The same Step Tables may be used in many Suites. In this way we only develop the minimum number of Step Tables necessary. We then mix-and-match them in Suites according to the purpose and design of our tests, for maximum reusability.

The Suite Tables are handled by the SuiteDriver module which passes each Step Table to the StepDriver module for processing.

For example, a Suite using two of the preceding Step Tables might look like Table 10:

Suite Table: StartSite
STEP TABLE REFERENCE	TABLE PURPOSE
LaunchSite	Launch web app for test
Login	Login "MyUserID" to app

Table 10

Other Suites might combine other Step Tables like these:

Suite Table: VerifyTOCPage
STEP TABLE REFERENCE	TABLE PURPOSE
VerifyTOCContent	Verify text in Table of Contents
VerifyTOCLinks	Verify links in Table of Contents

Table 11

Suite Table: ShutdownSite
STEP TABLE REFERENCE	TABLE PURPOSE
LogOffSite	Logoff the application
ExitBrowser	Close the web browser

Table 12

High-Level Test Tables or Cycle Tables combine intermediate-level Suites into Cycles. The Suites can be combined in different ways depending upon the testing Cycle we wish to execute (Regression, Acceptance, Performance…). Each Cycle will likely specify a different type or number of tests. These Cycles are handled by the CycleDriver module which passes each Suite to SuiteDriver for processing.

A simple example of a Cycle Table using the full set of tables seen thus far is shown in Table 13.

Cycle Table: SiteRegression
SUITE TABLE REFERENCE	TABLE PURPOSE
StartSite	Launch browser and Login for test
VerifyTOCPage	Verify Table of Contents page
ShutdownSite	Logoff and Shutdown browser

Table 13

1.3.7 The Core Data Driven Engine:

We have already talked about the primary purpose of each of the three modules that make up the Core Data Driven Engine part of the automation framework. But let us reiterate some of that here.

CycleDriver processes Cycles, which are high-level tables listing Suites of tests to execute. CycleDriver reads each record from the Cycle Table, passing SuiteDriver each Suite Table it finds during this process.

SuiteDriver processes these Suites, which are intermediate-level tables listing Step Tables to execute. SuiteDriver reads each record from the Suite Table, passing StepDriver each Step Table it finds during this process.

StepDriver processes these Step Tables, which are records of low-level instructions developed in the keyword vocabulary of our Component Functions. StepDriver parses these records and performs some initial error detection, correction, and synchronization making certain that the document and\or the component we plan to manipulate are available and active. StepDriver then routes the complete instruction record to the appropriate Component Function for final execution.

Let us again show a sample Step Table record in Table 14 and the overall framework pseudo-code that will process it in Figure 6.

Single Step Table Record

DOCUMENT

COMPONENT

ACTION

EXPECTED

VALUE

LoginPage

UserIDTextbox

VerifyValue

"MyUserID"

Table 14

Framework Pseudo-Code

Primary Record Processor Module:

Textbox Component Module:

Validate the action keyword "VerifyValue".
Call the Textbox.VerifyValue function.

Textbox.VerifyValue Function:

Get the text stored in the "UserIDTextbox" Textbox.
Compare the retrieved text to "MyUserID".
Record our success or failure.

Figure 6

In Figure 6 you may notice that it is not StepDriver that validates the action command or keyword VerifyValue that will be processed by the Textbox Component Function Module. This allows the Textbox module to be further developed and expanded without affecting StepDriver or any other part of the framework. While there are other schemes that might allow StepDriver to effectively make this validation dynamically at runtime, we still chose to do this in the Component Functions themselves.

System-Level Commands or Driver Commands:
In addition to this table-processing role, each of the Driver modules has its own set of System-Level keywords or commands also called Driver Commands. These commands instruct the module to do something other than normal table processing.

For example, the previously shown LaunchSite Step Table issued the LaunchBrowser StepDriver command. This command instructs StepDriver to start a new Browser window with the given URL. Some common Driver Commands to consider:

Common Driver Commands
COMMAND	PURPOSE
UseApplicationMap	Set which Application Map(s) to use
LaunchApplication	Launch a standard application
LaunchBrowser	Launch a web-based app via URL
CallScript	Run an automated tool script
WaitForWindow	Wait for Window or Browser to appear
WaitForWindowGone	Wait for Window or Browser to disappear
Pause or Sleep	Pause for a specified amount of time
SetRecoveryProcess	Set an AUT recovery process
SetShutdownProcess	Set an AUT shutdown process
SetRestartProcess	Set an AUT restart process
SetRebootProcess	Set a System Reboot process
LogMessage	Enter a message in the log

Table 15

These are just some examples of possible Driver Commands. There are surely more that have not been listed and some here which you may not need implemented.

All for One, and One for All:
This discussion on the Core Data Driven Engine has identified three separate modules (StepDriver, SuiteDriver, and CycleDriver) that comprise the Core. This does not, however, make this three-module design an automation framework requirement. It may be just as valid to sum up all the functionality of those three modules into one module, or any number of discreet modules more suitable to the framework design developed.

1.3.8 The Support Libraries:
The Support Libraries are the general-purpose routines and utilities that let the overall automation framework do what it needs to do. They are the modules that provide things like:

File Handling
String Handling
Buffer Handling
Variable Handling
Database Access
Logging Utilities
System\Environment Handling
Application Mapping Functions
System Messaging or System API Enhancements and Wrappers

They also provide traditional automation tool scripts access to the features of our automation framework including the Application Map functions and the keyword driven engine itself. Both of these items can vastly improve the reliability and robustness of these scripts until such time that they can be converted over to keyword driven test tables (if and when that is desirable).

1.4 Automation Framework Workflow

We have seen the primary features of our automation framework and now we want to put it to the test. This section provides a test workflow model that works very well with this framework. Essentially, we start by defining our high level Cycle Tables and provide more and more detail down to our Application Map and low-level Step Tables.

For this workflow example, we are going to show the hypothetical test design that might make up security authentication tests for a web site. The order in which we present the information and construct the tables is an ideal workflow for our automation framework. It will also illustrate how we do not even need a functioning application in order to start producing these tests.

1.4.1 High-Level Tests -- Cycle Table

We will start out by defining our high-level Cycle Table in Table 16. This will list tests that verify user authentication functionality. There is no application yet, but we do know that we will authenticate users with a user ID and password via some type of Login page. With this much information we can start designing some tests.

At this level, our tables are merely keywords or actions words of what we propose to do. The keywords represent the names of Suites we expect to implement when we are ready or when more is known about the application.

We will call this particular high-level test, VerifyAuthenticationFunction (Table 16). It will not show all the tests that should be performed to verify the user authentication features of a web site. Just enough to illustrate our test design process.

Cycle Table: VerifyAuthenticationFunction
KEYWORDS (Suite Tables)	TABLE PURPOSE
VerifyInvalidLogin	Tests with Invalid UserID and/or Password
VerifyBlankLogin	Tests with Missing UserID and/or Password
VerifyValidLogin	Tests with Valid UserID and Password

Table 16

The preceding table illustrates that we plan to run three tests to verify the authentication functionality of our application. We may add or delete tests from this list in the future, but this is how we currently believe this functionality can be adequately verified.

1.4.2 Intermediate-Level Tests -- Suite Tables

When we are ready to provide more detail for our authentication test effort we can begin to flesh-out the intermediate-level Suite Tables. Our high-level VerifyAuthenticationFunction Cycle Table defined three Suites that we must now expand upon.

First, we plan to verify invalid login attempts--those with an invalid user ID, invalid password, or both. This first Suite was aptly dubbed, VerifyInvalidLogin (Table 17).

Second, we want to run a simple test without any user ID or password whatsoever. This second Suite was called, VerifyBlankLogin (Table 18).

The last Suite we must implement is the one that insures we can successfully login when we provide a valid user ID and password. This one was named, VerifyValidLogin (Table 19).

Suite Table: VerifyInvalidLogin
KEYWORDS (Step Tables)	USERID	PASSWORD
LaunchSite
Login	BadUser	GoodPassword
VerifyLoginError
Login	GoodUser	BadPassword
VerifyLoginError
Login	BadUser	BadPassword
VerifyLoginError
ExitLogin

Table 17

Suite Table: VerifyBlankLogin
KEYWORDS (Step Tables)	USERID	PASSWORD
LaunchSite
Login	""	""
VerifyLoginError
ExitLogin

Table 18

Suite Table: VerifyValidLogin
KEYWORDS (Step Tables)	USERID	PASSWORD
LaunchSite
Login	GoodUser	GoodPassword
VerifyLoginSuccess
ShutdownSite

Table 19

Notice that we start to see a large amount of test table reuse here. While not yet defined, we can see that we will be using the LaunchSite, Login, VerifyLoginError, and ExitLogin tables quite frequently. As you can probably imagine, VerifyLoginSuccess and ShutdownSite would also be used extensively throughout all the tests for this web site, but we are focusing just on user authentication here.

You should also notice that our Login keyword is describing a Step Table that will accept up to two arguments--the user ID and password we want to supply. We have not gone into the specific design details of how the automation framework should be implemented, but tests accepting variable data like this provide significant reuse advantages. This same table is used to login with different user ID and password combinations.

1.4.3 Application Maps

Up to this point there was little need for an Application Map. Nearly all the high-level and intermediate-level test designs are abstract enough to forego references to specific window components. But as we move towards our final level of test design we indeed must reference specific elements of the application. Thus, for test automation, we need to make our Application Maps.

Naming the Components:
Unless the application has formal design documentation that explicitly provides meaningful names for the windows and components, the test team is going to have to develop this themselves.

The team will discuss and agree upon the names for each window and component. Sometimes we can use the names developers have already given the components in the code. But the team can often come up with more meaningful and identifiable names. Regardless, once defined, the names chosen should not change. However, if the need arises, an item can always have more than one name.

Test Design Application Map:
For low-level test design and manual testing, an Application Map suitable for human consumption should be created. This is often done with screen captures of the various application windows. These screen captures are then clearly annotated with the names given to each component. This may also indicate the Type for each component.

While many components may be exactly what they look like, this is not always the case. Many controls may simply be windowless, painted elements that the underlying environment knows nothing about. They can also be custom components or COM objects that are functionally different from the controls they appear to emulate. So care must be taken when identifying the Type of a component.

Automation Framework Application Map:
For automated testing, an Application Map suitable for the automation framework will be created. We will use the Test Design Application Map as our reference for the names used to identify the components. The identification syntax suitable for the automation tool will then be mapped to each name as discussed in Section 1.3.4.

Our test design so far has indirectly identified three documents or windows that we will interact with: (1) the Login page, (2) an Error dialog or message displayed during our failed Login attempts, and (3) the Home page of our web site displayed following a successful login attempt. We will also need to reference the browser window itself throughout these tests.

We must now create an Application Map that will properly reference these items and their components for the automation framework. For the sake of simplicity, our Login page in Figure 7 will contain only the two textbox components for user ID and password, and two buttons; Submit and Cancel.

Login Page

Figure 7

The Error dialog in Figure 8 is actually a system alert dialog. It has a Label containing the error message and an OK button to dismiss the dialog.

Error Dialog

Figure 8

The Home Page of the application may contain many different elements. However, for the purpose of these tests and this example, we only need to identify the document itself. We will not interact with any of the components in the Home Page, so we will not define them in this sample Application Map.

Table 20 shows the Application Map we will use to identify the browser window and the three documents in a manner suitable for the automation framework.

Site Application Map
OBJECTNAME	IDENTIFICATION METHOD
Browser:
Browser	WindowID=WebBrowser

LoginPage:
LoginPage	FrameID=content;\;DocumentTitle=Login
UserID	FrameID=content;\;DocumentTitle=Login;\;TextBoxIndex=1
Password	FrameID=content;\;DocumentTitle=Login;\;TextBoxIndex=2
SubmitButton	FrameID=content;\;DocumentTitle=Login;\;ButtonText=Submit
CancelButton	FrameID=content;\;DocumentTitle=Login;\;ButtonText=Cancel

ErrorWin:
ErrorWin	WindowCaption=Error
ErrorMessage	LabelIndex=1
OKButton	ButtonText=OK

HomePage:
HomePage	FrameID=content;\;DocumentTitle=Home

Table 20

The physical format of the Application Map will be determined by how the automation framework will access it. It may be delimited files, database tables, spreadsheets, or any number of other possibilities.

Notice that we have identified each document with its own section in the Application Map of Table 20. We do this to avoid naming conflicts among the many components of our application. For instance, there may be many forms that contain a Submit button. Each form can name this button the SubmitButton because the names only have to be unique within each individual section of the Application Map.

With this we have now uniquely identified our components for the framework. The OBJECTNAME is how we reference each component in our low-level Step Tables. The IDENTIFICATION METHOD is the information the automation tool needs to identify the component within the computer operating system environment.

The syntax for these component identifications is different depending upon the automation tool deployed. The example syntax we used is not for any particular automation tool, but is representative of what is needed for automation tools in general. The Application Map designer will need a thorough understanding of the automation tool’s component identification syntax in order to create effective Application Maps.

New Component Types:
As we examine the application and develop an Automation Framework Application Map we may find new component types not handled by existing Component Functions. To deal with this, we need to either implement a new Component Function module for each new component type, or determine how best they can be handled by existing Component Functions. This, of course, is a job for the automation technical staff.

1.4.4 Low-Level Tests -- Steps Tables

Now that the design of our application is known and our Application Map has been developed, we can get down to the step-by-step detail of our tests. We can still develop Step Tables without an Application Map. But without the map, we cannot automatically execute the tests.

Looking back at all the Suites that detailed our high-level VerifyAuthenticationFunction Cycle Table, we see they invoke six reusable, low-level Step Tables that we are now ready to implement. These are listed in Table 21.

Step Tables Invoked by Suites
STEP TABLE	TABLE PURPOSE
LaunchSite	Launch the web app for testing
Login	Login with a User ID and Password
VerifyLoginError	Verify an Error Dialog on Invalid Login
ExitLogin	Exit the Login Page via Cancel
VerifyLoginSuccess	Verify Home Page up after Successful Login
ShutdownSite	Logoff and close the browser

Table 21

We develop these Step Tables using the component names defined in our Application Map and the keyword vocabulary defined by our Component Functions. Where test designers find missing yet needed keywords, actions, or commands in our Component Functions; the technical staff will need to expand the appropriate Component Function module, Driver Commands, Support Libraries, or find some other solution to provide the needed functionality if possible.

Now we can provide the detailed test steps that make-up our six Step Tables.

Step Table: LaunchSite
COMMAND/DOCUMENT	ARG/COMPONENT	ACTION	EXPECTED RESULTS
LaunchBrowser	Default.htm
Browser		VerifyCaption	"Login"

Table 22

Step Table: Login &user &password
DOCUMENT	COMPONENT	ACTION	INPUT DATA
LoginPage	UserID	InputText	&user
LoginPage	Password	InputText	&password
LoginPage	SubmitButton	Click

Table 23

Step Table: VerifyLoginError
DOCUMENT	COMPONENT	ACTION	EXPECTED RESULT
ErrorWin		VerifyCaption	"Error"
ErrorWin	ErrorMessage	VerifyText	"The User ID or Password was invalid."
ErrorWin	OKButton	Click

Table 24

Step Table: ExitLogin
DOCUMENT	COMPONENT	ACTION
LoginPage	CancelButton	Click

Table 25

Step Table: VerifyLoginSuccess
DOCUMENT	COMPONENT	ACTION	EXPECTED RESULT
HomePage		VerifyTitle	"Home"
Browser		VerifyCaption	"Welcome"

Table 26

Step Table: ShutdownSite
DOCUMENT	COMPONENT	ACTION	INPUT DATA
Browser		SelectMenuItem	File>Exit

Table 27

As you can see, our high-level test VerifyAuthenticationFunction has been detailed down to a very sparse set of highly reusable test steps. Our test designs have taken a high-level test specification, given that some abstract scenarios to perform, and finally provided the step-by-step instructions to execute those scenarios. We did all of this without resorting to difficult scripting languages, or complex software development environments.

It may seem simple enough, but that is because we have the underlying automation framework doing so much of the work for us.

Now that we have all of this defined, what does it actually do?

Remember, the automation framework is invoked with one or more high-level Cycle Tables. These tables call the test Suites that, in turn, call the Step Tables to perform the low-level test steps that drive the application.

We developed our own Cycle Table called VerifyAuthenticationFunction. This calls our own collection of Suites, and ultimately the Step Tables we just finished developing. If you look over all of these tables, you can see they form a relatively small set of reusable instructions that make up this test. But they generate a large instruction set at time of execution.

The following section will actually illustrate the automated execution flow of the test we have just implemented.

Table 28

Execution Flow of VerifyAuthenticationFunction Test
Cycle Table Suite Table Step Table	DOCUMENT Or COMMAND	COMPONENT Or COMMAND ARG	ACTION	INPUT DATA Or EXPECTED RESULTS
VerifyAuthenticationFunction

VerifyInvalidLogin

LaunchSite
	LaunchBrowser	Default.htm
	Browser		VerifyCaption	"Login"

Login	&user=BadUser	&password=GoodPassword
	LoginPage	UserID	InputText	&user
	LoginPage	Password	InputText	&password
	LoginPage	SubmitButton	Click
VerifyLoginError
	ErrorWin		VerifyCaption	"Error"
	ErrorWin	ErrorMessage	VerifyText	"The User ID or Password was Invalid."
	ErrorWin	OKButton	Click

Login	&user=GoodUser	&password=BadPassword
	LoginPage	UserID	InputText	&user
	LoginPage	Password	InputText	&password
	LoginPage	SubmitButton	Click
VerifyLoginError
	ErrorWin		VerifyCaption	"Error"
	ErrorWin	ErrorMessage	VerifyText	"The User ID or Password was Invalid."
	ErrorWin	OKButton	Click

Login	&user=BadUser	&password=BadPassword
	LoginPage	UserID	InputText	&user
	LoginPage	Password	InputText	&password
	LoginPage	SubmitButton	Click
VerifyLoginError
	ErrorWin		VerifyCaption	"Error"
	ErrorWin	ErrorMessage	VerifyText	"The User ID or Password was Invalid."
	ErrorWin	OKButton	Click
ExitLogin
	LoginPage	CancelButton	Click

VerifyBlankLogin

LaunchSite
	LaunchBrowser	Default.htm
	Browser		VerifyCaption	"Login"

Login	&user=""	&password=""
	LoginPage	UserID	InputText	&user
	LoginPage	Password	InputText	&password
	LoginPage	SubmitButton	Click
VerifyLoginError
	ErrorWin		VerifyCaption	"Error"
	ErrorWin	ErrorMessage	VerifyText	"The User ID or Password was Invalid."
	ErrorWin	OKButton	Click
ExitLogin
	LoginPage	CancelButton	Click
VerifyValidLogin

LaunchSite
	LaunchBrowser	Default.htm
	Browser		VerifyCaption	"Login"

Login	&user=GoodUser	&password=GoodPassword
	LoginPage	UserID	InputText	&user
	LoginPage	Password	InputText	&password
	LoginPage	SubmitButton	Click
VerifyLoginSuccess
	HomePage		VerifyTitle	"Home"
	Browser		VerifyCaption	"Welcome"
ShutdownSite
	Browser		SelectMenuItem	File>Exit

Table 28

Linux Commands

2007-07-05T23:30:00.001-07:00

This is a practical selection of the commands we use most often. Press to see the listing of all available command (on your PATH). On my small home system, it says there are 2595 executables on my PATH. Many of these "commands" can be accessed from your favourite GUI front-end (probably KDE or Gnome) by clicking on the right menu or button. They can all be run from the command line. Programs that require GUI have to be run from a terminal opened under a GUI.

Legend:
<> = single special or function key on the keyboard. For example indicates the "control" key.
italic = name of the file or variable you probably want to substitute with your own.
fixed width = in-line Linux commands and filenames.

Notes for the UNIX Clueless:
1. LINUX IS CASE-SENSITIVE. For example: Netscape, NETSCAPE and nEtscape are three different commands. Also my_filE, my_file, and my_FILE are three different files. Your user login name and password are also case sensitive. (This goes with the tradition of UNIX and the "c" programming language being case sensitive.)
2. Filenames can be up to 256 characters long and can contain letters, numbers, "." (dot), "_" (underscore), "-" (dash), plus some other not recommended characters.
3. Files with names starting with "." are normally not shown by the ls (list) or dir commands. Think of these files as "hidden". Use ls -a (list with the option "all") to see these files.
4. "/" is an equivalent to DOS "\" (root directory, meaning the parent of all other directories).
5. Under Linux, all directories appear under a single directory tree (there are no DOS-style drive letters).
6. In a configuration file, a line starting with # is a comment.

1.1 Linux essential shortcuts and sanity commands

Switch to the first text terminal. Under Linux you can have several (6 in standard setup) terminals opened at the same time.

(n=1..6)
Switch to the nth text terminal.

tty
Print the name of the terminal in which you are typing this command.

Switch to the first GUI terminal (if X-windows is running on this terminal).

(n=1..12)
Switch to the nth GUI terminal (if a GUI terminal is running on screen n-1). On default, nothing is running on terminals
8 to 12, but you can run another server there.

(In a text terminal) Autocomplete the command if there is only one option, or else show all the available options.
THIS SHORTCUT IS GREAT! It even works at LILO prompt!

Scroll and edit the command history. Press to execute.

Scroll terminal output up. Work also at the login prompt, so you can scroll through your bootup messages.

Scroll terminal output down.

<+>
(in X-windows) Change to the next X-server resolution (if you set up the X-server to more than one resolution). For multiple resolutions on my standard SVGA card/monitor, I have the following line in the file /etc/X11/XF86Config (the first resolution starts on default, the largest determines the size of the "virtual screen"):
Modes "1024x168" "800x600" "640x480" "512x384" "480x300" "400x300" "1152x864"

<->
(in X-windows) Change to the previous X-server resolution.

(in X-windows) Kill the current X-windows server. Use if the X-windows server crushes and cannot be exited normally.

<Del>
Shut down the system and reboot. This is the normal shutdown command for a user at the text-mode console. Don't just press the "reset" button for shutdown!

c
Kill the current process (mostly in the text mode for small applications).

d
Log out from the current terminal. See also the next command.

d
Send [End-of-File] to the current process. Don't press it twice else you also log out (see the previous command).

s
Stop the transfer to the terminal.

q
Resume the transfer to the terminal. Try if your terminal mysteriously stops responding.

z
Send the current process to the background.

exit
Logout. I can also use logout for the same effect. (If you have started a second shell, e.g., using bash the second shell will be exited and you will be back in the first shell, not logged out.)

reset
Restore a screwed-up terminal (a terminal showing funny characters) to default setting. Use if you tried to "cat" a binary file. You may not be able to see the command as you type it.

Paste the text which is currently highlighted somewhere else. This is the normal "copy-paste" operation in Linux. (It doesn't work with Netscape and WordPerfect which use the MS Windows-style "copy-paste". It does work in the text terminal if you enabled "gpm" service using "setup".) Best used with a Linux-ready 3-button mouse (Logitech or similar) or else set "3-mouse button emulation").

~
(tilde) My home directory (normally the directory /home/my_login_name). For example, the command cd ~/my_dir will change my working directory to the subdirectory "my_dir" under my home directory. Typing just "cd" alone is an equivalent of the command "cd ~".

.
(dot) Current directory. For example, ./my_program will attempt to execute the file "my_program" located in your current working directory.

..
(two dots) Directory parent to the current one. For example, the command cd .. will change my current working directory one one level up.

1.2 Common Linux commands--system info

pwd
Print working directory, i.e., display the name of my current directory on the screen.

hostname
Print the name of the local host (the machine on which you are working). Use netconf (as root) to change the name of the machine.

whoami
Print my login name.

id username
Print user id (uid) and his/her group id (gid), effective id (if different than the real id) and the supplementary groups.

date
Print or change the operating system date and time. E.g., I could change the date and time to 2000-12-31 23:51 using this command:
date 123123512000
To set the hardware (BIOS) clock from the system (Linux) clock, use the command (as root) setclock

time
Determine the amount of time that it takes for a process to complete + other info. Don't confuse it with the date command. E.g. I can find out how long it takes to display a directory content using:
time ls

who
Determine the users logged on the machine.

rwho -a
(=remote who) Determine all users logged on your network. The rwho service must be enabled for this command to run. If it isn't, run setup as root to enable "rwho".

finger user_name
System info about a user. Try: finger root

last
Show listing of users last logged-in on your system.

history | more
Show the last (1000 or so) commands executed from the command line on the current account. The "| more" causes the display to stop after each screenful.

uptime
Show the amount of time since the last reboot.

ps
(=print status) List the processes currently run by the current user.

ps axu | more
List all the processes currently running, even those without the controlling terminal, together with the name of the user that owns each process.

top
Keep listing the currently running processes, sorted by cpu usage (top users first). In KDE, you can get GUI-based Ktop from "K"menu under "System"-"Task Manager" (or by executing "ktop" in an X-terminal).

uname -a
(= Unix name with option "all") Info on your (local) server. I can also use guname (in X-window terminal) to display the info more nicely.

free
Memory info (in kilobytes).

df -h
(=disk free) Print disk info about all the filesystems (in human-readable form)

du / -bh | more
(=disk usage) Print detailed disk usage for each subdirectory starting at the "/" (root) directory (in human legible form).

cat /proc/cpuinfo
Cpu info--it show the content of the file cpuinfo. Note that the files in the /proc directory are not real files--they are hooks to look at information available to the kernel.

cat /proc/interrupts
List the interrupts in use.

cat /proc/version
Linux version and other info

cat /proc/filesystems
Show the types of filesystems currently in use.

cat /etc/printcap
Show the setup of printers.

lsmod
(As root. Use /sbin/lsmod to execute this command when you are a non-root user.) Show the kernel modules currently loaded.

set|more
Show the current user environment.

echo $PATH
Show the content of the environment variable "PATH". This command can be used to show other environment variables as well. Use "set" to see the full environment.

dmesg | less
Print kernel messages (the content of the so-called kernel ring buffer). Press "q" to quit "less". Use less /var/log/dmesg to see what "dmesg" dumped into this file right after the last system bootup.

1.3 Basic operations

any_command --help |more
Display a brief help on a command (works with most commands). "--help" works similar to DOS "/h" switch. The "more" pipe is needed if the output is longer than one screen.

man topic
Display the contents of the system manual pages (help) on the topic. Try man man first. Press "q" to quit the viewer. The command info topic works similar and may contain more up-to-date information. Manual pages can be hard to read. Try any_command --help for short, easy to digest help on a command. If more info needed, have a look to the directory /usr/doc. To display manual page from a specific section, I may use something like in this example: man 3 exit (this displays an info on the command exit from section 3 of the manual pages).

apropos topic
Give me the list of the commands that have something to to do with my topic.

help command
Display brief info on a bash (shell) build-in command.

ls
List the content of the current directory. Under Linux, the command "dir" is an alias to ls. Many users have "ls" to be an alias to "ls --color".

ls -al |more
List the content of the current directory, all files (also those starting with a dot), and in a long form. Pipe the output through the "more" command, so that the display pauses after each screenful.

cd directory
Change directory. Using "cd" without the directory name will take you to your home directory. "cd -" will take you to your previous directory and is a convenient way to toggle between two directories. "cd .." will take you one directory up.

cp source destination
Copy files. E.g., cp /home/stan/existing_file_name . will copy a file to my current working directory. Use the "-r" option (for recursive) to copy the contents of whole directories, e.g. , cp -r my_existing/dir/ ~ will copy a subdirectory under my current working directory to my home directory.

mcopy source destination
Copy a file from/to a DOS filesystem (no mounting necessary). E.g., mcopy a:\autoexec.bat ~/junk . See man mtools for related commands: mdir, mcd, mren, mmove, mdel, mmd, mrd, mformat ....

mv source destination
Move or rename files. The same command is used for moving and renaming files and directories.

ln source destination
Create a hard link called destination to the file called source. The link appears as a copy of the original files, but in reality only one copy of the file is kept, just two (or more) directory entries point to it. Any changes the file are automatically visible throughout. When one directory entry is removed, the other(s) stay(s) intact. The limitation of the hard links are: the files have to be on the same filesystem, hard links to directories or special files are impossible.

ln -s source destination
Create a symbolic (soft) link called "destination" to the file called "source". The symbolic link just specifies a path where to look for the file. In contradistinction to hard links, the source and destination don't not have to tbe on the same filesystem. In comparison to hard links, the drawback of symbolic links are: if the original file is removed, the link is "broken", symbolic links can also create circular references (like circular references in spreadsheets or databases, e.g., "a" points to "b" and "b" points back to "a").

rm files
Remove (delete) files. You must own the file in order to be able to remove it. On many systems, you will be asked or confirmation of deleation, if you don't want this, use the "-f" (=force) option, e.g., rm -f * will remove all files in my current working directory, no questions asked.

mkdir directory
Make a new directory.

rmdir directory
Remove an empty directory.

rm -r files
(recursive remove) Remove files, directories, and their subdirectories. Careful with this command as root--you can easily remove all files on the system with such a command executed on the top of your directory tree, and there is no undelete in Linux (yet). But if you really wanted to do it (reconsider), here is how (as root): rm -rf /*

cat filename | more
View the content of a text file called "filename", one page a time. The "|" is the "pipe" symbol (on many American keyboards it shares the key with "\") The pipe makes the output stop after each screenful. For long files, it is sometimes convenient to use the commands head and tail that display just the beginning and the end of the file. If you happened to use "cat" a binary file and your terminal displays funny characters afterwards, you can restore it with the command "reset".

less filename
Scroll through a content of a text file. Press q when done. "Less" is roughly equivalent to "more" , the command you know from DOS, although very often "less" is more convenient than "more".

pico filename
Edit a text file using the simple and standard text editor called pico.

pico -w filename
Edit a text file, while disabling the long line wrap. Handy for editing configuration files, e.g. /etc/fstab.

find / -name "filename"
Find the file called "filename" on your filesystem starting the search from the root directory "/". The "filename" may contain wildcards (*,?).

locate filename
Find the file name of which contains the string "filename". Easier and faster than the previous command but depends on a database that normally rebuilds at night.

./program_name
Run an executable in the current directory, which is not on your PATH.

touch filename
Change the date/time stamp of the file filename to the current time. Create an empty file if the file does not exist.

xinit
Start a barebone X-windows server (without a windows manager).

startx
Start an X-windows server and the default windows manager. Works like typing "win" under DOS with Win3.1

startx -- :1
Start another X-windows session on the display 1 (the default is opened on display 0). You can have several GUI terminals running concurrently. Switch between them using , , etc.

xterm
(in X terminal) Run a simple X-windows terminal. Typing exit will close it. There are other, more advanced "virtual" terminals for X-windows. I like the popular ones: konsole and kvt (both come with kde) and gnome-terminal (comes with gnome). If you need something really fancy-looking, try Eterm.

xboing
(in X terminal). Very nice, old-fashioned game. Many small games/programs are probably installed on your system. I also like xboard (chess).

shutdown -h now
(as root) Shut down the system to a halt. Mostly used for a remote shutdown. Use <Del> for a shutdown at the console (which can be done by any user).

halt
reboot
(as root, two commands) Halt or reboot the machine. Used for remote shutdown, simpler to type than the previous command.

Network apps

netscape
(in X terminal) Run netscape (requires a separate Netscape installation). The current versions of Netscape (4.x) are known to be big and buggy. They occasionally crash by vanishing (no other harm done). Also, when not connected to the network , Netscape likes to refuse to do anything (looks like it hanged)-it revives when you connect.

netscape -display host:0.0
(in X terminal) Run netscape on the current machine and direct the output to machine named "host" display 0 screen 0. Your current machine must have a permission to display on the machine "host" (typically given by executing the command xhost current_machine_name in the xterminal of the machine host. Other X-windows program can be run remotely the same way.

lynx file.html
View an html file or browse the net from the text mode.

pine
A good text-mode mail reader. Another good and standard one is elm. Your Netscape mail will read the mail from your Internet account. pine will let you read the "local" mail, e.g. the mail your son or a cron process sends to you from a computer on your home network. The command mail could also be used for reading/composing mail, but it would be inconvenient--it is meant to be used in scripts for automation.

elm
A good tex-mode mail reader. See the previous command.

mutt
A really basic but extremally useful and fast mail reader.

mail
A basic operating system tool for e-mail. Look at the previous commands for a better e-mail reader. mail is good if you wanted to send an e-mail from a shell script.

licq
(in X term) An icq "instant messaging" client. Another good one is kxicq. Older distributions don't have an icq client installed, you have to do download one and install it.

talk username1
Talk to another user currently logged on your machine (or use "talk username1@machinename" to talk to a user on a different computer) . To accept the invitation to the conversation, type the command "talk username2". If somebody is trying to talk to you and it disrupts your work, your may use the command "mesg n" to refuse accepting messages. You may want to use "who" or "rwho" to determine the users who are currently logged-in.

mc
Launch the "Midnight Commander" file manager (looks like "Norton Commander" for Linux).

telnet server
Connect to another machine using the TELNET protocol. Use a remote machine name or IP address. You will be prompted for your login name and password--you must have an account on the remote machine to login. Telnet will connect you to another machine and let you operate on it as if you were sitting at its keyboard (almost). Telnet is not very secure--everything you type goes in open text, even your password!

rlogin server
(=remote login) Connect to another machine. The login name/password from your current session is used; if it fails you are prompted for a password.

rsh server
(=remote shell) Yet another way to connect to a remote machine. The login name/password from your current session is used; if it fails you are prompted for a password.

ftp server
Ftp another machine. (There is also ncftp which adds extra features and gftp for GUI .) Ftp is good for copying files to/from a remote machine. Try user "anonymous" if you don't have an account on the remote server. After connection, use "?" to see the list of available ftp commands. The essential ftp command are: ls (see the files on the remote system), ASCII, binary (set the file transfer mode to either text or binary, important that you select the proper one ), get (copy a file from the remote system to the local system), mget (get many files at once), put (copy a file from the local system to the remote system), mput (put many files at once), bye (disconnect). For automation in a script, you may want to use ncftpput and ncftpget, for example:
ncftpput -u my_user_name -p my_password -a remote.host.domain remote_dir *local.html

minicom
Minicom program (looks like "Procomm for Linux").

File (de)compression

tar -zxvf filename.tar.gz
(=tape archiver) Untar a tarred and compressed tarball (*.tar.gz or *.tgz) that you downloaded from the Internet.

tar -xvf filename.tar
Untar a tarred but uncompressed tarball (*.tar).

gunzip filename.gz
Decompress a zipped file (*.gz" or *.z). Use gzip (also zip or compress) if you wanted to compress files to this file format.

bunzip2 filename.bz2
(=big unzip) Decompress a file (*.bz2) zipped with bzip2 compression utility. Used for big files.

unzip filename.zip
Decompress a file (*.zip) zipped with a compression utility compatible with PKZIP for DOS.

unarj e filename.arj
Extract the content of an *.arj archive.

uudecode -o outputfile filename
Decode a file encoded with uuencode. uu-encoded files are typically used for transfer of non-text files in e-mail (uuencode transforms any file into an ASCII file).

1.4 Process control

ps
(=print status) Display the list of currently running processes with their process IDs (PID) numbers. Use ps axu to see all processes currently running on your system (also those of other users or without a controlling terminal), each with the name of the owner. Use "top" to keep listing the processes currently running.

fg PID
Bring a background or stopped process to the foreground.

bg PID
Send the process to the background. Opposite to fg. The same can be accomplished with z. If you have stopped jobs, you have to type exit twice in row to log out.

any_command&
Run any command in the background (the symbol "&" means "run the proceeding command in the background").

batch any_command
Run any command (usually one that is going to take more time) when the system load is low. I can logout, and the process will keep running.

at 11:00
Execute a command at a specified time. You will be prompted for the command(s) to run, until you press d.

kill PID
Force a process shutdown. First determine the PID of the process to kill using ps.

killall program_name
Kill program(s) by name.

xkill
(in an xwindow terminal) Kill a GUI-based program with mouse. (Point with your mouse cursor at the window of the process you want to kill and click.)

lpc
(as root) Check and control the printer(s). Type "?" to see the list of available commands.

lpq
Show the content of the printer queue. Under KDE (X-Windows), you may use GUI-based "Printer Queue" available from "K"menu-Utilities.

lprm job_number
Remove a printing job "job_number" from the queue.

nice program_name
Run program_name adjusting its priority. Since the priority is not specified in this example, it will be adjusted by 10 (the process will run slower), from the default value (usually 0). The lower the number (of "niceness" to other users on the system), the higher the priority. The priority value may be in the range -20 to 19. Only root may specify negative values. Use "top" to display the priorities of the running processes.

renice -1 PID
(as root) Change the priority of a running process to -1. Normal users can only adjust processes they own, and only up from the current value (make them run slower).

c, z, s, and q also belong to this chapter but they were described previously. In short they mean: stop the current command, send the current command to the background, stop the data transfer, resume the data transfer.

1.5 Basic administration commands

printtool
(as root in X-terminal) Configuration tool for your printer(s). Settings go to the file /etc/printcap.

setup
(as root) Configure mouse, soundcard, keyboard, X-windows, system services. There are many distibution-specific configuration utilities, setup is the default on RedHat. Mandrake 1.0 offers very nice DrakConf .

linuxconfig
(as root, either in text or graphical mode). You can access and change hundreds of setting from it. Very powerful--don't change too many things at the same time, and be careful with changing entries you don't understand.

xvidtune
(in X-terminal). Adjust the settings of the graphical display for all resolutions so as to eliminate black bands, shift the display right/left/up/down, etc. (First use the knobs on your monitor to fit your text mode correctly on the screen.) To make the changes permanent, display the frequencies on the screen and transfer them to the setup file /etc/X11/XF86Config.

alias ls="ls --color=tty"
Create an alias for the command "ls" to enhance its format with color. In this example, the alias is also called "ls" and the "color" option is only envoke when the output is done to a terminal (not to files). Put the alias into the file /etc/bashrc if you would like the alias to be always accessible to all users on the system. Type "alias" alone to see the list of aliases on your system.

adduser user_name
Create a new account (you must be root). E.g., adduser barbara Don't forget to set up the password for the new user in the next step. The user home directory is /home/user_name.

useradd user_name
The same as the command " adduser user_name ".

userdel user_name
Remove an account (you must be a root). The user's home directory and the undelivered mail must be dealt with separately (manually because you have to decide what to do with the files).

groupadd group_name
Create a new group on your system. Non-essential but can be handy even on a home machine with a small number of users.

passwd
Change the password on your current account. If you are root, you can change the password for any user using: passwd user_name

chmod perm filename
(=change mode) Change the file access permission for the files you own (unless you are root in which case you can change any file). You can make a file accessible in three modes: read (r), write (w), execute (x) to three classes of users: owner (u), members of the same group as the owner (g), others on the system (o). Check the current access permissions using:
ls -l filename
If the file is accessible to all users in all modes it will show:
rwxrwxrwx
The first triplet shows the file permission for the owner of the file, the second for his/her group, the third for others. A "no" permission is shown as "-".
E.g., this command will add the permission to read the file "junk" to all (=user+group+others):
chmod a+r junk
This command will remove the permission to execute the file junk from others:
chmod o-x junk
Also try here for more info.
You can set the default file permissions for the news files that you create using the command umask (see man umask).

chown new_ownername filename
chgrp new_groupname filename
Change the file owner and group. You should use these two commands after you copy a file for use by somebody else.

su
(=substitute user id) Assume the superuser (=root) identity (you will be prompted for the password). Type "exit" to return you to your previous login. Don't habitually work on your machine as root. The root account is for administration and the su command is to ease your access to the administration account when you require it. You can also use "su" to assume any other user identity, e.g. su barbara will make me "barbara" (password required unless I am a superuser).

kernelcfg
(as root in X terminal). GUI to to add/remove kernel modules. You can do the same from the command line using the command "insmod", but "insmode" is less "newbie-friendly".

lsmod
List currently loaded kernel modules. A module is like a device driver--it provides operating system kernel support for a particular piece of hardware or feature.

modprobe -l |more
List all the modules available for your kernel. The available modules are determined by how your Linux kernel was compliled. Every possible module/feature can be compiled on linux as either "hard wired" (fast, non-removable), "module" (maybe slower, but loaded/removable on demand), or "no" (no support for this feature at all).

insmod parport
insmod ppa
(as root) Insert modules into the kernel (a module is roughly an equivalent of a DOS device driver). This example shows how to insert the modules for support of the external parallel port zip drive (it appears to be a problem to get the external zip drive to work in any other way under RH6.0 ).

rmmod module_name
(as root, not essential). Remove the module module_name from the kernel.

setserial /dev/cua0 port 0x03f8 irq 4
(as root) Set a serial port to a non-standard setting. The example here shows the standard setting for the first serial port (cua0 or ttyS0). The standard PC settings for the second serial port (cua1or ttyS1) are: address of i/o port 0x02f8, irq 3. The third serial port (cua2 or ttyS2): 0x03e8, irq 4. The forth serial port (cua3 or ttyS3): 0x02e8, irq 3. Add your setting to /etc/rc.d/rc.local if you want it to be set at the boot time. See man setserial for good a overview.

fdisk
(as root) Linux hard drive partitioning utility (DOS has a utility with the same name).

cd /usr/src/linux-2.0.36
make xconfig
(as root in X terminal). Nice GUI front-end for configuration of the kernel options in preparation for compilation of your customized kernel. (The directory name contains the version of your Linux kernel so you may need to modify the directory name if your Linux kernel version is different than 2.0.36 used in this example. You also need the "Tk" interpreter and the kernel source code installed. ) The alternatives to "make xconfig" are: "make config" (runs a scripts that asks you questions in the text mode) and "make menuconfig" (runs a text-based menu-driven configuration utility). Try: less /usr/doc/HOWTO/Kernel-HOWTO for more information.
After the configuration, you may choose to proceed with kernel compilation of the new kernel by issuing the following commands:
make dep
make zImage
The last command will take some time to complete (maybe 0.5 h, depending on your hardware). It produces the file "zImage", which is your new Linux kernel. Next:
make modules
make modules_install
Read: /usr/doc/HOWTO/Kernel-HOWTO for information on how to install the new kernel. You will probably also find it useful to read "man depmode". Configuration, compilation and installation of a new kernel is not difficult but it CAN lead to problems if you don't know what you are doing.
Compilation of a kernel is a good way to test your hardware, because it involves a massive amount of computing. If your hardware is "flaky", you will most likely receive the "signal 11" error (read the beatiful /usr/doc/FAQ/txt/GCC-SIG11-FAQ). See this for details on kernel upgrade.

depmod -a
(as root) Build the module dependency table for the kernel. This can, for example, be useful after installing and booting a new kernel. Use "modprobe -a" to load the modules.

ldconfig
(as root) Re-create the bindings and the cache for the loader of dynamic libraries ("ld"). You may want to run ldconfig after an installation of new dynamically linked libraries on your system. (It is also re-run every time you boot the computer, so if you reboot you don't have to run it manually.)

mknod /dev/fd0 b 2 0
(=make node, as root) Create a device file. This example shows how to create a device file associated with your first floppy drive and could be useful if you happened to accidentally erase it. The options are: b=block mode device (c=character mode device, p=FIFO device, u=unbuffered character mode device). The two integers specify the major and the minor device number.

fdformat /dev/fd0H1440
mkfs -c -t ext2
(=floppy disk format, two commands, as root) Perform a low-level formatting of a floppy in the first floppy drive (/dev/fd0), high density (1440 kB). Then make a Linux filesystem (-t ext2), checking/marking bad blocks (-c ). Making the files system is an equivalent to the high-level format.

badblocks /dev/fd01440 1440
(as root) Check a high-density floppy for bad blocks and display the results on the screen. The parameter "1440" specifies that 1440 blocks are to be checked. This command does not modify the floppy.

fsck -t ext2 /dev/hda2
(=file system check, as root) Check and repair a filesystem. The example uses the partition hda2, filesystem type ext2.

dd if=/dev/fd0H1440 of=floppy_image
dd if=floppy_image of=/dev/fd0H1440
(two commands, dd="data duplicator") Create an image of a floppy to the file called "floppy_image" in the current directory. Then copy floppy_image (file) to another floppy disk. Works like DOS "DISKCOPY".

Program installation

rpm -ivh filename.rpm
(=RedhatPackageManager, install, verbose, hashes displayed to show progress, as root.) Install a content of RedHat rpm package(s) and print info on what happened. Keep reading if you prefer a GUI installation.

rpm -qpi filename.rpm
(=RedhatPackageManager, query, package, list.) Read the info on the content of a yet uninstalled package filename.rpm.

rpm -qpl filename.rpm
(=RedhatPackageManager, query, package, information.) List the files contained in a yet uninstalled package filename.rpm.

rpm -qf filename
(=RedhatPackageManager, query, file.) Find out the name of the *.rpm package to which the file filename (on your hardrive) belongs.

rpm -e packagename
(=RedhatPackageManager, erase=uninstall.) Uninstall a package pagckagename. Packagname is the same as the beginning of the *.rpm package file but without the dash and version number.

kpackage
gnorpm
glint
(in X terminal, as root if you want to be able to install packages) GUI fronts to the Red Hat Package Manager (rpm). "glint" comes with RH5.2, "gnorpm" with RH6.0, "kpackage" comes with RH6.1 or must be installed separately but is the best of the three. Use any of them to view which software packages are installed on your system and the what not-yet-installed packages are available on your RedHat CD, display the info about the packages, and install them if you want (installation must be done as root).

Accessing drives/partitions

mount
See here for details on mounting drives. Examples are shown in the next commands.

mount -t auto /dev/fd0 /mnt/floppy
(as root) Mount the floppy. The directory /mnt/floppy must exist, be empty and NOT be your current directory.

mount -t auto /dev/cdrom /mnt/cdrom
(as root) Mount the CD. You may need to create/modify the /dev/cdrom file depending where your CDROM is. The directory /mnt/cdrom must exist, be empty and NOT be your current directory.

mount /mnt/floppy
(as user or root) Mount a floppy as user. The file /etc/fstab must be set up to do this. The directory /mnt/floppy must not be your current directory.

mount /mnt/cdrom
(as user or root) Mount a CD as user. The file /etc/fstab must be set up to do this. The directory /mnt/cdrom must not be your current directory.

umount /mnt/floppy
Unmount the floppy. The directory /mnt/floppy must not be your (or anybody else's) current working directory. Depending on your setup, you might not be able to unmount a drive that you didn't mount.

1.6 Network administration tools

netconf
(as root) A very good menu-driven setup of your network.

pingmachine_name
Check if you can contact another machine (give the machine's name or IP), press C when done (it keeps going).

route -n
Show the kernel routing table.

nslookup host_to_find
Query your default domain name server (DNS) for an Internet name (or IP number) host_to_find. This way you can check if your DNS works. You can also find out the name of the host of which you only know the IP number.

traceroute host_to_trace
Have a look how you messages trave to host_to_trace (which is either a host name or IP number).

ipfwadm -F -p m
(for RH5.2, seen next command for RH6.0) Set up the firewall IP forwarding policy to masquerading. (Not very secure but simple.) Purpose: all computers from your home network will appear to the outside world as one very busy machine and, for example, you will be allowed to browse the Internet from all computers at once.

echo 1 > /proc/sys/net/ipv4/ip_forward
ipfwadm-wrapper -F -p deny
ipfwadm-wrapper -F -a m -S xxx.xxx.xxx.0/24 -D 0.0.0.0/0
(three commands, RH6.0). Does the same as the previous command. Substitute the "x"s with digits of your class "C" IP address that you assigned to your home network. See here for more details. In RH6.1, masquarading seems broken to me--I think I will install Mandrake Linux:).

ifconfig
(as root) Display info on the network interfaces currently active (ethernet, ppp, etc). Your first ethernet should show up as eth0, second as eth1, etc, first ppp over modem as ppp0, second as ppp1, etc. The "lo" is the "loopback only" interface which should be always active. Use the options (see ifconfig --help) to configure the interfaces.

ifup interface_name
(/sbin/ifup to it run as a user) Startup a network interface. E.g.:
ifup eth0
ifup ppp0
Users can start up or shutdown the ppp interface only when the right permission was checked during the ppp setup (using netconf ). To start a ppp interface (dial-up connection), I normally use kppp available under kde menu "internet".

ifdown interface_name
(/sbin/ifdown to run it as a user). Shut down the network interface. E.g.: ifdown ppp0 Also, see the previous command.

netstat | more
Displays a lot (too much?) information on the status of your network.

Music-related commands

cdplay play 1
Play the first track from a audio CD.

eject
Get a free coffee cup holder :))). (Eject the CD ROM tray).

play my_file.wav
Play a wave file.

mpg123 my_file.mp3
Play an mp3 file.

mpg123 -w my_file.wav my_file.mp3
Create a wave audio file from an mp3 audio file.

knapster
(in X terminal) Start the program to downolad mp3 files that other users of napster have displayed for downloading. Really cool!

cdparanoia -B "1-"
(CD ripper) Read the contents of an audio CD and save it into wavefiles in the current directories, one track per wavefile. The "1-"
means "from track 1 to the last". -B forces putting each track into a separate file.

playmidi my_file.mid
Play a midi file. playmidi -r my_file.mid will display text mode effects on the screen.

sox
(argument not given here) Convert from almost any audio file format to another (but not mp3s). See man sox.

Graphics-related commands

kghostview my_file.ps
Display a postscript file on screen. I can also use the older-looking ghostview or gv for the same end effect.

ps2pdf my_file.ps my_file.pdf
Make a pdf (Adobe portable document format) file from a postscript file.

gimp
(in X terminal) A humble looking but very powerful image processor. Takes some learning to use, but it is great for artists, there is almost nothing you can't do with gimp. Use your mouse right button to get local menus, and learn how to use layers. Save your file in the native gimp file format *.xcf (to preserve layers) and only then flatten it and save as png (or whatever). There is a large user manual /usr/

gphoto
(in X terminal) Powerful photo editor.

giftopnm my_file.giff > my_file.pnm
pnmtopng my_file.pnm > my_file.png
Convert the propriatory giff graphics into a raw, portable pnm file. Then convert the pnm into a png file, which is a newer and better standard for Internet pictures (better technically plus there is no danger of being sued by the owner of giff patents).