Squish tip of the week: Automation Setup on Windows

Automation Setup on Windows
There are situations in which test scripts will hang and time out on Windows while executing. Most of this cases involve the lack of drawing/painting the application on the “screen”.

The underlying problem is that if the GUI of the application cannot be rendered, its objects do not have coordinates on the screen and testing software, like Squish, cannot find out where to perform a mouse click.

“The AUT did not respond to network communication” would be one indication of a test script execution problem in the error log.
(more…)

QtCon: Squish for Qt Training in Berlin

QtCon

On September 1st, as part of the QtCon conference, our partner KDAB hosts a day of training. This training day allows you to gain knowledge in several Qt-related topics, including automated Qt GUI testing with Squish for Qt.

froglogic‘s ISTQB-certified Senior Software Trainer Florian Turck will conduct the full-day Squish for Qt training and share his in-depth experience of effectively using Squish. Seats for the training are still available.

Register for QtCon here:

https://conf.qtcon.org/en/session/new?conference_acronym=qtcon

Bug Location with Squish Coco 3.4

Locating a software failure can be a tenuous and a time intensive operation due to the fact of the explosion of the source code size and their test suite. Also the complexity of some software imposes an organization in which the test team is separated from the development teams. In this condition, it is generally difficult to find with a simple test report the code parts responsible for a bug. A common way to facilitate the correction is to provide additional information like code dumps, execution traces, screen shots…
Code coverage metrics can also be provided. This metrics consists of recording if a source code item was executed or not. This is less precise that execution traces, but it has the advantage that this information is always available for the project on which it is also used to measure the quality of the code.
One way to use this information, is to compare a failed with a passed test. As explained in a previous post, the difference in the executed code can give a hint to the location of the bug. But on huge project with a lot of tests it is difficult to choose the pertinent tests and there is no guarantee that the failed test is executing more code as the passed tests.

A better approach is to process all coverage data globally with an algorithm which scans the execution of all passed and failed tests. I present here the philosophy of it as implemented in Squish Coco v3.4.
(more…)

Squish tip of the week: Automated Qt and QML GUI testing with Squish (Webinar)

View a full recording of the webinar* about automated Qt and QML GUI testing with Squish. During the Webinar, several questions were answered which can be found below the video.

View more Webinars and Tutorials in our Video Library.

(more…)

Visual Testing of elements and controls with Visual Verification Points

Agile Testing with Visual Verfication Points

What is Visual Testing?

Visual testing is a testing activity that aims to verify the presentation properties of a GUI object under various conditions. Testing of GUI based systems and software consists of the validation of both the GUI visual layout and its functionality.

Visual testing provides developers with the ability to monitor what was happening at the point of software failure by presenting the data in such a way that the developer can efficiently find this information.

For example, checking that a given object has the correct font size can be handled in isolation, while verifying that two objects are appropriately aligned will require comparing the position properties of both of them.
(more…)

Improved Management Of Object Names – Part 2

In a previous blog entry, we introduced an alternative, script-based, approach to maintaining a mapping of symbolic names (variables) to the actual object names (strings). By using script variables instead of free-form strings, the mapping was no longer stored in a separate text file but instead it was brought into the domain of the programming language, thus enabling a lot of tooling support e.g. for renaming symbolic names or finding references of a symbolic name in the test code.

However, there are still some annoyances related to managing object names like this, most notably caused by the fact that the actual object names are still plain strings:

