Six Questions for a Quick & Easy Root Cause Analysis

Posted by Hollis Hazel on March 8, 2022

What’s a Root Cause Analysis?

When an issue is found at a customer, my team first solves the issue. Then we take a closer look at how the issue occurred to see how we can prevent the same thing from happening again.

How do I do one?

A Root Cause Analysis is otherwise known as a bug retrospective. There are many models and frameworks available, like the Five Why’s or Fishbone Diagrams. But at its core, a Root Cause Analysis is very straightforward. You just want to know two things:

What happened?
How can we prevent this from happening again?

To help you get started, I want to share my guide to a Quick and Easy Root Cause Analysis.

Resources for Exploratory Testing

Posted by Hollis Hazel on August 30, 2018

What is Exploratory Testing?

In scripted testing you follow a script that tells you where to click, what to enter, and what to expect. Freestyle exploratory testing does not rely on scripts, but rather on the experience and intelligence of the tester. As you go you change your plan and approach based on what you have seen so far, just as you would when exploring an island or a new city.

Exploratory testing is not ‘just clicking around randomly’. It is quite the opposite. Good exploratory testing demands critical thinking, an eye for detail, a good deal of imagination and a natural curiosity for “what if”’s. It takes expertise, intuition and practice.

Exploratory testing is perhaps the most difficult and skilled form of manual testing. So I’ve gathered a few of my favourite resources to help you on your way.

How to Organise a Bug Hunt in Six Easy Steps

Posted by Hollis Hazel on August 29, 2018

In this blog, I want to share my experiences in organising a bug hunt. Testers at my organisation formed teams, who then set about testing a piece of the software that my own team had developed. It was a great learning experience for everyone involved, and something I’d highly recommend.

What is a Bug Hunt?

During a bug hunt, a Test Owner presents two teams (of two or more people) with a piece of software to be tested. The Test Owner provides some basic information, and the teams get to work testing the product. At the end of the session, they report their findings back to the Test Owner. The activity can be seen as training in how to organise and communicate testing, but is also a fun way to learn a new piece of software.

How Do You Organise a Bug Hunt?

Here are a few insights from my first experience as Test Owner. One of the hardest things for me was estimating how complex to make the test object. The most enriching on the other hand was seeing other testers dissect software that I had helped build. Because the teams were distributed, I also picked up tips on how to make working remotely go smoother.

Your experience will undoubtedly be a personal one. Nevertheless, the tips below will make the first time much easier.

Five Free Web-based Tools for Exploratory Testing API Responses

Posted by Hollis Hazel on August 7, 2017

How to test whether your API can handle anomalous HTTP responses.

Today I was exploratory testing my Service, which performs sequential HTTP requests that depend on the response of the previous request. I wanted to find out how our API would handle a variety of HTTP responses. I also wanted to see what would happen if things went wrong. What if the response contains an image? Or an error code? Or what if there was a timeout?

To answer these questions as quickly and easily as possible I ventured on to the web. With some effort, I found what I was looking for, and on the way I discovered a few tools that are just great for exploratory testing your API’s response handling. If you test or debug API’s on a regular basis, here are a few free tools you’ll definitely want to check out.

Exploring Trends in Testing

Posted by Hollis Hazel on June 23, 2017

TestNet Spring Conference: Trends in Testing

A week or two ago I went to the TestNet 2017 Spring Event. I’m not going to recount the content of each talk or workshop I attended. Instead I want to combine this event with my experience at other conferences, and give you an overview of the biggest trends in agile testing right now.

International Hackathons: Tinkering Time, Freedom and Responsibility

Posted by Hollis Hazel on March 29, 2017

What makes TOPdesk TOPdesk? When you ask around, it all comes back to our corporate culture. TOPdesk gives its employees freedom to explore and experiment, coupled with the responsibility to use this wisely. Just one example of this is our International Hackathons, where self-selecting teams work on a project of choice. At the latest International Hackathon, TOPdesk colleagues from all over Europe gathered together in Kaiserslautern for three days of innovation and fun.

