Friday, 9 December 2016

Taking Software Testing More Seriously By Using Humour

TLDR; Everyone can tap into humour when they are themselves and with their friends. Can you respect your work peers enough to be yourself with them and tell hard truths using humour when necessary?

I was listening to an audio book by Grant Cardone this morning and he was talking about humour in the sales process, the author of this audio book. I was thinking, I use humour in software testing. I cover humour in the book Dear Evil Tester, and there’s a section in here in the afterword section.

This post is also available as a video - embedded below - or watch on

Read the Afterword in “Dear Evil Tester”

The ‘Afterword’ is a a section that I think some people skip. That’s up to them, but they’re losing some of the most valuable material where we summarise the main points of the book.

There’s a section in there where I’m saying “humour can tell hard truths in a way that people listen”. I noticed that when I was working on waterfall projects in the past, where, in meetings, software testers were the ones that were cracking jokes. Trying to make the situation, not less serious but less tense, because everyone was getting really tense, everyone was getting antagonistic, and there was no joy, or love, or respect, or humour in the room whatsoever.

That still happens nowadays even in agile projects, in stand-ups or retrospectives.

Humour helps us explore our situation and change

At the point in the project where we have to retrospect, self-analyze, and take things really serious to get down to the root cause, but not so serious that we blame everyone. Seriously enough that we can take our process forward and improve, humour can work really well in there.

Again, I’ve seen testers, and sometimes the project managers, because managers often know how to use humour in a situation to help bring the team together (some people might perceive that as their only skill!).

People do this in different ways. Some people crack jokes; I don’t crack jokes. I don’t remember any jokes, and the comedians I like, don’t really tell jokes. They use observational humour, humour that comes from truth that’s sometimes hard to accept. They often describe a situation and take it to an extreme in order to demonstrate its absurdities and its ambiguities. But still try to get at the core of what is important in the situation, but strips away, through humour, the things that are not important, that are absurd and that complicate and distract us from the point that we can deal with.

When I mention this to people, they sometimes say, “But I’m not funny.”

“No”, pretty much everyone is funny with their friends. When you’re chatting with your friends in an informal situation, you will interrupt them, you will make jokes, you will have observations that people laugh at. Everyone is funny when we are ourselves, when we tap into that thing that makes us us. We have to do that for our testing because we have to make our testing unique and personal to us.

I’m going to give you a technique - study

I’ve been rambling a bit, so… a technique.

You could study things.

I found a tape set a long time ago, it’s called “Humour, Risk and Change” by C.W. Metcalf.

Unfortunately it’s unreasonably hard to get hold of now and can be very expensive, but you can find some videos of him on YouTube.
He used humour in a medical setting.

There is a book called Provocative Therapy by Frank Farrelly. He used humour in a very human therapy approach.
Or study the comedians you like. Whatever comedians you like, listen to their records. I really like Bill Hicks, so I thoroughly recommend Bill Hicks even though his style of communication might not be the best one for the meetings that you’re in, but I really like Bill Hicks. Find a comedian you like and look at how they communicate.

Another technique - model

If you don’t want to do that, if you’re nervous about bringing professional humour or therapy into a process you’re working with, look at the people around you, the ones that do use humour to diffuse situations or to communicate messages that are hard.
  • Look at what they do.
  • Look at how they do it.
  • Try to deconstruct it, then own it.
  • First of all, copy it.
  • Deconstruct it to model it.
  • Build a model.
  • Use it and own that model.
  • Observe what happens
  • use the feedback that comes back, and amend your model.

Easiest technique - respect

The easiest way to do this, remember, is to respect the people you’re with, treat them as though they’re you’re friends - and that doesn’t mean you’re nice to them, that means you’re honest with them because they’re actual humans and peers and you respect them.

You respect them enough to bring yourself to the table, and the meeting, and open yourself up for the humour inside you, and the risk that that involves when no one laughs, no one enjoys what you said.

But you said it honestly, there was a truth that was spoken and you tried to make it light because you’re trying to strip away the biases and tenseness that sits there.

This is one of the things that I cover or stress in Dear Evil Tester.

