On why and how I became a freelancer

Every now and then I get an email or a LinkedIn message from someone asking me for advice on how to become a freelancer in the test automation space. Since I’m a lazy guy, I prefer to not do the same thing too often, and that’s why I’m writing this blog post. In the future, it’ll save me some time, hopefully, since I can simply answer similar questions by sending this link. Also, I think it might give you, my readers, some insights into how I work and what I do.

My career so far
I’ve been in the test automation field for about 11 years when I’m writing this. After getting a master’s degree in Computer Science from Twente University and a 1,5 year stint in a job unrelated to testing, I started my test automation career as a young professional with Sogeti. Three years into that, I felt like I hit a ceiling and moved to Oelan, a smaller consultancy firm. This being a much smaller organization allowed me to make myself much more visible and work on much more interesting projects.

I had a great time there, with awesome coworkers and a relatively large amount of freedom. Next to being an automation engineer, this is also where I took my first steps as a trainer, providing tool-specific automation training to clients around the country. Lastly, in the final years of my time at Oelan, I also started this blog, which celebrates its fourth birthday next month.

So, why did I become a freelancer then?
Even though I was quite happy with my job, the idea of working as a freelancer started to nestle itself inside my head ever firmer in the last years. The idea of being

  • 100% free to decide which projects to say ‘yes’ to, and which to respectfully decline,
  • 100% free to decide how I fill my working days, instead of having to work with the target billable hours of an employer, and
  • 100% responsible for all decisions I make with regards to the way my career develops

was something that I’d at least wanted to try once.

Note that money was not a primary factor for me in the decision to start freelancing. It is true that my income has seen a decent rise since I quit being an employee, but with that comes responsibility. More on that later.

How did I start out?
The final trigger to make the jump towards freelancing came when I was invited for a chat by someone from The Future Group, a Dutch collective of freelance IT specialists. I joined them as a freelancer in November 2014, and in return for a part of my hourly fee, they arranged meetings, sales and administrative support and some other useful things. For all tax and legal purposes, I was a freelancer, but with a safety net.

After just under three years of working with The Future Group, I felt that I was ready to go fully solo, and as of September 1st of this year I’ve been working under the flag of On Test Automation. I couldn’t be more content. And a little proud as well (though that’s still hard to admit to myself..).

Now I really want to be a freelancer too! What I do need to take care of?
For me, the feeling of being a freelancer can be summarized in two words: freedom and responsibility.

  • I’ve got the freedom to decide what I want to do, when I want to do it. Sure, I need to keep my clients happy, but that still leaves a lot of room for freedom. Freedom to take a day off to spend it with my sons instead of going to work. Freedom to say ‘yes’ to an invitation for lunch with a prospective client or partner. Freedom to, in short, do what I want, not what somebody else think I should do. All without having to deal with a maximum amount of annual leave, billable hour targets, or anything else.
  • On the other hand, my levels of responsibility have increased vastly as well. I can’t rely on a steady paycheck from an employer anymore, yet I still have a family, a mortgage and other things to provide for. I have no automatic pension plan, yet I want to be able to retire comfortably at some point in time. I have no employer that takes care of insurance, yet I still run the risk of breaking stuff or becoming ill.

Some tips to deal with this: reserve time for business and personal development, take care of insurances, think about a pension plan, get a reliable accountant. And enjoy the ride! Even if you someday go back to being an employee, at least you’ve tried. That’s more than a lot of other people can say. There’s nothing wrong with being an employee, but there is no point in saying ‘I wish I did so or so’ when it’s too late.

So how do you get projects?
I’m the first to admit I’m in a luxury position. I’ve got decent automation skills, I have decent communication skills, and that’s more than enough to pretty much get work thrown at you at the moment. At least here in the Netherlands, I can’t speak for other countries.

There’s one thing I do religiously to make it as likely as possible that I remain in this position, though, and that’s investing in myself. This manifests itself in different forms:

  • I take time to talk to potential clients and partners and see if I can help them, even if this cuts into my billable hours.
  • I take time to learn and study, even if this cuts into my billable hours.
  • I take time to work on my personal brand (through writing or speaking), even if this cuts into my billable hours.