Hackathons – An Agile Development Microcosm

International Hackathons at TOPdesk are a microcosm for the way that TOPdesk tackles the challenges of Agile Development. Nobody is going to breathe down your neck and tell you how to do your work. No, sir.

Instead, we give individuals the space to experiment. Teams look critically at their own processes, and select those methods that lead to the best results. You see this in the variety of tools and techniques in use at our (currently) sixteen Scrum teams. I want to share a few of the tools my International Hackathon team selected to make our project a success. Come, take a peek into the world of Agile Development at TOPdesk.

At the core of the TOPdesk culture are freedom and responsibility.

No Root Cause Analysis? Here’s why you’re missing out.

Posted by Hollis Hazel on October 7, 2016

What is a Root Cause Analysis?

Think for a minute. What usually happens when a serious bug makes it to production?

Someone walks by and asks you to look into it. ‘Find the cause’, they say. So you go in search of the cause, with the goal of fixing it as soon as possible. This is good, but it is by far not the most ideal situation. Let me explain.

Consider the very real error that led to the immediate destruction of an aircraft before take-off. In an unfortunate turn of events, instead of flipping the switch for raising the flaps, a pilot accidentally flipped the switch for raising the landing gear. Although nobody was injured the pilot’s mistake inconvenienced customers and led to expensive repairs. The cause of the failure was noted as pilot error. Why wasn’t this the end of it?

Why the Lean Unconference is gaining popularity

Posted by Hollis Hazel on August 5, 2016

One of the great things about working at TOPdesk is the freedom you get to organize your own events, like the recent Pecha Kucha evening that the Agile Community held, or our annual innovation Hackathon. In this post I want to share what it’s like to participate in a Lean Unconference (a conference with no schedule), a concept I first encountered in the Leancamp Startup circle.

What is a Lean Un-conference?

The Lean Unconference started with a kick off. Together with around thirty young professionals and entrepreneurs, the organisers gathered in the lobby. They first recapped the format and goals of the (half) day and gave everyone time to fully arrive and focus on the present.

The organisers underlined elimination of waste is at the heart of Lean. A Lean Unconference thrives on the premise that we have all come to learn or to share. If you are not doing one or the other, you risk wasting not only your time, but the time of others who are trying to learn or share. We agreed to use the law of two feet. If a session is not as relevant as hoped, use your time wisely and join another session instead.

Instead of a passive conference experience, the Unconference organisers did a good job in activating the participants. For a short time, they said (and they were right!), we had access to a wealth of knowledge, experience and expertise. It would take weeks, or even years to share all that we had learned. We only had half a day, so let’s make the most of it! An introduction like this generated a noticeable drive among those present to make it time well spent.

An Un-scheduled conference?

When I say an Unconference has no schedule, this is not strictly true. An empty schedule posted in the central area displayed six slots of a half hour, each with a number of available rooms (say, four or five).

Before each block of three slots, participants could pitch their session to the group. We then assigned post-its to a room big enough to seat those interested. While everyone was welcome to prepare, keeping the schedule empty ensured that all proposed topics were current, relevant and interesting. It was perhaps more reminiscent of open spaces or breakout sessions than a traditional conference.

What can the sessions be about?

This is another advantage of Unconferences. Sessions can be about anything! You might follow a particular theme (Agile Testing, Customer Feedback) or simply leave your options open. To make the outcome as useful as possible, pitches should be relevant (address a current issue) and personal (based on experience).

You might ask a question: How does user experience fit into Agile Development?
You could share tips or experience: How I made Risk Poker really work for my project team.
Maybe you want to teach a new skill: Mind-mapping for user scenarios.
Or get advice: How do I get my team to talk more about unit testing?

For each session, the host could choose from a number of interesting session formats.