Mobius Labs is once again hosting Mike Kelly and I for Exploratory Testing in Practice. This time we’ll be presenting a three-day version of the course. It’s an experiment that may permanently change the format of the course if the feedback is positive. The first time we provided the course it was only two days and several participants requested an extra day.

This course is a lot of fun as an instructor and an attendee. I like giving it because there are no bullets points to read – our slides are titles and pictures and that’s it. It’s an approach I borrowed from Matt Heusser, and I like the effect as a presenter. It’s just you, the topic, the picture, and the audience. If you don’t know what you’re talking about there are no bulleted lists to hide behind.

I think this approach is good for the attendee as well – the feedback we’ve received supports this idea. It’s less boring this way, because the instructor’s engagement level evokes greater interest in the attendees.

At any rate, the course is a valuable way to learn the session-based approach to exploratory testing. It is a good course for testers of all levels, including your business partners who perform acceptance testing of a “finished” product. The mix of lecture and practice helps you transition from book learning to practical experience – in the class we test real software, which helps cement the concepts we learn in class as working practices.

To read more about the course or to register for the August 26-28 course in Indianapolis, visit MobiusLabs.com.

Unfortunately, the format of automated tests I want to create is not supported by the Selenium IDE. The Ruby script it generates is for Unit::Test, not RSpec, which is the format I want. So over the last week I’ve gotten pretty good at generating the Unit::Test code and converting it to RSpec so we can run it in a headless grid integrated with our CI environment.

But I’d rather just export it as RSpec directly and skip the whole conversion process. As it turns out, it’s pretty easy to add a new exporting format to the Selenium IDE. So I did it, by modifying the code that creates Ruby – Unit tests so that it will create RSpec code instead. It only took about ten minutes to do, and the end result isn’t 100% perfect, but for most of the testing I do it will generate RSpec code that will run right the first time.

I know Selenium/RSpec doesn’t have a huge user base at the moment, but if anyone would like to download the file, here it is. I’m not reserving any rights to this – do what you want with it, use at your own risk. To install it, open the Selenium IDE, pick Options=>Options. Click on the formats tab, then the add button. You will see two fields, one tiny, one huge. In the tiny field, type Ruby – RSpec. In the huge field paste the entire contents of the file OVER the pre-populated stuff.

Now, whenever you export a file, Ruby – RSpec will show up as one of your choices. Cool, eh?

If you make improvements to this file, please let me know. I’d like to benefit from them as well. One of the things that would be cool is if I could create describe…do and it…do blocks from the IDE. That would probably require a combination of extensions and changes to the format.

Mike Kelly and I delivered our two-day practicum, “Exploratory Testing in Practice” at Mobius Labs in Indianapolis a few weeks ago. I haven’t posted about it since then, but I had a good excuse – the birth of my son Jake.

The feedback we received on the course was really positive. The 50/50 mix of classroom style learning and testing exercises against production applications seemed to work really well. Many of the participants wished it had been a three day course, and given the chance to reflect on the course a little I have come to agree with them.

Expanding the course to three days will give us more time to get specific with oracles and heuristics, plus we’ll have time to introduce different approaches to managing charters. I think adding another day will really enrich the experience for attendees.

I’m planning to present this course a few more times this year in different cities throughout the US. These events will follow the three-day format recommended by our attendees of our pilot course. The first class will be held in the Dallas/Ft. Worth area from July 15-17. Subsequent classes will be scheduled for San Francisco and Chicago in August and September.

Registration for the DFW course will open on May 1. If you are interested in this or any of the other training events, please send an email to dave at techdarkside with “ETP” as the subject and I’ll send you an email update when more information is available.

I am also happy to bring this course on-site to your location. For details about pricing and scheduling, send me an email with your contact information and we can discuss your needs.

I don’t know what websites I visited that day, but I learned that what was bothering me was the system did not match up with my User Expectations. More importantly, those user expectations came from using common commercial software made by the big manufactures.

When software does not match up to their expectations, it frustrates users. Think of software you are frustrated with and then see if this might be why.

From that point on, I began looking more at the User Interface of the software I tested. I didn’t realize it was a heuristic either. It was just something I wanted to see in the software I tested. Later when I learned about heuristics and was asked to define one that I use, GAUI was born and I gave it a cool name. GAUI is Generally Accepted User Interface. I have to admit, for some brief moment, the GAAP thing from accounting may have popped into my head to contribute to the name.

When learning a new concept in programming, I couldn’t do it without some examples. So, here are some examples of GAUI in practice:

In the particular web-page I was testing:

In conclusion, we have a set of User Expectations when we use an application. That is my GAUI.