Five reasons starting with F on why I use Watir

Bret Pettichord is working on a business case for Watir and has asked the Watir community for reasons on why they use it.

Here’s my ordered list of five reasons I use Watir:

1. It’s Free (as in beer)

Watir being free (as in beer) straight away makes it a very attractive test tool. This has meant that automated testing has ‘gotten in the door’ on projects where commercial automated testing tools would not have been looked at in the first place.

Once Watir’s benefits are evident, more and more team members want to use it. It is then a simple, quick install on other’s machines. The process for purchasing and generating commercial test tool licenses is often very lengthy and time consuming which means it ultimately won’t be running on as many machines as Watir will be.

2. It’s Free (as in freedom)

Because Watir is open source and uses a modern object oriented scripting language, it provides its users with the freedom to tailor it to how they want to use it. Nothing is hidden and mysterious so users can often solve their own problems without consulting others or vendor support.

3. It’s Flexible

Watir is a very flexible ruby library that supports many scripting tasks. The main reason I have used it is to conduct automated regression testing but I have also used it to create test data in systems, schedule and run automated web site monitoring scripts (complete with alerts), as well as one-off scripts that are quick to write and get the job done.

4. It’s Fast

Execution speed is as good as Quick Test Professional. The in built browser synchronisation is better than Quick Test Professional.

The ramp up time for users to learn ruby and watir is very fast compared to languages like TSL (WinRunner), SQA-Basic (RR) and Java (RFT).

The installation and implementation of Watir is fast, easy and lightweight. There are no server components to install like Selenium.

5. It’s Fun

Ruby is a unique programming language in that it has been designed to be fun and you can get better at using it every day. I love the ‘Ah-ha’ moments when using Ruby where you realise that you can do something just a little bit neater and more efficient.

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, OpenQA.org 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.

Conclusion
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.

Customer.rb

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

   def Customer.add_book(book_title)
   end

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

  def Customer.empty_cart
  end
end

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.