Object Names As Strings Cause Trouble

  1. Composing object names is awkward and error-prone. For instance, assume that there are two object names for an imaginary Add User dialog and an OK button in the objectsmap.js file we introduced in the previous blog article:
    addUserDialog    = "{type='Dialog' text='Add User'}"
    okButton         = "{type='Button' text='OK'}"
    

    Since there can be multiple OK button objects visible at the same time, you might want to introduce a dedicated object name which specifically references the OK button in the Add User dialog by using the special container constraint. You might do:

    addUserOKButton  = "{container={" + addUserDialog + "} type='Button' text='OK'}"
    

    …i.e. use plain string concatenation. However – notice the mistake we made? The addUserDialog variable has a value which is already enclosed in curly braces, so we don’t need to (in fact: must not) specify them again when using the variable. So what we actually should have done is:

    addUserOKButton  = "{container=" + addUserDialog + " type='Button' text='OK'}"
    
  2. Implementing parametrised object names is fragile. To implement ‘parametrised symbolic names’ (which a programming language usually calls ‘functions’ or ‘procedures’ or ‘subroutines’) you could define a function such as
    def dialogName(title):
        return "{type='Dialog' text='" + title + "'}"
    

    This works well for many invocations such as dialogName(“Add User”) to generate the object name {type=’Dialog’ text=’Add User’}, but there’s a bug in here: what if the title contains a single quote character, e.g. for a dialog which is shown when a file could not be written to disk as in:

    cannotWriteFileDialog = dialogName("Can't Write File");
    // OOPS: cannotWriteFileDialog is set to {type='Dialog' text='Can't Write File'}
    

    This generates an invalid object name, causing an error at runtime.

  3. Both of these issues are only detected so late (when actually using the object name) because the object names are plain strings. Had we used some more expressive data structure, standard tools such as syntax checkers of ‘lint’-style programs might have detected the issue before we even ran the test.
    (more…)

Improved Management Of Object Names

TL;DR: Using plain script language variables over the standard objects.map file simplifies refactoring and maintenance at the expense of losing the ability to generate (or reuse) the names when recording.

NOTE: Throughout this blog article, we will use the JavaScript language for code samples. Everything shown here can be expressed in any of the programming languages shipped by Squish though, usually with only minor syntactic changes.

Object Names

To reference controls in a user interface, Squish uses so-called ‘multi property names’ in test scripts. Such names are basically strings using a dictionary-like notation to express a set of constraints which any matching object has to satisfy. For instance, the name

{type='Button' text='OK'}

matches the first found object for which the type property has the value Button and the text property has the value OK. Object names can also be nested to express relationships between objects. For instance, the name

{container={type'Dialog' text='New Document'} type='Button' text='OK'}

would match the first object with the type property Button and the text property OK which is contained (hence the container constraint) in an object whose type is Dialog and the text is New Document. This naming scheme has proven to be very powerful and is successfully used by Squish customers. It provides a number of useful benefits:

  • The naming scheme is entirely independent on the visual rendering of the control, i.e. the screen resolution or X/Y coordinates do not matter.
  • It’s also possible to use wildcards (or even regular expressions) in object names.
  • The object names are generated automatically as tests are recorded.
  • The set of properties used for generated object names is highly configurable to satisfy the automation requirements on a vast range of applications (e.g. translated user interfaces).

Using this naming scheme which is both expressive but also robust is an important tool to ensure that test scripts are easy to maintain even if the application changes (e.g. buttons get reordered). Hence, it is no surprised that object names are ubiquitous in Squish test scripts.
(more…)

Squish tip of the week: How to modify the WaitForObject timeout

Troubleshooting a script can be long and exhausting especially if there are objects which can not be found. Fortunately, we can adjust the timeout duration for waitForObject to save us some time.

By default the duration of waitForObject is 20000 milliseconds (20 seconds), which looks like this:

waitForObject(":myObject")

During the given time Squish will check if the object can be located, is visible and enabled. If this is the case, the script continues otherwise returns an error and stops.
(more…)

Squish 6.1 Beta with Visual Verification Points

About ten months after the release of Squish 6.0, we are proud and excited to make available a BETA of Squish 6.1 to you.

The main new features of this release is an innovative approach to visual verifications; convenient application window and screen control as well as general improvements to Squish.

You can read the full announcement at https://www.froglogic.com/news-events/index.php?id=squish-6.1-beta-released.html

We are looking forward to your feedback which we happily accept at squish@froglogic.com.