Blog

  • Global initialization and cleanup functions

    By on July 25, 2017

    Squish offers a great way to separate the main body of your test case, initialization and cleanup parts. It can be useful in many cases, simplifies complexity and improves test case readability. In combination with some scripting it can reduce one of the worst enemies of maintainability – code duplication. The init() and cleanup() functions have a huge advantage over standard functions calls. They are independent of the main() function so even if the code inside the main() throws an error, those two functions are executed. For more information about the init() and cleanup() please refer to our documentation. init() and cleanup() for a single test suite Putting some code into init() and cleanup() functions is often a first step to increase readability and maintainability of your test case. If the body of those functions is the same across different test case it might be a good idea to...

    Read more
    froglogic
  • Finding & Fixing Dependencies Between Test Cases

    By on July 18, 2017

    Works for me! Did you ever hear yourself uttering those words, or maybe you heard them from a colleague? Tests which work on one system may fail on another. This can happen for many reasons: the application under test (AUT) depends on the operating system on which it is executed. The test case code depends on the application build being tested. Or test cases depend on each other, and the order in which they are executed is important. The last issue can become a real problem: as test suites grow, it can happen that implicit dependencies are established between test cases. In this article, we’ll discuss where dependencies between test cases come from, why they are bad, and how to detect them using froglogic Squish.

    Read more
    froglogic
  • Squish GUI Testing Case Study: Topcon Agriculture Group replaces manual testing with Squish Automated Tests

    By on July 12, 2017

    Topcon Agriculture Group makes a line of Console Displays, GPS systems running embedded Linux and software written in Qt. For 5 years, Topcon has been using froglogic Squish to develop and run almost 1000 automated tests against these devices saving their field testers a lot of time: “Within the first year , we developed enough automated tests to save our field testing guys 8 hours per build!” Read the complete Topcon Case Study.

    Read more
    froglogic
  • Keyboard shortcuts in the Squish IDE

    By on July 4, 2017

    Keyboard shortcuts Since the Squish IDE is based on Eclipse it has a lot in common with it, for example the keyboard shortcuts functionality. For me keyboard shortcuts are very important, because they are a way to… boost my productivity (perceived as well as actual – at least I like to believe so), improve how much “at home” I feel with a tool, and avoid – to me – clumsy, “slow” mouse usage (locate mouse pointer, locate target, move to target, aim, click). Viewing & changing keyboard shortcuts In the Squish IDE the existing (default) keyboard shortcuts can be viewed and changed at Edit > Preferences > General > Keys:   Filtering the commands list As the above screenshot shows, there is a long list of commands which keyboard shortcuts are and can be assigned to. To quickly see only the keyboard shortcuts that relate closely to Squish one...

    Read more
    froglogic
  • Using HTML5 data attributes in Squish/Web object names

    By on June 27, 2017

    One of the more challenging aspects of creating Squish tests is the generation of stable object names. The name to identify an object should ideally never match any other object on the screen. And using a name for identifying an object should not include data that is to be used for a verification, since that would disallow doing multiple verifications if one of them fails as an object lookup error aborts the test execution. In modern Web applications it is common to use data attributes to include internal data information for web objects visualizing that data. This internal data can be useful to improve object names that are unstable or that should be isolated from expected changes in the visible text of the object.

    Read more
    froglogic
  • 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
Load More