"Dear Evil Tester" isn’t just for testers, this isn’t just for people who want to improve their testing. This is about how to take your testing or your discipline seriously enough that you will find humour in it. That’s what I hope you do because that’s essential in meetings and making things work.

- P.S. Dear Evil Tester makes the perfect Christmas present. I’ve just bought 50 copies myself and I’m sure I’ll be giving some as Christmas presents this year.

Thursday, 8 December 2016

Lessons learned and tips for testing from public bug bash events

TLDR; Tips for external public bug bash testers. This is not testing as you know it. Change your beliefs. Get ready in advance. Hit the system hard, hit it fast. Report quickly and well. Demoralise the other teams. “Congraturation! You Sucsess!”

Stop the Express - ZX Spectrum - from RZX Archive

Lessons learned and tips for testing from public bug bash events

There seem to be a few public ‘Software Testing Cups’ and competitions. Which all seems like jolly good fun. The closest I’ve come to taking part is when I attend public bug bashes. I’ve been to a few in the past. So I’ll list some pro-tips and experiences.

Adopt a different belief model for testing

One thing I particularly enjoy about the competitions and bug bashes is that ‘testing’ is very hard to judge as a competitive sport. And unfortunately I love the irony that we fall back on the ‘thing’ that we are all told not to do in ‘real’ testing. Which is judge the testing by the bugs we raise. We all know that ‘testing’ isn’t ‘all about bugs’ and the value of testing is in the ‘information’ not the ‘bugs’ etc. etc. But not in a bug bash [insert evil laugh here].

So the first set of pro-tips embody that:
  • This is a competition, that means ‘winners’ and ‘losers’
    • The losers are going to be the people who hang on to ‘beliefs’ about what testing means
    • “Bug Bash” doesn’t imply “Testing” it means “hit the software hard and fast and find as many bugs as you can”
      • Think like a bargain basement testing warehouse
      • Pile em high, sell 'em cheap
    • The winners will be the people who can:
      • find bugs fast
      • document bugs into the tracking system (because you’re going to be judged on the bugs you raise in the system, not those in your notebook)
      • have bugs that are well supported with evidence: steps to re-trigger, screenshots, succinct and clear descriptions

How to also go deep

Now, you don’t have to embody that. You can go into the ‘competition’ with an attitude that:
  • I’m going to learn, and
  • I’m going to test it properly
  • Quality over quantity
I’ve done that. It can be a good personal exercise. I was involved in one bug bash on a test environment where I didn’t race to the bottom and pick up everything I saw. Instead:
  • I scouted around,
  • observed,
  • found some good risks,
  • followed the risks to their functional source,
  • infiltrated the functionality,
  • went into deep cover
  • and found a massive security issue that gave me access to all the customer details on the production system
  • and no-body cared [insert laugh of incredulity here]
I learned a lot doing that which helped my personal test approach, and about the company in question.
So this can be a good personal strategy to adopt in a bug bash. But when you adopt this attitude - don’t join a team that wants to win.

Often when I follow this strategy I end up finding ‘big’ bugs, so it is generally the strategy I use for private bug bashes when we conduct them internally. The hard part about this strategy is that you often stumble over bugs on the way: during your scouting, reccie, pursuit, infiltration prior to your hard contact. In a team, a good strategy can be too pass those on to other team mates while you continue on your deep infiltration mission.


Based on experience, here are a few “Don’ts” - assuming you want to ‘win’, if you want to ‘learn’ then these might be suitable tactics, but you won’t find the winning team using these.
  • Don’t try and use tools you’ve never used before
    • You will lose a lot of time learning and configuring the tools.
    • Do use tools you already know how to use.
  • Don’t assume you’ll configure your machine when you get there
    • Make sure you know how to configure your machine prior to the event
      • for different wifi networks, proxies, VPNs
      • to connect your mobile decide to your laptop via cable, or wifi, or bluetooth
    • You normally use your laptop with an external monitor, mouse and keyboard?
      • make sure it works without those connected
  • Don’t check you’ve got the tools you need when you get there
    • that USB stick with all those portable tools that you used last year - check it works and has the tools you need.
All of the above relates to a lack of approach planning, so don’t NOT plan.


