I’ve been using the free Squirrel SQL SQL client under windows for a month or so now.  It’s a good tool, though somewhat annoying to get working.  Today it stopped working.  The loading splash screen would display, the progress bar would get about halfway through and then Squirrel would exit without any messages.  I had no desire to recreate all of my connections or reinstall the various drivers again, so I really wanted to fix my installation.

After trolling through forums, there was a suggestion that the problem may have been preferences related. No precise solution was offered, but I began to experiment to see if this was my problem.

First, I found the preferences folder, which lives in Windows’ documents and settings folder (eg. c:\Documents and Settings\). Inside this folder will be Squirrel’s preferences folder, named ‘.squirrel-sql’. I renamed this and restarted Squirrel. Things looked good with the application starting, so it seemed I was looking in the right place. In order to troubleshoot further, I wanted to restore the state of the application, so I renamed the new preferences folder that Squirrel had created and tried to rename the old preferences folder.

No luck! Windows didn’t like me trying to rename the folder back to its original name. I ran Squirrel again, which caused Squirrel to create another preferences folder. I now had three folders – squirrel-sql.old, squirrel-sql.new and the current preferences folder ‘.squirrel-sql’. I opened the old preferences folder, copied the contents and pasted them into the ‘.squirrel-sql’ folder.

Looking inside the preferences folder, I could two folders ‘plugins’, and ‘logs’. I could also see a number of xml files. Now that I had found the broad area I needed to investigate, I wanted to only change one element at a time. As my main objective in resurrecting Squirrel was to not lose my database connections and plugins, I ignored the xml files that were related to these, and looked at the most interestingly named file – ‘prefs.xml’. I renamed this to ‘prefs.xml.bak’ and restarted Squirrel. Still no joy, so I closed Squirrel and restored the original name of the file..

I repeated this step for ’sql_history.xml’, thinking that this file might be dynamic enough to cause problems. Again, Squirrel failed to start correctly.

Next, was a file named SQLAliases23_treeStructure.xml. Suspiciously, this was zero bytes, which seemed odd for something that looked like it was supposed to contain some kind of data structure. I added a ‘.bak’ extension to this and restarted Squirrel again.

Success! I closed Squrrel and I could see that it had recreated the SQLAliases treeStructure file again, this time with data. I restarted Squirrel one more time to make sure that there wasn’t some recurring problem with my database aliases, and it happily started again with my connections and query history intact.

I’m starting to set up redirects to move (hopefully) painlessly across to the new Wordpress blog. Hopefully there’s minimal impact and everything is up by Monday.

I may be a bit slow, but when checking the links in my last post, I noticed that there have been updates to the Context-driven website. It’s worth a read – http://www.context-driven-testing.com.

You can see the old version at http://web.archive.org/web/20020727051040/http://www.context-driven-testing.com/

I hadn’t originally planned to go to the STANZ conference this year, but at the last minute they added two additional keynote speakers, James Bach and Julian Harty of Google, and it’s hard to pass up an opportunity to catch up with James when he’s in the country. Also, as someone aligned with the Context-driven school of thought, any STANZ with more than one context-driven presenter is a good year, so I’m looking forward to meeting Karen Johnson.

I’ve attended James’ Rapid Software Test class previously, and my understanding was that the “Exploratory Testing Explained” tutorial is a one-day version of his RST course, so I asked what value I might get from doing the course again. James offered three reasons, but my notes appear to have gone missing and I can only remember enough to paraphrase two –

- The course materials change over time, so there may be new things if it’s been a while since you took the course.
- You may benefit from going through things again, to refresh or pick up new nuances.

A third, which James may not have mentioned, is that sometimes he gets those that have done exercises before to help out with their running, so that may be an added bonus if tester training is something you like to do.

One of the other reasons I’m attending STANZ this year is to network. In a tough employment market (I’m paying my own way to STANZ – ouch), extending my network is important, as is learning which companies still have budget enough to send their testers to conferences!

It looks like a good mix of presenters this year, although I was disappointed to see Karen Johnson’s test strategy workshop is Wellington-only. As per my recent post, I think this is an important area that’s underdone. Some of the feedback from the workshop I ran with Paul Szymkowiak at last year’s STANZ also suggested that this is an area of interest for many of us.

If you’re attending, and you’re reading this, make sure you go out of your way to track me down.

I’ve recently been on the move a little, and have had a lot of chances to work on test strategy. I generally have historical documents to work from, but decided I should try to come up with a mnemonic device to ensure that I have all of the critical conversations that I need.

One of the most influential things for this was the RUP development case that Michael Ruschena presented when I worked with him at ANZ. This documented the team approach we had agreed upon to deliver a solution to the customer’s needs when working on our first agile project. This was one of the first times I was really conscious of “software development as applied problem solving”, prior to encountering Gerry Weinberg’s work. Paul Szymkowiak also commented that my test strategy reproduces a lot of what would be in the RUP vision artefact. I realised that in many cases, that’s true. Before deciding on the testing mission, what I’m frequently trying to facilitate is consensus on the project or business goals.

