Aiming for (at least minimum) quality software

Posted by Bart Klinge on January 12, 2024

In the summer of 2022, I had a child; a beautiful son who can’t stop trying to get himself hurt, or worse. Luckily, next to us being vigilant all the time, the world tries to help us a bit. A recent, real-life example I saw was a stuffed elephant. Either they put warnings on their product (like 3+), or they make sure that it is a suitable quality for their sweet spot customer. For my kid (3-), this means that his toy is safe and has no small parts that can almost be swallowed. Because he likes to break things, the toy should also be robust, perform well and, last but not least, be accessible. Kids tend to be on the tiny side, so their hands need to be able to grab the toy.

For TOPdesk this isn’t any different. To have our product suitable for our customers it should adhere to a certain level of quality. It should have no security leaks that put a lump in your throat, no crashing environments, and be accessible for a wide group of users. Next to that, as TOPdesk, we want to build one product that is consistent throughout all the different components. This means we need to have a quality baseline that is shared among all teams.

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.

Testing Accessibility with Accessibility Insights

Posted by Anna Maier on December 9, 2019

There are many tools out there that help you check if your website or webapp is accessible. Most of them do an automatic check based on some accessibility guidelines. Some also provide functionality to do checks yourself, for example, to check the color contrast. The open source tool Accessibility Insights takes a different approach: on top of the usual automated checks there is a set of guided manual checks. This makes it a great tool to learn about accessibility testing and programming.

Frontend Testing with Jest – Assertions deep dive

Posted by Anna Maier on April 29, 2019

When it comes to frontend testing, most developers think of slow tests using selenium and a connected browser in an error prone setup. With more and more logic moving to the frontend, this picture is now slowly changing. Modern javascript testing frameworks make it possible to run tests fast and reliably.

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.

Google Test Automation Conference 2016 – When top players talk about Automated Testing

Posted by Tobias Spöcker on December 5, 2016

golden-gate-foggy

This image perfectly pictures my first feelings about the conference, but let me go into a bit more detail first.
I signed up for the Google Testing blog more than a year ago. There I found a lot of interesting and useful reading about the world of automated testing. When I later got an email from Google informing me that there would be a conference held by them, I was not entirely sure wether I should apply. Is it relevant for me? Am I experienced enough to contribute? Well, what’s the worst that could happen? So I applied for it and did not regret it in the end.