You won’t have all the information you need to create a detailed plan, but you should have enough information to to think through the problem.
  • If you’re testing a web app then:
    • make sure your browsers are up to date
    • have a range of browsers available to test on
    • know how to use the dev tools for the browsers you’re going to use
    • make sure you can configure your proxies with the browers
    • make sure you have the proxy https certificates installed on your laptop and browser
    • make sure you know how to use the proxy
    • make sure you know how to toggle between proxy and without proxy
    • have link checkers available
    • have a mix of local and remote tools
      • e.g. if your link checker is cloud based but the test environment is locked to a local ip range or wifi network then you betterknow how to create a tunnelto allow the remote client to connect, or have a local tool that will work so long as your machine can connect.
    • know how to use your proxy functions in unconventional ways e.g. Fuzzers for automating over a massive data set, rather than writing code to automate the system.
  • If you’re testing a device based app then:
    • make sure you know how to toggle developer mode on your device
    • make sure you know how to side load apps on to your device (just in case)
      • this also allows you to rip the app off the device for local decompilation and binary artifact investigation
    • make sure you know how to take screenshots
    • if you choose to do all your testing and bug reporting from the device itself then I recommend being able to hook up a keyboard to it
    • if you can, have the ability to take movie
    • I recommend using your device in conjunction with a laptop
      • make sure you can transfer screenshots, files etc from device to the laptop
      • connect the device to the laptop
      • show the screen of the device on the laptop
      • take screenshots on the laptop
      • capture movies in parallel on the laptop
      • use the laptop to raise defects rather than the mobile device
  • Have the essentials
    • screenshot tools
    • screen movie capture tools
    • text editors
    • file compare tools
    • data generators e.g. counterstrings
    • learn to touchtype fast prior to the event
    • etc.
  • Parallelise (is that word? it should be? I hereby declare its existence thus!)
    • use tools that can statically analyse as you test
      • e.g. static analysis plugins on tools to check traffic for issues
    • scan http traffic logs looking for 4xx and 5xx status codes
    • use tools that can work in parallel to you
      • link checkers that spider and scan the site
      • spiders that pull out comments from HTML pages
      • standard compliance tools that spider sites
      • binary analysis tools for common vulnerabilities
Any tool that can work in parallel and alert you to issue that you might not notice, and are a good way to pick up low hanging bugs for free:
  • spelling errors on pages
  • missing images
  • missing include files
  • server errors on ajax requests
  • broken links
If you aim to win then you are going to do more in a short period of time than you have ever done before, and you’re going to use a range of tools. Make sure you startup all the tools you use before you go and that they are up to date and functional.

Work as a team

This is essential.

It is way too easy for everyone on a team to hit the same area, and then follow someone else into that area when they find a problem.

Working in pairs can be useful:
  • particularly if it is a tricky area that neither of you understand fully.
  • your partner might observe something that you’ve missed.
But… I’ve found that:
  • sending everyone out on their own,
    • to different areas of the app,
    • to the same area, with different observational and attack focus
  • concentrating on each persons strengths
    • ‘you like to do accessibility’
    • ‘you like to get technical’
    • ‘you know how to use tool X, so you can follow behind Bob when he does Y’
A more organized wide dispersal coverage in parallel seems to work better than a self organizing swarm, if you want to win.

And… the team needs to communicate:
  • when you find a problem then communicate it to your team,
    • not so that you can swarm and see it, but more so that you can generalise to a root cause or pathology and see if a similar fault exists in the other areas of the app that other people are looking at.
  • sometimes it is useful for someone to find a problem, then pass on their notes to another team member to raise the defect, while they continue to sweep the area for further issues when they are in the groove
  • quietly.
    • The other teams (for the period of time that the competition is on) are your enemies
    • They can, and will, steal your intel if you shout it out (you might not be able to exploit the intel, but they might)
    • They can prioritise, if they know you are working in an area of the app, they could hit it hard and fast to find low hanging fruit that you waste time raising when they have already raised it.
    • they could steal your defects if you are slow to raise them, but discuss them loudly and carelessly
    • “loose lips, sink ships”

Other tips

Depends on the rules for the bug bash but if the bug bash has a rule that “First to find the defect claims the defect, and duplicates don’t count”

Get efficient in raising defects

