Lessons learned while training

Recently, I’ve had the opportunity to deliver a couple of workshops to various groups of people. First, there was the REST Assured workshop I hosted at the Romanian Testing Conference, then after that two separate versions of my ‘test automation awareness’ training. I can now safely say that I enjoy teaching hugely, and that it is something I want to pursue further in the future.

Of course, even though I’ve been in the whole workshop and teaching business for a while now, there’s still a whole lot to learn. I’ve delivered (tool-specific) automation training for my previous employer, and since I’ve taken the freelance route, several opportunities have come my way as well, but I’m still not the teaching master I’d like to be. There’s still so much to learn, and for me, one of the best ways to learn is to reflect on and write about my experiences. So, that’s what I’m going to do here… Who knows, maybe these experiences are valuable to others as well. Let’s take a look at some of the lessons I’ve learned in my teaching efforts so far.

Tool-specific workshops are popular
Most of the requests I see or hear about are for workshops that cover one specific tool, be it on an introductory or an advanced level. The most in demand at the moment is Selenium, but I’ve been receiving multiple requests for REST Assured workshops as well. At the moment, I only offer these in house, in person, so I have to decline most of them, unfortunately. It’s highly unlikely that one individual requesting training is able to cover travel, lodging and my training fee. This means I’m mostly delivering training in the Netherlands (where you can get everywhere in an hour or two), or occasionally at a conference abroad (where occasionally means once, so far).

Of course, most training requests don’t even reach me, since I don’t offer training preparing for specific certifications (ISTQB, CAT, PSM, you name it), nor do I have the desire to start doing so. Test automation is my game, and I’d like to stick to that. And when people think of automation, they tend to think in terms of specific tools. How I feel about that? Well…

Tool-specific workshops can be good, but…
While I think it’s very useful to attend workshops and classes to learn either the basics or more advanced features of specific tools (again, Selenium being the most popular), I feel there’s something missing. In my opinion, even the best tool workshops are useless in the long term if they’re attended by people that are unaware of the ‘why?’ to use the tool (or automation in general) in the first place. Good tool-specific workshops teach you this. Not all of them do.

The risk you run as an attendee, or as an organization sending a group of your employees to a tool training that fails to provide the necessary background and context, is that you’re likely to end up with people that have been given a shiny new hammer and start to think that suddenly, everything is a nail. Not good.

Again, I’m not saying that all tool-specific workshops are like that, but at least some of them are. I know, because I’ve delivered them as well in the past. I’m still learning, too.

Tool-agnostic workshops work well. For the right audience.
As a counter-initiative to the aforementioned tool-specific workshops, I’ve started to develop, promote and deliver a ‘test automation awareness’ workshop. In this workshop, I teach some of the principles behind test automation and try to debunk common myths. After the workshop is over, I (hopefully) have achieved two things with this workshop:

  • Teach people that test automation is a craft, requiring skills that need to be developed, and principles that need to be adhered to.
  • Give people a solid basis for asking the right questions once they enter a tool-specific training. With this awareness workshop, I’d like to answer the ‘why?’ and the ‘what?’ of automation, so that they can safely move on to the ‘how?’ in, for example, a Selenium workshop.

After having delivered my awareness workshop a couple of times now, in different formats and for different audiences, I’ve learned a couple of valuable things that will definitely help me improve it further:

  • The workshop works best for people that have had some prior exposure to automation. I’ve presented the subject, the principles and my trains of thought to several audiences, ranging from business analysts and project managers to experienced testers, and the people that aren’t working in and with automation on a regular basis tend to zone out after a while. For those people, a (half) hour presentation might work better. For testers (and probably for developers, too), it has worked out nicely so far.
  • You can offer people an exercise or two teaching them something about automation without there being programming involved. And I’m not talking about codeless automation tools. It has taken a bit more work and imagination, but I’ve come up with some exercises that have people think about proper automation implementation and discussing this among themselves without putting them in front of a keyboard. Again, there’s a lot to be covered related to the ‘why?’ and ‘what?’.
  • There is definitely a need for workshops like these. I’d gauged that from the popular Lego Automation workshop offered by the Ministry of Testing, but after a couple of runs of my own workshop and the feedback received both during and after, I can confirm that there IS a market for training that provides some realism with regards to automation.

As the year moves on, I’ll be working on improving my current training offerings and developing new ones. I’ve got some dates lined up already, but there is always room for more. Feel free to contact me with feedback, ideas for training or opportunities!

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.

