Blog

  • Accessing a SQL database from your JavaScript Test

    By on June 19, 2017

    A common task in GUI tests is to automate entering some data into forms. To properly test and verify such scenarios, it is often necessary to interact with the database backend from the test. As an example, let’s take the evaluation form on our website and assume we’d like to write a test for this. So whenever a visitor fills out the evaluation form, among other things the entered information is put into an SQL database. Let’s assume the following tables in the database backing the evaluation request form. CREATE TABLE evaluation_requests ( id CHAR(36), insertTime timestamp DEFAULT CURRENT_TIMESTAMP, name VARCHAR(255), email VARCHAR(255), company VARCHAR(255), countryCode CHAR(2), productId SMALLINT, PRIMARY KEY (id) ); CREATE TABLE countries ( id CHAR(2), name VARCHAR(255) ); CREATE TABLE products ( id SMALLINT, name VARCHAR(255) ); And let us take the following scenario as the test we want to automate: Feature: Creating Evaluation Requests...

    Read more
    froglogic
  • Squish Tip: Using startSection/endSection to improve test result readability

    By on June 13, 2017

    Sections are especially useful for marking groups of related results in data-driven testing, and also for describing a hierarchy of test results, where simple log messages will simply not suffice.

    Read more
    froglogic
  • Approaches to creating BDD Scenarios

    By on June 6, 2017

    Behavior Driven Development uses conversations around concrete examples of system behavior to get a common understanding of features that are going to be implemented. This is the heart of BDD, as the quality of those examples affects the whole development process. How to organize this conversation in practice? There are three approaches, that I would like to present. The whole team workshop This approach is good for teams new to BDD. At an early stage of iteration gather everyone involved (Bussines Analysts, Developers, Testers) to start a conversation about scenarios that examine a feature to be implemented. As everyone involved gives input and instant feedback, high-quality examples are created as a result of this meeting. Additionally, it gives the team a shared understanding of the features. But it comes at a high cost: such a meeting is hard to organize (people are busy) and expensive (people hours). Three Amigos...

    Read more
    froglogic
  • Squish Tip: Silent verifications

    By on May 30, 2017

    Motivation The verification functions provided by Squish have built-in logging that can be augmented or customized, one of this customizations allows to silence the logging of test.vp() calls. In Squish the synchronization between the test script and the application is mostly done via the use of the waitForObject() functions. This means that your test script waits for a specific condition, such as an object (a popup for example) to exist, before executing further actions. In some cases a synchronization needs to be made based on the result of e.g. an image verification. We would achieve it by polling the results of a test.vp() call, for example: # -*- coding: utf-8 -*- def main(): startApplication("MyApplication") while test.vp("MyTest"): continue #following actions But this has the side-effect of reducing the readability of the test report due to the default logging of each call to test.vp(). Squish provides a setting to silence the logging of any test.vp() call...

    Read more
    froglogic
  • Squish Tip: Customizing QtQuick support

    By on May 23, 2017

    Motivation Squish supports automating QtQuick 2.x based applications out of the box. One frequently asked question is about custom QML components or custom QtQuick controls and how Squish supports these. Testing QtQuick with Squish is very similar to Web testing in this regard. By default, Squish will record on the basic elements that a component is made of. For custom controls this means that Squish will usually record on some BackgroundImage, Text or Rectangle item instead of the expected control. By extending Squish and giving it knowledge of these custom types, we can record test scripts that are easier to understand and maintain.

    Read more
    froglogic
  • Squish Tip: Testing Tooltips on Windows

    By on May 16, 2017

    For many Windows controls (i.e. GUI components) Squish exposes the tooltip property. That property can be checked during a test execution using standard Property Verifications. But how can you check whether the tootlip is really displayed to the end users? You first have to trigger (i.e. display) the tooltip by moving the mouse cursor over a component (see the line 17 in the code below for our Addressboook example), then you can iterate over all top-level objects and check their class names (see the loop at line 3). Native Windows tooltips are of the window class “tooltips_class32” and tooltips from Windows Forms have class names like “WindowsForms10.tooltips_class32.app.0.b7ab7b”. So usually they have the part “tooltips_class32” in common and that can be used to identify top-level tooltip windows. Once you have identified the tooltip window, you can just check its text property (see the line 7). function verifyTooltip(tooltipText) { var topLevels = object.topLevelObjects(); for...

    Read more
    froglogic
  • Squish Coco: MC/DC Coverage and Short Circuit Explained

    By on May 9, 2017

    Modified Condition/Decision Coverage (MC/DC) is a code coverage metric that is referred to in many safety standards as the highest level of quality. It was first defined to provide an intermediate metric between condition and multiple-condition coverage for integrated circuits. Whereas plain condition coverage was considered too simple, the Multiple-Condition Coverage has the drawback of a potential exponential explosion of test cases. MC/DC is a compromise that guarantees a number of test cases that merely grows linearly with the number of conditions, while still achieving a higher level of confidence compared to basic Condition Coverage. Here is the DO-178C standard definition of MC/DC: Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken all possible outcomes at least once, every decision in the program has taken all possible outcomes at least once, and each...

    Read more
    froglogic
  • Testing same named AUTs in Squish

    By on May 2, 2017

    We often get asked what is the best approach for testing two AUTs with same name in Squish. Consider an example where a user wants to test two different versions of an AUT located at two different paths and both AUTs are calledfoo.exe. The information about the registered AUTs is stored in the filesquishserver.ini found at %APPDATA%\froglogic\Squishver1\server.ini (Windows) or “$HOME/.squish/ver1/server.ini” (Unix)). The registered entry for AUT foo version in the file squishserver.ini looks like below: AUT/foo = “C:\applications\version1” After registering the AUT foo for version2 in squish, the previously registered entry for foo.exe version1 will get overwritten by the entry for foo.exe version2. The registered AUT entry for foo in thesquishserver.ini will now look like below: AUT/foo = “C:\applications\version2” This causes only the last registered AUT to be tested, and switching between the two AUTs requires re-registering the AUTs each time which can be inconvenient. The following approach can...

    Read more
    froglogic
  • Support for testing Chromium-based desktop applications with Squish for Web

    By on April 25, 2017

    Motivation Adding HTML/Web support to a desktop application, or even providing a desktop application that’s almost completely built with Web technologies, is quite a popular way of providing modern and fast-evolving user interfaces and applications. There are some projects that embed an almost complete web browser into the application, while others focus on providing a ready-made shell for showing a web application to users on desktop platforms. Many of these projects use the Chromium browser component that Google Chrome is based on, for example Chromium Embedded Framework, Electron or nw.js to name just a few. One thing these Chromium-based frameworks have in common is that they remove or disable some of the features that a full-blown browser has, for example, they usually do not provide support for installing extensions into the browser. That has been a problem for Squish for Web so far since it heavily relies on information...

    Read more
    froglogic
  • How to design good BDD steps

    By on April 18, 2017

    Some time ago I started to work on a new product and we decided to do the tests with BDD. I learned some lessons from the experience of doing real world BDD tests. Designing good BDD steps is especially an ongoing process. In this blog article I want to share some insight I gained. This article is for readers already familiar with the basics of BDD and Gherkin. Short steps for easy scenario variations If your steps do just a single simple action, it is easy to combine them to new scenarios: you can achieve variations of scenarios without writing new step implementations. Take for example a web site where you can add comments to articles, reply to comments, and modify comments and replies. One scenario could be: Feature: ... Scenario: Reply to edited comment ... When I log in as Arthur Dent And I add a comment to the first article with...

    Read more
    froglogic
  • Squish adds support for web testing with Microsoft Edge

    By on April 11, 2017

    So far Squish for Web, which supports a wide range of web browsers for automated Web testing, didn’t support Microsoft Edge. The Edge browser was introduced with the release of Windows 10 and is replacing Internet Explorer as the default browser on Windows. With the upcoming release of Squish 6.3 we will finally add official support for the new browser from Microsoft. The Edge browser will be the first browser that Squish automates using the Webdriver API. The same API will also be used to add support for the Chromium Embedded Framework. We leverage this technology in the future to further improve our ability to do web testing on mobile devices. Webdriver Squish uses a wide range of techniques to be able to automate the different supported browsers. While Squish uses a COM-Interface to automate Internet Explorer, for both Chrome and Firefox custom browser plugins were developed. What all the different...

    Read more
    froglogic
  • How to execute only desired BDD scenarios

    By on April 4, 2017

    When doing BDD testing sometimes there is a need to execute only certain scenarios instead of all the scenarios of the feature file. Tags are a great way to organize/group your Scenarios. One can use squishrunner’s  – -tags option to execute just those BDD secnarios which match a given tag filter. Setting a tag filter for BDD scenarios: In the example below @foo and @bar tags are used to tag scenarios. Feature: Filling of addressbook As a user I want to fill the addressbook with entries @foo Scenario: Initial state of created address book Given addressbook application is running When I create a new addressbook Then addressbook should have zero entries @bar Scenario: State after adding one entry Given addressbook application is running When I create a new addressbook And I add a new person 'John','Doe','john@m.com','500600700' to address book Then '1' entries should be present @foo @bar Scenario: State...

    Read more
    froglogic
  • Debugging Coco with the verbose build mode

    By on March 28, 2017

    When an application is instrumented with Squish Coco and problems arise, it is often helpful to run the compilation in the verbose build mode. This is especially useful when some of the program files are excluded from the instrumentation. With the verbose build enabled, one can see which files are read, which of them are included in the instrumentation, and which command line option was responsible for the inclusion. This also helps to find the reason why a function was not included in the code coverage.

    Read more
    froglogic
  • Verifying Custom Properties of a QObject in Squish

    By on March 23, 2017

    If you’re testing a Qt-based application with Squish, you probably know the problem: one of your classes has custom properties you would really like to verify, but you cannot seem to get hold of it from a test script. First the bad news: making it available requires changing your application. The good news: the required changes are really simple! Consider this example class. It has a collection of members and properties which can be used just fine from C++ code: class FrogView { Q_OBJECT public: enum FoodType { Fly, Grasshopper }; FrogView(QWidget *parent = 0); QString name(); void setName(QString name); QList<QString> preferredFood(); signals: void quack(); public slots: void feed(FoodType type); private: QString m_name; }; Note: You probably noticed at once that we should really use the FoodType enum as return type for preferredFood() instead of returning plain strings. That is true of course, but let’s keep it this way...

    Read more
    froglogic
  • Code Coverage Case Study: Learn How InnovMetric Software Benefits from Squish Coco

    By on March 21, 2017

    InnovMetric Software Inc., the leading provider of universal 3D metrology software solutions, started to use froglogic’s Code Coverage Tool Squish Coco in 2015. The main objective was to understand how much of their applications’ code is properly tested by their 15,000+ tests. After some time InnovMetric’s engineers concluded: “Coco seemed like a regular code coverage tool at first, but after we started using it, we found some very advanced features.”. Read the whole story at https://www.froglogic.com/squish/success-stories/coco-case-study-innovmetric/.

    Read more
    froglogic
  • Hybrid Qt on Android App Testing

    By on March 14, 2017

    Squish-6.1 for Android now has support for the UIAutomator framework for Android 4.3 or newer. Qt applications running on Android have C++ and Java code bundled together and running side-by-side. Squish can access objects from each language, but from a single test case, we must distinguish between these two parts of an application somehow. We achieve this with the Application Context. Testing an application running on Android with Squish requires usage of the built-in hook to access Qt objects from Squish. Squish can access such a running app from a test script, using the attachToApplication function.

    Read more
    froglogic
  • Automatically create and update JIRA tickets based on Squish test results

    By on March 7, 2017

    Squish can be used for creating and updating JIRA tickets in response to fails and errors of nightly scheduled test runs automatically. It is possible to give an automated build test its own corresponding JIRA ticket.  These tickets can be assigned automatically to specific people, based on latest errors or changes which happened. In addition, overall statistics for the entire test suite’s life-cycle is available.

    Read more
    froglogic
  • Squish and Functional Mockup Interfaces (FMI)

    By on February 28, 2017

    When testing an application that interfaces with external devices, one often doesn’t want to use an actual device. A typical testing setup in such cases would encompass a simulation tool that mocks the device(s) in a predictable and controllable way. Testing using simulated devices have a range of benefits: No need for an actual device, No risk of damaging the device with erroneous commands, Simulation can mock rare conditions: e.g. device malfunction, Simulation can provide the test environment with it’s current state, Simulation can be controlled by the test environment. There is a large number of tools available on the market that allow simulation of various devices, especially used in embedded software development. Many of those tools are capable of communicating with other tools using Functional Mockup Interfaces – FMI. FMI Interface Functional Mock-up Interface (FMI) is a standard describing binary interface between simulation applications. It allows sharing the simulation data and...

    Read more
    froglogic
  • We met Squish users in Poland for “UI Behavior Driven Testing” workshop

    By on February 27, 2017

    On Wednesday, 22 February 2017, our Squish experts Tomasz Pawlowski and Jakub Topolski conducted a “Squish in Action: UI Behavior Driven Testing” one-day workshop. We met with 16 participants in the beautiful city of Gdansk (Poland). Shortly after 9am we started with a decent theoretical introduction to Behavior Driven Development. After that, we split up the participants into 4 groups with a task to create BDD Scenarios in the Gherkin language. The participants then were introduce to the Squish GUI Tester to start automating those Scenarios. In the meantime we had Pizza giving us some time to relax and do some networking. After the break, we presented how to implement each Scenario giving our participants some time to practice the same with their own Squish installation. While doing that we demonstrated how to interact with objects, widgets, properties & the API. With Squish’s true object-level access and Behavior Driven Testing...

    Read more
    froglogic
  • Define your own Symbolic Names

    By on February 21, 2017

    Usually when Squish adds an object to the Object Map, Symbolic Name is created as a combination of its properties (e.g. caption and type of the selected object). Thanks to that, most of the time it’s easy to identify objects behind these names. However, there are cases where it is not enough. We would like to show you a different approach of defining your own Symbolic Names, even before you start to write your first functional test case. On the image below you can see an “Address Book – Add” dialog from our example application – Addressbook. Here is a list of Symbolic Names of objects located in this dialog. :Address Book - Add.Cancel_JButton :Address Book - Add.Email:_JLabel :Address Book - Add.Email:_JTextField :Address Book - Add.Forename:_JLabel :Address Book - Add.Forename:_JTextField :Address Book - Add.OK_JButton :Address Book - Add.Phone:_JLabel :Address Book - Add.Phone:_JTextField :Address Book - Add.Surname:_JLabel :Address Book -...

    Read more
    froglogic
Load More