SilkTest Interview Questions Testing

Regression Testing: Here, automated testing is suitable because of frequent code changes and the ability to run the regressions in a timely manner.

Load Testing: Automated testing is also the best way to complete the testing efficiently when it comes to load testing.

Repeated Execution: Testing which requires the repeated execution of a task is best automated.

Performance Testing: Similarly, testing which requires the simulation of thousands of concurrent users requires automation.

Silk Test is the Silk Test client used by the Automation tester how wants to reduce the manual testing efforts. It provides the visual test option where automation suite can be easily created with no coding knowledge.

Where as a scripting option provides extra advantage power and flexibility to the automation suite. Visual tests can be combined with the VB.NET scripts to enhance the suite. However with Silk Test Workbench functional flows/test case can be  recorded for system under test to create tests which can be further enhance by adding verifications and test logic, and play back the tests to ensure that the applications work as per the expectation.

Silk test methodology is a six-phase testing process:

• Plan - Determine the testing strategy and define specific test requirements.
• Capture - Classify the GUI objects in your application and build a framework for running your tests.
• Create - Create automated, reusable tests. Use recording and/ or programming to build test scripts.
• Run - Select specific tests and execute them against the AUT.
• Report - Analyze test results and generate defect reports.
• Track - Track defects in the AUT and perform regression testing

Visual tests can be a series of simple recorded actions, or they can be complex, involving function calls or ActiveData.

Recording is the best way to quickly create visual tests. During recording, all actions except interaction with Silk Test Workbench are recorded. However, it is possible to interrupt recording to insert verification. You can modify a visual test after initial recording is finished.

• Recording a Visual Test - Record the actions that you want to test.
• Recording a Visual Test from the Start Screen - Record a visual test from the Start Screen.
• Recording a Visual Test that Tests Multiple Test Applications - Record the actions that you want to test for a test that uses multiple test applications.
• Navigating from a Locator to an Object Map Entry in a Visual Test - Describes how to navigate from a locator to an object map entry in a visual test.
• Configuring a Visual Test to Launch an Application that Uses the Java Network Launching Protocol (JNLP) - Applications that start using the Java Network Launching Protocol (JNLP) require additional configuration in Silk Test Workbench.
• Configuring a Visual Test to Launch in a New Browser Window - Configure a test to launch a separate browser window for tests that you will execute from Silk Central.
• Viewing Specific Steps in a Visual Test - Customize which test steps display in a visual test to only view certain steps.
• Identifying a Control for a Visual Test in the Test Application - Identify a control in the application under test to change a visible control that is used in a visual test or to manually insert a test step into a visual test that performs an action against a visible control.
• Identifying a Control for a Visual Test in Screen Preview - Identify a control in the Screen Preview to change a control that is used in a visual test or to manually insert a test step into a visual test that performs an action against a control, if the application under test is not available.
• Identifying a Control for a Visual Test with the Identify Object Dialog - Use the Identify Object dialog to identify a non-visible control, for example a container, in the application under test.
• Recording Additional Actions at a Specific Test Step - Update an existing test with additional actions when needed.
• Inserting a Screen from the Test Application into a Visual Test - Inserting a screen capture enables you to manually build a visual test that contains updated screens from the test application, which, in some cases, might be more efficient than recording the new screen.
• Recording an Object Map Item or a Locator Manually For a Visual Test - Manually capture an object map item or a locator using the Identify Object dialog box and create a corresponding test step in a visual test.
• Opening an Existing Visual Test - You can open an existing visual test from the Start Screen or the Asset Browser.
• Saving a Visual Test - Explicitly save a new or changed visual test.
• Visual Tests Overview - Provides an overview of visual tests

Silk Test Workbench uses scripts in the same manner as visual tests to mimic the actions that are performed while testing an application. It controls an application or Web page in the same way that a user would by using keystrokes and mouse actions to select menus, list items, and buttons. During recording, Silk Test Workbench generates all of the keystrokes and mouse clicks that test the application.

Silk Test Workbench's scripting language is Microsoft's Visual Basic, a robust programming language that gives you total control over any application running in the Microsoft .NET framework. .NET scripts contain the functionality of a high-level programming language as well as features designed specifically for software control and testing. Using the language, you can develop scripts that:

• Run automatically at a specified time of day.
• Run entirely unattended.
• Interact with users to receive confidential information such as IDs and passwords.

