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


Squish tip of the week: How to use the Squish Documentation

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.


Squish tip of the week: 3 Steps to Mask a Screenshot Verification Point

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.


Squish tip of the week: Screenshot Verification Point

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.


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

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 work on your code?
9. Have you ever wanted to submit a change to someone else’s code?
10. Have you ever wanted to review the history of some code?