As you begin building your Automated GUI Testing Framework, the first set of tests you’re likely to automate are those manual test cases which while required are perhaps mundane, repetitive or require meticulous detail review.
Use existing manual test cases as your base
Sample Manual Test Case: Create New Address Book
- Open Application
- Create a new address book using application menus
- Expected result: Confirm new addressbook created without any entries
Squish provides many options when working with dynamic objects:
- Using Wildcards in the Object Map
- Using Regular Expressions in the Object Map
- Using Wildcards or Regular Expressions with Object Real Names in a script
- Building Object Real Names within a script using information retrieved during script execution
Watch the videos below to learn two approaches to working with dynamic objects
The videos demonstrate the Squish for Qt edition and sample Qt application; however the same options apply working with other Squish editions.
Use the Search feature on the frogblog to find past Squish tips of the Week, tech articles and other valuable information.
Did you know Squish can help you create a data-driven script?
Simply highlight the code to loop, right-click and select Make Code Data Driven. By telling Squish which data file to use, Squish will produce the loop and applicable variable statements to extract the data from the data file.
Your batch runs, or scheduled automated test executions can run remotely without question. But did you know you can also develop and manage tests remotely?
With the Squish Server running on the remote environment, the Squish IDE can create and execute tests remotely (you still need the ability to control the remote AUT, via remote desktop, vnc, direct access to the system, etc.)
Three simple steps:
- Indicate what incoming IP addresses to allow by modifying the squishserverrc file on the remote machine.
- Start the Squish Server on the remote machine to listen for incoming requests
- Point the Squish IDE to the remote machine’s IP address and port from Edit > Preferences (Mac: Squish > Preferences) > Squish > Remote Testing
A different twist on the tip this week. We want to hear from you!
What are your most value added ‘toolbox’ scripts?
Implementing an automated test framework with re-usability in mind saves time down the road, especially when it comes to script maintenance. Each application should have a toolbox of re-usable scripts.
Question: Is it possible for Squish to hook into (interact with) an application that was started manually?
- Start the application using start*aut instead of starting it directly:
startaut --port=<portNumber> <AUT_PATH>
- Register the AUT as an Attachable AUT
Using start*aut you can playback or interact with a running application using Squish, because the hook is already loaded and ready.
- Update your Test Suite Setting’s Application list to use <No Application>
- Now when you record, the Record Settings window displays where you can select to use the running application
Did you know that Squish can monitor for various events and dialogs? The events can be handled, allowing scripts to continue where they left off.
For example, in a Windows application you may install an event handler to react to unexpected open message boxes using MessageBoxOpened. The example below demonstrates logging the handled event and closing the message box should the message box appear at any point in the executing script:
test.log("MessageBox opened: '%s' - '%s'" % (
Learn more about using event handlers
Many times tests are implemented using a single approach to validate a desired result. Do users use the application the same way? Changes are high they don’t.
Consider enhancing your automated testing to incorporate altering workflows to validate the same end result.
- Come up with (minimum) 3 ways a test can confirm the same desired result
- Break each approach into a function
- Randomly call one of the three functions each time the test executes