Squish tip of the week: Create tests against a remote environment

Your batch runs, or scheduled automated test executions can run remotely without question. But did you know you can also develop and manage tests remotely?

With the Squish Server running on the remote environment, the Squish IDE can create and execute tests remotely (you still need the ability to control the remote AUT, via remote desktop, vnc, direct access to the system, etc.)

Three simple steps:
  1. Indicate what incoming IP addresses to allow by modifying the squishserverrc file on the remote machine.
  2. Start the Squish Server on the remote machine to listen for incoming requests
  3. Point the Squish IDE to the remote machine’s IP address and port from Edit > Preferences (Mac: Squish > Preferences) > Squish > Remote Testing

    squishPreferences_RemoteTesting

(more…)

Squish tip of the week: Building a script toolbox

A different twist on the tip this week. We want to hear from you!

What are your most value added ‘toolbox’ scripts?

Implementing an automated test framework with re-usability in mind saves time down the road, especially when it comes to script maintenance. Each application should have a toolbox of re-usable scripts.
(more…)

Squish tip of the week: How to work with an already running application

Question: Is it possible for Squish to hook into (interact with) an application that was started manually?

Answer: Absolutely!

Here’s how

  1. Start the application using start*aut instead of starting it directly:
    startaut --port=<portNumber> <AUT_PATH>
  2. Register the AUT as an Attachable AUT

Going Forward

Using start*aut you can playback or interact with a running application using Squish, because the hook is already loaded and ready.

  • Update your Test Suite Setting’s Application list to use <No Application>
  • Now when you record, the Record Settings window displays where you can select to use the running application

(more…)

Squish tip of the week: Handle unexpected events

Did you know that Squish can monitor for various events and dialogs? The events can be handled, allowing scripts to continue where they left off.

For example, in a Windows application you may install an event handler to react to unexpected open message boxes using MessageBoxOpened. The example below demonstrates logging the handled event and closing the message box should the message box appear at any point in the executing script:

def handleMessageBox(messageBox):
    test.log("MessageBox opened: '%s' - '%s'" % (
        messageBox.windowText, messageBox.text))
    messageBox.close()

def main():
    startApplication("myapp")
    installEventHandler("MessageBoxOpened", 
                        "handleMessageBox")
    ...
Learn more about using event handlers

Squish tip of the week: Alter test scenario workflow to increase test effectiveness

Many times tests are implemented using a single approach to validate a desired result. Do users use the application the same way? Changes are high they don’t.

Consider enhancing your automated testing to incorporate altering workflows to validate the same end result.

Challenge:
  1. Come up with (minimum) 3 ways a test can confirm the same desired result
  2. Break each approach into a function
  3. Randomly call one of the three functions each time the test executes

(more…)

Squish tip of the week: Use environment variables in your scripts

Did you know Squish Test Scripts have access to Environment Variables?

Environment variables can contain platform-specific information of value to your test scripts.

In Python for example, os.environ["< env_var_name >"] returns a string value of the given environment variable. Each scripting language has its own variation.

Example getting PATH Environment Variable
import os

def main():
    msg = os.environ["PATH"]
    test.log("This system's PATH: " + msg)

(more…)

Squish tip of the week: Timesavers for testing Multi-lingual Qt Applications

Did you know you can test your Qt application across languages without creating localized scripts for each language?

As with many things in Squish, implementation options exist. You and your team can decide which approach works best for you.

  1. Avoiding ‘translatable’ object properties to identify objects
  2. Auto-translate objects using SQUISH_TRANSLATION_AWARE_LOOKUP
  3. Programmatically translate objects using Qt’s translation mechanism for internationalization (i18n)

While this scenario applies to Qt-based applications, similar approaches can be taken (excluding the i18n functionality), to test non-Qt applications by using a repository containing translations. Programmatically translate objects within scripts, loading the translations to each language-specific object map.

For implementation details see Testing internationalized (i8n) Qt applications

Squish tip of the week: How to Optimize your Smoke Test Suite

Large or growing automated GUI test suite? Need to pin-point key tests for smoke testing?

With each sprint, well-suited smoke tests can go a long way to ensure critical application areas are tested.

What if you could generate a report by simply executing your entire test suite, which revealed an optimal execution order for your tests? Which tests covered the most ground, and which added little or duplicate value?

What’s stopping you? You can generate an Optimized Execution Order report using Squish Coco by simply executing your Squish test suite.

Here’s how:
  1. Using Squish Coco, create an instrumented executable of your application
  2. Execute each test in your Squish test suite using the instrumented executable
  3. Load each Squish Coco execution report in the CoverageBrowser
  4. Select Tools > Optimized Execution Order

The analysis reveals the optimal execution order as well as the percent of application coverage by test:

Sample Optimized Execution Order Report

Learn more:

Video:

Squish tip of the week: How to run Squish tests from Bamboo

Did you know that you can execute Squish tests as part of your Bamboo build process?

Using the Squish Bamboo Plugin you can:

  1. Execute Squish tests from a Bamboo Job
  2. Run Squish tests against local and remote agents
  3. Review Squish results as part of your build results
  4. Monitor new, existing and fixed Squish test failures and builds
  5. View and compare Squish result history

Learn how here!