MyTechFinds.com

Probably most of you (SilkTest savvy) people will agree with me that working with SilkTest and creating a reliable UI Test Automation suite with SilkTest is not an easy task. Though SilkTest has usual record-playback feature, it is much more powerful than that. Following are some of the tips/guidelines to take your SilkTest automation one step closer to success (now, how we measure test automation success is a whole different topic..:) and not covered here). 

Folder Structure

• Declarations - Keep the object declarations of the application in a single include (.inc) file. This makes it easier to manage the include file for the module or application under test. Do not put the functions in the object declarations file. Keep the functions in a separate .inc file. And include it in the object declarations file using a “use” statement.

• Test - The script files definition depends on the test strategy. You can have a single script file per module. Keep the script files (.t) in a separate folder.

• TestPlan - Keep the test plan (.pln) files in a separate folder.

• Suite - Keep the suite (.s) files in a separate folder.

• Input - Keep all the input data files (.txt/.ini) used by the test scripts in a separate folder.

• Output - Redirect the user generated message or result files in a separate folder.

In general, the goal any file structure is to minimize the places in which you need to make a particular change. You need to keep the balance granularity with ease-of-use, separating everything into separate files may give you greater control over the code but it also makes it difficult to track which file contains what code.

Make right selection of SilkTest options

• Extensions

  • Decide on the “primary extension” (DOM/Virtual Object) to use before starting the automation.
  • Decide the properties for the primary extension. (Enabling Java Plug-in…etc)

• Agent options

  • Set the agent options.

• Window declarations

  • Use multitag declarations.

  • Use window ID and index in the multitag declarations.

• Try to avoid caption and/or location in the multitag declaration, as the caption is language specific and which can change on a locale build.

After configuring SilkTest, save these settings as an option set. This will help to maintain the SilkTest configuration on different machines.

Making the automation framework generic

Step 1 : Making the declarations language independent: The declarations for the window tags and the body text tags contain the strings. If these strings change, the script is going to fail. So keep such strings in a separate file, may be an .ini file. Replace such tags with the functions returning the actual string from the .ini file.

Example:
[-] window BrowserChild LoginPage
  [ ] tag GetMainTag()

Step 2 : Making the declarations machine independent: In case of a web-based application, the declarations for the images contain the machine specific data such as the URL. If the URL is changed, the identifiers fail to match with the declarations and the script fails. So keep such machine specific information in a separate file, may be an .ini file. Replace the machine specific part in the declarations with the function returning the correct information. If the URL changes, just edit the .ini file for the new URL and the declarations will still work.

Example:

[-] HtmlImage ArrowOne
  [ ] tag "{GetURL()}images?listboxArrowWhite.gif[2]"

Step 3 : Designing functions and methods: Creating general use methods and functions is a good way to reduce the size of the script and increase the reusability of the code. When writing functions and methods:

• Keep the method or function as generic as possible by passing parameters.

• Consider passing a record rather than separate variables if multiple variables are needed. Passing records instead of separate variables makes the method or function more maintainable. If an additional variable is needed later, it’s easy to add a variable in the record than changing a function declaration. So the programming interface is unchanged.

• Consider creating sets of functions that can work together rather than creating a single function doing everything but is less flexible.

• Avoid using the object names in the declarations in the functions. Instead use window IDs in the functions.

Example:

[-] type USER is record
  [ ] STRING sUName
  [ ] STRING sPassword
[-] public Login(USER nUser)
  [ ] Browser.SetActive()
  [ ] // // Creating a user of type USER
  [ ] Browser.HtmlText(“$uname”).SetText(nUser.sUName)
  [ ] Browser.HtmlText(“$pass”).SetText(nUser.sPassword)
  [ ] Browser.HtmlPushButton(“$submit”).Click ()
[-] main()
  [ ] // // Creating a user of type USER
  [ ] USER admin
  [ ] 
  [ ] // // Setting the field values
  [ ] admin.sUserName=GetUserName()
  [ ] admin.sPassword=GetPassword()
  [ ] // // Passing the record to the function
  [ ] Login(admin)

Generalizing Your Test Cases: Use Data Driven Testing

Segue SilkTest now supports data driven testing. In the past we had to read the data from the file and use that in the testcase, which is a bit tedious method of using the same testcase for different sets of data. Now, SilkTest has an option to make the testcase data driven. Further, the testcase can pull the data from a spreadsheet or a database, making it easier to maintain the test data.

 
Example: 
[-] type SEARCHINFO is record
  [ ] STRING sText// Text to type in document window
  [ ] STRING sPos // Starting position of search
  [ ] STRING sPattern// String to look for
  [ ] BOOLEAN bCase// Case-sensitive or not
  [ ] STRING sDirection // Direction of search
  [ ] STRING sExpected // The expected match 
// // Passing a record to the testcase 
[-] testcase FindTest (SEARCHINFO Data)
  [ ] TextEditor.File.New.Pick ()
  [ ] DocumentWindow.Document.TypeKeys (Data.sText+Data.sPos)
  [ ] TextEditor.Search.Find.Pick ()
  [ ] Find.FindWhat.SetText (Data.sPattern)
  [ ] Find.CaseSensitive.SetState (Data.bCase)
  [ ] Find.Direction.Select (Data.sDirection)
  [ ] Find.FindNext.Click ()
  [ ] Find.Cancel.Click ()
  [ ] DocumentWindow.Document.VerifySelText({Data.sExpected})
  [ ] TextEditor.File.Close.Pick ()
  [ ] MessageBox.No.Click () 

Call the testcase from a plan file as,

 
[-] Standard FindTest
  [ ] script:..\scripts\find.t
  [ ] testcase:FindTest
  [ ] testdata:{'Test Case','END','C',TRUE,'Up','C'}

In this sample data driven testcase, the testcase data is stored in a list within the script itself. It is also possible to store the data externally and read records into the list.