The actions taken to test an application, making menu selections, typing data, checking the way it is processed, and so on, are represented in scripts as VB.NET commands. These commands are inserted into a script and can be modified and played back.

Silk Test Workbench lets you quickly record and playback scripts. Modify scripts to include “hand-coded” statements that cannot be recorded, to make amendments to reflect changes in the test application, or to create new scripts by cutting and pasting code from existing scripts. You can also use the Identify Object dialog box to record locators or object map items for individual objects and then use the locator or object map item in a script.

Recording is the best way to quickly create scripts. Recording enables you to become familiar with how Silk Test Workbench generates code for scripts. This provides familiarity with the basics of script creation, which then allows better understanding of creating efficient test solutions, modularizing scripts, and creating independent code modules.

Scripts records each and every action performed by the user at object level. Scripts are been recorded for each test steps that includes the menu selection from the dropdown, typing the test data in the text field, clicking a button or icons or links and verifying the test results.

Below are the advantages for maintaining test procedures in scripts

1. Highly Extensible - Complex Test cases are transformed into test scripts with the help of .NET scripting.
2. Common Scripting Language - Common scripting been used between Developers and testers as VB.NET.
3. Low Maintenance - Scripts can be reused with minimal efforts if the test application is been changed.
4. High usability/Reusability – If any new test procedures are been introduced then same can easily implemented by copying or modifying the existing scripts. And even Scripts can be called to the other scripts or functions.
5. Multiple Iteration – Scripts can be executed n number of times to test a process with same or different test data.

While creating the test script there are few general guidelines that might help to create test scripts that are maintainable, reusable, and lead to stable tests.

1. Test scripts should be properly named and they should be self-explaining. Naming convention should be in such a way that it explains the tested functionality.
2. Test scripts should have proper comments which describe the test case thoroughly.
3. Test Scripts should be build in such a way the other test scripts can be started without any issue one by one without manual efforts. Proper pages/states should be loaded up when the other test script is started
4. Test Script should be inter depended with each other if still there is a dependency then test scripts need to be executed in the proper order.
5. Test Scripts should always have the verifications points which indicate the correctness of the application under test as well as the functional flow.
6. Keyword driven framework should be implemented in the scripts to create highly reusable
7. Test script should be created in such way that the maintainable is minimal and reusability is high.
8. Redundancies should be avoided.

An object map is a test asset that contains items that associate a logical name (an alias) with a control or a window, rather than the control or window's locator. Once a control is registered in an object map asset, all references to it in visual tests and scripts are made by its alias, rather than by its actual locator name.

You can use object maps to store objects that you are using often in multiple scripts. Multiple tests can reference a single object map item definition, which enables you to update that object map definition once and have Silk Test Workbench update it in all tests that reference the object map definition.

In your scripts, you can mix object map identifiers and locators. This feature enables you to keep your object maps relatively small and easier to manage. You can simply store the commonly used objects in your object maps, and use locators to reference objects that are rarely used.

Tip: To optimally use the functionality that object maps provide, create an individual project in Silk Test Workbench for each application that you want to test.

Example for object maps

The following construct shows a definition for a BrowserWindow where the locator is used:

_desktop.BrowserApplication("cnn_com").BrowserWindow("//BrowserWindow[1]")

The name of the object map asset is cnn_com. The locator that can be substituted by an alias in the object map is the following:

"//BrowserWindow[1]"

The object map entry for the BrowserWindow is BrowserWindow.

The resulting definition of the BrowserWindow in the script is the following:

_desktop.BrowserApplication("cnn_com").BrowserWindow("BrowserWindow")

If the index in the locator changes, you can just change the alias in the object map, instead of having to change every appearance of the locator in your test script. Silk Test Workbench will update all tests that reference the object map definition.

Object maps have the following advantages:

• They simplify test maintenance by applying changes made to a locator for an object map item to all tests that include the corresponding object map item.
• They ease the handling of locators in a large scale functional testing environment.
• They can be managed independent of individual scripts.
• They substitute complex locator names with descriptive names, which can make visual tests and scripts easier to read.
• They eliminate dependence on locators, which may change if the test application is modified.

You can configure Silk Test Workbench to use the locator name or the alias from the object map during recording.

To use the alias from the object map during recording:

