Contract vs Full Time IT Salary Rates in Australia

I have worked as both a IT contractor and also as a full time member of staff. I found there are benefits with  each form of employment.

To me, some of the benefits of being a contractor are:

  • Ability to change projects more readily;
  • Shorter term commitments to work; and
  • Networking opportunities working across various companies/contracts.

To me, some of the benefits of being a full time member of staff are:

  • More stability in times of turbulence;
  • Greater continuity of work;
  • Greater ability to borrow money from banks;
  • Availability of professional development and career opportunities;
  • Employee fringe benefits (shares/bonuses/insurances); and
  • The feeling of belonging and providing value to an organisation/team.

A lot of people I meet prefer contracting because they think it pays more. I am personally not convinced that contracting is much more lucrative. Let’s compare the same theoretical IT job as both a contractor and a full timer.

Job Details

Hours of work: 7.5 hours per day
Public Holidays:
11 public holidays per year
Annual Holidays: 4 weeks (20 days) per year
Sick Leave: Assume we take 5.
Professional Development: Attend 1 course and 1 conference per year. 5 days off work and $5000 in attendance costs.
Work Days In Year: 52 weeks * 5 days = 260 days
Days Off From Work (see above): 41 days
Actual Days Worked: 219 days
Actual Hours Worked: 219 days * 7.5 hours = 1642.5 hours

Full Time – $80,000 year base + superannuation (9%)

Total Salary Package = $80,000 + $7,200 super + $5,000 courses = $92,200 p.a
Effective Rate per hour:
$92,200 / 1642.5 hours = $56.13 per hour.

Contracting – $60 per hour net including superannuation (and agents fees and insurance already paid)

Gross Amount Received: 1642.5 hours * $60 per hour = $98,550
Effective Base Salary: $98,550 – ($8,136 (Super) & $5,000 courses) = $81,412.84 p.a

You can see that the financial difference between earning a salary of $80,000 per year and earning $60 per hour as a contractor is nominal.

But what if you worked, and billed, much longer hours as contractor? You could earn more, but that’s not really comparing apples with apples is it?

In conclusion, it does pay to think about what a full time salary means and what an hourly rate means. $60 per hour might seem like a lot but when you take into account all the extras that full time employment provides (continuity, superannuation & career development) you may not be getting a bad deal as a full timer after all.

Photo by jsarcadia (creative commons)

Why I like ruby over vbscript

I am glad that Watir uses ruby, rather than something like VBScript. I have been using VBScript a lot in my current job (as it is the only language that QuickTest Professional supports) and when I compare it to ruby, I often find it annoying and inefficient.

A dictionary (a.k.a. hash or associative array) is a good example.

Here is some code I used to create a simple dictionary in VBscript with five items, which then displays one of the item values:


Set dictCheckValues = CreateObject( "Scripting.Dictionary" )
dictCheckValues.Add "a",1
dictCheckValues.Add "b",2
dictCheckValues.Add "c",3
dictCheckValues.Add "d",4
dictCheckValues.Add "e",5
msgbox dictCheckValues.item( "c" )

Here is the same example but this time I used ruby:


check_values = {'a'=>1,'b'=>2,'c'=>3,'d'=>4,'e'=>5}
puts check_values['c']

You can see that the ruby example is not only more concise (2 lines vs 7), but I also find it more readable.

Python is another concise and highly readable language.


check_values = {'a':1,'b':2,'c':3,'d':4,'e':5}
print check_values['c']

I sometimes wish that Watir originally chose to use python over ruby. I find python is more broadly used there are generally a lot more libraries available for it. Although Python’s indentation can be confusing at times, especially across different platforms.

Five organisations I would love to work for (geography aside)

I believe that it’s a good idea to keep a wish list of companies that you’d love to work for. This is not just to make sure you keep an eye out for opportunities at these companies, but also to discover what it is that makes you want to work at these companies. This makes it easier to chose other jobs that have some of those same qualities.

Your wish list also guides you to make decisions that open up opportunities at these companies, whether that talking to your work collegues about what it would be like to work there, or doing a LinkedIn search to see if anyone in your ‘network’ already works there.

