I currently have a vacancy in my team for an assistant test lead to carry some of the low-level planning, bug and environment management load.  They would also be hands-on.

See Transurban’s career site for details or contact me if you have questions.

Five years ago I wrote, somewhat flippantly, on automation failure, but apparently some people never noticed.  It still seems relevant, so please go and read (or re-read) ‘Automate your way to ineffective testing with my twelve step program…‘

On the off chance it helps someone else, when firing up CA Workload Automation for the first time, it failed to start with the message ‘JVM terminated, error code=-1′.

There was no obvious cause for this, the install was a fresh one on a newly set up machine.   I reinstalled the JDK, and still the same error.  A bit of reading suggested there may be issues with an ini file related to eclipse.  I found the CAWADesktopClient.ini file and had a look.  The file looked a bit messed up, with lines being broken in odd places.

After making it look like this…

…everything is working as it should be.

Hope this helps someone.

This came out of the blue, and I don’t know much about them, but someone from Yodle.com asked me if I would spread the word about their open tester position (New York-based). On paper, it looks pretty interesting, and my readership is mostly US-based, so hopefully this might help someone out: http://www.yodle.com/yodle-careers/jobs/new-york/qa-engineer/

Based on some current work, I’m going to need to extend my test strategy mnemonic to include ‘Accountabilities’.   That gives me a ton of options, such as ‘Gated Script Rats’, ‘Script a test drag’, ‘Attracts Red Pigs’ or ‘Egad! Script tarts’.

I’ll update once I’ve decided, but feel free to offer your favourites from the Anagram server, here and here.

Via Ben Kelly, Rikard Edgren’s brief but dense ‘Little Black Book On Test Design‘ is worth a read.

It’s cheap both in dollars (free) and time (less than 15 minutes if you’re quick).

I don’t know if it is, but I enjoyed Michael’s post on problematic uses of ’should’ in requirements.  Enjoy.

I’m currently looking for two testers, a junior and slightly-less-junior to come and work as permanent employees in my team at Transurban.

You can view the current PD at http://www.transurban.com.au/532.htm.  I haven’t had time to update it (it was created prior to me starting here), but I think it’s  a reasonable statement of the technologies involved.  If you do have any questions before applying, feel free to contact me via the ‘About’ page on this site.

Tim seems to be pretty busy now that he’s a free agent, so I’m looking forward to trying this new(ish) gem he announced recently for querying browser performance stats.

I can’t believe it’s been as long as it has since I last posted.  This has mostly been because I’ve been busy preparing to become a dad.  I’m a dad as of two weeks ago, and have a new job, so as things settle down I hope to get through my backlog of posts, mostly on technical topics and tools.

Alister Scott has posted some code examples on watirmelon.com that show different solutions to a problem that arises for people implementing the Page Object pattern for test automation.

I found Alister’s approach solutions interesting, because as my automation usually models business/user goals and/or domain features/concepts,  I don’t often have my own page abstraction.  See http://gojko.net/2009/10/06/putting-selenium-in-the-right-place/ for an example of the approach I’m thinking of.

At the top level might be something like:


google=Google.new
google.search(search_phrase)


At the next level down, I potentially want to be independent of the user interface, so it doesn’t make sense to organise around page components.  I might have something like:


def search(search_phrase)
enter_search(search_phrase)
submit_search
....
end


When we get to the third (task) level, this is still at a user or business activity level, so the page model still doesn’t make sense for me.  I’ll just use the browser driver directly (or my own driver abstraction):


def submit_search
Driver.button(:value, => "Google Search").click
end


Yes, I could have another level here such as:


def submit_search
GoogleHomepage.search_button.click
end


In most cases though, the task-level UI element has a single purpose, so there’s not much of an issue with violating DRY. I also try to keep the automation stack as small as possible, so can tolerate a little bit of duplication. Regardless, it’s easily factored out into a new method if duplication becomes an issue because methods are common to the domain.

I’ve seen some frameworks that have a really abstract UI driver at the next level (so that they could drive a rich client app, a mobile app and a web app all using the same methods), but I’ve never needed to do that.

I favour a business/domain oriented approach because at the business level, the goals and activities don’t change that much (and I tend to let the automation lag behind my understanding of the problem).  It also encourages me to pay attention to the things that matter and be less implementation-focused.