On choosing both/and, not either/or

Choices. We all make them tens of times each day. Peanut butter or cheese (cheese for me, most of the time). Jeans or slacks (jeans, definitely). Coffee or tea (decent coffee with a glass of water on the side please). And when you’re working on or learning about automation, there’s a multitude of choices you also can (and sometimes have to) make. A lot of these choices, as I see people discussing and making them, are flawed in my opinion, though. Some of them are even false dichotomies. Let’s take a look at the choices people think they need to make, and how there are other options available. Options that might lead to better results, and to being better at your job.

Do I need to learn Java or .NET? Selenium or UFT?
Creating automation often involves writing code. So, the ability to write code is definitely a valuable one. However, getting hung up on a specific programming language might limit your options as you’re trying to get ahead.

I still see many people asking what programming language they need to learn when they’re starting out or advancing in their career. If you’d ask me, the answer is ‘it doesn’t really matter’. With the abundance in tools, languages, libraries and frameworks that are available to software development teams nowadays, chances are high that your next gig will require using a different language than your current one.

As an example, I recently started a new project. So far, in most of my projects I’ve written automation in either Java or .NET. Not in this one, though. In the couple of weeks I’ve been here, I’ve created automation using PHP, Go and JavaScript. And you know what? It wasn’t that hard. Why? Because I’ve made a habit of learning how to program and of studying principles of object oriented programming instead of learning the ins and outs of a specific programming language. Those specifics can be found everywhere on Google and StackOverflow.

The same goes for automation tools. I started writing UI-level automation using TestPartner. Then QuickTest Pro (now UFT). I’ve used Selenium in a few projects. I’ve dabbled with Cypress. Now, I’m using Codecept. It doesn’t matter. The principles behind these tools are much the same: you identify objects on a screen, then you interact with them. You need to take care of waiting strategies. If you become proficient in these strategies, which tool you’re using doesn’t matter that much anymore. I’ve stopped chasing the ‘tool du jour’, because there will always be a new one to learn. The principles have been the same for decades, though. What do you think would be a better strategy to improve yourself?

Identify and learn to apply common principles and patterns, don’t get hung up on a single tool or language. Choose both/and, not either/or.

