Introducing quoth: a random wikiquote gem

I just released quoth: a ruby gem that displays pseudo random wikiquotes on demand.

I really like the wikiquote gem, but it only retrieves the wikiquote of the day, so you’ll only ever run it once a day (or else see the same thing over and over again). Quoth displays a random quote from the entire wikiquote archive.


$ gem install quoth
$ quoth

The time is always right to do what is right ~ Martin Luther King, Jr.


$ irb
>> require 'quoth'
=> true
>> Quoth.get
=> "I like a huge range of comedy — from broad and farcical, the most sensitive, the most understated — but I always wanted my comedy to be more embracing of the species rather than debasing of it. ~ Lily Tomlin"
>> Quoth.refresh_quotes
=> "Successfully refreshed quotes from"

I’ll write soon about how you can use this gem in your automated testing. You can check out the source code on github. Enjoy!

Reflecting on this blog

I fired up my netbook tonight to read and reflect on some of my old blog posts. Here’s a collection of my favourite blog posts and a comment about each from my current perspective.

Five organisations I would love to work for (geography aside): Amazingly this two+ year old list is still very accurate. In 2010 I’d possibly drop 37signals from number 5 and replace them with either Thoughtworks or Mozilla or Google. Proving how great Atlassian is, Jeffrey Walker commented on this post, but very sadly, he’s no longer with us.

Software Piracy: I still stand by my views on pirated software being unnecessary, and still love my ‘biting the hand that feeds you’ analogy.

Why I do automated testing: This question still comes up (a lot) when attending job interviews. My answer is, unsurprisingly, still the same.

Version control your tests, quickly, easily, today for free: There’s still no excuse not to have version control of your automated tests. Please do it.

Create fancy wiki home pages with Confluence, Lozenge and Nuvola Icons: A dead simple way to create an attractive Confluence home page with free icons.

Weird ways of working, car indicators, and shoshin: The thing that amazes me today about my eight month year old son is his shoshin, and how he contributes to my own.

Running Watir tests from a Confluence wiki page: Some cool stuff I wish I could use more in my day job. One day.

Five reasons starting with F on why I use Watir: Again, two+ years later and all the reasons are still relevant.

Let me know if you have any favourites or would like me to write about something in particular in the future.

Update 20 July 2010:

Somehow I forgot this post I am really proud of: Software Testing Career Development

Easily define Watir tests in excel, OO, wikis and Google docs using Roo

I spent this evening playing with Roo, the ruby library for reading data from spreadsheets and I am very impressed. In a very small amount of time I was able to define tests in four different forms/places and could execute my tests from each of these:

  • An Excel file (.xls): stored locally
  • An OpenOffice (.ods): stored locally
  • An Excel file (.xls) stored in a Confluence wiki page with Confluence Office Connector; and
  • A Google Docs spreadsheet.

The great thing about Roo is that you don’t actually need Excel; Roo simply reads the file, unlike the ruby Excel COM WIN32 API I have used previously.

The spreadsheet (embedded in Confluence) looks like this:


The cool thing about embedding it in Confluence is that you can click the title of the spreadsheet to edit it (in OpenOffice in my case).

I made some minor changes to my existing code that executed my depot tests from a wiki page, and it was as easy as that. A data driven Watir solution with four possible ways to define test cases. Cool.

You can find all the code needed below.

require 'watir'
require 'rubygems'
require 'roo'
require './Customer.rb'
require './Common.rb'

case ARGV[0]
when "excel"
	ss ="watirmelon.xls")
when "wiki"
	ss ="http://localhost:8080/download/attachments/2097153/watirmelon.xls")
when "gdocs"
	ss ="")
	ss ="watirmelon.ods")

