Utterly unemployable, or another update on crafting my career

I can’t believe we’re almost halfway through April already.. With 2017 well on its way, I thought it would be a good time for another post on the way I’m trying to craft my career and build my ideal ‘job’ (that’s intentionally put between quotes). As you might have read in previous posts I wrote on this topic, I’m working hard to move away from the 40 hour per week, 9 to 5 model that’s all too prevalent in the IT consultancy world.

I’m writing this post because I see another trend in the projects I’m taking on. Whereas earlier I would join an organization temporarily as part of an Agile team and take on all kinds of tasks related to testing and test automation, I’m more and more working on shorter term projects now, where clients ask me to build an initial version of a test automation solution for them and educate them in extending and maintaining it.

Not coincidentally, this is exactly the type of project for someone who gets bored as quickly as I do. A typical project nowadays spans between two weeks and two to three months and looks somewhat like this:

  1. Client indicates that help is needed in setting up or improving their test automation solution.
  2. I discuss with and interview client stakeholders to get the questions behind the question answered (what is it that you want to test in an automated manner? Does that make sense? What’s the reason previous attempts didn’t work?). This is probably the most important stage of the project! Failing to ask the right questions, or not getting the answers you need increases the risk of a suboptimal (or useless) ‘solution’ afterwards.
  3. I start building the solution, asking for feedback and demoing a couple of times per week, with the frequenct depending on the number of days I have for the project and the number of days per week I can spend on the project.
  4. I organize a workshop where the engineers that will be working with the solution after I have left the building spend some time writing new tests and maintaining existing ones. This gives me feedback on whether what I’ve built for them works. It also gives the client feedback on whether the solution is right for them.
  5. After gathering feedback, I’ll either wrap up and move on or do a little more work improving the solution where needed. This rework should be minimal due to the early feedback I get from interviews and discussions with stakeholders.

After my time with the client ends, I’ll make an effort to regularly follow up and see whether the solution is still to their liking, or if there are any problems with it. This is also an opportunity to hear about cool improvements that engineers made (and that I can steal for future projects)!

Next to this consulting work, I’m spending an increasing amount of time writing blog posts and articles for tech websites (and the occasional magazine). You might have seen the list of articles that have been published on the articles page. As you can see, it’s steadily growing, and at the moment, I’ve got at least four more articles lined up for the year, a number that’ll surely increase as 2017 proceeds.

Another thing I’ve noticed is that my work is slowly but steadily getting more and more international. This doesn’t mean I’m travelling the world consulting and speaking (at least not yet), but recently, I’ve been discussing options for collaboration with people and organizations abroad. These opportunities vary from writing, to taking part in webinars all the way to (remote) consulting projects. Not all of them have come through, and with a new home and two small children I’m not exactly in the position to travel that much right now, but I’m nurturing these relationships nonetheless, since you never know where they will lead you..

Currently I’m doing a trip in May for the Romanian Testing Conference, where I’ll host a REST Assured workshop and will attend the conference itself, and I’m looking at another trip somewhere in the fall. Not sure where I’ll be bound, but there are some opportunities that can definitely lead to something. And I’m always keeping my eyes and ears open for opportunities I just can’t say ‘no’ to..

I’m starting to love the ‘job’ (there are the quotes again) I’m slowly crafting this way. It gives me the opportunity to say ‘yes’ to the things I want to do, and to say ‘no’ if something isn’t interesting enough or if I don’t have the time. Although I’m still struggling with that last bit, there’s just too much cool stuff to do! I’m not sure how my career and my working days will look like in five years, so don’t ask. I hate that question anyway. I AM thinking about the future though, and about whether it will be as easy for me to do the things I love if a) I get older and/or b) the market for test automation slows down or comes to a halt.

I’m also noticing that I’m growing increasingly unemployable, in the sense that I can’t see myself working for a boss or manager anytime soon. The prospect of having to deal with end-of-year reviews, billable hour targets and having to say ‘no’ to something I want to do yet might not be in the best interest or directly profitable to the organization makes me never want to return to that anymore. I hope I’ll never have to, ever again. But I don’t worry about that yet, because it’s quite hard NOT to have a freelance project (or three) at the moment. Real first world problem right there!

