Never mind the bollocks, Here’s House of Test UK

House of Test have been the punk rockers of the testing world in Europe for years. Now a new chapter begins as House of Test bring their inimitable style and unique software testing approach to London, United Kingdom.


“This is a perfect next step for House of Test to achieve its humble mission of taking over the world. We are excited to become part of London’s vibrant business climate.”

Says Henrik Andersson CEO, House of Test


Effective immediately, House of Test is operational in London and we’re delighted to announce this endeavour will be led by Ben Kelly. Ben joins House of Test from eBay’s European Product Development department in London where he acted as Head of Testing.


“Since their inception, House of Test has been the embodiment of how I think software testing should be done. They understand the need to add value to their clients and I’m excited to bring the House of Test approach to the UK.”

Says Ben of his new role.


“Ben’s solid reputation in the testing community is remarkable and he has year after year proven his vast capacity in testing.

We believe Ben’s professional irreverence for the status quo perfectly represents what House of Test brings to the UK.”  

Says Henrik Andersson CEO, House of Test


Punk isn’t all mohawks and piercings. It’s challenging the establishment. Going against the norm. Why do what you’ve always done? Shoot for something better. Find your inner punk.


What separates House of Test consultants from the average run-of-the-mill test consultants is our unstoppable drive and thirst for knowledge about software testing. We pride ourselves on housing some of the world’s leading trainers, coaches, and test experts on our roster. Regardless of your testing problem, you can rest assured that House of Test can help you solve it.

House of Test has chapters in Sweden, Denmark, Switzerland, South Africa and UK


Tapir Fever: A heuristic on conference speaking

Four months ago my first proposal for a conference was accepted. It’s been an interesting journey in unknown territory. The conference is in two days.

Lately on Twitter there’s a lot of talk on the Speak Easy program and on gender inequality in tech conference speakers. To this I’d like to pass on some points to others doing their first conference presentation. “Preparation is your friend”, a friend told me. But what does that really mean? Here is a preparation heuristic for you:

  • Throw away the ideas that don’t work for you. Don’t succumb to the sunk cost fallacy. If you can’t get a hang on the topic or the angle doesn’t work for you, just let it go. Start over. Go with whatever you feel is interesting.

  • Accept feedback and criticism. People are trying to help you, so listen to their feedback and points. They are probably right.

  • Pause. Take a break. Start preparing early enough so you have time to leave your preparation alone for days or weeks. A critical distance will make it better.

  • Isolate yourself. Stop writing and talking to other people. Start talking to yourself, the mirror or the wall. You think you are going to “have a conversation” or a dialogue with the conference audience, but really it’s a monologue until the talk is over and discussion begins. So you need to practice talking without expecting or relying on feedback.

  • Research and review. Get to know your topic in depth. Who has written and said things about it? What theories are you using and how does that affect your talk? Are your sources all Wikipedia, blogs or academic papers?

  • Flow. Every time you practice and for every week that goes by, the focus and the presentation will change a little bit. Or a lot. Let it change because every audience and every context is different, so you need to be able to adapt.

  • Embrace creativity. Write everything down and then throw it away. I have no text in my presentation slides, but that doesn’t mean I haven’t written anything. I have written what could be a short novel, because I am most creative and innovative when I write. If your creative mode isn’t writing, then find out what it is and start doing that.

  • Visuals. Pictures, graphics and layout take time to find or create. I made simple drawings of my topics main elements and a friend (and cartoonist) drew the whole slide deck. I paid her with a good bottle of wine. So find someone who is good at layout design or drawing.

  • Environment and resources. Look around you. I’ve used my friends and surroundings as much as possible. We all know people that are specialized in some area: My sister is a designer (nice layout), my big sister coaches people in public speaking (yay!), my step mother is a consultant in organizational change (organizational theory), my husband is a developer (general discussions on test/dev relationships) and I have friends that are sociologists and philosophers (just smart people). And last but not least: my colleagues and friends at House of Test (test discussions)

  • Rehearse your talk. Find someone to practice with. When you think you know your presentation, find a colleague or a friend who will listen. The first 2-3 times are horrid but that’s okay. Now you can improve the presentation.

The last bullet didn’t fit in the catchy name of the heuristic. But here it is anyway:

  • Panic. When you panic and decide to quit because the mere thought of presenting to others freaks you out: Call a friend. Get a perspective on things and accept your fear as a normal feeling for any human being.

Good luck and I am looking forward to seeing you!



Releasable is not the same as Release Worthy