Your wish list doesn’t even need to be realistic. None of the companies on my list are based in Brisbane, and only two are even based in Australia. I’m pretty much set on living in Brisbane; I love it for many reasons. The main reason is the proximity to my family and inlaws. At the moment, no job could be better than that.

But here’s my list:

  1. Threadless: I think this article pretty much sums it up. I also love this other quote about when they were deciding on how to make more money: We’re like, “we should give them stickers because stickers are awesome.”
  2. Atlassian: They make rock solid products (Confluence, JIRA…), aren’t afraid to take on the big players, and strongly support open source. I also love their mission and culture.
  3. Automattic: – Any wordpress user would know why I would love to work for Automattic. They advertise jobs such as Happiness Engineer and state that… everyone who joins Automattic, regardless of position, does support for 3 weeks.
  4. The Big Issue: Not only do The Big Issue support a great cause: homelessness in Australia, but the magazine is a really good read too. There’s no other mag that I enjoy reading more. This is truly a dream job though – they only have a full time staff of… three!
  5. 37Signals: Who wouldn’t want to work with the creators of ruby on rails and the authors of Getting Real? They also write one of my favourite blogs. But the real reason is that they really dig writing skills, and I dig that.

Simple web application monitoring with Watir

One of things I love about Watir is its flexibility. For example, you can quickly and easily write a script to monitor your web application availability and schedule it to repeat periodically.

I like the idea of application monitoring that acts like a real user. It’s all well and good to monitor a server’s CPU and memory but if the user can’t access the logon page then the application is not doing its job.

I use SMTP to send an email if a page is unavailable. There is some good information about using SMTP connections in ruby available here. You need to specify an SMTP server which most organisations already have running, otherwise you can run one locally or use a public one such as Gmail. You can set up notification groups which then send text messages as well.


require "watir" # For connecting to web pages
require "socket" # For getting host name
require "net/smtp" # For sending email

MONITORED_URLS = ["http://www.google.com","http://www.ruby-lang.org/en/"] #This is a list of urls
EMAIL_FROM = "your.email@example.com"
EMAILS_TO = ["your.email@example.com"] # This must be a list of addresses.
SMTP_SERVER_NAME = "localhost"
LOG_FILE_NAME = "./watir_monitor_log.txt"

def check_page_available(url)
   begin
      start_time = Time.now
      ie_page = Watir::IE.start(url)
      load_time = (Time.now - start_time).to_s
      if (ie_page.check_for_http_error() or ie_page.text.include?('The page cannot be displayed')) then
         result = false
      else
         result = true
      end
   rescue
      puts "EXCEPTION RAISED: #{$!}"
      result = false
   end
   ie_page.close
   return result, load_time
end

def send_email(subject)
   Net::SMTP.start(SMTP_SERVER_NAME) do |smtp_server|
      EMAILS_TO.each do |email_address|
         email_message = "From: Web Site Monitoring Script \n"
         email_message << "To: #{email_address}\n"
         email_message << "Subject: #{subject}\n"
         email_message << "#{subject}\n\n"
         smtp_server.send_message email_message, EMAIL_FROM, email_address
      end
   end
end

# Start of Script
host_name = Socket.gethostname
MONITORED_URLS.each do |url|
	puts url
	date_time = Time.now.strftime( "%A %d/%m/%Y %I:%M %p" )
	result, load_time = check_page_available(url)
	if not result then
		send_email( "Could not connect to URL: . There may be a problem with this site." )
	end
		
	File.open(LOG_FILE_NAME, File::WRONLY|File::APPEND|File::CREAT, 0666) do |log_file|
		log_file.puts "#{date_time},#{host_name},#{url},#{result},#{load_time}"
	end # File closes automatically
end
# End of Script

I like to record page load times for historical data collection. I have logged this information locally for simplicity but you can also easily log this information to a wiki page (such as Confluence) so that it is easy for others to access as well.

Once you have the ruby script ready you can simply schedule it to run as a Windows task every 10 minutes or so. I usually create a one line batch file to call the script with the -b flag so the browser doesn’t display during execution.

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.