Squish tip of the week: How to Automate a Modern UI Windows Store App

Did you know that Squish supports automating Modern UI/Windows Store apps (also called Metro applications) when used on the Windows desktop*?

If an application offers information about its GUI objects via UI Automation, it is possible to automate the application with Squish and the supported Microsoft’s UI Automation API.

How to inspect an Application or GUI Control for UI Automation Support

With the Microsoft Inspect tool (direct download) it is possible to check whether an application (or a particular GUI control in an application) exposes/supports UI Automation.

Squish tip of the week: How to look up Windows control class names

When a window is created, an application defines a window class, which is registered with the system. This class defines various properties of the window like the window title, background color, cursor and the window class name itself.

But how to get a Windows control class name?

Class names of Windows controls can be looked up with tools like Spy++ or AU3_Spy.

froglogic enters partnership with E.S.L. to expand into Israel

Hamburg, Germany (2016-06-14)

E.S.L. and froglogic GmbH today announced a strategic partnership to distribute and support froglogic’s Squish GUI Tester and Squish Coco products in the market of Israel. E.S.L. will promote and resell Squish GUI Tester and Squish Coco in Israel and provide local, technical support services to their customers.

Squish GUI Tester is the market leading, functional test automation tool for cross-platform and cross-device GUI testing on desktop, embedded, mobile platforms and web browsers.

Squish Coco is the professional, cross-platform C, C++, C# and Tcl code coverage analysis tool. Both tools are used in more than 3,500 QA and development organizations around the world.


Squish tip of the week: Show View Action

Squish provides various views which are not shown all the time to unclutter and tidy up the Squish interface. However, sometimes specific views are needed. So how do you access them?

The easiest way is the so-called “Show View action” which is useful to open a view that isn’t already open.

One way to open a new view is by clicking Window > Show View and to choose from the listed submenu. If the wanted view is not visible, click the “Other…” option to pop up the Show View dialog.

Bug Location and Patch Analysis with Squish Coco 3.4

Hamburg, Germany June 7, 2016
Squish Coco 3.4 Release

froglogic is excited to announce version 3.4 of Squish Coco, its multi-platform C, C++, C# and Tcl code coverage analysis tool.

Besides several smaller improvements, this new release of Squish Coco features two innovative, new features to help developers use code coverage data to analyze the impact of source code patches and find potential bug locations in the source code:

  • Extended Patch Analysis.
    With this feature, a source code patch can be analyzed to find out which tests have covered the modified code. The analysis identifies the impact areas of the changes and the associated vulnerabilities. This extends the Squish Coco 3.3 pre-commit patch analysis feature, which analyzed the impact of a patch only before it was committed.
  • Bug Location.
    This feature allows computing, based on coverage data, a list of source code lines which are most likely responsible for a failure in the test suite and therefore likely are the location of buggy source code.
  • Two More Report Modes.
    The HTML coverage report now has a new tree display mode for functions and for source files, in addition to the existing modes. The tree display makes navigation easier especially in large projects.

The release notes of Squish Coco 3.4 can be found at http://doc.froglogic.com/squish-coco/3.4/releasenote.html.

To evaluate Squish Coco 3.4, please visit Evaluate Squish Coco.

Squish tip of the week: Breakpoints View

Usually, breakpoints are good for debugging or extending an existing test case with further actions. However, what if you want to run several test cases or a test suite with breakpoints or want to disable certain breakpoints in specific test cases?

Sure, you could do this by opening every single test case and selecting or deselecting breakpoints. But wait, there is a more convenient way of doing this and to see, skip or remove breakpoints in bulk.

Squish tip of the week: How to Record after a Breakpoint

In some cases it is necessary to extend an existing test case with further actions. However, it would be tedious to have to re-record the entire test from scratch. For example just to click an additional icon or button in the test.

One solution it to edit the test script and add a few lines with the additional actions that are required. However, sometimes it is more convenient to simply record the extra actions at the point in the script where they are required.

Recording within an existing test is possible by placing a breakpoint in an existing test script at the point where the newly recorded actions should be inserted. Once the breakpoint is in place, execute the test which will then stop running as soon as the breakpoint is reached.