I sometimes get asked why it is that projects come to me. This is why. I invest heavily in myself and my network. In return, people call me when they need someone.

I haven’t had to actively look for a new project for a while and I’d like that to remain the same for the foreseeable future. I wouldn’t like to be one of the many fighting to be hired for available projects if the market gets worse.

Personally, I prefer working with consultancy firms instead of freelancers. Since I’ve been in the field for a while, and since the field over here isn’t that huge, my network is quite substantial, also within these consultancy firms. Some of them do work with freelancers in case they haven’t got anyone available themselves who’d be a good fit for their clients.

The big advantage they have over working with most recruitments firms is that they work directly with their clients, and as such know exactly what their clients need and if I’d be a good fit. This works well for everybody. There’s one recruitment agency in the Netherlands that I do like to work with, since they specialize in testing and automation and I know them quite well.

Other than that, I almost exclusively work through consultancy firms (it’s still quite hard to get a foot in the door with a client directly as a freelancer).

What does my future look like?
I’d love to do less ‘billed-by-the-hour’ projects and more training, writing and speaking in the future. I gave a talk at a Dutch testing conference last week, and I’ll be speaking at TestBash Manchester next week, so that’s a good start, but I’d love to become even better at public speaking. I’m working on it, though! I’ll also be delivering a couple of training courses (in various forms) in the coming months, so that’s improving too, but there’s room for more. Here, again, it comes down to investing time in selling myself and making others aware that this is something I have to offer.

In the end, I hope to be able to experience this freedom for a long time to come. I know that in order to do so, I’ll have to keep investing in myself, so I will do that. There’s a lot at stake, and I really don’t want to be an employee anymore! At least, that’s how I feel now. People change, and so may I, but for now, I’m quite the unemployable..

I hope this information has given you some insight in why and how I became a freelancer and what I think it takes to become a successful one. As always, feel free to comment or send me an email if you’d like to react or want to know more.

On finding my ideal ratio between consulting, teaching and writing

Those of you that have been reading my blog posts for a while know that I like to reflect on my own career from time to time. Since it’s been a while since I wrote such a blog post, I thought it would be a good idea to share with you what I’m up to at the moment.

Basically, my working time is still divided into three subjects: consulting, teaching and writing. I’m continuously trying to find out what is the ideal ratio between each of these activities, something that’s partly under my own control, yet also depends on the amount of work that’s coming my own. Or that I am able to steer my way, of course.

Here’s a quick recap of my activities in each of these three fields.

On site consulting still makes up the major part of my working week. Not sure how the situation is in the rest of the world, but here in the Netherlands there’s plenty of work available for those who know a little about test automation and have some communication skills too, so getting projects isn’t too hard at the moment. I have to say ‘no’ more often than I can say ‘yes’!

That’s a very luxurious position to be in, I definitely realize that. And yet.. It’s safe, since I am guaranteed an income for at least 25-30 hours per week (it’s all billed by the hour), but I feel it does also make me complacent at times. This might sound strange (or spoiled), but I could actually do with a little less consulting work, but that would require having more work in the other two categories. Either that, or seeing a significant (but hopefully temporary) fall in my income, a prospect which I don’t particularly look forward to.

It’s been too long, but I finally had (or created, depending on how you look at things) another opportunity to deliver on site training, this time with my former employer. I spent two evenings with around 10 students, teaching them about the concepts behind API testing and automation and introducing them to a range of tools (more on that training course and the approach I experimented with here). This reminded me how exciting and motivating it is to deliver training, and that it definitely is something I feel I should pursue harder. Ideally, I’d do at least two or three of these courses a month, but I’m nowhere near that frequency yet.

I have started working on a related project, though. It’ll be an online course around Selenium, which will hopefully see the light of day in the coming months.

