Review: Automation Guild 2017

About half a year ago, in July of 2016 to be exact, I was invited by Joe from the well-known TestTalks podcast to contribute to a new initiative he had come up with: the Automation Guild conference. Joe was looking to organize an online conference fully dedicated to test automation, and he asked me if I wanted to host a session on testing RESTful APIs with REST Assured. Even though I’d never done anything like this before -or maybe because I’d never done anything like this before- I immediately said yes. Only later realizing what it was, exactly, that I had agreed to do..

Since the conference was online and Joe was looking for the best possible experience for the Automation Guild delegates, he asked each of the speakers to record a video session in advance, including sharing of screens and writing and executing code (where relevant, of course). This being an international conference of course also meant speaking in English, which made it all the more challenging for me personally. I’m fine with speaking in English, but the experience of recording that, listening to it and editing all the ‘ermm..’s and ‘uuuhh’s out was something entirely new, and not exclusively pleasant either! It also took me a lot longer than expected, but in the end, I was fairly happy with the result. And I learned a lot in the process, from English pronunciation to video editing, so it was definitely not all bad!

Enough about that, back to the conference. It was held last week, January 9th to 13th, with around 5 sessions every day plus a couple of keynotes. The actual videos were released beforehand so all attendees could watch them when it best suited their schedule, while on the conference days there were live Q&A sessions with all of the speakers to create a live and interactive atmosphere. Having never participated in anything similar, and even though I caught only a couple of sessions due to other obligations (the time zone difference didn’t help either) I think this worked remarkably well.

My own Q&A session flew by too, with a lot of questions ranging from the fairly straightforward to the pretty complex. These questions did not just cover the contents of my session, but also API testing in general and there were some questions about service virtualization as well, which made it an even more interesting half hour.

I liked this interactive Q&A part of my talk and of the conference as a whole a lot, since getting good questions meant that the stuff I talked about hit home with the listeners. I’ve had conference talks before where the audience was suspiciously quiet afterwards, and that’s neither a good thing nor an agreeable experience, I can tell you. But in this case, there were a lot of questions, and we didn’t even get to all of them during the Q&A. If all goes well, I should receive them later on and get to interact with a couple more listeners in that way. But even so far, I had an amazing time talking to Joe and (indirectly) to the attendees and answering their questions in the best way I could.

As for the other speakers, Joe managed to create a world-class lineup of speakers, and I’m quite proud to have been a part of the speaker list. I never thought I’d be in a conference lineup together with John Sonmez, Alan Richardson, Seb Rose, Matt Wynne and so many other recognized names in the testing and test automation field. So far, I only managed to watch a couple of the other speakers’ sessions, but luckily, all of them are available for a year after the end of the conference, so I’ll definitely watch more of them when time permits in a couple of weeks.

I can only speak for myself, but I think that the inaugural edition of Automation Guild was a big success, given such an incredible lineup and over 750 registered attendees. This is mostly due to the massive amount of effort Joe has put into setting this up. I can’t even begin to imagine how much time it must have cost him. Having said that, I am already looking forward to the second edition next year. If not as a second-time contributor, then surely as an attendee! If you missed or couldn’t make the conference, then mark your agenda for next year, because surely you don’t want to miss it again!

Why I don’t call myself a tester, or: defining what I do

Warning: rambling ahead!

Recently, I’ve been forced to think about roles in my profession, and what role it is exactly that I fulfill when at work. ‘Forced’ sounds way more negative than it is, by the way.. In fact, I think it has been a good thing, because it has helped me to think and better define what it is I actually do… So, thanks to Richard:

and Maaret (she’s quoting this blog post, by the way):

for making me think about the restrictive activity of pinning roles and labels on people. Nobody conforms 100% to the definition of a given role, should such a definition ever be created and agreed upon by everybody (good luck with that!). On the other hand, being able to explain what I do and what value I can add to a person, a team or an organization is something I can’t really do without, especially as a freelance contractor. And that, sadly, involves roles and labels, because that’s mainly how the keyword-driven IT freelancing and contracting business works.

So far, I’ve mainly defined what I do by referring to what I’m not, something you can see in the tweets I referred to above:

  • I am not a developer, at least not when compared to what the majority of people think of when they think of a developer. For someone involved in test automation (which is a form of software development), I write a shockingly low amount of code. I can’t even remember exactly when the last time was I wrote code that was used in actual automated test execution. Somewhere at the beginning of last year, I think…
  • I am not a tester. The last time I evaluated and experimented with an application in order to assess its quality and usefulness has been years ago. I think it involved TMap test design techniques and rather large Excel sheets…
  • I don’t fit into an Agile team. This is the most recent realization I’ve made. A lot of projects that come my way ask me to be a member of an Agile team, contributing to testing, test automation and possibly some other tasks. That just doesn’t fit with what I like to do or how I like to work. For starters, I think it’s kind of hard to be a member of an Agile team when you’re only there two days a week. You just miss too much. But I like to work on multiple projects at the same time and also have some time left for training, business development and other fun stuff. Unfortunately, the freelance project market here largely consists of projects for 32-40 hours a week, with Agile being a very popular way of working..