On becoming a test automation craftsman

As an automation engineer, it’s hard not to get carried away by the latest tools, frameworks (I don’t like that word, but hey) and other gizmos when you’re dutifully automating away. New tools that promise to make your test automation even snazzier than it already is are popping up on an almost daily basis. But are you really missing out when you’re not including these into your daily work? I’d like to think that more often than not, you’re not. Most true craftsmen have become what they are because they’ve become exceptionally good at doing one or two things, whereas the ‘jack of all trades, master of none’ types are often quickly forgotten. So, if you want to become a test automation craftsman (or craftswoman, of course), how should you go about doing that?

Instead of frantically trying to keep up with all of the tools that are flying around, I would advise you to:

  1. select a couple of them that will likely do the trick in most situations you encounter,
  2. get really good at using them,
  3. and then provide your client or your boss with the best possible solution using this tool set.

Select your ‘go to’ tool set (and do it wisely)
The first step in becoming a craftsman is to choose a set of tools that you’re sure will go a long way in allowing you to provide maximum value to your clients or your employer. This will over time become ‘your’ tool set, and maybe, given you provide excellent work and aren’t afraid of some personal branding, you’ll become known as the go to guy or girl for questions related to a specific tool or tool set. But even if you don’t want to become a source of knowledge for other people (although I have a hard time imagining why you wouldn’t), being exceptionally skilled in one or two things will likely advance your career faster and in better ways than a shotgun approach will ever do.

As an example, I was asked a couple of months ago by Joe Colantonio (the guy behind the excellent TestTalks podcast) to contribute to his Automation Guild online conference initiative. He recognized me as someone that is knowledgeable on a specific tool (in this case it’s REST Assured) and asked me to do a session on just that specific topic. I’d like to believe he invited me because I’ve written quite a few blog posts on the tool on here in the past (it can’t be my good looks..). Had I just written bland introductory posts on a variety of tools instead of focusing on one or two quality tools, I’m not sure this opportunity would have come by.

On a side note, you should really check out Automation Guild. Not because I’m a speaker there, but because I am really enthusiastic about the concept and because I think it’s a great way for you to further hone your craftsmanship from the comfort of your own home. There are so many great crafts(wo)men on the list!

Note that you should be careful when choosing what goes into your test automation tool belt. It does not make sense to pick a tool just because there’s nobody else on the web that’s specialized in it, for example. Usually there’s a good reason for such a lack of online presence: it’s highly likely that there’s not enough market demand for the tool, and/or the tool just isn’t all that useful. Instead, it would make more sense to pick something that’s reasonably established and well supported.

Select the contents of your tool belt wisely!

Learn everything there is to know about ‘your’ tools
Now that you have selected what goes into your personal test automation tool belt, it’s time to learn the heck out of it. To be considered a craftsman, you should try and learn everything there is to know about your tool(s), both the positive and the negative sides. Or at the very least, you should know exactly where to get the information required to do your work in the best possible way. Showcase what you know, be it at your day job, online, or at conferences, to build a following and get your name out there. Connect with fellow craftsmen to exchange knowledge and further hone your skills.

For example, check if there are any classes, workshops or online courses you can take that are related to your tools of choice. They’re often chock full of goodies, examples and exercises that will help you learn even more than you already think you knew. Plus, this too is a great way of meeting like-minded folks and grow your network. You’ll never know how and when you meet your next client, coworker or employer.

Workshop at Testworks Conf

Provide your stakeholders with the best solution using your tools
Finally, after you have selected and sharpened your tools and your skills, it’s time to put them to good work. Even though I’ve mostly focused on tools in this blog post so far, in the end, it’s not about them, it’s about what you do with the contents of your tool belt. The solutions you build using your tools are what will ultimately provide value to your stakeholders. You wouldn’t pay a carpenter if all he did was give you a couple of pieces of wood and a box of nails, right?

Updating your tool belt
Of course, in the case that the contents of your tool belt no longer fit the job you’re asked or choose to do, then you’re free (and even required) to look for additions to the contents of your test tool tool belt. Acting like everything is a nail when all you’ve got is a hammer is not the approach that will lead to success. Instead, in that case, it’s probably time to look for new additions to your tool set, and possibly also a good moment to throw out some of the stuff that is no longer of use to you. But until that time, I’d stick with what you know best and keep focusing on providing as much value as you can using your tools. Be(come) a craftsman.