1. Click Tools > Options.
2. Click the plus sign (+) next to Record in the Options menu tree.
   The Record options display in the right side panel.
3. Click Locator.
4. To define whether you want to record object map entries or XPath locators, select the appropriate recording mode from the Record object map entries list:

• Object map entries for new and existing objects. This is the default mode.
• XPath locators for new and existing objects.
• XPath locators for new objects only. For objects that already exist in an object map, the object map entry is reused. Choosing this setting enables you to create object maps for the main controls of an AUT, and to persist these object maps while creating additional tests against the AUT.

This behavior has the following benefits:

• Silk Test Workbench correctly reuses an object map identifier during recording, even if the locator in the object map has changed.
• A recorded script cannot contain wrong object map identifiers, and therefore will never fail to play back because of a wrong object map identifier.
• If you restructure your object map, for example by adding an additional level of hierarchy, the object map identifiers are still reused

You can use image recognition in the following situations:

• To conveniently interact with test applications that contain highly customized controls, which cannot be identified using object recognition. You can use image clicks instead of coordinate-based clicks to click on a specified image.
• To test graphical objects in the application under test, for example charts.
• To perform a check of the visible UI of the application under test.

If you want to click on a control that is otherwise not recognizable, you can use the ImageClick method with an image asset. If you want to verify that an otherwise not recognizable control exists in your application under test, you can use the VerifyAsset method with an image verification.

Image recognition methods are supported for all technology domains that are supported by Silk Test Workbench.

You can use image assets in the following situations:

• To conveniently interact with test applications that contain highly customized controls, which cannot be identified using object recognition. You can use image clicks instead of coordinate-based clicks to click on a specified image.
• To test graphical objects in the application under test, for example charts.

Image assets consist of an image with some additional information that is required by Silk Test Workbench to work with the asset.

You can create image verifications in one of the following ways:

• By using the Asset Browser.
• During recording.
• By inserting a new image verification into an existing visual test.

When the execution of an image verification in a visual test or a script fails, you can open the Image Verification Differences View to examine the differences between the expected image and the actual image found in the application under test.

To open the Image Verification Differences View, perform the following steps:

1. Open the result of the execution run in which the image verification has failed.
2. Right-click on the failed image verification step in the visual test or script.
   The Image Verification Differences View opens.
3. Compare the expected image and the actual image to see why the image verification failed.
4. Optional: If an image verification has failed because the actual image in the AUT has changed, click Save as Expected to set the actual image as the expected image.

Keyword driven testing helps non techies i.e. business analysts to get involved in automation testing

Silk Central and Silk Test support the keyword-driven testing methodology.

Keyword driven test is set of executable keywords and been executed just like any other normal test script.

There are two steps involved while creating keyword-driven tests:

1. Designing the test.
2. Implementing the keywords in the test.

The advantages of using the keyword-driven testing methodology are the following:

• Early Test Scripts Creation: Test scripts can be created even before application under test is been delivered and keyword can be implemented post to the application is been delivered.
• No Programming skill set: To create the test script no programming knowledge is required.
• Low Maintenance: It require low maintenance for longer period as only keywords need to be updated based on the application and remaining test script code remain the same.
• Easy Understandable: Non technical team can understand & read the test scripts
• High Reusability: Existing keyword can be reused in the new test case/script which ease the test coverage to larger extend.

You can pass parameters between keywords and you can pass back values from a keyword, which is implemented as a visual test or a .NET script. You cannot pass back the value of visual test global variables to a keyword, as these variables are managed by the visual test execution engine and are not visible to .NET scripts and keywords.

• If you want to pass data from one keyword to another keyword:
  • Add an output parameter to the keyword from which you want to pass data.
  • Add the same parameter as an input parameter to the keyword to which you want to pass data.
• If you want to pass back data from a keyword, which is implemented as a visual test or a .NET script:
  • Add an output parameter to the keyword from which you want to pass back data.
  • In the visual test or the .NET script, to which you want to pass back the data, create a local variable to store the data that is passed in.
  • Use the local variable within the visual test or .NET script.

On top of keyword list recommended keywords are been listed down which are been indicated by a bar graph with the filled-out portion of the graph corresponding

Based on the following point Silk Test Workbench is been recommended