In a previous assignment we were introducing a continuous integration type of process to allow us to deliver code faster and in smaller parts to the main codebase. The idea was that each code delivery should be extensively checked by our test-automation resulting in the main codebase being in an always releasable state. The theory was that we should always be able to pick the latest build and be able to use it and release it. However my manager at the time, Mattias Göransson, made a very insightful comment about what always releasable actually meant in our context:

“We might have an always releasable state of our main code base but that does not mean it is release worthy”.

During the project we reached a stage where we could always send out the latest executable and we could with confidence lean on our automation to say that the product could be installed and used (to some degree). But to make sure it was actually release worthy, that it solved the intended problems for our customers, we needed eyes-on testing. For example; in this particular context it was important to have a user friendly interface and our automation could not make a judgment and provide us with an answer if our product lived up to that requirement or not. What the automation could tell us was that the product was technically working (to some degree).
The distinction between something that can technically be used and being worthy to release gave me a much better language to use when discussing and planning what testing was needed in what part of the process. I believe the distinction also helped us keep focus on our the testing by better understanding in the organization about what values the automation could and could not provide.


How ISTQB made me feel bad about good testing

In the beginning of my career I was assigned to test a part of a very complex automotive system. The project was behind schedule and a fixed release date was closing fast. In the automotive industry there are fixed release dates and patching is very expensive since it requires the car to be brought to a workshop. The system developed was much more complex than the ones currently in production; unfortunately it was in terrible condition. The system crashed on a regular basis, features were missing or not working and there were a lot of re-design and requirement updates.

My approach was to divide the system on the different GUI views. I listed these in Excel. Then I added the subparts of the views into my Excel spreadsheet. By reading the different specifications and talking to the system owners I came up with a lot of things to test and added them to the items. The reporting was done by color marking the items based on my opinion.

  • Green: No problem found
  • Yellow: Small issue
  • Red: Major issue or many small issues (or that feature was untestable because of other defects)
  • Grey: Not tested

I reported issues with the system or specifications into a bug tracking tool. The severities of these issues were discussed with system owners and the project manager. If needed, I updated the colors of my excel items to reflect any new information regarding severity. I also added references to the bug reports next to the colored items. When they were retested ok I crossed them out but kept them in my spreadsheet for regression testing. Both system owner and project manager were very satisfied with my work.

The next step

Eager to learn more about testing I signed up for a course. At this point an international known course like ISTQB Foundation sounded as a good idea. It wasn’t… at least not for me…

The course was packed with text-heavy PowerPoint slides. There were almost no discussion around concepts and no actual practice. Since the goal of the training was to pass an exam there was a big focus on memorizing answers to questions. When I challenged some of the “facts” in the training material the teacher told me to just remember it and take it with a grain of salt.

The importance of salt

Unfortunately, as a rookie in software testing I did not bring enough salt. There was very little discussion about in which situation use certain approach would be recommendable. Context was not considered at all. When I got back to my assignment I tried to implement some of the stuff we had learned at the training.

I started to make detailed test case specifications and mapping these to requirements. I also spent time thinking on how to measure requirement coverage. After a while I realized that even if I did test all the requirements they would have changed when I was done. And updating the test specifications would take a lot of the time I could use for doing testing. And the requirements were nowhere near a full description of the system. So I stopped, and went back to my former way of testing and reporting. All good? Unfortunately not…

Everyone’s happy, except me

Although the project manager, system owners and suppliers thought I was doing a great job, and there was really good progress, I couldn’t lose the feeling that I was cheating. I did not do it the “right” way… How could they be happy about my work? Was it because they didn’t know anything about testing? For a couple of months I got nothing but praise for my excellent work but still felt bad. Then I went on a seminar called “Beyond Test Cases” by James Bach… He made me realize that there was no right way of doing testing and that testing is not about presenting a number of failed or passed test cases. Nor is it about producing requirement coverage metrics. It’s about questioning the product to reveal information about it which is useful for the stakeholders. And the way you approach this challenging task is different in every situation. When the assignment ended and the customer made a performance review of me I got 4,7/5 with the motivation ” I don’t want to give you all 5’s because you might get cocky”. That was great, but the best part was that I finally felt that I had done a great job and that I deserved the praise.

Thank you James for showing me a better path!


Two recent interviews with Henrik Andersson

Two recent interviews with Henrik Andersson have been published.

In Testing Circus Henrik speaks about the risks and problems with the new testing standard ISO 29119.
In Tea-time with Testers Henrik gives his thought on recruiters, how we train skilled testers and that it is time for us to raise the bar.

You can read the interviews here.
Tea-time with Testers

Testing Circus
Sida 1 av 41234