FrogBlog

So I went to the Berlin summit this year. I might not have come if it wasn’t for for bunanson bringing my little project at a more popular level.

It was really nice to meet him in person (left on the picture, as a big thanks I bought him a german weizen beer). He also did a presentation, presenting his worldtv99 playlist.

Anyhow, the visit was really great and interesting. Mobile computing is an exciting area and, thanks to the Nokia internet tables, Moblin, Android and what not, opening up for open source.
Nokia employees presented the roadmap of their internettablet. Some insight talks about UI design. With years of experience with small form factor devices and their Symbian OS, definitely a good learning experience.
So the next device will include OpenGL-ES and on top Clutter for eye appealing applications. From what I recall, the destop will be Clutter based. Applications remain Gtk based. They’re pushing Gtk offscreen rendering for use with Clutter and there seem to be an effort for a Symbian port. So I don’t suspect this is likely to change anytime soon.
Qt is coming though, Ari Jaaksi talked about this toolkit for enabling multi-platform support for their applications. Also a Howto was presented by Nokia as one of the parallel sessions. As a froglogic Squish developer, I’m of course quite happy about this.
Exciting times for both toolkit, now competing on the same GUI. Obviously, the linux desktop as a whole will benefit from this downscaling and speedups.
Nokia UI designers seem to be quite modest about using animations though, avoid wow first, annoyance later experiences. I do suspect things like roll-down menus and such will be there. I think that animations may help hiding latencies for e.g. application loading and such.

One addition to my last blog, I already talked about the ‘handhelds GUI != desktop GUI’ thing. An UI design talk presented the minimal space for finger friendly clicking is nine millimeter, with a screen of 225dpy gives (9 mm * 225 px/inch) / (25.4 mm/inch) = 79.7 px. Now that is almost an inch on for destop screen.

Today I’d like to write about some of Squish’s features which are not so well known but which makes Squish a really powerful GUI testing solution.

Extensibility: When we started to create Squish, our main focus was to support all standard components of the supported GUI technologies (Qt, Swing, SWT, etc.) very well. But soon we found that in nearly every GUI application custom components are used. These are often complex and interactive controls visualizing data in some way. While basic support for all custom components can be provided out-of-the-box (and is provided that way by Squish), there is no way a GUI testing tool can know all internals (such as internal objects) of such custom controls and support that in a robust way.

This made us think about extension capabilities. The first Squish edition where we offered an extension API was Squish for Web- the automted GUI testing tool for web applications. The reason for that is probably that esp. in the world of AJAX GUIs nearly all controls used are custom controls.

This extension allows users to implement a few functions in JavaScript to let Squish know how to query internal information of custom AJAX controls. That way every custom AJAX control can be supported equally well as standard HTML and AJAX controls already known to Squish.

Later we introduced a similar mechanism for our Squish for Java tool, which features automated testing of Java GUIs such as Swing, AWT, SWT and Eclipse RCP. Here we provide a few Java interfaces which you need to implement for your custom Java controls to allow Squish to drill down into the details of your custom controls.

Since these extensions solve many problems of GUI testing, we are now introducing similar extension APIs for our Squish for Qt edition. Also our new Squish edition for testing native Windows applications, which will be part of the upcoming Squish 4.0, will be completely built on this extension mechanism even internally.

Integratability: Many vendors of testing tools want to completely lock their users into their world. So they come with the complete tool set needed to automate the QA. We early realized that GUI testing is just one part of the whole QA process and also saw that most of our users already have automation systems in place for their unit testing. So they usually prefer to integrate Squish into their existing automation system instead of setting up a completely separate automation just for GUI tests.

So we decided to focus on making Squish easy to integrate instead of developing our own test management solution. To allow that we provided easy-to-use command line tools to start and control Squish test runs and generate an easy-to-process XML report from any test run. This allows for easy integration.

In addition we now also offer ready-made integrations for CruiseControl, Maven, Ant, Eclipse TPTP, HP Quality Center and more so Squish can be used as part of the whole test automation regardless of the tools in use.

We will also release our own test management system, which we use internally, eventually. But this will be just another way to do it and not replace our integration. Rather the opposite But we will always ensure that Squish stays easy to integrate since we really think that our users should have the choice what they want to use.