1. While creating keyword driven test when first keyword is been inserted Silk Test Workbench searches for the similar keywords which are been used as the first keyword in other keyword-driven tests or keyword sequences. The keywords which are most frequently used are recommended higher.
2. Silk Test Workbench considers how similar the found keywords are.
3. If you have established a connection with Silk Central, any keywords included in keyword-driven tests, which belong to the keyword library that corresponds to the current project, are also considered.

With Silk Test Workbench, you can replay tests against web applications that use:

• Internet Explorer.
• Mozilla Firefox, both on Microsoft Windows and on macOS.
• Google Chrome, both on Microsoft Windows and on macOS.
• Microsoft Edge.
• Chrome for Android on an Android device.
• Apple Safari, both on macOS and on an iOS device.
• Embedded browser controls.

You can record tests for web applications using one of the following browsers:

• Internet Explorer.
• Microsoft Edge.
• Mozilla Firefox, both on Microsoft Windows and on macOS.
• Google Chrome 50 or later, both on Microsoft Windows and on macOS.
• A mobile browser on a mobile device.

When recording a script for cross-browser testing, Micro Focus recommends using Google Chrome, Mozilla Firefox, or Microsoft Edge, as a script recorded with Silk Test Workbench against Internet Explorer might slightly differ in comparison to a script recorded on one of the other browsers.

To repeatedly play back visual tests and scripts using data other than the literal data, you must modify the visual tests or scripts to use different data values.

ActiveData testing enables you to leverage existing data as input for powerful, comprehensive application testing solutions. With ActiveData, you can perform multiple transactions against test applications using a different set of data for each transaction without writing complicated code or compromising existing data.

You can write new data to existing data files without having to edit those data files manually.

Using ActiveData, testers can input valid or non-valid data into the test application and verify the results. This means fewer visual tests or scripts are needed to carry out a series of test conditions and less maintenance overhead.

Application testing often involves inserting data into controls in the application under test (AUT), then processing the data, and finally reporting results to ensure the AUT works as expected. Entering data while recording a test and replaying the test without any further modifications only validates that the AUT works as expected with the specific data set.

To help you in creating tests that test your AUT against a wide variety of supported scenarios and edge cases, instead of having to record individual tests for each scenario, Silk Test Workbench includes the ActiveData testing feature, which offers the following benefits:

• Test a wide variety of supported scenarios and edge cases with a single test, using a different set of data during each test run.
• Make changes the test data both directly in the ActiveData file and within Silk Test Workbench, without changing the actual test.

Visual tests provide the following advantages:

• Record and edit tests against test applications without generating a programming language based script.
• Visually set actions and values against controls in test applications at the test step level.
• See the relationship between a text-based action step in a visual test and the object of the action.
• Take greater ownership in the testing process (for users familiar with business processes being automated).
• Leverage existing scripts and all other existing test assets by using them in visual tests.
• Recapture test applications and controls during testing without requiring access to the application being tested.
• Update screen captures automatically as test applications are updated without having to rewrite tests.
• Collaborate test project issues, assignments and other test team information using flags.
• Test against an application by playing back a visual test. Visual tests can by played back for application testing at any time. Visual tests can:
  • Run automatically at a specified time of day.
  • Run entirely unattended.
  • Interact with users to receive confidential information such as IDs and passwords.

Silk Test Workbench provides the following features to support you when you are working with custom controls:

• The dynamic invoke functionality of Silk Test Workbench enables you to directly call methods, retrieve properties, or set properties on an actual instance of a control in the application under test (AUT).
• The class mapping functionality enables you to map the name of a custom control class to the name of a standard Silk Test class. You can then use the functionality that is supported for the standard Silk Test class in your test.
• Silk Test Workbench supports managing custom controls over the UI for the following technology domains:
  • Win32
  • Windows Presentation Foundation (WPF)
  • Windows Forms
  • Java AWT/Swing
  • Java SWT
• You can add code to the AUT to test custom controls.
• The Manage Custom Controls dialog box enables you to specify a name for a custom control that can be used in a locator and also enables you to write reusable code for the interaction with the custom control.

With the help of Dynamic Invoke methods can be called directly, properties can be retrieved or even properties can be set in the application under test. Moreover methods and its propertied can be called even though they are not available in the Silk Test Workbench API for this control.

In visual tests Dynamic invoke is not available.

