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.


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.


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.


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/

Ep 65: A Gordian Knot of Numbers

Or: This week Matt and I talk ourselves in circles about metrics:

Opening thoughts:

  • Why measure? Because everyone wants to improve.
  • What to measure? Very very difficult to measure “soft skills” like testing.
  • Several perspectives on this.


I’ve worked in places where they counted bugs and I’ve made the mistake of counting test cases.

Further thoughts:

  • Power to change the need for overly simplistic metrics?
  • Asked for metrics but allowed to choose what to measure?
  • Try to identify why they want those metrics and use critical thinking to explain why it is flawed.
  • Counting bugs – project that is near completion vs a new project?
  • Counting test cases – no test case is equal, all written differently. What is a “test case”?
  • To the junior testers – help your test lead
  • To the test managers – don’t rely on metrics
  • Consider the danger of KPIs, what behaviours do you want to encourage?

Testing could be measured by:

  • Are customers happy?
  • Is the product selling?
  • Are there very few critical issues found in production?
  • Are budgets and schedules being met?
  • Are developers happy?
  • Are product managers happy?
  • Are testers happy?
  • If you have to count bugs then can you add some context to those metrics?

Asked around testersio slack team:

Feelings of metrics not making sense for individuals, only departments
Could measure % of production deployments without a critical defect reported in 24 hours/week?

Ep 64: This Modern Testing

This week I’m talking to Andy Tinkham about his testing philosophy: Modern Testing.

You may be familiar with this alreadY: Andy has been on both Test Talks and the Testing Show talking about it. I highly recommend both those episodes if you’d not already listened to them.

That’s where I first heard about Andy’s philosophy, which has 4 pillars at its core:

  • Context First
  • Testers are not Robots
  • Uses Multiple Lenses for Test Design
  • Providing Useful and Timely Information

This philosophy also has a challenge: Write your testing manifesto. Define what testing is or isn’t to you. Publish it if you want. Get feedback, get challenged, find your own path. I’ve published mine below.

The angle I wanted to tackle was my thoughts on the philosophy as a new tester: For new testers, defining what you do can be intimidating: I feel like I’m on the cusp of understanding what testing is to some extent but it also feels almost ineffable. The pillars here are great for a starting point – the details can be different dependent on context but the names are good guidance.

It also provides a framework for learning the more ‘fuzzy’ parts of testing: looking for context, thinking outside of tests cases, learning mnemonics and how to apply them, methods of efficient communication, etc).

All in all, it’s a great philosophy, and a great conversation, I hope you enjoy it!

Gem’s testing manifesto challenge response:

This was hard, but interesting for me anyway as I have absorbed so much about testing in such a short space of time, that while I had loads of ideas about what testing was, I hadn’t really truly considered what I thought testing was, and how I practised testing, so I think it’s really invaluable to do that, even if you never share it with anyone.

My attempt, in bulleted form:

  • Context is important
  • Providing value is the most important thing
  • The above two will be almost constantly changing
  • Avoid absolutes (except this one)
  • Communication is key
  • Everyone is human
  • Vulnerability can be powerful
  • Ask the stupid questions
  • Knowledge is our greatest tool
  • Balance learning and applying that learning
  • Breathe
  • No, I don’t break things

Ep 63: Testbash bonus!

Or Testbash Manchester!

That’s right, the Testbash review episode you didn’t know you needed. I’m here with Matt Bretten to discuss the whats, whens, whos, and hows of what can only be described as one* of the best weekends of the year. This is as close to ‘live’ as we get here at LTATB towers, so enjoy!

Testbash had a one day traditional conference, then one day of open space where the schedule was made by the attendees. I had a spot pre-selected thanks to Richard Bradshaw, where I spoke about helping testers in a bad situation. See my mindmap here. Matt lead a great discussion on Test in Devops, which had a lot of food for thought.

We discuss all aspects of the conference, from the pre-meetup to the open space, plus 99second talks, and a diversion on bread nomenclature.

*There are many testbashes. Who are we to rate them against each other?

Ep 62: Banishing the Permenantly Exhausted Pigeon

This week I talk to Neil Studd about motivation! We touch on a lot of stuff including but not limited to: burnout, 9-5 testers, neurodiversity, and more.