The message behind all of the above is that in testing and test automation too, there IS a way other than spending 40 hours per week on a given project for months (or years) on end. I’m not saying that there’s anything wrong with doing so, but it doesn’t work for me any more, and I’m pretty sure I’m not alone. It DOES take time, effort and above all perseverance, though, to get where you want to be. Whenever I tell someone about an email I received through this blog, asking me to collaborate on a cool project, what they don’t (or even don’t want to) see is all the work I’m putting in writing and publishing a blog post. Every. Single. Week. That takes time. That takes effort. And above all, that takes perseverance. But only by persevering and putting out (hopefully quality) content habitually and sharing your knowledge, expertise and experiences (for free, mostly) will you start getting noticed. And maybe, after a couple of years, there will be some paid spin-off work. It’s worth it. It just doesn’t happen overnight, though.

An update on crafting my career

Now that it’s almost time for me to go on what I think is a well deserved holiday, I thought it would be a good idea to take some time and see where I stand with regards to reshaping my career the way I want it to look like. In the last couple of months, some interesting developments have taken place that I think are small steps in the right direction. I also discussed my ideas on how my ideal working life would look like (freedom and variety basically sums it up) with some other people, resulting in either encouragement or blank stares. I don’t know what to make of the latter, but the encouragement is nice.

So, what have I been up to? First of all, I started a new project, since the one I was previously working on was not a good fit for me. I didn’t feel I could make a valuable enough contribution there to warrant both my hourly rate and the commute (an hour one way), so I decided to end it and go look for a new one. My current project is in an enterprise environment with a very heterogeneous application landscape and lots of room for improvement in the testing and test automation area. I’ve come to realize that this kind of organization and project fits me much more than the web development organization I was at before. Also, my commute has been cut in half, which gives me much more time to spend at home with the wife and kids, and to work on other projects, which to me is huge as well. That’s one thing I love about being self employed: the ability to choose what you’ll be working on and when to stop a project that is not a good fit.

Freelance freedom

Also, I’ve been asked by O’Reilly (the media and publishing company) to write a 20-30 page report on the state of and current trends in service virtualization. At the time of publishing of this blog post, it’s up for a final review, with a planned publishing date of September of this year. I’ll probably write a separate blog post with a link to the report once it’s published, so keep an eye out for that one to see if it is interesting to you too. The report will be accompanied by a blog post on another web site as well (of which I currently do not know the URL), which is part of the package deal agreed upon. The report will be freely downloadable and sponsored by HP Enterprise. I am very excited to have been asked to do this in the first place, much more because these writing assignments are exactly the type of projects I would like to fill my ideal workday with. Also, it’s another valuable exercise in honing my technical writing and English skills.

Furthermore, a couple of weeks ago, I had the privilege to receive an invitation to deliver a test automation-related workshop at the first edition of the Iasi spin-off of Romania Testing, to be held on November 4th (thanks again, Richard, for referring the organization to me!). Needless to say I happily accepted the invitation, so I’m currently in the early stages of workshop preparation. Also, I’ve never been to Romania before, so that’s a nice bonus too for someone that wants to see as much of the world as his schedule and finances allow.

Romania Testing - Iasi edition

Next to that, I’ll be giving a presentation at Centric (an IT services provider) in November as well on a yet to be determined topic related to test automation. I was invited to do this thanks to a referral from Sara, who attended my REST Assured workshop in May. So, again, thanks for that! It’ll be a nice opportunity to meet new people, do some networking and to further practice my public speaking skills.

Another thing that has kept me busy for some time now is the idea of transitioning from billed-by-the-hour work to offering project- and value-based services. Or even a product.. I’m still not sure as to what such a service or product should look like, but I AM sure that I don’t want to be depending purely on hourly work for long anymore. It doesn’t scale and it is a restriction to the freedom of working when and where I want to that I would like to have. As you can read above, I’ve been given the opportunity to take some small steps in the right direction, but I’m not nearly there yet.

The last I’ve been thinking about, and this is the first time I’m talking about this to anyone but myself, is writing a book on test automation. I know, there are lots of those already, but a lot of them focus on specific tools and how-to’s. What I think is missing is a thoughtful and balanced overview of the current state of test automation, and a debunking of a lot of still common test automation myths. If I decide to go through with this plan (currently I’m veering towards a ‘yes’) that’s another thing I would like to start on this year. Any comments or ideas are highly welcomed!

To round things up, I’m still not sure as to how to move forward, but writing this up makes me see for myself that I am moving in the right direction. The end goal is pretty clear now, but the road towards that goal is still pretty misty. Maybe some time off work will generate new ideas that can be pursued once I get back.

Finally, I’d like to share two blog posts from Louise Stigell that pretty much describe how I’m thinking about my career at the moment: ‘Being rich versus being free‘ and ‘Unemployable and proud‘.