ss.default_sheet = ss.sheets.first
ss.first_row.upto(ss.last_row) do |line|
	if ss.cell(line,1).strip != "Function" then #We have an executable test
			module_name = ss.cell(line,1).strip
			method_name = ss.cell(line,2).downcase.strip.sub(' ','_') # automatically determine function name based upon method name.
			comments = ss.cell(line,3).strip
			expected_outcome = ss.cell(line,4).strip
			expected_error = ss.cell(line,5).strip
			required_module = Kernel.const_get(module_name)
			required_method = required_module.method(method_name)
			arity = required_method.arity() # this is how many arguments the method requires, it is negative if a 'catch all' is supplied.
			arity = ((arity * -1) - 1) if arity < 0
			parameters = []
			1.upto(arity) do |p|
			actual_outcome, actual_output =*parameters)
			# determine the result.
			if (expected_outcome = 'Success') and actual_outcome then
			    result = "PASS"
			elsif (expected_outcome = 'Error') and (not actual_outcome) and (expected_error = actual_output) then
			    result = "PASS"
			    result = "FAIL"
			puts "\nRunning Test: #{method_name} for #{module_name}."
			puts "Expected Outcome: #{expected_outcome}."
			puts "Expected Error: #{expected_error}."
			puts "Actual Outcome: #{actual_outcome}."
			puts "Actual Output: #{actual_output}."
			puts "RESULT: #{result}"
			puts "An error occurred: #{$!}"

See the full test code below the break.

Continue reading “Easily define Watir tests in excel, OO, wikis and Google docs using Roo”

Create fancy wiki home pages with Confluence, Lozenge and Nuvola icons

I think that it’s important to have nice looking wiki pages, especially for those high level pages that are viewed by a large audience. I’ve put this post together to explain how to setup Atlassian’s Confluence wiki with some freely available macros and icons to make fancy wiki pages to impress.


1) Atlassian Confluence

You need a running instance of Atlassian’s Confluence Wiki – you can get a free 30 day trial or free personal server license for personal use.

2) Content Formatting Macro

You need to have the free Content formatting macros installed. This can be easily done in Confluence under Administration->Plugin Repository.

3) Nuvola Icon sets attached to Confluence

You need to download the Nuvola icon set locally and attach these to your Confluence instance. Nuvola is a elegant looking icon set released free under LGPL.

Download this file, then unpack it (on Windows use something like 7-Zip), then upload all the 48×48 icons to new wiki pages in Confluence using the Confluence File Uploader that conviently runs directly from your browser.

I created five separate wiki pages under a master page called ‘Icons‘. I called these icons pages: ‘Icons Actions‘, ‘Icons Apps‘, ‘Icons Devices‘, ‘Icons Filesystems‘ and ‘Icons Mimetypes‘. You can create these pages under any space, so if you have an admin type space you’re probably best to use that.

You should put {gallery:columns=8} in each icon wiki page so the icons appear as thumbnails. You can put {children} in your Icons page to display the other child icon page names.

Creating the Actual Page

Creating the actual page is pretty easy once you have all the icons uploaded. The page uses three macros: columns, sections and lozenges. It’s a matter of reading the doco for each and experimenting with what looks best. I’ve posted my wiki source below.

You can then easily create a page template with some icons and blank labels so that others who use your wiki can easily create pages that look like this.

The Result

The final result
The final result - click to enlarge

Source code is posted below.

Continue reading “Create fancy wiki home pages with Confluence, Lozenge and Nuvola icons”

Software Testing Career Development

I am very interested in actively driving my own career in software testing. I believe that everyone should take responsibility for their own professional career development whether or not they get support from work to do so.

Ian Clatworthy recently shared his own professional development framework aptly named M.E.T.A. – Management, Engineering, Technology and Applications.

The framework is great in that it superbly breaks down technical professional development into four dimensions/pillars. The M.E.T.A. framework is probably better for software engineering so I have remixed it into something that suits my own software testing context better.

Leadership (Ian’s Management)

