Category Archives: Career

Take control of your own career

During my career, I’ve come across numerous testing colleagues with no experience in automated testing who say things like “I’d love to do automated testing”. They expect to be put into an automated testing role so they can learn automated testing.

I don’t think it should work like that. Your employer shouldn’t be solely responsible for you enhancing your skills and progressing your career.

And, the thing is, it’s never been easier to pick up some new technical skills.

If you want to learn programming start by learning something like Ruby. If you want to learn about automated web testing learn Watir. If you want to learn about behavior driven development tools learn Cucumber.

I taught myself Ruby. I taught myself Watir. I taught myself C#, Python, Selenium, Cucumber and Jenkins. The list goes on.

The barrier to entry has never been lower. Try codeacademy, try ruby koans, download the free watir book, buy Cheezy’s cheap eBook about Watir & Cucumber.

So, instead of watching television or going out for drinks, spend your nights and weekends learning some new skills and taking control of your career instead of expecting your employer to hand it to you on a plate.

You’ll then be able to say “I’m learning all about Watir at the moment and I would love to apply that on a project” instead of “I’d love to do automated testing”.

Software testing as a career

This post is part of the Pride & Paradev series.


What do I think of software testing as a career?


Software Testing is the Worst Career on the Planet

It’s amazing how quickly you tire of testing the same thing over again in Internet Explorer 7 because the programmers don’t use Internet Explorer and hadn’t thought to test it in that.

The harder you work at finding bugs the lazier the developers become at letting them through.

People constantly question you about why you’re still a software tester and haven’t turned into a programmer yet as though technical specialism is a natural career progression.

Lots of people call themselves software testers because they’ve played with software over a couple of years and attended a testing certification course over a couple of days. You’re grouped into the same group as those people.

Just when you think you’ve got a user story tested in three different operating systems, four devices and eight browsers, the programmer decides to ‘refactor’ their code, or switch to a more in vogue JavaScript framework, rendering all your testing work void because every screen you have tested no longer functions.

And they expect you to test it by the end of the iteration which happens to be today.

Despite what iterative development brings testing always gets squeezed and you’re expected to constantly go above and beyond to get things done.

Career progression means either becoming a specialist ‘automated tester’ or a test manager, one involves writing code, that no one ever sees, the other usually involves writing wordy template driven test strategies, again, that no one ever sees.

But the absolutely worst thing about being a software tester is the distrust you develop in software. You constantly see software at its worst: it’s hard to believe that any software can be developed that actually works without any issues. This means you hold a deep breath every time you hit submit on a credit card form, praying that it will actually work and not crash and charge your credit card three times.

Software Testing is the Best Career on the Planet

Some days I am amazed at how much fun my job is. I get to play with cool gadgets: I have four smart phones and an iPad on my desk, use three operating systems and eight browsers on a daily basis.

I get to look at software from all different angles: from a user’s point of view, from the business/marketing view, from a technical viewpoint and try all kinds of crazy things on it.

I get to really know and understand how a system works from end-to-end, and get to know its quirks and pitfalls. Finding bugs prevents them from being released into Production and causing someone else a great inconvenience.

I develop great relationships with programmers who like the feedback I give, and business people who I work with to develop acceptance criteria and discuss issues in business terms and how they will be effected.

I get to understand code, database schema, servers and browsers. I am involved in automating acceptance tests. I get to go to awesome software testing conferences around the world to meet other testers.

I get to tell my family about all the cool things I’ve tested and they get excited to occasionally see things I have worked on in the media etc.

It’s a really cool career.

Thoughtworks Team Hug - September 2010 - Rutherford Park, Victoria - 20

Thoughts on Thoughtworks Australia Team Hug September 2010

I haven’t started yet at Thoughtworks (it’s still a week away), so I felt very privileged to be invited to the the bi-annual Thoughtworks Australia Team Hug over the weekend in country Victoria.

The weekend consisted of a series of talks and heaps of fun. I really enjoyed the talks by Martin Fowler on DSLs (Domain Specific Languages) and Chris Bushell on how to avoid branching code which was interesting as it relates to the new focus on Continuous Delivery.  I also enjoyed the two Dev-Ops talks, one frightening story by Tom Sulston and a much calmer one by Evan Bottcher. I need to look more closely into the Twist automated testing tool after seeing a demonstration of its features.