Next to that, I’m actively working on finding more ways to deliver on site training, both at clients here in the Netherlands as well as at conferences. This is a slow process, but I’ve made some good connections in the past few months and I’m positive this effort will pay off soon enough.

And while we’re on the subject of conferences: I’ve got two talks coming up this month. First, I’ll be at the fall conference of the Dutch testers association TestNet (site in Dutch), and later this month it’s time for TestBash Manchester. Really looking forward to speaking at and being a part of both of these events!

Finally, I was a panelist at a webinar hosted by the people at Testim, where we talked about creating an automation strategy fit for CI/CD and the skills required to do so. For those of you that missed it, you can find a recording here.

This one I’ve actively put on the back burner for a while. In the past few months, I’ve written quite a few articles for TechBeacon, StickyMinds and some other one-off blog posts, next to my weekly blog post on this site, of course. That spread me a little thin so I decided to stick with my weekly OnTestAutomation blogs for a while.

I am currently working on something related to writing, though: I’m the technical editor for a book on test automation that’s to be released in the first half of next year. This is something I’ve never done before, but that’s only a good thing.

The gist of this is that I could do with a little more teaching and a little less consulting and that I’m actively working on making that happen. As ever, it’s an interesting journey.

Why there’s no such thing as codeless automation

In today’s blog post – which, again, is really nothing more than a thinly veiled rant – I’d like to cover something that’s been covered before, just not by me: codeless test automation and why I think there isn’t and should not be such a thing.

I’ve seen numerous ‘solution’ vendors advertise their products as ‘codeless’, implying that everybody in the team will be able to create, run and maintain automated tests, without having to, well, write code. I’ve got a number of problems with selling test automation in this way.

It’s not codeless. It’s hiding code.
The first gripe I have with ‘codeless’ automation is a semantic one. These solutions aren’t codeless at all. They simply hide the code that runs the test from plain sight. There are no monkeys in the solution that magically execute the instructions that make up a test. No, those instructions are translated into actual code by the solution, then executed. As a user of such a solution, you’re still coding (i.e., writing instructions in a manner that can be interpreted by a machine), just in a different syntax. That’s not codeless.

While it might be empowering, it’s also limiting.
Sure, using codeless tools might potentially lead to more people contributing to writing automated tests (although from my experience, that’s hardly how it’s going to be in the end). The downside is: it’s also limiting the power of the automated tests. As I said above, the ‘codeless’ solution is usually nothing more than an abstraction layer on top of the test automation code. And with abstraction comes loss of detail. In this case, this might be loss of access to features of the underlying code. For example, if you’re using a codeless abstraction on top of Selenium, you might lose access to specific waiting, synchronization or error handling mechanisms (which are among the exact things that makes Selenium so powerful).

It might also be loss of access to logging, debugging or other types of root cause analysis tools, which in turn leads to shallower feedback in case something goes wrong. While the solution might show you that something has gone wrong, it loses detail on where things went wrong and what caused the failure. Not something I like.

Finally, it might also limit access to hooks in the application, or limit you to a specific type of automated tests. If such a solution makes it potentially easier to write automated tests on the user interface level, for example, there’s significant risk that all tests will be written at that level, even though that might not be the most efficient approach in the first place. If all you’ve got is a hammer…

It’s doing nothing for the hard problems in creating maintainable automation.
Let’s face it: while writing code might seem hard to people that haven’t done it before, it actually isn’t that difficult once you’ve had a couple of basic programming classes, or followed a course or two on Codecademy. What is hard is writing good, readable, maintainable code. Applying SOLID and DRY principles. Structuring your tests. Testing the right thing at the right level. Creating a solid test data and test environment strategy. Those things are hard. And codeless test automation does nothing for those problems. As I tried to make clear in the previous paragraphs, it’ll often make it even harder to solve those problems effectively.

I’m all for creating solutions that make it easier to write, run and maintain automation. I hate people selling solutions as something they’re not. Codeless test automation is not going to solve your test automation problems. People that know

  • how to decide what good automation is
  • how to write that automation, and
  • how to pick the tools that will help them achieve the goals of the team and organization