Whilst I have been in direct Management roles in the past, I currently do not work in one. I believe that it is important to demonstrate leadership no matter what role you are in. Even if your are not given the title Manager or Supervisor, or even if you don’t have people to manage, you can, and should, still demonstrate leadership. This is why I renamed Management to Leadership. For me Leadership is all about:


  • Using the right side of my brain – being organised, tidy & efficient (following concepts like 5S), being emotionally intelligent and aware, developing creative solutions.
  • Having a project management focus – following sound project management techniques and conducting each bit of work as a small project.
  • Writing Well – following known writing guidelines. Documenting every bit of work. Sharing all knowledge and information.
  • Communicating Well – Documenting well. Communicating progress and issues in the right format at the right time.
  • Team Building – establishing productive relationships with members of teams working in and with. I can’t emphasise how important this is.
  • Finding Informal Career Guiders – always indirectly looking out for people who you can chat to informally about career stuff. This is where I have discovered great leadership styles and techniques. I call these people career guiders because I really hate the word ‘mentor‘.
  • Being ethical – Making sure I provide value and I am honest in everything I do.
  • Sticking up for others you work with – Making sure that your fellow team mates are well supported.

Concepts (Ian’s Engineering)

I personally have chosen to focus more on the software part of software engineering. For me the Concepts pillar is all about the concepts and theories behind software design, development and testing. This is the stuff that I learnt at University and is generally timeless. For me Concepts is about ‘understanding’:


  • Understanding Software Development Methodologies: how IT software design and development works as a whole.
  • Understanding Software Projects: how IT software projects work.
  • Understanding Programming: knowing programming concepts and techniques.
  • Understanding Testing: understanding testing best practices, test driven development, test automation, acceptance testing.
  • Understanding User Centred Design: focusing on usability and designing for users. Paper prototyping and iterative design.
  • Understanding Design: understanding general design principles.

Tools (Ian’s Technology)

I was going to leave this called Technology but I ended up changing it to Tools as this is pillar is essentially the tools required enable the ‘Concepts’ above. These are different from concepts in that while most concepts are timeless, the tools or technologies tend to change.At present I am focusing on developing skills in using open source tools. I find these are good in that they are open and free (as in speech). Some tools I know and/or use are:


  • Programming Languages: such as Ruby, Python, Jython.
  • Testing Tools: such as Watir, and homebrew test automation tools.
  • Collaboration Tools: such as wiki’s, defect management, blogs.
  • Versioning Tools: such as SVN, Git, Mercurial, Bazaar

I guess that one component to this pillar that doesn’t fit under the term tools are the technologies that are worth knowing about and understanding (perhaps I should call it Technology after all!). Things like:

  • Ajax (Rich Internet Applications)
  • Web 2.0
  • Social Networking
  • Tag-based Folksonomies
  • RSS

Business-focus (Ian’s Applications)

I believe it is important to understand the business of where you work, as well as the applications that support the business. Even open-source projects have business, they are in the business of providing software developed by communities of people to be used by other communities of people. I often see IT staff that do not have understanding or respect for the business. For me, displaying a business-focus means:


  • Understanding business goals: why I am employed in the first place.
  • Understanding business applications: what they do and how they fit into the business processes.
  • Understanding business processes: how business is conducted, with or without IT.
  • Understanding how business and IT collaborate and partnership: Hoping that the tail doesn’t wag the dog!
  • Providing value to the business: continuing to be employed.
  • Keeping up to date with the business: knowing what the business industry/competition is doing and about the other happenings in the business domain.
  • Understanding how executive management operates: because they usually pay you and maybe you would like to be there someday.

As Ian covers well in his post, the pillars make a great ordered list of dimensions in terms of career mobility. As I renamed his Applications pillar to my Business-focus pillar, I tend to consider my Business-focus pillar to be equally as or more important than my Tools pillar.


This means that my ordered list of dimensions is essentially Leadership, Concepts, Business-focus & Tools.

Like any contextual approach, everyone’s pillars will be different. This is a good thing. Although sometimes an unbalanced focus on a particular pillar can cause problems in your career. For example, focusing mostly on the Buiness-focus pillar may mean you can’t easily move jobs into a different organisation/industry when you want to.

