Ep 66: When all you have is a hammer

So I am a manual tester. I’ve dipped my toes into automation, and I’ll continue to do so, but for now, I’m a manual gal. I enjoy exploring a system, figuring out what works and what doesn’t. But that can only take you so far.

Sometimes I feel like I’m so far behind everyone else. I hear people talk about automation in terms I can’t get my head around. I hear people talking about looking at logs and all this stuff I can’t do. Pair that with the shift towards technical testers, and shift right, and I started to panic a little. Panicking gets me nowhere, I have years of practice to know that, so I tried to take a step back and see what I can do. If I have a future in testing, I need to try and catch up.

I’m probably not going to be managing builds and releases to QA any time soon, but what I can do is dig into the system in front of me. I’m already pretty familiar with the systems we use, and what the most obvious issues are caused by, but there’s always more to be done, more to learn.

I saw a post a while ago – maybe even last year – on Chrome developer tools for testers. I was familiar with them already, viewing elements, using the emulator for mobile devices, but I knew there was more in there I could utilise. I decided to start with dev tools as it’s something I can learn by myself. I don’t need to request any structural changes to how we work to use them, and learn what I can find out with them. Once I know what they can do, what I can use them for, and by extension, what else would be useful, then I can make further progress with more technical stuff.

Baby steps, is what I’m saying.

I’m starting with what I know, and what I have forgotten I know, and I’ll do a part two (or three) of this work as I learn more.

I’m hoping to do this more often next year: I pick a topic, do either an episode or a segment on what I know, and what I’ve chosen to learn, I learn it for 2 weeks, do a retrospective. If I think it’s worthwhile, or feel I need more time, then I carry on for two weeks. Rinse, repeat. Then I move onto another topic.

So, onwards into the world of dev tools. I’ll be talking Chrome here, as that’s what I use, but I know firefox, IE, and other browsers have similar tools available.

Inspect

This perfect for figuring out what that weird-ass element on the page is that’s causing issues. You can also live edit the page here. If you click on an element, you can change the HTML or the CSS.

Device emulator

When you’ve got dev tools open, there is an icon that looks like a phone in front of a tablet. Clicking this will start a device emulator. You can change device type to see how it looks on different devices, from blackberry phones to laptops with a touch screen. Now, this isn’t perfect by any means, but if you’ve not got access to devices or browserstack, it’s a good start. It’s also good for grabbing screenshots when getting one from a device to your computer is a pain in the arse.

Things you can also do here: internet throttling. Want to see what happens when your site or app is viewed on a device with 2G, or GPRS? Click the list of devices at the top of the screen, go to edit, then click throttling in the resulting settings screen. Boom, you don’t have to leave the office to figure out if the app’s not gonna work on a train.

Geolocation

Location spoofing in Chrome: a thing you can do!

So, under the Sensors tab, there is a Geolocation option: This will spoof your location to a number of preset ones around the world, and a location not found option. Useful for checking localisation without the need for an offshore person.

Network

There’s a network tab, and this shows how long things take to load. Refresh the page you’re on and the network tab will fill what’s being loaded on the page, and how long it takes. Wondering why a page is suddenly taking an age and a half to load? The network tab is your friend.

I’m gonna leave this here. As I said, I’ll be learning more over the coming weeks, I’ll report back if I find anything particularly nifty. If anyone knows any resources, ping them my way. I feel weird announcing that I basically know nothing about technical testing, but I figure I can’t be the only one feeling like this, so let’s learn stuff together.

Want to learn more? There’s a great course here: http://discover-devtools.codeschool.com/

2 thoughts on “Ep 66: When all you have is a hammer

  1. Hi Gem,
    Thanks for doing your podcasts I enjoying listening to them.

    I agree baby steps. I have just completed 4 days of courses all based around Automation concepts, coding and tools with Richard Bradshaw(The Friendky Tester). There is so much to learn, so much practice needed and so many tools out there! Also how much is enough to be able to secure a role where you can progress ?! At times it can feel overwhelming.

    I, like you use some of the options in the Chrome Dev tools. One of my take away from the course was to become more familiar with the other functions. So that I am more informed and can decide in future which to use appropriate to the situation.

    Another thing I took away from the course and meeting others, is there are quite a few Manual testers feeling the same way.

    Automation is almost the key word on most job adverts I see these days. However, I am not convince most employers appreciate what is actually involved and that an essential skill is deciding what adds value by being automated as not everything does.
    That it is not just simply a case of automating everything !

    1. Hi Hazel,

      Thanks! I’m glad you enjoy them.

      I agree with everything you’ve written. Testing is so vast that it just seems overwhelming at times. But we have some amazing resources available! And the community is always ready to help as well.

      People seem to think you can just ‘do automation’ without asking things like, ‘automate what?’ and ‘why?’ and even ‘who owns this? Who maintains it? Who hooks it up to the existing architecture?’.

Leave a Reply

Your email address will not be published. Required fields are marked *