Blog

  • Bug Location and Patch Analysis with Squish Coco 3.4

    By on June 7, 2016

    Hamburg, Germany June 7, 2016 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...

    Read more
    froglogic
  • Review of Squish Day Munich

    By on June 6, 2016

    The first froglogic “Squish Day” is over with more than twenty people joining us in Munich, Germany.

    Read more
    froglogic
  • Squish tip of the week: Breakpoints View

    By on June 1, 2016

    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.

    Read more
    froglogic
  • froglogic expands into the Chinese market

    By on June 1, 2016

    After a great start into 2016, froglogic today announced that it will form a strategic partnership with Apera to build a localized offering of the Squish GUI Tester and Squish Coco Code Coverage tools in the markets of China, Macao, Hongkong and Taiwan.

    Read more
    froglogic
  • Squish tip of the week: How to Record after a Breakpoint

    By on May 25, 2016

    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.

    Read more
    froglogic
  • Locating Bugs by Comparing Coverage of Two Tests

    By on May 23, 2016

    The typical answer to the question: Which source code line is responsible for a bug? is Use a debugger! However, it’s not always that simple. Here’s why: Without good working knowledge of the code, it can be difficult to set a breakpoint at a pertinent location, enabling you to even start the investigation. Many problems are difficult to reproduce because the environment is unavailable or the issue doesn’t occur systematically. Issues are not always discovered by developers themselves, but instead reported by an integration team using a detail-lacking report – often requiring further interpretation. The number of source code lines containing error candidates can be reduced using Squish Coco’s coverage information: simply compare the execution of two similar tests and analyze the difference between the passed and the failed test.

    Read more
    froglogic
  • Squish tip of the week: How to add a Breakpoint in a Test Case

    By on May 18, 2016

    Adding a breakpoint in a test script is easy and can be very useful when inserting a verification point or adding missing and additional steps. Furthermore, the breakpoint functionality can be used to see the call stack and to use the Spy to examine application object property values.

    Read more
    froglogic
  • Squish Day Munich: Learn from froglogic's experts about Squish!

    By on May 12, 2016

    Do you want to learn from froglogic engineers everything about automated GUI Testing with  Squish GUI Tester and Code Coverage Analysis with Squish Coco? Join us for a day at the Squish Day in Munich

    Read more
    froglogic
  • Squish tip of the week: How to automatically update screenshot verification points

    By on May 11, 2016

    Did you know that Squish supports an easy way to deal with screenshot verification points when there are significant changes in the appearance of applications? As it is quite common that GUI’s of applications change with new releases, features and enhancements, it would be a real pain to retake all screenshots manually. The solution to this problem is to automatically update all screenshot verification points with one single command:

    Read more
    froglogic
  • Squish tip of the week: 32-bit or 64-bit: Picking the Right Squish Binary Package

    By on May 4, 2016

    Sometimes we get asked what is the right Squish binary package to download? To answer this question, we first need to find out what 32-bit and 64-bit is. The terms 32-bit and 64-bit (the number of bits is called the word size*) refers to the information processing of the processor of a computer processor, also known as Central Processing Unit or CPU. The type of processor a computer has affects not only its overall performance but can also dictate what kind of software it uses. 32-bit versus 64-bit As the number of bits increases, there are significant benefits. More bits means that data will be processed in larger chunks which also means more accurately as the system can point to or address a greater number of locations in physical memory. Software programs that require many calculations to function smoothly can operate faster and more efficiently. Squish binary packages can...

    Read more
    froglogic
  • Squish tip of the week: How to describe your automated tests

    By on April 27, 2016

    While working on automating test cases, it is important to describe them well. After some time, the number of automated test cases can be enormous. Giving your test suites and test cases self-explaining and meaningful names can help in the future when you try to find a particular test case among hundreds you already automated. How to provide an additional description of a test case? Your test cases are scripted programs written in one of scripting languages supported by Squish (Python, JavaScript, Perl, Ruby, Tcl). Therefore, at the beginning of each test case you can always have a comment section with a description. Unfortunately, this description will not be included in test case execution results.

    Read more
    froglogic
  • Are Unit Tests necessary, or do System Tests suffice?

    By on April 25, 2016

    In theory, each new or modified function should be tested. Often, the initial reaction is to have one unit test per code change. It’s not that simple however. Writing unit tests is time consuming, and only makes sense for functions containing non-trivial code or a minimum level of computational complexity. For example, writing unit tests for getter and setter functions is an inefficient use of time and produces little value. If a function is tested correctly, it does not imply the code calling it will work (in most cases because the function is called using illegal parameters) – Meaning, even if many unit tests are available, a system test may still be necessary. Also, just because a computation is correct, doesn’t mean the main application results are meaningful. Many times, I have seen an entirely correct result, which once displayed by the end application, is completely unusable. Take for...

    Read more
    froglogic
  • Squish tip of the week: The Complete Beginner's Guide to Support

    By on April 20, 2016

    Even with an exceptional GUI regression testing software like Squish there is sometimes need for support. Support is defined by an after-sales service provided by a software publisher or vendor in solving software conflicts updates and patches for bugs and security holes in the program. Many questions and requests reach us every day. The following information will help you to use our support efficiently and to ensure that you receive the best possible response times and quality from our support.

    Read more
    froglogic
  • Exhibition & Conference: froglogic at QtDay 2016 in Florence

    By on April 13, 2016

    froglogic will be present again at the QtDay 2016 in Florence, this time from April 29th – 30th 2016. Schedule April 29th – Training session with a froglogic representative at QtLab April 30th – At our booth (right in front of the conference facilities) we are showing live demos, testing BDD and embedded HMIs using Squish GUI Tester! If you would like to schedule a meeting at QtDay 2016 with a representative of froglogic, please contact us. More information about QTDay 2016 in Italy. Last years talk about Qt GUI Testing with Squish

    Read more
    froglogic
  • Squish tip of the week: How to use the Squish Documentation

    By on April 13, 2016

    Are you feeling lost or overwhelmed by the many different functionalities in Squish? We from froglogic know there are lots of features in Squish, and sometimes you can easily get lost in all the functions and extensions which Squish supports. Nevertheless, we are working hard to make sure that our customers always get what they need or look for and that is why we have an extensive Online Documentation with Search capability. The easiest way to use the Squish Documentation or Manual is by navigating into the different topics using the Table of Contents on the left of the main Squish Documentation page. There is also an A-Z Index which lists all terms and functions and if you already know what you are looking for there is a great search function in place.

    Read more
    froglogic
  • Squish tip of the week: 3 Steps to Mask a Screenshot Verification Point

    By on April 6, 2016

    Did you know that you can set masks on screenshot verification points? With the masks functionality provided in Squish it is possible to apply positive and negative masks on screenshot verification points to ignore or focus on specific areas of an image comparison which allows us to make screenshot verifications more reliable and robust.

    Read more
    froglogic
  • Exhibition & Conference: froglogic at BIOMEDevice 2016 Boston

    By on April 4, 2016

    froglogic is attending BIOMEDevice 2016 in Boston, Massachusetts April 13th & 14th. Come find us at Booth 120 showing live demos, testing BDD and embedded HMIs using Squish GUI Tester!

    Read more
    froglogic
  • Squish tip of the week: Screenshot Verification Point

    By on March 30, 2016

    The most commonly used verifications in Squish are object property verifications – comparing the object properties values with an expected value. Those verification points can easily be inserted into a test script using the Squish IDE’s point & click interface. This method is sufficient and for most scenarios best practise. Nevertheless, sometimes it can be useful to have an additional screenshot verification point in place to be able to compare visually how an image (or logo) appears with an expected outcome or image.

    Read more
    froglogic
  • Squish tip of the week: Browser Support in Squish for Web

    By on March 23, 2016

    Did you know that Squish for Web supports all standard web browsers like Firefox, Safari, Google Chrome, Opera and even Internet Explorer?

    Read more
    froglogic
  • Squish tip of the week: 10 reasons why using a version control system is awesome!

    By on March 16, 2016

    Why is it important to use a version control system also known as source control or revision control? Please ask yourself: 1. Have you ever had to maintain multiple versions of a product? 2. Have you ever lost code or had a backup that was too old? 3. Have you ever made a change to code and realized, it was a mistake and wanted to revert back? 4. Have you ever wanted to experiment with a new feature without interfering with working code? 5. Have you ever wanted to see the difference between two, or more, versions of your code? 6. Have you ever wanted to see how much work is being done, where, when and by whom? 7. Have you ever wanted to prove that a particular change broke or fixed a piece of code? 8. Have you ever wanted to share your code or let other people...

    Read more
    froglogic
Load More