This means you need to be efficient in raising defects. I recommend copy and pasting into a defect tracking system rather than writing it directly into the browser. Why?
  • defect tracking systems can crash
  • create your own ‘template’ to copy and paste commons stuff e.g. priority, environment, version into mandatory fields with no default
  • you have a local record that you can scan without having to use their system
  • if it crashes or messes up when you raise the defect you just create a new defect and paste from your notes rather than typing again

Low hanging fruit

Use low hanging fruit to demoralise the enemy.

Early on in the competition, have at least one person monitoring your parallel tools and report spelling errors or broken links and images. Raise these into the bug tracking system quickly and make a big deal of it. Then it looks like your team is raising Bug, Bug, Bug after Bug. This can panic the other teams into losing site of their strategy and following you into the areas you have already cleared.

When you do raise bugs, don’t announce the content, just celebrate loudly the raising. You might get lucky and the other team might waste time going into the defect system to read your reports.

If you are lucky then periodically the organisers will announce how many bugs have been raised, and if you have dominated the bug count, even with low severity issues, you can gain a psychological edge on your opponents, aided for free by the Progress Propaganda Department of the organisers.


A public bug bash is not your normal testing exercise. Particularly if you want to win.
  • target bugs, pile 'em high, and pile 'em fast
  • get ready before you go, install what you think you’ll need, make sure you know how to use it, and make sure it all works before you go
  • harness parallelism
  • demoralise your opponents by announcing defects
  • organise as a team
  • Hit the system hard, hit it fast
  • Report quickly and well
This post is in response to @ncbaral's twitter request for "have you got any #protip" for Bug Bash attendance.

Thanks Nirmal.

Wednesday, 7 December 2016

How to improve your CV and improve your chances of finding your next software testing job

TLDR; Write your CV as benefits, and build a portfolio, to become more than just another CV on the pile and help the busy CV reader see the value that you can bring to their team.

I’m trimming out an email backlog and came across a few “I can’t get a job - please review my CV and tell me what I’m doing wrong!” emails.

I’ve collated and distilled the advice I tend to give out, to help me trim out my email and an attempt to cut down on the number of CV’s I’m sent with people asking for “help” - although agencies and companies I’ll happily consult with you, for suitable remuneration, to help you solve your CV and recruitment issues.

Some of this may have appeared on this blog before. And if you’ve asked for my advice before don’t be alarmed. I have generalized and anonymised any personal details.

Your CV is a sales pitch

Your CV is an initial sales pitch. And the easy thing to learn from sales is “concentrate on benefits not features”, but its hard to put into practice. Particularly when CVs are involved.
  • Most CVs are lists of features
    • my name is
    • i live at
    • I have been trained in A (on this date), B (on this date), C (on this date)
    • from time X to time Y
      • I worked here
      • my job title was Z
      • i did X
    • i went to school, here are my grades
    • i went to university, here is my final grade
    • i like to read books and walk in the park and do other stuff too, here is a list
I look at my CV and the second page is pretty much like this too, so I don’t fully take my own advice.
Because it’s hard.

Why does it benefit the reader, your future employer, that you were “trained in A”, did you use that information? Did you build on that skill? What did you achieve with that skill? How will it transfer to my environment? Do you even remember it?

I think this is the hardest thing to do, but please try.

Make the early part of your CV a sales pitch, so read sales books, advertising copy books, and tweak and edit mercilessly.

Once you’ve sold the benefits, show them the product

We can’t wait till an interview to show the product (which is us, by the way, the person who writes the CV).

We want to show them the product early so that, either:
  • they want to interview us and are excited by our profile
  • they don’t want to interview and know that we are not for them
We only want to work with people that we are a good fit for, so we need to have a way of filtering out those environments that are not a good fit for us.

“But I put my interests on the bottom of the CV”

Yeah, I assume you can read. And I don’t care if you like to walk in the park. I want to know if you can actually do what you’ve said you can do. Assuming that you’ve already convinced me that I will benefit from you doing it.

