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.

Locating Bugs by Comparing Coverage of Two Tests

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.

Squish tip of the week: How to automatically update screenshot verification points

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:

Squish tip of the week: 32-bit or 64-bit: Picking the Right Squish Binary Package

32bit vs 64bit squish package

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 be downloaded for both 32-bit and 64-bit computers. To get the right Squish package the word size* must match for which your application was compiled.

Squish tip of the week: How to describe your automated tests

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.


Are Unit Tests necessary, or do System Tests suffice?

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 example exceedingly large results, containing far too many false positives or false negatives. Such results give the false impression of weak unit tests and that only system tests should be written. This is of course inaccurate, as unit tests are the only practical method for validating rarely occurring situations, such as complex error cases.


Squish tip of the week: The Complete Beginner’s Guide to Support

The Complete Beginner’s Guide to Support
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 and usability problems and in supplying 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.


Exhibition & Conference: froglogic at QtDay 2016 in Florence

froglogic will be present again at the QtDay 2016 in Florence, this time from April 29th – 30th 2016.


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

QTDay GUI Testing with Squish