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 ^_^

Happy Halloween little nerds!
Helena <3

Le Gasp! Our first blog - On beginnings and passion

When thinking of where, when or how to even start a blog, I ended up exactly where countless famous books have started. In the beginning...

I was tech support. I liked it too. I enjoyed working out what was going wrong somewhere and helping someone get it working again. It was great when it was great, and it was hell when it was bad. A few years ago I asked to move to QA. Now, being tech support I vaguely understood what QA (or Testers) did, and it seemed appealing. Just find the stuff I was finding anyway right? But before the customer? I know what you're all thinking now. WRONG. But actually, I was kind of right. When they let me move over to QA, no one really knew what to tell me. I was given bugs to check in Jira and I checked that those bugs had been fixed, then I handed the Jira back with a yay or nay. No one told me to do otherwise, and honestly, I'm not sure anyone else was doing anything different. Well, there were a few super experts who got asked their opinion on everything, but mostly everyone seemed to check bugs, and automation.

Oh man, automation was new and I was suppose to teach myself C# (I did) and learn automation (I did that too), but that's another story for another day.

Mostly my first months as a tester were spent watching youtube, and believe me, I wasn't happy about it. It kinda sucked. Occasionally my team would remember I was there and I'd get a bug to test, but honestly I wondered if I'd made a huge mistake. Maybe I should go back to Tech Support? At least I was useful over there. Was this all there was to testing?

It turned out the answer was two fold. For some people, that's really what testing is. You have super specific test cases and you just see if they're a pass or fail. For others though, testing was this massive thing that could make or break your product/software. There were testers out there who did BA, UX, Dev, automation. People who really care about the output of their teams and who through their passion, get others to care about those things too. I never would have turned into one of the second lot of testers if it hadn't been for a new wide-eyed team lead who started maybe 4 months after I moved to testing. She cared. She really cared, and because she did, I started to care too. Suddenly I'm starting to look into what exploratory testing really is (I was doing it well wrong), how testers can guide the team without doing every tiny bit of testing and checking that needs to be done. Did you know there's a whole world of tools and discussion out there about testing? 2 years ago me didn't, but boy did she learn.

It's interesting to think that without the addition of my new Team Lead, I might never have stayed or learned about what testing really is. I might not have tried my hand at public speaking at WeTest this year, and I might not be writing this blog.

All it takes is a spark to ignite passion in someone, and even though it took a bit more time and work over the next 2 years to get where I am now (with a fair few tantrums and almost giving it all up), I'm glad it worked out the way it did. Otherwise, I might never know otherwise.

Helena <3