Summarised transcription provided by Matt Bretten:

  • In terms of trying to motivate myself and those around me, it’s a real challenge. People will brush it off as “just feelings” or “just emotions”, but it can have a profound physical impact on you if you bottle it up.
  • Change and the size of change can have a big effect on motivation. The role of testing is changing so much and our role boundaries are blurring. Ideas such as a “developer could do some of the testing” can lead to questions like “why do we need testers then?”. This sort of thing is uncomfortable for a lot of people.
  • When we’re talking about managing change, we’re not really talking about those people that listen to podcasts like this, as you’re likely to want to improve and react to change. We’re talking about those people that have no idea change is going on all around them, who don’t listen to the podcasts or go to meetups.
  • I find myself taking on far too much work and becoming burnt out, this can affect your motivation too. A technique to help with this is to make time to organise your work, even though this feels like work itself, it helps make sure you manage your time more effectively.
  • The Dunning-Kruger effect is always going on, each time you think you know enough, you find there are so many more things to learn. It can be hard to push through the downward cycle of motivation through feeling Imposter Syndrome.
  • Make sure your work-life balance is not just ok for you, but also the other people in your life.
  • There are many more reasons than just a lack of motivation for why “9 to 5” testers don’t come to meetups or learn about testing outside of work. People have families and commitments or some people like to have boundaries between their work and home life. Or people may not feel comfortable attending in person. The thing to focus on is whether or not people are willing to learn.
  • We should try and help those who can’t attend events by bringing the ideas to them in the workplace, through brown bag lunches or streaming talks. At the same time, we shouldn’t try to force people to pick up certain ideas but instead think about letting people find their own way to make use of these ideas. It’s useful to consider things like Intrinsic vs. Extrinsic Rewards.
  • It can be easier to change your current workplace than move to another workplace. You have reputation you can spend and you can try and find out why the workplace is resistant to a change you’d like to implement. However, not everyone is capable of speaking up about wanting change, there can be many reasons people might not feel comfortable or able to such as introversion, autism and deafness.
  • The challenge around motivation can be helped with a few simple things to keep in mind to help you along the right path:
    • Forge your own career path, don’t assume other people will do that for you. If you can take other people, great but don’t hold yourself back just because you feel you need to bring other people with you.
    • Use all of your tools are your disposal, find out the budget available, find out how much time you’ve got and find out how open your workplace is for going out to events. Make use of the skills available from the people around you.
    • Be true to yourself, have a sense of integrity and do things for the right reasons. If things go wrong you can at least know you don’t waste time second guessing your decisions.
    • Leave room to enjoy yourself outside of the office. If you want to work outside of the office, don’t feel you have to and don’t sacrifice other parts of your life in order to do so. Having extra happiness will enable you to be a better tester.


Neil’s blog post on 9 to 5 testers:

Sallyann Freudenberg’s CAST talk on Neurodiversity:

Meri Williams talk on stealing people lessons from AI, which touches on the motivators mentioned in Daniel Pink’s Drive:

Ep 61: It Takes Two