Convince me with a (demo) portfolio of work.
  • create a blog - blogger, wordpress, medium, whatever free blog host
  • write up what you learned when you ‘did X’ and your ‘job title was Z’
  • demonstrate as many benefits as possible
    • if a benefit you will bring is ‘improving testing efficiency by coding adhoc custom automated tools’, then show me some code that does that on Github
    • if a benefit is that you can create ‘robust automated execution of the system to continually check high priority functional flows succeed by using Selenium in Java’ then show me some code that does that on Github
    • if a benefit is that you are ‘Trained in A and can knowledge share quickly with my co-workers’, then show me the evidence, and possibly slides that show your distilled knowledge
Release everything:
Releasing code to github also demonstrates, and builds, competence with version control systems. Using Travis can demonstrate, and build, an understanding of CI.

If you are nervous that the code you do outside work doesn’t reflect the quality of your code then:
  • release it
  • critique it in a blog post
“But all my work is commercially sensitive and belongs to my past employer”

Then do more work, at home, so you own it. Write code that represents the core parts of what you have learned.

“But I don’t have time”

Here’s some other advice from people:

Felix Feng
TJ Maher

If you want it, you work for it.

And you probably already have worked for it.

I want you to make all the hard work that you’ve already done, and continue to do, impossible for the people reading your CV to ignore.

Because they will try to ignore it. Because they are busy. And the first excuse they have to drop your CV and move on to the next, they will take.

Rewrite your CV for the role

Why are CV’s short? Is it for the benefit of the reader?

No. It’s so we can update it and tailor it for each role. (and possibly for the benefit of the reader).

When you do this, you might find that some of your experience doesn’t fit the role. Particularly when you are just starting out.

Which means, for experience that is not related to the current role, rewrite to emphasise the overlap between the previous role, not just the task. This helps when you take a ‘benefit’ approach to writing your CV.

It is vital to rewrite your summary for each role. Particularly if you have an “I am looking for a role where I can…” section, you better make sure that what you’ve stated you want, is actually on offer, otherwise the reviewer won’t move beyond that.

What about Linkedin?

Use Linkedin as a supplement for your CV.
  • Your CV can concentrate on the benefits and the evidence since it only has a short amount of space.
  • Linkedin can describe the features - where you worked, and what you did.
  • Linkedin can also support your evidence with slideshare integration and ‘publications’ and ‘projects’
  • Use the summary on Linkedin as your sales pitch.
  • Remember to make your profile visible to public visitors, because people reviewing your CV probably aren’t connections yet.
We don’t have time to cover Linkedin profile summaries here, but feel free to have a look at mine and reverse engineer it to tweak yours:
A few tips we do have time for:
  • sell in the summary
  • use unicode characters (stars, ticks, circles, etc.) to format your title and summary
  • have a decent/business photo
  • write information about each role, flesh the profile out
Melanie Dodaro has good advice on using linkedin on her blog


  • benefits not features
  • provide links to evidence in a portfolio
  • make every experience count by describing benefits
  • supplement your benefit based CV with Linkedin
If you do a little extra work building a portfolio, then you can become more than just another CV on the pile. And you’ll help the busy CV reader see the value that you can bring to their team.

Best of luck.

Wednesday, 30 November 2016

Notes on Leanpub podcast with Peter Yaworski - Web Hacking 101

I just finished listening to the Leanpub podcast with Peter Yaworksi.
There is a transcript with some links embedded on the podcast page

Actions Taken:
Next Actions:

Tuesday, 29 November 2016

A retrospective critique of an exploratory testing session

These are the notes for a critique of this Exploratory Testing Session on YouTube

You can watch the critique below on youtube


I picked Google Search because I thought:
  • an obvious software
  • simple to understand
  • at a high level just an input and an button
  • didn’t expect bugs to distract so could focus on thought process and execution
I was wrong.

Note: Time stamp links in the header are links to the YouTube video at the point where the retrospective notes discuss that section.

Thursday, 24 November 2016

Software Testing YouTube Channels to Subscribe to - and how to subscribe

TLDR; There are a lot of amazing YouTube channels to learn from. If you're not using subscriptions on YouTube with notifications or RSS then you are missing out.

When I started with YouTube I used it as a search engine and didn’t subscribe to any channels.

There are so many testing channels and conference channels that learning how to subscribe to YouTube channels will massively boost your learning opportunities. Use the list of recommended channels below and the instructions on how to subscribe to boost your learning opportunities.