Besides the talks, there was a great Wild West themed party on Saturday night, complete with a photo booth that produced lots of hilarious photos. I dressed up as a cowboy, complete with chaps, boots, hat and guns. People went to huge effort in getting dressed up, there was even someone in a giant cow costume!

I managed to fit in a nice morning stroll on Sunday morning to enjoy the fresh country air and surroundings, which was very pleasant as I live in the city-city.

It was a great introduction to Thoughtworks culture and people and an all round enjoyable event.

thoughtworks Australia

A ThoughtWorker to be

I’ve recently accepted an opportunity with Thoughtworks, who are setting up a presence here in Brisbane, Australia.

I am thrilled to be offered this opportunity to work for a company who is passionate about revolutionizing IT and is so well aligned with my values and ideas. I found the Thoughtworks recruitment process to be very thorough, whilst not over the top, and actually enjoyable. This is because it gave me a great insight into the company as I got to meet a lot of thoughtworkers, and I felt very confident to  accept the job offer without any reservations. Thoughtworks thoroughness in assessing candidate’s technical ability and aptitude also made me confident that I will be working with other very capable individuals.

I look forward to beginning at Thoughtworks in mid-September as a Senior QA Consultant, and in the meantime I will be having a short break with my family.

Why I do automated testing

I often get asked the question: “so why do you do automated testing?” both in job interviews and from people I meet. My answer is always pretty much the same; being that it provides me with exposure to a variety of business domains and technologies, and allows me to write code.

Let me expand a bit further on this. I like writing code but I’ve chosen not to be a software engineer. The reason is that I have met lots of different software engineers that have responsibility for one area of a system. They become the expert in this area of the system, hence when you find a problem in that area, you know who to speak to. Often time these people don’t really know much outside their area of expertise in the system, so when the problem is outside their own area, you need to speak with someone else. There’s nothing wrong with this, but it just isn’t me.

I like to know, or attempt to ‘work out’, how the system functions as a whole. I usually achieve this on a project I join by writing an automated build verification test, or ‘smoke’ test, that verifies the system functions as a whole. I love writing these kinds of tests because you need to know how the entire thing works, not just the isolated components. Software testing is one of the few areas where you get this broad level of exposure, and this keeps things interesting.

Another added bonus of doing software testing, is that your skills are pretty transferable, both across business domains and different technologies. For example, so far in my career I have tested systems that:

  • manage job advertisements, job seeker matches and interviews;
  • process immigration and visa applications;
  • manage disability support and funding;
  • produce electronic school report cards;
  • optimise large scale open cut mines;
  • monitor health of heavy machinery; and
  • manage large funds for people’s retirements.

These systems were developed in various technologies including:

  • Java;
  • Microsoft .NET;
  • Cobol;
  • Powerbuilder;
  • Web;
  • Active X;
  • Terminal Emulators;
  • SOAP web services and;
  • CICS.

The point I am trying to make is that if I decided to be a Java Software Engineer when I finished university, because that’s why I studied, I wouldn’t have had exposure to so many technologies and business areas that I have had as an automated software tester.

Sure, I could become a business analyst, because they work across business domains and technologies, but business analysts don’t code, and I do like writing code, that’s why automated testing is perfect.

The final benefit I see in automated testing is that you can apply your skills in particular testing tools to other tools fairly easily, as the concepts are the same. The biggest issue I see with people doing automated testing isn’t picking up a new tool, but rather developing a maintainable and easy to use test framework. Once you have developed a few frameworks for various business domains and technologies, it is easy to apply the concepts to other testing tools.

So that’s why I do automated testing, and I proud of it.

Austin Workshop on Test Automation (AWTA) 2009

Watircraft are organising the Austin Workshop on Test Automation to be held on 16-18 January 2009 in Austin, Texas.

I have been approved to attend. It means three long flights from Australia (about 25 hours each way) but I am really looking forward to attending and meeting different people who are involved in Watir.

I haven’t been to America before either, so it should be really good.

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.

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)