On the other hand:

  • I work a lot with developers, helping them to realize WHY they need to spend time creating automated tests and WHAT approach might work best. I gladly leave the HOW to them, since they’ll run circles around me with their development skills. This requires me to stay sort of up to date with tools, approaches and practices in software development, even though I don’t write code (often).
  • I work a lot with testers, helping them to think properly about what test automation can do for them and how to ‘sell’ it to other stakeholders. This requires me to stay up to date with how testers think and work, even though I don’t test myself.
  • I work a lot with Agile teams, helping them to create and especially test software more efficiently through smart application of tools. This requires me to stay up to date with team dynamics, Agile practices and trends, even though I haven’t been contributing to daily standups and sprint planning sessions for a while.

But I still have a hard time defining exactly what it IS that I do! My LinkedIn tagline says this:

Test automation | Service virtualization | Consultant | Trainer | Writer | Speaker

Those probably come closest to what I do. Most importantly, it states in what fields I am active (test automation and service virtualization). What other people call consulting makes up for most of my time spent working at the moment (I’d like that to change a little, but that’s a different story). But I don’t like the word ‘consultant’ or ‘consulting’. It makes me think too much of people with big mouths, expensive suits and six months of actual experience. And I don’t wear expensive suits. Or suits in general.

The rest of my time is spent training a little (hopefully more in the near future), writing a little (same goes for this) and speaking a little (and for this too). Yet, I don’t consider myself a trainer, a writer or a speaker. But maybe I am all of them. As well as a developer. And a tester. I don’t know.

Long story short, what I think it boils down to is that I help people, teams and organizations perform better in the areas of test automation and service virtualization. Areas that are of course not to be considered as goals of their own, but rather as servant to the larger scale goals of more effective testing, software development and doing business in general.

I think the key word here is ‘help’. I like to help. It isn’t about me. It shouldn’t be. If it looks like it is about me, please say so, because I’d like to avoid that by all means possible. As a start, next week I’ll talk test automation or service virtualization again.

Oh, and of course happy 2017 to all of you! I’m very much looking forward to helping people even more this year.

Should test automation be left to developers?

I am not a developer. I have a background in Computer Science, I know a thing or two about writing code, but I am definitely not a developer. This is similar to me knowing how to prepare food, but not being a cook. People that have met me in person probably remember and will possible be bored to death by me using this analogy (sorry!).

On the other hand, I also try to repeat as often as possible that test automation is software development, and that it should be treated as such. So, you might ask, how come I am working in test automation, yet I don’t call myself a developer? And more importantly, shouldn’t test automation be left to developers, if it really IS software development? Recent blog posts I’ve read and presentations I’ve heard have made me think a lot about this.

So, to start with the second and most important question: should test automation be left to developers? My answer would be yes.

And no.

Test automation should be left to developers, because
writing automated tests involves writing code. Personally, I don’t believe in codeless solutions that advertise that ‘anybody’ can create automated tests. So, since code writing is involved, and since nobody knows writing code better than a developer, I think that writing automated tests can best be done by a developer.

I’m going to use myself as an example here. Since writing code isn’t in my DNA, I find it takes me three times as long – at the minimum – to write automated tests compared to your average developer. And with high-pressure projects, short release cycles and the trend of having less and less testers for every developer in development teams, I just couldn’t keep up.

To make matters worse, new automation tools are being released what seems like every day. Especially within the Java and JavaScript worlds, although it might be just as good (or bad?) in other ecosystems, just less visible to me personally. I don’t know. For a while, as a non-developer, I’ve tried to keep up with all of these tools, but I just couldn’t manage. So, instead of frantically trying to keep up, I’ve made a career shift. This came naturally after I realized that

Test automation should not be left to developers, because
nobody knows testing better than testers. As I said, I (and possibly many people involved in test automation along with me) am not skilled enough to compete with the best on how to create automated tests. However, I think I (and a lot of others) can teach a lot of people a thing or two about the equally, if not more important questions of why you should (not) do test automation, and what tests should and should not be automated.

A lot of developers I have met don’t have a testing mindset (yet!) and tend to think solely along the happy path. ‘Let’s see if this works…’, rather than ‘let’s see what happens if I do this…’, so to say. When writing automated tests, just as with creating specs for the software that needs to be built, it requires a tester’s mindset to think beyond the obvious happy flow. This is why I think it isn’t wise to see test automation as a task purely for developers.

It also helps if people other than developers feel some sort of responsibility for creating automated tests. Given that most developers are busy people, they need to choose between writing tests and writing production code on a regular basis. Almost always, that decision will be made in favor of production code. This does make sense from a deadline perspective, but not always as much when you look at it from a quality and process point of view. Having people in other roles (testing, for example) stressing the need for a mature and stable automated testing suite will definitely improve the likelyhood of such a suite actually being created and maintained. Which might just benefit the people continuously fretting about those deadlines in the long end..

So, to answer the first question I posed at the beginning of this post: Why am I still working in test automation despite not being a developer? Because nowadays I mainly focus on helping people answer the why and the what of test automation. I do some stuff related to the how question as well, especially for smaller clients that are at the beginning of their test automation journey or that don’t have a lot of experienced developers in house, but not as much as before. I love to tinker with tools every now and then, if only just to keep up and remain relevant and hireable. I’m not as much involved in the day to day work of writing automated tests anymore, though. Which is fine with me, because it plays to my strengths. And I think that’ll benefit everybody, in the long end.

I think the test automation community could use a lot more highly skilled people that are (not) developers.