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?
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.
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.
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
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.
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.
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.