Oh, and if you’ve already returned from your holiday: I hope you had a good one. If you’re still going: enjoy it! If you’re currently on holiday: what the &*%^ are you doing here?

For those of you thinking about moving into the test automation field

Thinking about changing your career by moving into the test automation field? This post might be just for you…

So, you decided to become a test automation engineer / SDET / test automagician / … Excellent. Test automation is an important part of the software testing field. But if you’re thinking about taking this route just because you fear that your employer is planning to cancel all manual testing effort, maybe you just need to become a better tester. Show them what value you’re adding to your company and to its products and services as a tester. Either that or leave as soon as possible, because your employer clearly doesn’t know what testing is about and you’re better off at a place that values both automation and actual testing and testers.

What I’m trying to say is that you should first and foremost ask yourself ‘why?’. Why do you want to move into test automation? Is it because you’ve seen other people work on automating checks, test data generation or any other activity related to testing and thought ‘hey, that’s interesting, I want to know more!’ or ‘Hey, that’s nice and all, but I’m sure I could do this better / faster / fancier!’? Marvelous. The test automation field eagerly awaits your arrival. However, if all you’re doing is moving towards test automation because ‘it’s a trend’, ‘I’m afraid to lose my job’ or ‘the pay is better’ (actually, I can understand that last one to some extent..) then please do the field a favor and get better at what you’re currently doing. We need motivated individuals willing to learn, teach and share, not opportunists just looking for the next fad or pay raise.

Still interested? Here’s some more things to consider before making the switch:

Test automation is a craft (not in this way, though)
Using test automation well in your project and organization requires knowledge and skills. It’s just like a real job like that: you need to be willing and able to constantly learn and improve. How can you do that? Read and listen. A lot. Read blogs (the links in my blogroll should provide a nice start), listen to podcasts, go to conferences. Also, following the 10,000 hour rule, do a lot. Tinker with tools, repeat instructions presented in tutorials and then try and expand upon what you’ve learned and maybe most importantly: have your work reviewed. Nothing better than having someone more experienced look at your code and give tips on how to improve. I’ve been in the field for 10 years now and I still do this on a daily basis. Why? Because I know it will make me better at my job.

Test automation is software development
I’ve repeated this a lot of times now (yes, repeated, someone probably much smarter than myself said it long before): test automation is software development. Please treat it like that by:

  • Testing your tests. If you rely on the outcome of your automated checks when deciding to take something into production, you better make sure that your tests do what they promise, and that they fail when required.
  • Applying good design practices and patterns. They’ll make your test code better maintainable, readable and transferable to others.
  • Version controlling your stuff. Check in your test code in just the same way as you check in your production code. It makes it easier to share and review code and to revert any changes if necessary.

Don’t believe tool vendors and fanboys
Don’t get me wrong, I’ve got nothing against tool vendors. I even have a very good professional and personal relationship with some of them (you know who you are). I don’t take everything they say for granted, though. Even though the test automation field has long left behind the era of automation by record and playback and the miracles of codeless test automation solutions (it has, hasn’t it?), there are still tools and vendors that claim that everybody and their dog can use their solution and save millions of hours / dollars on testing. While some tools are indeed easy to use (a good UX design and / or a clear API go a long way) they’re forgetting that probably not everybody can use their solution AND do it successfully. Success for the project or organization that is, not for the tool vendors themselves.

Pretty much the same thing goes for tool fanboys. They’ll do anything to convince you to use their favourite tool, because all the alternatives suck / are too expensive / somehow insulted their family members. While they might have a point sometimes (in those cases where their favourite tool IS the right solution in your case) but make sure to investigate alternatives, or build your own tool if that’s a viable option. Try not to fall into the ‘if all you have is a hammer … ‘ trap.

Think beyond simulating user interaction
As Richard Bradshaw explained much more eloquently in his talk at this year’s Test Automation Day, test automation is much more than simulating the interaction between an end user and your application under test. A script that generates test data for testers is test automation. A routine that checks log files for exceptions during exploratory testing is test automation. In short, every tool and piece of code that is used to support or automate activities related to testing in some way, shape of form is a part of your test automation efforts. Broaden your scope.

Still thinking about moving into test automation?
Excellent. This post wasn’t meant to make you refrain from doing so. All I wanted to do (and what I’ll continue to do in the future) is create a view of the test automation field that’s a little more realistic than some of the pictures painted in other places on the Internet. Did I succeed? I don’t know, I’ll let you decide. As always, please do let me know. Leave a comment or send me an email, I’m always happy to talk to fellow test automation engineers and any of you thinking of becoming one.