When you record a script, a base state is automatically recorded that starts the application that you want to test. However, if your script tests multiple applications or you turn off the Execute base state functionality for any reason, you must start the test application from within your script.

1. Open the script in which you want to include the code to start the application.
2. Type Imports System.Diagnostics at the beginning of the script.
3. To define the application as a new process, type:
4. Define the full path to the application

Note: If the executable for the application that you want to test is in the same directory as Silk Test Workbench, you do not need to specify the full path.

1. To initially go to a certain Web page, set the ProcessStartInfo.Arguments property to the URL.
2. Specify the code to start the process.
3. Save the script.

The entire script to start Internet Explorer and go to Yahoo.com looks like the following:

Imports System
Imports System.Diagnostics
Public Module Main
 Public Sub Main()
   Dim _desktop As Desktop = Agent.Desktop
   Dim ieProcess As New Process()
   Dim psi As New ProcessStartInfo()
   psi.FileName = "C:\Program Files\Internet Explorer\iexplore.exe"
   psi.Arguments = "http://www.yahoo.com"
   ieProcess.StartInfo = psi
   ieProcess.Start()
 End Sub
End Module

Assuming the table has a hierarchical structure similar to HTML, you should be able to do the following:

1. Locate a cell in the row you are looking for that is easy to find, e.g. //WPFDataGridCell[@text='Obama'].
2. From that cell, move up the hierarchy one step using ...
3. Now you're in the correct WPFDataGridRow, search down again for the row's "Default" link with //WPFHyperLink[@caption='Default'].

Putting it all together, you'll get a locator like //WPFDataGridCell[@text='Obama']/..//WPFHyperLink[@caption='Default'].

Unfortunately it’s not possible to use action recording for uploading the file, but there are ways to achieve this via scripting

With _desktop.BrowserApplication()
  With .BrowserWindow()
    .DomTextField("//INPUT[@id='file-upload']").TypeKeys("c:\temp\test.txt")
    .DomButton("//INPUT[@id='file-submit']").Click()
    Workbench.Verify("test.txt", .DomElement("//DIV[@id='uploaded-files']").Text)
  End With
End With

Or you can click on the upload control to bring up the "File Open" dialog and then automate that via the Win32 API

With _desktop.BrowserApplication()
  With .BrowserWindow()
    .DomTextField("//INPUT[@id='file-upload']").Click()
  End With
End With
With _desktop.Dialog("@caption='Open'")
  .TextField("@caption='File name:'").SetText("c:\temp\test.txt")
  .PushButton("@caption='Open'").Select()
End With
With _desktop.BrowserApplication()
  With .BrowserWindow()
    .DomButton("//INPUT[@id='file-submit']").Click()
    Workbench.Verify("test.txt", .DomElement("//DIV[@id='uploaded-files']").Text)               
  End With
End With

You could add a timer to the code that uses SendKeys.SendWait - like this - adapting it a little for your test environment

Dim WithEvents timer1 As New System.Timers.Timer
timer1.Interval = 5000
timer1.Enabled = True
MsgBox("Hello. I will go bye-bye in 5 seconds.")
timer1.Enabled = False

And as a separate sub

Private Sub Timer1_Tick(sender As Object, e As EventArgs) Handles timer1.Elapsed
    SendKeys.SendWait("{ENTER}")
End Sub

It is known as ActiveData in silk test Workbench

It allows enhancing your visual tests with external data, for example from an Excel file.

ActiveData testing enables you to leverage existing data in external files as input for powerful, comprehensive application testing solutions. ActiveData testing enables you to perform multiple transactions against test applications using a different set of data for each transaction without writing complicated code or compromising existing data.

We can use cascading dynamicInvoke-calls to access the elements in the LegendCollection.

We can then also access properties of that element if the default ToString().

You might want to not use the generated IDs as identifies in the test scripts. Therefore you can tell SilkTest to not use the "id" attribute when it creates an locator (e.g during recording).

You can do this as follows:
In SilkTest Workbench: Open Tools > Options > Record > xBrowser. Add id attribute to the "Locator attribute name exclude list" text field

When you delete a test script or a visual test that includes object map entries, the associated object maps are not changed. All object map entries are persisted

It is recommended to create the object maps during the recording of a test. However, you can also create an empty object map and manually add object map entries to this map.

To create a new object map, right-click on Object map in the Asset Browser and select New Object map.