I'm not completely satisfied because although the ID is good, it could be improved with suggestions of names for some method, for example, or variable, or class. I'd like to see suggestions for options. I'd also like the solution to be faster because a project is initially saved quickly, but after an hour of working, saving takes longer and I need to reload IDE and turn all of them on to improve speed. 

They could have better support for scheduling jobs in Jenkins. As things stand, continuous integration is very poor, and when you work in production you need many more settings in order to tune it, to be a Web user interface, for example, which is currently impossible. And there are just a few basics I think you can manage in Jenkins, because Froglogic made some plug-in to Jenkins that connects Squish and Jenkins, but the plug-in is not as good as  expected, and should be improved.

There had been a lot of improvements with froglogic Squish already. There were some scenarios in which this particular solution was available in different flavors. They have pulled everything together in one solution. There were some monitoring systems, which were missing out from the solution earlier. They have a centralized dashboard for monitoring the test cases and their execution. It's a full-blown solution, there are not many glitches in terms of something missing out of the package.

The froglogic Squish solution is only handling GUI regression testing, this is its forte. However, a lot of clients are looking into performance testing associated with it. If a performance testing capability can be added as a part of it, this would bring great value. froglogic Squish has a code coverage solution and they have done a pretty good job on it. The penetration testing could be added as a separate module, this would be beneficial.

I'm relatively new to Squish, so I'm not familiar with all its pros and cons. Currently, I haven't identified any specific improvements. However, one feature I miss is Git integration within the tool. In my previous experience with Selenium and Python in PyCharm, it was straightforward to create and review changes before pushing them. I haven't found a similar option in Squish, and having an integrated tool for managing conflicts would be beneficial in certain scenarios where collaboration is involved.

The price could be better. 

NetBeans is a Java Integrated Development Environment (IDE) particularly well suited for Graphics User Interface (GUI) development. It allows a number of GUI features such as Text Field to be defined and positioned in a GUI window. When they are first placed in the window they are given generic names such as "textfield1". Then the developer is allowed to change the name of the feature to, e.g. "ClientName", which is easier to remember the association with a program object.

When Squish is running it allows the developer to place restrictions on the contents of GUI features in order to verify correct functioning of the GUI program. These are mostly referred to by the generic name rather than to an assigned proper feature name. This requires the Squish user to either keep a cross reference list of feature names for each GUI window or to try to discern the proper feature from its contents. It would make the work of the Squish user easier and quicker if Squish would display the proper feature names, when assigned.

The only criticism I have is the IDE needed a bit of polish in version 5.2 (this may have been fixed in the latest versions). For example, I had a few occasions where Squish would fail to hit breakpoints. An application restart would fix this however.

• Features like recovery scenarios can be added as an improvement
• Reporting can be improved.

We have faced some difficulties in identifying canvas objects initially. Canvas images are not actual objects that can be picked by any inspect tool (including Squish as it works based on Objects). You need to use the visual picker or mouse click property of Squish to work with them. I have faced some difficulties in automating this for platform-independent automation. Once it got automated, then it is going fine.

The most complete way of testing is on several OS's, even platforms. Here, the solution provided by Squish, trough several python script files, could be simplified in such a way, so that even black box testers could manage it easy. At the moment, you need to have a basic knowledge about Python and programming so you can master it and use it.

Robotics automation could be added with Squish. Squish works based on objects so, adding this feature would actually help us a lot to get everything in one suite. Their roadmap shows robotic automation and local web portal based reporting will be added in future releases. If this can be fastened, that would be really helpful.

Till now I have not noticed anything that needs improvement. I believe Squish is going at a great pace and in a good way. Squish is lagging in handling swing objects, but I believe Squish will overcome this shortly. Moreover, we don't concentrate on swing objects that's why I am not mentioning it as an important thing.

I like it how it is, but it's not cheap.

The Squish team provides regular updates, and they are improving the features of Squish. Anyhow, we can't automate the applications which are completely built on C/C++ without using Qt. As per my view, Squish should provide support for these type of applications. 

Not much as of now. Squish is going in a good direction and if I feel any difficulty or anything needed to be improved, I will let you know.

Recording tests with Squish IDE creates quite ugly code and it is very difficult to maintain tests that have been recorded. That is one reason why I haven’t used Recording and Playpack feature at all.

It still requires better solutions for object identification and an enhancement to identify all the objects of the AUT before building the object map.