So that’s how this helps me. I hope it might help you. To that end, I present the first public version of my test strategy mnemonic – “GRATEDD SCRIPTS”.

• Goals – What are the critical goals of the product? What are the things that absolutely must work?
• Risks – What things are we hoping to avoid? What bad things might happen? What are we doing to address these?
• Approach – How are we going to test this? How we will work together? Who will do what?  Accountabilities may also be considered here.
• Tradeoffs – What tradeoffs we are prepared to make in order to deliver the desired business outcomes?
• Environments – What environments do we have or need? What testing will we do in those environments?
• Dependencies – Is anyone ‘outside’ the project depending on us? Are we depending on anyone? Are there external gates or constrained resources?
• Data – Where will data come from? Are there any special needs?
• Stakeholders – Who has a stake in the software/product/test effort? What are their goals? Who is accountable for what?
• Coverage models – What models will we use to know that we are testing the things we care about? What models will drive test design and test coverage discussions?
• Resources – Who is available to help with testing? What other resources might we need? What’s the budget?
• Information needs – What information needs to come out of the testing process? What decisions does it need to support? What are we trying to learn?
• Prioritisation – What is most important? How will we resolve competing interests, tasks or tests?
• Tooling – Will any special tools be required? Will support be needed to develop these?
• Schedule – What are the important dates and timings?Some of the items overlap, but that’s OK for my brain. Different prompts cause me to consider things in a different light.Ben Kelly proposed ‘Budget’ as a separate item. For myself, I cover this in Resources, but if you work in an environment where you are more hands-on with budgets than I typically am, you might find the mnemonic “B-GRADED SCRIPTTS” to help you with a more explicit ‘B for Budget’ reminder.

  So next time you are thinking about what your test effort should look like, try to work through the above points and see if there is anything you’re missing. Try to come up with your own mnemonic devices too to help you remember things that are important.

I’ve been helping out testing Jonathan Kohl’s Session Tester over the last few months. While the second release was the first that appeared to meet my needs to a degree, it had a few critical problems that lead to data loss. If I’m taking notes, the most critical feature is that my notes be preserved.

I’m pleased to say that the latest release, version 0.2.1 is much more stable. I’ve had no issues with notes going missing over the last six weeks or so, and can recommend picking it up and taking a look. You can download it at http://sessiontester.openqa.org/download.html

Session Tester is based on James Bach’s Session Based Test Management method. The long-term road map also includes some other exciting ideas. Right now though, this is a product very much in early development. You won’t be able to run your test effort using SBTM as described in the original article. If that’s something you need, or would like to try, you can probably get close to it if you are prepared to spend some time transforming XML documents so that they can feed into the tools provided at satisfice.com.

What it will give you though, and the part that I find of great value right now, is a nice framework for taking notes on your testing, and managing your personal testing process. The tags that it provides, and for which it generates reports, help to remind me of the things that I should be paying attention to. Again, it’s not 100% complete yet, but it’s a good start, and you may find it helps you take better notes when you’re testing.

You may not like the way it does something. That’s OK. The project has an aim of providing open interfaces which will let you modify, transform and hack. If you don’t like its output, you can probably find a way to fix it. Or better yet, you can go straight to the source and tell us how it should be!

The project is looking for another developer to help out right now, so if you’d like to participate in a community project, get in touch with me or Jonathan Kohl.

I’m going to be trekking around Korea later in the year, and have started blogging in preparation. It will cover some of my last trip, some of my dabblings in the language, and plans for my upcoming trip, which is going to be themed around Korea’s food and drinking culture. It’s also a good chance for me to practice writing about something other than IT. If you’re interested in a change of pace, check it out at http://www.quinert.com/korea.

Time has passed, and I thought it was time to update my thoughts on what’s critical to successful software testing (and development). While originally, I started noting important ideas for agile teams, Increasingly, I find most of these apply no matter what environment I’m working in. Check them out on my Haiku page.

Since reading about Celerity, I’ve been excited by the idea that I might be able to take my Watir scripts and run them more quickly by using a browser simulator. It also raised the possibility of taking scripts and running them in different environments and on different platforms, because Celerity runs under JRuby without a browser. It makes http requests directly, and simulates javascript behaviours without actually rendering pages.

I had the hope that this would give me an option to get quicker feedback from my automation. Unfortunately, this hasn’t turned out to be the case for the applications I’m currently testing. Simulation of the javascript on the page seemed to take longer than the real browser. I got quicker feedback by turning off images, blocking certain external hosts and using Internet Explorer. I still hold out hope that Celerity may improve performance, or that the applications I’m testing will be less javascript intensive.

