Header Tabs

Sunday, 30 October 2016

On automation and learning the hard way

I promised we’d talk about automation, and don’t worry, we’ll get into some of the nitty gritty stuff soon enough, but this is mostly the second half of my origin story. That’s right, in my head I’m basically a superhero, I’m also dressed as Harley Quinn as I write this, so be prepared for some comic references.

Automation was pretty damn new when I started testing a few years ago, in fact, our framework had only been in existence for around 6 months and all the people (all 6 of them) working on it were previously manual testers who’d been doing some Pluralsight courses on C# and Selenium. This was the big change time, manual testing was out, and we really needed to get up to speed on this automation business. Regression was taking around 2 weeks and anyone can see that that’s just not sustainable. At least, not when you’re releasing every 3 weeks. So we all went hard out.

While at the beginning, as we talked about last time, I had no real clue what to do with the manual side of testing, the automation side came to me quite easily. I may not have coded before (well, except for a Fairy website that I setup using html on geocities when I was about 13), but I was technical, coding made sense. We were still learning how to put it all together in a way that worked for automated testing (and by that I mean learning the hard way that you can’t code everything), but we were getting good at it. At least that’s what we thought at the time.

If anyone here has ever coded before, in any language, you already know what I learned. That looking back at code that you wrote 3 months ago, that you were really proud of at the time, is a pretty humbling experience. “Ouch” was the most often heard thing in my head whenever I needed to go back and fix something.

There are two main lessons I’ve learned about automated testing over my testing time (ha! "my testing time" - just call me old man Helena).

The first is that when you focus either entirely on automation or entirely on manual, you’ll fail. There is a time and place for both, there must be balance to the force (I know, I know. It’s not a comic reference, but meh, this is my blog and I’ll do what I want!). We dropped all focus on manual testing when we moved to automation, and we lost something important because of it, we lost the humanity in our testing. Equally, we wouldn’t be where we are now (using a Continuous Integration release process) without all the effort we put into automation. It was hard at the time, and it’s painful to look back on, but we needed to do what we did. We’re aware now though, and we’re redressing the balance. That’s all you can hope for.

The second big lesson was that automation isn’t a second class coding citizen. It’s not the Marvel Squadron Supreme to the DC Justice League (got one!). Automation is coding, it’s proper, normal coding, the same theories and standards apply as usual. One of our biggest challenges was getting Developer help with our automation. We should have asked for it sooner, we should have pushed for it sooner. For every dev that said to me“Oh, I don’t know how automation works” was one who said “It’s just normal code, here, let me show you.” We’d been learning from online courses, they had years of experience. Eventually that experience became our savior, our Framework is in pretty good nick all things considered. Nowadays we even have dev college graduates do a Testing rotation, where they do both automation and manual testing. It took time to get to this mindset though.

So that’s the high level overview of my origin story. I may not be an actual superhero (or to be more honest, a super villain) but everyone deserves an origin ^_^

Yes! I love being able to do both. Being a generalist can be a lot of fun, it gives you a huge amount tools and tricks to draw from. Specialist are important too, but I love sitting in the middle between manual and automation :)

I agree with Toine. Nicely put Helena. I've prided myself on being a tester without a developer background, but I feel that is going to have to change as more and more places are requiring automation experience.

Automation is definitely part of the future, but it's important not to forget that automation and manual testing are different things. Automation let's you move super quickly, but manual specialists in things such as UX or exloratory testing shouldn't be forgotten. Or you'll end up with quickly released software that no one wants to use :p

Hi Helena. I'm curious about one thing that you mentioned: You dropped all focus on manual testing when doing automation. If this is the case, how did you work out what to automate? I mean, in deciding what and how you automate something, you have to test it first then you automate it. This is what i instill in my team.

Working out what to automate is only sort of manual testing. By that I mean, yes you work out your given when thens, you go through the CSS pulling out element locators etc. But it involves none of the other things that manual testing should, like proper exloratory testing, UX, or even testing the documents early on. Automation, since we were all so new to it, took up all our time, at the expense of all the other things you would normally do. Now we've hit a balance between specialist at either end and generalist who sit in the middle and do both :)

I forgot to say, when I say dropped focus, I mean it become not important, not that it wasn't happening at all. Automation just became the priority and manual testing dropped back to it's honestly bug monkey days. Click button, button works, automate.