This week I talk to Maaret Pyhäjärvi about pair testing. But this is an interview with a twist: we did an hour of strong style pair testing (http://visible-quality.blogspot.co.uk/2015/10/a-course-on-testing-pairing-and-mobbing.html) first, and recorded our thoughts and experiences regarding that.

I cannot recommend pair testing enough! It’s hard work, but totally worth it – you have to think about communication a lot, including precision, and assumptions – and it really gets the job done.

Find Maaret on Twitter (https://twitter.com/maaretp) and at her blog (http://visible-quality.blogspot.co.uk/)

Ep 60: Go Soft or Go Home

This week I talk to Matt Bretten about Humans vs. Tools. Matt’s gonna be a voice you’ll be hearing more of moving forward. Stay tuned for more news!

This is an unfairly stacked deck, I admit. You can’t really take the position that tools are more important/better than the human side of testing. However, we did touch on myriad fascinating topics:

  • “A bad workman always blames his tools”
  • Psychology and it’s importance to software development
  • Writing code and using tools is the easy part, it’s harder to know when to make use of them and when not but also communicate and work together effectively
  • You could describe ideas, knowledge and skills as tools – for example I consider pairing a tool I find useful for certain situations
  • Boeing report – 80% of aircraft incidents caused by human error
  • The ELIZA effect

Ep 59: Hit Record (and play)

Quick news:

I am going to be at Leeds Testing Atelier on 20th September, which is a free one day testing conference, and I’m very excited to be there1., there’s going to be some amazing talks and some people I’m excited about meeting IRL at last.

Obviously I am also going to be at TestBash here in my adoptive city of Manchester, which is also very exciting! Plus more podcast interviews and other awesomeness.

This week, I want to talk about Selenium IDE.

Selenium has two parts: the script management/automated testing bit (Webdriver) and a Firefox add-on (IDE) that you can use to record browser actions and then play them back. It’s often denigrated by the testing community and for some very good reasons:

They’re brittle and flakey (but then again, so is every automation script that relies on find_element_by_id as far as I can tell). If nothing else, you’re only testing the UI, or through the UI2., and that can can cause issues (Mark Winteringham talks about this briefly in this blogpost here, and I saw him do a talk about this in Liverpool this month, it was very good, highly recommended, the video is on youtube3.). Some of these tests should be pushed down to the API/service level, not the UI level, and that isn’t really possible using the IDE add-on.

They get mis-sold. There are a lot of ‘record and play automation: so easy anyone can do it’ adverts and that annoys testers and leaves a bad taste in a lot of mouths (and rightly so). Testing is skilled work, and the idea that an automated record and play system can replace the work of a tester – even if that tester is solely an automation tester – is ridiculous. Writing them requires a human, and a tester at that. Someone who can bring all the skills of a tester; the curiosity, the need to gather information, things like that.

There are many reasons IDE is not a good choice for building an automation suite. But I’ve used IDE, and I found it useful, so I’m going to share my use case with you today.

I’ve literally just started Selenium, in bits and pieces, between other bits of work and podcasting, etc. and I had no idea where to start. I could find the header of the script from the documentation (where you call the webdriver and other bits you need from selenium), but after that I wasn’t sure. So I recorded a brief session around the site I wanted to get some automation on. The IDE has an option to export the scripts into code. So I exported the script into Python, which is the language I was planning to use, opened it in Sublime, and started to review the script.

The commands are slightly different, but it gave me a good starting point. From there I can make changes to make things robust. I wasn’t sure how to do something, but with the IDE commands in front of me, I could google those and then find out what they did, what they were called in webdriver, and if I could improve it in any way (IDE does implicit waits by default, for example, and I could change these to explicit waits.

In the world of Selenium based automation, it gave me a starting point. I converted the script to a ‘better’ webdriver script, and saved that out for repeated use. And once I got that down, it was a lot easier to start again, from scratch, to do another test. And yeah, it was hard and I still have no idea why people like coding, but I did it, and I felt I had a good grounding to do it and google about for help (read: copy and paste shit off stackoverflow as I am a true developer 😉 ). And now I’ve proven the concept, I’m doing more and it’s starting to form an automation strategy, which is incredibly exciting.

So IDE is a tool, and like any other it can be used or misused. For me, it’s a great starting point for Selenium, where I would probably still be bashing my head against a wall if I tried to build this from scratch. I have a lot to learn, but this was certainly a good springboard.


[1] http://leedstestingcommunity.co.uk/
[2] http://www.mwtestconsultancy.co.uk/cross-browser-checking-anti-pattern/
[3] https://www.youtube.com/watch?v=VGNxv9ilFbQ

Ep 58: Hot tub time machine

Or: The future of testing!

This super bonus episode is the second of my iterviews with Leigh Rathbone! We make several references to the previous episode (see here), so you may want to catch up on that episode first.

In this episode we discuss:

  • James Whitaker and the Hot Tub being the future of the internet of things
  • The changing landscape of testing and adding value
  • Crowdsourcing testing
  • Testing is dead, long live testing

Ep 57: Don’t go chasing waterfalls

This week is a guest episode! While I was in Liverpool for Liverpool Tester Gathering (http://www.meetup.com/Liverpool-Tester-Gathering/), I managed to grab some of Leigh Rathbone’s time for a couple of episodes! This is the first one and is about transitioning from Waterfall to Agile, with a focus on testers and test teams.

We cover the pros and cons of the different ways of working, and how to alleviate some of those cons. We reference the Agile Testing Quadrants:

The Agile Testing Quadrants, from The Agile Testing Book
The Agile Testing Quadrants, from The Agile Testing Book

And SMURFS: https://www.agileconnection.com/article/instead-mvps-maybe-we-should-be-releasing-smurfs