Once I set to getting my Watir scripts working with Celerity, I needed to overcome a few issues. The last of these was the number of differences between Celerity’s behaviour and Watir’s behaviour. Resolving this turned out to be reasonably simple, and the same strategy for getting consistent behaviour between Celerity and Watir driving IE turns out to solve some other problems with differences in behaviour in Watir’s drivers for IE and Firefox.

My first cut at this is by no means complete, with a bunch of unnecessary duplication that can be easily factored out. For now however, it gets the job done, and may be instructive for others.

The strategy is simple -

- Wrap the browser in your own class.
- Dynamically require the appropriate library for the driver you need
- Create your own methods that provide consistent behaviour for the different browsers. In my case, I needed to be able to get the actual html content of the page after it had been modified by scripts running on the page. Each driver (IE, Firefox, Celerity) required a different method to be called to achieve consistency, but using this approach, I can call browser.html and get (almost) the same result from all browsers and drivers.
- Intercept any calls to methods that you haven’t implemented and pass them through to the actual browser object.

This is the first time I’ve touched Ruby’s method_missing method, and it was pretty painless.

There are a few issues getting JRuby up and running with Celerity on windows as well. I’ll describe these shortly in another post. I’ve also recently had issues installing the latest version of Watir, and will detail the solutions to these as well.

Sample code is below. Note that you can actually do without assigning the browser to a global variable, but I provide this example just to show how you can fit this new solution into the ’standard’ Watir approach. If you modify things so that you can specify the driver from the command line, you should be able to run tests using something like -

jruby main.rb –driver :celerity
ruby main.rb –driver :watir_ie
ruby main.rb –driver :watir_ff

----- driver.rb ------
require 'singleton'
require 'rubygems'

class Driver
    include Singleton

    def set_driver(driver)
      @driver=driver
      if @driver==:celerity
        require 'celerity'
        @browser=Celerity::Browser.new
      end
      if @driver==:watir_ie
        require 'watir'
        Watir::Browser.default='ie'
        @browser=Watir::Browser.new
      end
      if @driver==:watir_ff
        require 'watir'
        Watir::Browser.default='firefox'
        @browser=Watir::Browser.new
      end
      return @browser
    end

    def html
      return @browser.document.body.innerhtml if @driver==:watir_ie
      return @browser.xml if @driver==:celerity
      return @browser.html if @driver==:watir_ff
    end

    def initialize
      @browser=nil
    end

    def method_missing(method, *args)
      @browser.send(method, *args)
    end
end

----- main.rb ----
require 'driver.rb'

driver=:watir_ff
#driver=:watir_ie
#driver=:celerity

Driver.instance.set_driver(driver)
$browser=Driver.instance
$browser.goto("http://www.quinert.com/blog/")
puts $browser.html

This tweet was forwarded to me yesterday:

martinfowler: Manual scripted testing should be a human rights violation

It bothered me on a few levels.

Firstly, the simplicity of phrasing around manual and scripted testing. Secondly, that agile developers might view themselves as the saviour of oppressed testers everywhere, and the perpetuation of the concept of tester as helpless victims. And thirdly, criticism of scripted testing is hardly new, and it’s a bit sad that one of the key proponents of test-driven development and design has taken so long to come to this idea.

Still, his comments make a nice soundbite, and what he states is often true, but until he says *why*, I’m not sure if he knows what he’s talking about. It just seems a perpetuation of simplistic binary models of automation and prescriptive testing.

We can do better. There’s much more we should be talking about when discussing manual testing and the conditions of testing in corporate life.

I start with these ideas -

- Let’s put under computer control and evaluation the elements of our tests which are well suited to manipulation and/or evaluation by computers.
- Let’s put under human control and judgement the elements of our tests which are well suited to human manipulation and evaluation.
- Let’s prefer exploratory approaches when we want to find new things and adapt to the information at hand.
- Let’s make sure that we record the details for important things that we don’t want to forget to do, for things that are confusing that we can’t fix.
- Let’s be aware that any test have elements of exploration and prescription.
- Let’s be aware that the testing model we work from biases the kinds of problems we’ll find and the kinds of things we’ll miss.
- Let’s choose appropriate levels of abstraction to help manage the cost of our test design.
- Let’s have as many ways as possible to model our test designs so that we can effectively solve the problem at hand.

In particular, the first two points suggest different ways of doing things that blur the lines between traditional automated and “manual” tests, as discussed by Kaner, Bach and Kohl:

http://www.kohl.ca/blog/archives/000193.html
http://www.satisfice.com/articles/boost.shtml
http://www.satisfice.com/blog/archives/118

On the dehumanising of work, a lot of testers pulled out of frontline business roles were probably already having their human rights violated for far less money than they now make as testers. That doesn’t excuse things, but there aren’t as many testers complaining about the status quo as one might expect. My observation is that the nature of testing as practiced in most places drives the majority of those who might want to take a more creative approach elsewhere.

Standard business practice continues to be to throw money at staff retention problems in skilled roles rather than consider how work might be made to suck less. This isn’t uniquely a software testing problem, and the world is some way from tackling this as an issue.