Personal Business Cards

Even though I do a lot of networking via the web these days, I still appreciate meeting people with similar work interests in person at events and conferences.

Although it may be considered old fashioned, I think it’s a really good idea to have business cards to share with others you meet so that they remember you and can connect with you later on if they want. Although some places provide business cards to their staff (like my current job), these are often quite bland, so I think it’s a good idea to have your own personal business card. A personal card is more likely to stand out and show who you really are. You can also put your personal contact details on it, like the address of your blog and your LinkedIn page, and have no hesitations about handing it out.

My favourite site for creating these cards is Moo, an online print shop that is located in London but ships worldwide. They use high quality card and inks, and send witty emails as well. I created some MiniCards a while back for my right brain blog, which are really cool, and I noticed last night they now do full size business cards which I ordered last night for this blog.

When coming up with a design, I considered designing a card with my name on in my own handwriting because of an excellent article I read recently. But I ended up with a different design because the handwriting was too risky. On one side I put the header of this blog in bright red, and on the other side some simple type with my details, but written in ruby syntax. I used ruby syntax to make it look clever and relevant.

They should arrive in the next few weeks (the express shipping was too expensive) and I’ll scan one and share it on here when they do arrive. I can’t wait.

The future of testers

Bret Pettichord wrote a thought provoking blog post today that raised some interesting questions about the future of testers in automated testing:

Will there be a role for testers in the future of automated testing? Will this role be defined by developers?

I agree with a lot that Bret has to say. With the increase of new, cheaper, more open and more integrated automated testing tools, I have noticed that developers are becoming increasingly interested in, and responsible for, automated tests. Whilst traditionally automated testing tools, especially ones that test GUIs, were the responsibility of a testing team during a testing phase, these new tools can easily be integrated into software development activities.

The benefits are quite obvious; developers start making their software more testable, and as their automated tests are run more frequently, they are more likely to be kept ‘alive’, and they find more defects early: increasing quality AND velocity.

But as Bret asks, what happens to the testers in all this? Those testers who once wrote and ran those automated tests.

Like Bret, I think that testers still will have a significant role in the future of automated testing. This is because I believe that a developer and a tester have two fundamentally different perspectives. I have found that developers often have a constructive perspective: focused on building something and making sure that it works, whereas a tester has an innate deconstructive perspective, trying to break the something or prove that it won’t work. These perspectives are shown by the fact that often testers design more comprehensive negative tests than developers.

But I don’t believe that having a different perspective will save a tester: it’s not that easy. I think, to survive, new testers need to adapt. And to adapt they need to be two things:

  • Technologically Savvy: Testers will need to be increasingly technical to keep up with developers who are also now doing automated testing. For example, a developer may write a neat XML API so that a tester can write tests more efficiently and effectively, but the tester will need to know how to do so.
  • Business Focused: With both developers and testers running automated tests, a key point of differentiation is business focus. Often developers write tests for specific functionality they have built, but a tester is often required to test multiple functions. When testing these multiple functions, the tester needs to be able to demonstrate to the business what is being tested. By focusing on business scenarios (or user stories) and using business terms, it is easier to link these tests back to the business and demonstrate value.

It’s great that so much effort has been put into deliberately making Watir user friendly. It has meant that it is easy for both developers AND testers to write tests.

One area of difference is deciding on how to implement a Watir framework, because I believe that some frameworks are developer focused (Rspec, Test::Unit) whereas others are more tester focused (Confluence & Rasta).

This is why I am looking forward to seeing future WatirCraft Watir offerings in the framework space. Because of the perspective thing I mentioned, I believe that it will be challenging to design a framework that suits these two different user groups.

Automated testing and saving money

I am embarrassed when I hear test tool sales people talk about how much money automated testing can save your organisations. I have heard them rattle off figures like ‘it’ll save you 85% of testing effort‘ and ‘it will reduce the number of manual testers that you need to employ‘.

These statements are wrong and contradict many of the lessons learned in software testing, including “Lesson 102: Speed the development process instead of trying to save a few dollars on testing”, and “Lesson 108: Don’t equate manual testing to automated testing”.

Because Watir is not a commercial tool and there are no up front licensing costs, I suppose that a return on investment doesn’t need to be justified in quite the same way. I do understand there are maintenance costs of Watir (time and effort), but if you incrementally implement Watir sensibly you can easily show the benefits as you go.

One of the best things I have heard someone say about automated testing is that it is one of the only things that can increase both quality and velocity.

For example, making sure that every line of code checked in has been peer reviewed may indeed increase quality but it may also severely impact velocity.

By contrast, doing daily builds may increase velocity, but it may also decrease quality if each build isn’t tested properly.

So, what the test tool vendors need to really say is that, automated testing, done well, can increase your quality and velocity. And while they’re at it, they may as well mention that Watir rivals many of the proprietary offerings, plus it has no licensing costs.

Weird ways of working, car indicators, and shoshin.

Have you noticed how weird you think things are when you start in a new organisation?

But then things slowly become normal, even though the ways of doing things don’t change?

For example, I bought a new car at the start of this year. In the first few weeks of driving I noticed that the indicators were weird; they made a loud clicking noise from the dash. Loud enough for passengers to hear (and comment on). But soon I stopped noticing them; my weird indicators had become normal. Last weekend I hired a car in Canberra for the weekend. The indicators were so quiet. Weird!

This concept is known in Zen Buddhism as Shoshin. From Wikipedia:

Shoshin (初心, also pronounced nyuanshin) is a concept in Zen Buddhism meaning Beginner’s Mind. It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject, even when studying at an advanced level, just as a beginner in that subject would.

This is a pretty powerful thing to have, but after starting in an organisation it’s also pretty easy to lose it. That’s why things no longer seem weird even though they haven’t changed.

As a new starter, make sure that you jot down all the weird things from day one, so that you can remember them. You can then organise a meeting with your manager a few weeks (or months if that’s more comfortable) and discuss these things. You should frame them in a positive way, that way you won’t come across as criticising things.

As a manager, you can make sure you capture all this powerful information by organising regular but succinct one-on-one meetings with your new starters and asking them what they think is weird and how things could be done better. Because It’s going to get harder to capture this information as your new starter slowly loses their shoshin and begins thinking of things as normal.

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.