Do I stay a manual tester or become an automation engineer?
Another one of the choices I see people struggling with often is the one between staying a ‘manual tester’ (a term that I prefer not to use for all the reasons Michael Bolton gives in this blog post of his and becoming an automation engineer. If you’d ask me, this is a perfect example of a flawed choice in the testing field. It’s not a matter of either/or. It’s a matter of both/and.

Automation supports software testing, it does not replace it. If you want to become more proficient in automation, you need to become more proficient in testing, too. I’ve only fairly recently realized this myself, by the way. For years, all I did was automation, automation, automation, without thinking whether my efforts actually supported the testing that was being done. I’ve learned since that if you don’t know what testing looks like (hint: it’s much more than clicking buttons and following scripts), then you’ll have a pretty hard time effectively supporting those activities with automation.

Don’t abandon one type of role for the other one, especially when there’s so much overlap between them. Choose both/and, not either/or.

Do I learn to write tests against the user interface, or can I better focus on APIs?
So, I’ve been writing a lot about the benefits of writing tests at the API level, not only on this blog, but also in numerous talks and training courses. When I do so, I am often quite critical about the way too many people apply user interface-driven automation. And there IS a lot of room for improvement there, definitely. That does not mean that I’m saying you should abandon this type of automation at all, just that you should be very careful when deciding where to apply it.

Like in the previous examples, it is not a matter of either/or. For example, consider something as simple and ubiquitous as a login screen (or any other type of form in an application). When deciding on the approach for writing tests for it, it’s not a simple choice between tests at the UI level or tests at the API level; rather it depends on what you’re testing. writing a test that checks whether an end user sees the login form and all associated in their browser? Whether the user can interact with the form? Whether the data entered by the user is sent to the associated API correctly? Or whether the form looks like it’s supposed to? Those are tests that should be carried out at the UI level. Checking whether the data provided by the user is processed correctly? Whether incorrectly formatted data is handled in the appropriate manner? Whether the right level of access grants is given to the user upon enter a specific combination of username and password? Those tests might target a level below the UI. Many thanks, by the way, to Richard Bradshaw for mentioning this example somewhere on Slack. I owe you one more beer.

Being able to make the right decision on the level and scope to write the test on required knowing what the benefits and drawbacks and the possibilities of the alternatives are. It also requires the ability to recognize and apply principles and patterns to make the best possible decision.

Again, identify and learn to apply common principles and patterns, don’t get hung up on a single tool or language. Choose both/and, not either/or.

The point I’ve been trying to make with the examples above is that, like with so many things in life, being the best possible automation engineer isn’t a matter of choosing A over B. Of being able to do X or Y. What, in my opinion, will make you much better in your role is being able to do, or at least understand, A and B, X and Y. Then, extract their commonalities (these will often take the form of the previously mentioned principles and practices) and learn how to apply them. Study them. Learn more about them. Fail at applying them, and then learn from that.

I’m convinced that this is a much better approach to sustainable career development than running after the latest tool or hype and becoming a self-proclaimed expert at it, only to have to make a radical shift every couple of years (or even months, sometimes).

Don’t become a one trick pony. Choose both/and, not either/or.

On quality over quantity and my career journey

As you might have read in last week’s blog post, TestBash Manchester, the talks I’ve heard there and the discussions I had around the event with other speakers and attendees, left me with a lot to think about. Especially Martin Hynie’s talk on tester craftsmanship, apprentices, journeymen and masters of the craft led to me asking a lot of questions to myself on where I am now, how I ended up where I am today, where I want to go and, most importantly, if the things that I am doing at the moment contribute to, or maybe hinder me, in my own journey towards who I want to become.

Martin’s talk and how he described masters of a craft confirmed me that that, for me, is what I do want to become: a master in the craft of automation. Someone that others turn to when they need help, and someone that is able to help and guide others on their way to becoming a master -or at least a better craftsperson- themselves. I also immediately realized that I’m nowhere near that point yet.

I might be on my way, possibly (hopefully!) even on the right way, but having thought about this for a bit now, it once more occurred to me that there is so much more to learn. Some aspects that I need to improve are directly tied to automation and testing, others are skills that are more broadly applicable (public speaking, teaching, communication skills, to name just a few), but all in all, there’s a lot of learning left to do.

I am very much looking forward to taking the next steps on my path towards mastery, but I also realize that I need to get rid of some superfluous baggage at the moment, consisting mostly of activities that take up a lot of my time yet aren’t contributing (enough) to my journey. In the words of the German designer and academic Dieter Rams, it’s time for ‘less but better’, or ‘weniger aber besser’ as he puts it himself, being a German and all..

Anyway, there are a couple of work-related activities that I will need to get rid of -or at least change significantly- in order to carve out the time required to work on the important. Starting with the projects I’m working on. I’ve just wrapped up one, but I’m still working on two different projects in parallel.

Where I used to think this was the ideal situation to be in (I do get bored quickly if I’m working on the same thing for too long), I’ve slowly started to come to the realization that all this context switching is driving down the quality of my work. Believe, no matter how hard you try dedicating specific days to specific projects, there will always be overlap in the form of emails, phone calls and other seemingly urgent, and sometimes even important, interruptions. Just like with other forms of multitasking, I lose a lot of time moving my mind from one project to the other and back again, sometimes multiple times a day.

What doesn’t help is that not all of the projects I’ve been working on lately have been equally satisfying (and in specific cases, that’s putting it mildly..). Doing only one project at a time should allow me to think more clearly about whether or not the project is, in fact, a good fit for me. So, effective as soon as I wrap up my current projects, I’ll start committing myself to working on just a single client project (meaning by-the-hour consulting work) at a time. Ideally, that would take up 3 (maybe sometimes 4, maybe sometimes 2) days of my working week, ensuring that I am both set with regards to my financial commitments (gotta feed the kids!) as well as have enough time left to dedicate to the other things I want and/or feel the need to work on. Most of those things revolve around training courses, workshops and a bit of public speaking, by the way.

Committing to less but better also means that I’m, at least for the moment, giving up on writing weekly blog posts for this site. Even though it is a highly rewarding activity, it takes up a lot of time to plan, write and review blog posts. I’ll leave the discussion on whether or not my blog posts look like significant time has been put into it to you.. Instead, I’ll shift towards writing at least one blog post per month.

The good news is that this will leave me more time to do research and thinking for my blog posts, which (at least theoretically) should lead to higher quality output. Again, less but better.. I might post more often than once a month, in case I’ve read a good book related to testing or automation, a conference experience I want to share or anything else I feel like writing about, since those posts take less effort in my case. However, I think I need to stop pressurizing myself to write a weekly blog post, since it might start to affect the quality soon. If it hasn’t started doing so already.

Lastly, I am considering looking for a mentor who can help me take the next steps on my journey towards mastery. The above measures I’m taking should help freeing up time to do the things I feel are important (e.g., more time for learning, more time to invest in teaching and developing courses), but I am by now quite convinced that I might benefit from a mentor that helps me to navigate the career and life path that’s ahead of me. I’d love to hear from others who either have been on roughly the same point in their career and have (or have not) benefited from having a mentor, or who can help me find a good mentor. All input is greatly appreciated.

So, in short, you’ll hear less from me from this moment on, but hopefully also more. And better. I’m looking forward to the next stage of my journey.

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.