Exploring Trends in Testing

Posted by Hazel Hollis 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.


Read more

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

Posted by Tobias Spöcker on December 5, 2016


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.

Read more

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

Posted by Hazel Hollis 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?

Read more

What happens between finding and reporting a bug?

Posted by Erik Hörömpöli on

Reporting a bug right away after finding it might not be the most useful thing you can do. What.. how? Here is an example and the theory behind it.

Looking at the bug itself, not only what it can cause

My team refactored a part of our application to start using javascript. I was curious how it would react to the biggest numbers that can be typed in when I found a bug. There was a shopping cart involved and multiplying really big numbers got the cart frozen, it seemed. I pressed F12 to see what was going on behind the scenes. It wasn’t only because of big numbers, but instead it was a digit overflow, caused by a precision error in javascript (which I then quickly learned about: http://www.w3schools.com/js/js_numbers.asp) Aha! From then on I could easily reproduce it. I wondered, how else this could be a problem? This lead to me adding some pretty average-looking numbers which then would cause the same problem, locking down the cart.

Read more