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