To end this article here are some links with further details on Squish’s extension and integration capabilities:

• Squish for Web’s extension API: http://www.froglogic.com/download/book/ug-jsapi.html
• Squish for Java’s extension API: http://www.froglogic.com/download/book/ug-javaextapi.html
• Squish’s integration plugins:http://www.froglogic.com/download/book/addons.html

The N810 is the third internet tablet that I own, starting with the first N770 that I got via the discount program.
Exciting to see that more KDE developers now starting to develop and blog about their experiences with this device. A somewhat dejavu feeling reading these blocks came about running desktop application KXyz and poor graphics etc.
I think it might be worthwhile for the new developers to catch up on the maemo-devel mailing list archives and read the lenghty threads about hardware limitation and such.
Btw. this mailing list was originally setup for the platform, but as developers prefer -devel mailings lists, changed to be targeted to application developers as well.

I have no idea what’s been said at the Academy presentations, so I hope it may be worthwhile to share my observation from the last three years as user (did some development too, but I don’t think that is very interesting to talk about).
A few weeks ago, I spent some days with friends in my home land. The N810 is really a nice travelmate to have. Listening to podcasts, reading a pdf file or watching a video while traveling, reading my google mail wherever I had Wifi access, using the GPS to find my way around, watching the latest news from the livestreams before I went to sleep and simply using it as a light source in an unfamiliar guest room.
At home, I basically use it as a mp3 player or as a TV device when drinking a glass of wine on the balcony. Since I live abroad, the Voice-IP feature is a real killer. Google talk is nice but not very common. Sip with an asterisk server is just great. I have one contact in my home land that has a VoIP account and flat rate access to the national phone network, I can dial to any number in this country for free using a second asterisk server over there.
The browser experience is okay, 800×640 is enough for most web sites. The keyboard is pretty good for responding to mails. However, the high dpi of 240 does makes reading stuff on web pages rather tiresome. A five euro +1 reading glasses surely helps a bit.
I’m not much of a gamer, did some quick games killing waiting time.

Some thoughts about software for this device. Like the first cars looked like a horse carriage without horse, the desktop metaphor might not apply on these devices.
Mouse drags, tab-and-hold for RMB, are just cumbersome, try to arrange the home applets. Now this may change in the next release, which should be more finger friendly (but this can only be about the size of widgets, dunno).
When publishing a program, keep in mind that slow application startup, slow feedback on actions are deadly. Actually, everything that consumes lots of battery power (unless the device is mounted somewhere so that it can charge constantly). What might sounds unexpected is that services listening for network data, drain the battery.

The trend observing is that the UI tends to become larger and more finger friendly. Which means that applications GUI’s diverge from their desktop counter parts already and becoming simpler.
The more popular provided open source application may show what makes sense currently. Various game emulators seem to be quite popular. Home automation, remote controls etc, surely are useful applications.
Analyzing software has its place. Bluethooth, Wifi, GPS, microphone and camera inputs allows things like network scanning, motion detectors etc (tricorder, anyone?).

Office or whatever management application are limited to mail and scribble/notes programs. Probably due to the troublesome way to enter enter text or do anything that requires lots of menu access and lack of overview given by the small display. I hope that this will improve, e.g. presentation software.
Interesting read is the thread from an Apple Newton developer in the maemo-devel archive. I really wonder if this device came too early that made them fail or that manipulating documents simply has no place on these gadgets,
I do suspect that perhaps in the propertarian world, things like invoice or whatever management in a client-server setup certainly may have some potential.

I hope the new KDE develops come with lots of new ideas. Qt surely lowers the barrier to get started.

We did another Squish success story. This time with the German Funkwerk IT, who uses Squish to test the control panel of an electronic railway control center.

You can read the full story at our web page

Now that KDE 4.1 there is some time to think about new features again. As almost every piece of KDE the KHTML library had been heavily affected by the changes in the underlying infrastructure. The switch to Qt 4, replacement of DCOP with D-Bus, new networking code and others required adaptions (and consequently bug fixing) that did not leave much room to even think about adding new features.

