What is Code Folding
Code folding is the ability to expand and collapse certain code in programming constructs. This improves readability when a test script contains numerous functions or other blocks of code and comments that you want to hide when you are not currently working with that part of the file.
How to Expand and Collapse Code in Squish
You can collapse and expand code fragments in Squish so that you can view different sections of your test script without having to use the scrollbar.
To expand or collapse code, click the plus or minus sign that appears to the left in the test script editor.
To expand or collapse all of the code, place your cursor anywhere within the test script, right-click, and then select “Expand All” or “Collapse All“.
Example of expanding and collapsing Code in Squish (click to enlarge)
Many companies are moving away from hiring pure manual testers and prefer testers with test automation skills.
Learning a programming language will get you started with test automation. Not only that testers can speak the same “language” as developers, they will understand better what developers do and get a better appreciation of how complex development is. Further, a tester can do unit testing and participate in code reviews.
Programming languages come in all shapes and sizes, and each language has pros and cons for software testing hence it really depends on which one to learn on the testing situation and what one is trying to accomplish.
Some factors that might help to make a decision what programming language to learn for Test Automation:
When does the Object Not Found Dialog appear?
The object not found dialog automatically shows up during the execution of tests in the Squish IDE if a “waitForObject” command runs into a specified (or default) timeout. Furthermore, the dialog will show the error message generated for the lookup error and the object name for which the lookup was executed.
Manual vs. Automated Testing has always been a point of debate among software professionals but what are really the benefits of Automated Software Testing you may ask.
What exactly is Automated Testing?
Essentially, Test Automation is using code to create a program that performs automated tests for your software. The difference to manual testing is instead of actually performing the test one creates an automated testing scenario and is supervising it.
Test automation is, therefore, most commonly used for regression testing, which seeks out new bugs in a program and separates them. (Regression tests are very tedious and time-consuming)
One other area of code-driven testing is user simulation to replicate typical user interaction using automated keystrokes and mouse clicks where the software GUI response is recorded and analyzed.
Keys to Automated GUI Testing and Continuous Integration
There are certain factors and keys to successful automated GUI testing and continuous integration:
• How you move through the application and enter data
• How you detect state changes and failure conditions
• How the automation tool lets you change your tests, so you can quickly keep up with UI changes
• Having a software tool which supports continuous integration and runs tests unattended
With these points in mind the most significant benefits from automated GUI testing are:
At froglogic, we’re big fans of open source software. A large part of our engineering (and management!) staff contributed or contributes to open source projects, and everyone visiting our offices for a job interview certainly gets a big +1 in case she can show off some open source work! We also use a lot of open source software for our daily work, ranging from obvious projects like Git or the Linux kernel to individual libraries serving very specific purposes; the Acknowledgements Chapter of the Squish manual gives an impression of how tall the giants are upon whose shoulders we’re standing.
Over the last couple of years we contributed back various bug fixes and improvements to different projects we’re using, but we’d like to step things up a little bit. Hence, we now open-sourced an internally developed C++ framework called ‘TraceTool’ and made it available under the LGPL v3 license on our GitHub account:
TraceTool started out as a project which we did a few years ago but since grew to a full-fledged, efficient and configurable framework which we use ourselves internally in order to aid debugging our software.
TraceTool GUI highlighting trace statements generated by interesting function.
About twelve months after the release of Squish 6.0, we are proud and excited to make available Squish 6.1 which delivers several new features including:
* Visual Verification Points
* Window and Screen API
* QtWebEngine support
* Improved Squish installer
Did you know that it is possible to use multiple Squish editions in a single test script?
The following example describes the setup and workflow for such scenario utilizing Squish for Qt and Squish for Web.
- Install Squish for Qt.
- Install Squish for Web.
- Create a Squish for Qt test suite with the Squish for Qt IDE.
- Create a Squish for Web test suite with the Squish for Web IDE.
There are situations in which test scripts will hang and time out on Windows while executing. Most of this cases involve the lack of drawing/painting the application on the “screen”.
The underlying problem is that if the GUI of the application cannot be rendered, its objects do not have coordinates on the screen and testing software, like Squish, cannot find out where to perform a mouse click.
“The AUT did not respond to network communication” would be one indication of a test script execution problem in the error log.
On September 1st, as part of the QtCon conference, our partner KDAB hosts a day of training. This training day allows you to gain knowledge in several Qt-related topics, including automated Qt GUI testing with Squish for Qt.
froglogic‘s ISTQB-certified Senior Software Trainer Florian Turck will conduct the full-day Squish for Qt training and share his in-depth experience of effectively using Squish. Seats for the training are still available.
Register for QtCon here:
Locating a software failure can be a tenuous and a time intensive operation due to the fact of the explosion of the source code size and their test suite. Also the complexity of some software imposes an organization in which the test team is separated from the development teams. In this condition, it is generally difficult to find with a simple test report the code parts responsible for a bug. A common way to facilitate the correction is to provide additional information like code dumps, execution traces, screen shots…
Code coverage metrics can also be provided. This metrics consists of recording if a source code item was executed or not. This is less precise that execution traces, but it has the advantage that this information is always available for the project on which it is also used to measure the quality of the code.
One way to use this information, is to compare a failed with a passed test. As explained in a previous post, the difference in the executed code can give a hint to the location of the bug. But on huge project with a lot of tests it is difficult to choose the pertinent tests and there is no guarantee that the failed test is executing more code as the passed tests.
A better approach is to process all coverage data globally with an algorithm which scans the execution of all passed and failed tests. I present here the philosophy of it as implemented in Squish Coco v3.4.