What’s worse is not thinking about your career at all. Organisations may consciously develop their staff (as good managers do) but as staff are becoming increasingly mobile and contracted, the responsibility for career development is being pushed back upon the individual. This is when coming up with a personalised, balanced and ordered career development framework (and continually revisiting it) is so important.

Business Driven Testing

Watir is a great library, but to use it to its full potential you need to create your own framework to drive it.

As with any context driven approach, the framework/solution you decide to implement has to suit your own environment. One approach that I have used successfully in multiple projects (with tweaks for each) is the business driven approach.

All the software projects I have worked on have had one main purpose, that is to support a business need. This business need may be to allow people to easily travel from country to country, or in contrast, allow enthusiasts to efficiently buy books online. Creating a test suite that is focussed around these real business activities will clarify the link from these to the the user tests you are writing and running. This also compliments a risk based testing approach as it is often easy to get business people to express the important and risky areas of the business, this being what will be tested first.

The concept of my framework is that the functionality of the software is divided into functions, each of which has user tests defined and scripted. These user tests can be easily strung together to test entire business scenarios, or soap opera scenarios if you are so inclined.

The first thing to do is split the areas of the software up into functions. You can then define user tests for each function. User tests are something that a user will do or currently does. They have to be real world. They usually consist of some inputs (data), some processing and an outcome. If the outcome is positive, usually there is output, for example, an ID. If the outcome is negative, usually there is an error message.

Performing this activity for the Depot Rails Application creates something like:

Function: Customer
User Tests: Empty Cart, Add Book to Cart, Check Out

Function: Administration
User Tests: Log On, Ship All Book Orders, Ship Some Book Orders, Add User, Delete User

This activity can be done for any kind of requirements and even if requirements don’t exist. You can do this from a functional requirements specification, use cases/user stories (easier), and you can do this (albeit less easily) from an existing system interface or prototype.

Your functions then become modules of Watir code, and the user tests become methods in these modules. Each method takes some data, and returns an outcome (it worked or it didn’t) and optionally an error or an output value.

For example, this is an empty Customer module with just the methods defined.


module Customer
   URL = 'http://localhost:3000/store/'

   def Customer.add_book(book_title)

   def Customer.check_out(customer_name, customer_email, customer_address, customer_payment_method)

  def Customer.empty_cart

For efficiency and usability, I always ensure that each user test is home based, meaning that it starts and finishes on the same home page/screen. This avoids ‘state’ problems occurring, so a series of user tests can be called to test a business scenario without worrying about where each user test starts and ends. This also avoids repetitious and inefficient startup/logging in/logging out for each user test. Don’t laugh, I have often seen this done.Your user tests should accommodate positive and negative tests in the same method. For example, our ‘Customer.check_out(…)’ user test should be able to test both valid and invalid credit card numbers. This is done by making the method return the outcome and then determing the result outside the method depending on your expected outcome.For example, although the method may return an error, we could be expecting this in our negative test so therefore our test actually passes.I have seen many people write specific methods to test specific error messages. Don’t be tempted to write ‘Customer.check_out_valid_card(…)’ and ‘Customer.check_out_invalid_card(…)’. This leads to an unmaintainable set of user tests due to the repetition of code required. Limiting the number of methods also makes it easier to define business scenarios as there are a limited number of methods for a business scenario tester to choose from.
Once you have defined modules and methods you need to define the business scenarios which involve running user stories providing data (positive and negative) as well as expected outcomes. It is best to use a data presentation language to do this.

Excel is very common data presentation language for designing user tests and business scenarios but versioning excel files can be problematic due to their binary nature.

A wiki is excellent for defining user tests and business scenarios in wiki tables as wikis have in built versioning, a centralised, accessible and flexible nature, and are generally easy to use.

In the coming weeks I will discuss how to set up a wiki page in Confluence as a business scenario which includes a series of user tests and then how to dynamically call the ruby methods and determine the test results from the method outcomes.