Read the rest of this entry »

The end of the day at the office is nearing. Sitting at my desk, going through the list of people who have requested a trial version of Squish today. Of course several from the usual suspects, i.e. large
international cooperations. But what never ceases to amaze me is the sheer endless number of yet unknown shops of all sizes and domains that exist around the world.

I notice a high-pitched whistle filling my ears but can’t make out the origin. The harddisk of my machine started to sing its final song? A technician from the lab below passionately grinding a dental prosthesis into shape?

With our crew decimated due to vacation time it’s a bit more quiet than usual. Clearly audible are Rainer and Roberto fighting their last table soccer match of the day. Rob is busy with a new internal test library. Andreas and Frerich are discussing their major rewrite of our test development GUI. Just checked: no modal dialog blocking the user’s flow, yet. Aaron would be proud of them.

Looking at how much code I wrote myself today: not much. Busy with customer care, administrative tasks and design discussions. But that’s fine as long it allows the others to concentrate on their projects. We have a new product in alpha, another about to start later this year and of course many more planned. SO MUCH ONE COULD DO. If you want to join us on this trip and know how to hack in either (or all of) C++, Java and/or Python let me know!

Note to myself: reserve many hours of KDE coding time for the weekend. Investigate redoing the the tokenizer of KJS. With the recent performance improvements of the execution engine the parsing phase starts showing up in profiles. Should be able to do better than my simplistic implementation from ’99.

Next of the senses that gets stimulated: the cooking school downstairs has started their daily evening course. One scent more tasty than the other coming in through the open window. Hmmmmm. A master of the profession must be at work again. Getting extremely hungry, going home. Bye.

Now that Squish is adopted more and more in large enterprises (Siemens, Reuters, etc.) we often get asked for references.

We were able to make another reference public by interviewing Ericsson, who started to use Squish for the Java GUI testing last year.

You can read the interview here.

The JavaOne conference taking place next week will be our 3rd event to exhibit at this year. All of our customers and interested parties are invited to visit us at booth #940 in the Pavilion. We’ll be doing live Squish presentations and follow our tradition to hand out green gummi frogs. The conference program is loaded with interesting topics but I bet – and hope – that we’ll be too busy to attend any session ourselves.

We’ll be switching planes at London Heathrow on our way to San Francisco and back. When booking the flights I was still looking forward to using the new Terminal 5 to escape the traveller’s hell that Heathrow can be. Little did I know about the chaos that would arose at the day of its opening. Hope it will have settled once we are arriving there.

Anyone in for a spontaneous conference visit: please get in touch with us as we can provide reduced and free passes for the conference and exhibition area, respectively.

I will today abuse this blog to publish some work without having to write documentation for it.

While demonstrating Squish in web demos and at conferences I often get asked about keyword driven testing. Due to the powerful scripting features of Squish, this is quite easy to do with Squish. Now that I created such an example for a customer demo later this week, I thought I’d publish the perpared test so you can have a look at how simple it is to do a keyword driven test in Squish.

You can download the test suite from http://www.froglogic.com/~reggie/suite_nomadpim.zip. It contains three tests and some shared script files.

The first test case is the test script with hardcoded data but already abstracted into several functions (which will later serve as keywords).

The second test cases is the same but in a data driven fashion by using an external data file.

The third test shows how to turn that into a keyword driven test where the test steps and data comes from a data table and the script (keyword_driver.js) is completely generic.

So far there is not much documentation available for that but the tests and shared scripts are quite self explainatory.

Maybe we get around to create a nice tutorial out of that for Squish 3.4.

BTW: The test is for a standard Java RCP application which you can download from nomadpim.sourceforge.net

With the application deadline for this year’s Google Summer of Code being over now (and the list of accepted projects to be published soon) I’d like to point those looking to make a bit of money working on Open Source software to another initiative.

Matt’s Bargain Basement Summer Of Code is privately funded which I find quite impressive. Matt is offering bounties for fixing issues in several components of software he is using every day. If you are interested in working on one of the tasks contact him. If you want to discuss some details do so. I can confirm that he is open to suggestions.

Read the rest of this entry »