# Heuristics applied when opening a safe lock

When teaching testing I often talk about heuristics. Everyone uses heuristics whether you are aware of them or not. Simply explaining heuristics – A heuristic is a rule of thumb. It’s an approach or a method of how to a solve a problem. It’s important to remember that all heuristics are fallible.

In software development we use heuristics everyday. Your heuristics are build upon your experience. This is why I find it extra interesting comparing my heuristics with those of my children, who have different experiences than I have.

A few years ago when my kids still played with toys, I was in the bathroom getting myself ready for the day when I heard my youngest daughter crying from the other side of the wall. I opened the door and asked her what was going on.

“I can’t open the safe lock and I have all my money in there. We have forgotten the code and now we can’t open it.” Of course I went to see how I could help them.

My oldest daughter was sitting on the floor and furiously shaking the safe. She mumbled something about how she had changed the code a while ago. They had tried several different codes but with out any luck. So I sat down on the floor with my daughters and asked them to show me what happened when they entered the code.

They entered a code. “Error” was shown on the display and the safe made a kind of buzzing sound indicating that something was wrong .

I asked them what different things they had  tried to do to open it. They had actually tried several things like

• Trying to remove the hinges. Kind of clever I think ( but it might have broken the toy).
• Searching the internet for how to open the safe.
• Tried different codes.

Suddenly my youngest shouted, with pride in her voice: “We can use a saw and cut it open!” We chose to proceed without bringing out the saw since they really liked their safe lock.

Opening the safe box

To give you and idea of how the safe is opened, I have provided a short gif and a brief explanation. There are actual sounds made for each action you do but since I can’t upload videos without upgrading my account to Premium this will have to do. You just have to imagine any toy with sounds and I bet you will understand how this quickly can drive you crazy…

1. First insert a plastic “key” card (sound played).
2. Press the button “Withdraw” twice. Not sure why it needs to be pressed twice (sound played).
3. Then enter your code (sound!). Another sound is played when the code is correct. You can then open the safe with the black handle below the “Withdraw” button.

Heuristics applied

Before moving on with some ideas that came into my mind we tried a few codes again but without any luck.

Since the safe box actually had some software I used the “Long press heuristic” hoping I could reset the software. I even tried combining different buttons hoping to trigger some error which would reset the safe. Yes, this has actually happened before!

I then went with the “Google search heuristic”. It had already been tried by my children but I had a deeper knowledge of how to search the internet. This unfortunately didn’t help either and to be frank I was more eager to interact with the safe lock rather than reading.

When this didn’t help, I wanted to use my “Remove the batteries heuristic”. It was a long shot but it was a toy so maybe removing the batteries would reset the code. While doing so I discovered a tiny hole next to where the batteries goes.

You might wonder why I didn’t look for it when considering to reset the safe code – but it just didn’t cross my mind. As a side note there is a cognitive bias called the Hindsight biaswhich is very common and also known as the “I knew it all along” phenomenon. The effect of this bias is that it causes us to overestimate our ability to predict events. And might also be a reason for you thinking – “I would have looked for the reset option the first thing I did.” Maybe you would have – maybe you wouldn’t.

With excitement in my voice I asked the children to go get me a tooth pick. Again I was using my heuristics – “The press reset with a tooth pick heuristic“. I pushed the tooth pick into the tiny hole. The safe made a new type sound and seemed to be reset. “Wohoo! Could this be it?”

We inserted the plastic card, pressed the withdraw button twice and then pressed the code several times without any luck. The fourth time the safe made a new sound ( described as a sad sound by the children), a light went red and then the display was blank. This was a different behavior! Intriguing!

I noticed that the text on the display was very hard to read. It was not very bright. My youngest used her little hand to shadow the display to make it easier for me to read. I suspected that the batteries might be running low so we changed the batteries. And voilà we could finally open the safe.

My heuristics were build upon my experiences with toys, software, and software and hardware working together. Experiences which my children did not yet have. Some were consciously applied but I am certain there were several unconsciously used heuristics as well. Also by interacting with the toy, exploring different alternatives serendipity might have played a part here too. I still don’t know why the safe wasn’t reset properly after pressing the reset “button”. In hindsight it could have been waiting for a new code to be entered but that hypothesis have yet to be tried.

A toy safe is however different from a real safe. The context of where the heuristic is applied is of great significance.

To read more about heuristics in Software Development and Testing the following article, Software Testing Heuristics: Mind The Gap! by Richard Bradshaw and Sarah Deery is a great starting point containing a long list of references.

# Are you really a Test Coach?

For many years we have seen different kinds of coaches appearing within software development. As more and more companies strive to become agile, various types of roles are becoming obsolete or transformed into something different. The most prominent one seems to be Agile Coach. In the software testing domain it is the Test Coach or the Quality Coach.

The transformation and changes in expectations of a role have in my experience caused some identity crisis within the testing profession. Even though there is a need for testing many companies choose to remove the tester as a role. (This post is however not about testers so I will not continue down that road).

As for myself I’ve been struggling to put a label on the work that I do. For those who know me I am not a big fan of titles and labels, although they can be helpful in some contexts. My work for the last few years have focused on transformation and how testing needs to be interlaced with development. Many of the companies I’ve worked with do not even have testers.

## Coaching

Last year I went through a nine day training to become an ICF Coach. During that course I had many great insights. One of them relates to the Coach in the context of Software Development. A few times I’ve labeled myself Test Coach or Quality Coach but I struggled a bit with those titles as well. I just felt they didn’t really do justice to my work. In the context of coaching a coach is an expert on the process of coaching and is someone who facilitates learning.

“A coach is an expert on the process of coaching and is someone who facilitates learning. “

The client is the expert but the coach helps the client to unlock their potential to maximize their own performance. A skilled coach knows that the individual has the answer to their own problems.

## A coaching approach

Why I struggled with titles like Test Coach became very obvious during my coach training. I was presented with the following model, “The flower”, created by Polhage & Lundberg, who also run the training (the model is originally described in Swedish and this one has been visually modified by me). They differentiate between the coach as a profession and having a coaching approach. We can always apply a coaching approach whether it’s in our daily life or at work.

The flower petals represents several roles which we might step into during our daily life or at work. The Coach is one of these roles (and the one I was in training for).
You can move between these roles and decide who to be in different situations. As an example, sometimes you need to take decisions based on your responsibilities which makes you the Decision maker. The empty petal is left for you to decide what to put in there. Your flower might have many more petals.

No matter what profession or role you have you can always apply a coaching approach. This means how you act and relate to the values of coaching.

The root system represents eight characteristics to consider for constructive communication, which are used in a coaching approach.

I quickly realized why I have never been very fond of the title Test Coach. It doesn’t fully reflect what I do or who I am. I am a subject matter expert in testing trying to help an organization, a team or an individual to improve their testing by guiding them and showing what to do, how they can do it and why.

“I am a subject matter expert in testing trying to help an organization, a team or an individual to improve their testing by guiding them and showing what to do, how they can do it and why.”

But I am also a Decision Maker, a Teacher, an Inspirer and a Mentor (for those who choose me to mentor them). I shift a lot in between all of these. One role I have never used at work is the Coach. However I often apply a coaching approach. This is an approach where I ask questions, where I use my curiosity to understand where the team or individual is right now and where I display my courage to challenge and ask “uncomfortable” questions. Focusing on what works and what moves us forward is also part of what I apply in my daily job whether my title is Project Manager, Test Coach or Scrum Master.

The only time I have been the Coach and only a coach is when I am a professional Coach in an agreement with a client.

## Coaching in software testing

I recently had a short assignment where I was asked to coach a tester. She needed someone to talk to regarding her own journey where she was leading a change in her organization. In the beginning I found myself struggling with who to be. Biased by my recent experiences as a Professional Coach I started off in that role but quickly understood that my client needed something different. The focus was more related to guidance around the change she was implementing at work rather than her own journey. Sometimes it was hard to separate her own growth from the approach to testing that she was implementing.

Something that is very important is the agreement that you come up with before starting the sessions. The purpose of that agreement is to build trust and set expectations. Though this situation was a bit new for both myself and my client we decided to keep an open dialogue along the way to make sure she got value from our sessions.

My learning experience here is that it is not as black and white. What title you carry is not as important as the approach you choose.

“What title you carry is not as important as the approach you choose.”

During these sessions I used a coaching approach – actively listening, asking questions, driving my client to find her own solutions based on where she and her team are right now. In the cases where she wanted me to share my experience and thoughts, I did that as well.

What are your thoughts regarding coaches in Software Development/Testing?

## References

Polhage & Lundberg

# Testing beyond requirements

I often hear people talking about testing as validating and verifying requirements. But testing is so much more than that.

When we focus on verifying and validating we will most likely only find and look for those things we seek. It’s embedded in the meaning of the words themselves.

According to the Oxford Dictionaries;

Verifying is to: Make sure or demonstrate that (something) is true, accurate, or justified.

And validating means to: Check or prove the validity or accuracy of.

With this mindset we tend to focus on confirming whether the function or product works as stated. But we forget to observe what else is happening . It’s like reading your horoscope that says you will meet a blond stranger — and suddenly you are only paying attention to blond strangers.

Testing is to learn about the product through exploring and experimentation but when we focus on verification it turns into a demonstration of the product:

“Yes, I can login to the website.” “Yes, I can add some products in my shopping cart.” Does this seem familiar? However the demonstration only shows that the product can work, once, in some kind of controlled circumstance. It’s the process of verifying which leads us to think in this way.

When our brain is targeted towards verification we tend to forget to ask questions like:

What if…? What else? What happens when…? Who is this for? Why is it designed like this? When can this be used? How can this function be used differently then expected? What value does it provide? To whom?

By challenging the product or the system you are testing you will discover a lot of new things. When moving away from your confirmation bias you will increase the opportunity to find the bugs/defects you don’t want your users to find. In worst case those bugs which will cost your company a lot of money.

But we need to make sure we meet the requirements!

The most common argument I get when advocating for testing over validation and verification is “but we must make sure the requirements are fulfilled”.

Testing requires multiple information sources. The written requirements are only one input to the test analysis to decide what needs to be tested. If we want better products and software we must go beyond checking. Since we can’t test everything we must know what is the most important to test. There are many parameters which affects that decision and this is yet another skill which you need to have when testing. This is where I see many focus on a too narrow approach choosing verification over testing. What you can do instead is to focus on risk. What is the worst thing that can happen? What if we can’t proceed to checkout? Instead of checking a few specific flows — be creative and explore these flows from different perspectives.

We have both explicit and implicit requirements and we can’t write down every aspect of a requirement. Some things must be tried out before you understand it. Some things are considered so obvious that it is just not documented. There is always a possibility for interpretation and ambiguity in requirements whether they are written or spoken.

So why don’t we spend more time making sure the requirements are perfect? Perfect requirements is an illusion. Even if it would be possible to create perfect requirements we would be out of business before we got our product to our customers. The quicker we can challenge the product by interacting with the software or design, the faster our feedback loop becomes.

By challenging the product from different perspectives like different quality characteristics , different users, different context and applying different test techniques the more likely we are to find those critical bugs which in worst case can put us out of business.

## So let’s step out of the verification mode and start testing!

If you are to dive into testing beyond the requirements here is a bit of reading which I can recommend to start with:

James Bach
Testing vs Checking http://www.satisfice.com/blog/archives/856

# 2018 in retrospect – The last post

My reflection over the past year has come to an end. Looking back at the outcome of a very important decision I made in 2017 – I have now overcome the first year as my own boss.

It’s been a very busy year learning about all the things you need to know when having your own business. Someone told me it was easy and a piece of cake. I don’t agree. There are plenty of mistakes and wrong decisions that you can make unless you take help from others. Luckily I have friends who have helped me and along the way I have met many other freelancers who have shared their knowledge. I also decided to get professional help with bookkeeping and accounting.

It has been tough finding the right balance between family, my own health and interests, starting my new business, work, volunteering/community involvement, conferences and blogging. There has been quite some travelling this year and most of it has been work related. Yet I tried to prioritize hard this year and even kept my own Kanban board at home.

There are two reasons for keeping my Kanban board. It gives me visibility of all the things I need and want to do. It also gives me an enormous satisfaction when moving an activity to done. Unfortunately when I rearranged my office I lost the board. I didn’t keep any of the family related stuff on the board which was a mistake.

# So what’s up in 2019?

First up – get that Kanban board arranged!

Conferences and speaking

So far I have no speaking gigs. I had to turn one down which I was very proud for doing because I normally take on too much. One lesson learned from last year is that I need plenty of time around my speaking gigs. Last year I had too many things going on which caused a lot of stress.  I was also supposed to do a speaking gig together with Peter but unfortunately we couldn’t get someone to look after our children.

It feels good leaving the conference and speaking scene open for the moment. Who knows what opportunities might show up?

Volunteering and community involvement

As the the Conference Chair for CAST 2019, organizing and preparing for the conference will keep me busy. On top of that I am still a board member of AST and in March the board will meet up in Austin (US) for a meeting.  In August I will go to Cocoa Beach (US) for CAST 2019.

Black Koi Consulting

As mentioned earlier I want to put some focus on my website this year.

In April I will be hosting a training by Richard Bradshaw and Mark Winteringham in Malmö. The training reflects my view on “test automation” and is called Automation in Testing. I really wish that people understood why this training is so important. There are so many out there who believe automation will solve all problems. People who don’t see automation of test as software development – thus there’s a lot of really unskilled practitioners out there. That’s one of the reasons I am bringing this course to town.

Blogging and writing

I will definitely write more posts this year. I think I have already started well and I have a post coming up soon, explaining the concept of heuristics through lessons learned from today opening a safe when you have forgotten the code.

Clients

Tomorrow I start working with a new client in Copenhagen. It’s going to be a bit of commuting again. But for the right gig and client commuting is worth it. I am really looking forward to tomorrow!

# 2018 in retrospect – PART 4

2018 in retrospect – PART 3

## Conferences and blogging

This year I was invited to do my second keynote at RTC in Cluj, Romania (I wonder how many keynotes you need to do to stop counting them?). My first keynote happened last year at Testing Cup in Gdansk, Poland.

Also that first invite to talk at a conference feels wonderful – and so do the ones that follow. It is still rare for me to get invited to talk at a conference. But it is a sense of pride and joy when I do get an invitation. It’s payback for all the hard work I have put in so far in my talks.

This year my conference gigs took me to two new countries, Romania and Scotland.

Romanian Testing Conference

It was a great event and a nice atmosphere at the conference. As a speaker I was treated well and was picked up at the airport when I arrived. I had been invited to keynote and in my talk Testing through Space and Time I chose to talk about how the essence of testing is the same though our context is changing. I also shared how widely spread the misconceptions around testing is, unfortunately increasing the belief that testing can be replaced by automation.

I tried to enjoy as much as possible of the conference but like always I am a wreck before hitting the stage. But I managed to get to meet a few new people and have some interesting discussions around software development with Jim Holmes and Laurent Bossavit. Unfortunately I didn’t have the time to stay after the conference but I got a few hours of walking in Cluj together with Laurent.

Scotsoft

Next up was ScotSoft where I was invited many thanks to recommendations from Maaret Pyhäjärvi since she couldn’t go herself. ScotSoft was my first developers conference as a speaker. This invitation opened up for a great  opportunity to actually do a paired talk together with Peter, my husband who is a developer.

For those of you who have read my blog on volunteering and community involvement bridging between communities have been on my radar for quite some time. One thing that I assign to #bridgingbetweencommunities is,  to overcome misconceptions about testing we can’t stick to preaching to the choir but we need to reach a different audience. And what could be a better way of doing it as a developer and a tester and as an extra twist to it –  a married couple.

I’m not going to lie, getting the talk was quite a challenge. Peter, my husband normally takes care of everything when I am preparing a talk. This time he was preparing it with me. In the end it all worked out well and we were happy with our talk and the feedback we received.

We also got to enjoy Edinburgh since we stayed a few days after the conference. It’s a beautiful town and we also found some great food and beer places.

Agile Testing Days

I was happy to get to be part of ATD’s 10th anniversary. ATD is really a very big conference and  it is easy to feel a bit intimidated with all the attendees and speakers. Luckily I knew quite a few people there already from other conferences I’ve been to and people I follow on social media. I also really appreciated all the women from the Women In Testing group who were there and supported each other. A big thanks to Anne-Marie  who was my support and comfort in my workshop!

At ATD I ran my workshop creativity on testing and how limitations can be both boosting and hindering. I had run a similar one before but as most people I learn and adjust from each workshop and I talk I do and I improve my workshops. This was really fun to do so I hope to get to run it again at some other place.

Oredev

The last conference for this year was Oredev. Since Peter and I had put so much time and effort in to our talk for ScotSoft we wanted to run it again and also be able to update it with some of the feedback we had received. So I took a long shot and sent it to Oredev in case they hadn’t filled their program yet. We were lucky and got accepted. Being in Malmö where we both live made it easy to arrange for someone to look after our children.

A few years ago I was part of the program committee for a while but this was my first time as a speaker at Oredev. Getting to see the conference from the other side was really interesting.

The talk did not go as well as it did at ScotSoft. We are still not sure what parameters affected our talk this time. It didn’t flow and it wasn’t as natural as it was the first time but we got quite a few questions after the talk, which I think is a good sign. The talk made people think.

Blogging

First I thought I actually didn’t write anything this year. But I realised I had written two posts, just not on my own blog but for IKEA. It’s an initiative, part of the transformation they are currently going through. Since I really enjoy writing and have plenty of stuff to say I volunteered. Funny enough I left more drafts than actual published ones.

You can read the two post I published here:

Take aways from this episode

Four conferences this year was almost too much for me due to other commitments I had. I wrote too little and I want to be able to write more next year, because I have a lot to share.

I still prefer running workshops to talks because I can improvise and go with the energy in a completely different way than on stage.

Stay tuned for my 5th and last post.

# 2018 in retrospect – PART 3

2018 in retrospect – Part 2

## Volunteering and community involvement

AST

In 2017 I was elected as one of the directors of the Association for Software Testing (AST) board. This is now my second year as a board member and this year I am also VP of Marketing. Though there are some tasks that are focused around the board my main involvement for AST has been focused on CAST which is our yearly conference.

CAST 2018

Just before I was elected as a board member I had been asked to be the program chair for CAST 2018. As the program chair for CAST you are the one deciding the theme and putting the conference program together. I decided to take help from three persons to review the papers. The review was done blind meaning the name of the speakers were not visible in the first round of reviews. For the final selection the names were revealed as a further input for which papers/speakers made it. Having a blind review with different reviewers was great to get rid of my initial biases.

The theme I chose is something close to my heart. For a longer time I have felt and experienced that there are a lot of misconceptions around testing. The misconceptions around testing are widely spread both within the testing community but even more commonly outside of testing.  A lot of time testing conferences ends up in some sort of preaching for the choir. That is why I chose the theme Bridging between Communities hoping to attract people outside of the usual testing community. As an example I was looking for paired sessions between a developer and a tester. I was also hoping to attract other people from outside of the testing community.

I didn’t reach exactly what I was hoping for but the conference was still a success. We did bridge between communities, mostly between different testing communities but also tapped into UX and dev. People seemed content and happy with the tutorials, the program and the location.

Seriously – a conference just by the sea  with the possibility to watch a rocket launch from the beach in the middle of the night, wonderful competent and interesting people to chat to and network with and of course a great program. What could possibly go wrong?

In fact something did go wrong. Not with the conference but Jerry Weinberg  who have deeply influenced many people in the testing community passed away during CAST 2018. I met Jerry at my very first CAST in 2009 where I attended one of his experiential workshops. After that I also had the opportunity to attend PSL with Jerry, Esther Derby and Johanna Rothman in 2013.

However being at CAST where his spirit and wisdom is passed on to others through workshops and talks like the one Louise Perold ran the same day we found out about Jerry was very emotional. Somehow I am still thankful it happened when I was at CAST, surrounded by so many people who all cherished and admired him. To be able to honor his memory together was a sad but also heart-warming experience.

CAST 2019

Like being the program chair for CAST 2018 wasn’t enough I volunteered as Conference Chair for CAST 2019. The focus is quite different. The Conference Chair is responsible for tutorials and keynotes. This year’s Program Chair is Justin Rohrman the former President of The AST Board so he is in full charge for putting the conference track together. The work is in progress and it is about time that I roll up my sleeves and put some more focus on the conference which will be returning to beaches and rockets in the sunny Florida in August this year. Bringing a conference together is pretty much work and the team that bringing it together is quite small. August is so much closer than you think.

Speaking easy

I am a mentor for this wonderful initiative Speaking Easy which focuses on new voices from the testing community and particularly on women and people of color. Unfortunately this year I have had very little time mentoring but I will focus on my current mentee to help her apply for a conference in 2019.

My takeaways from this episode:

Though I do this as a volunteer like the rest of the people involved in AST I have a constant feeling of not having enough time to do all the things I would like to do for AST and its members. I noticed that being involved in organizing the conference takes a lot more time than I expected and it takes time away from other commitments as a board member.

On the positive side I have had the opportunity to get to travel a bit as a board member. But it is always about finding the right balance between work that gives you food on the table, volunteering and time with the family. To help that balance I brought the family along on one trip when the board gathered in Florida (at my own expense of course). It was nice having them along and then being able to spend some vacation together after the board meeting.

For 2019 I need to find an even better balance.

Stay tuned for next post.

# 2018 in retrospect – PART 2

2018 in retrospect- PART 1

## Clients, career hoping and identity crisis

I’ve been working with four different clients this year. As many of you already know IKEA has been my main client during 2018. During the first six months my role was focused on challenging existing patterns and driving change related to software testing. I had the opportunity to work with some fantastic perseverant people driving changes in software development from waterfall methodologies towards an agile mindset.

A few of the things I accomplished was:

• Enabling moving testers from separate testing teams to be part of the development teams
• Enabling the development teams to take responsibility for quality and testing by removing sign-offs and handovers which provided no value
• Removing (or perhaps minimizing) the focus on test reporting based on test case counting
• Introducing, creating awareness and running workshops on exploratory testing and session based test management
• Influenced the change from war room to collaboration room ( this might seem like a funny accomplishment but I am proud of it – I believe words can both mirror and affect behavior )

These might seem as small steps but in the context this was quite a challenge to get to. And it was just a start towards the right direction.

In June an opportunity emerged within IKEA. A position as Scrum Master became available. It would also mean that I could change two hours of commuting per day to only twenty minutes per day. You might think it was an easy choice but it was a pretty difficult one. In the process I  realized that my identity is tightly connected to software testing. This is where my passion lies and where I have my expertise. On the other hand I have always enjoyed working with teams and individuals to help them bring out the best in themselves and their work.

I took on the role as a Scrum Master with the hope of also being able to coach the team in software testing. For many reasons this did not happen. I had other challenges to focus on and new things to learn.

As I mentioned I had four clients this year. In between driving change at IKEA I did some consulting which involved recruitment of testers. I also advised a client on their testing process and helping them to shift their focus from testing to a holistic focus on quality engineering. The latter client had a very open mindset and I provided them a different way of visualizing their development process. Rather than writing a word document with diagrams I used sketchnote techniques to visualize the organic process that a development process actually is.

The variety of work these two assignments provided was something i enjoyed very much. Getting to work with new people and new contexts is very enriching and brings me new insights and learnings.

In the beginning of the year I had the opportunity to run a one-day training in exploratory testing for a client. This was a lot of fun and is something that I would like to do a lot more of in 2019.

### My takeaways from this episode:

Driving change is never easy. Though this is what I really enjoy doing I realized that I too have a limit. I spent an enormous amount of energy in 2017 and 2018 on changes in software testing. Having the opportunity to do something different from time to time for other clients helped bring me new energy and perspective.

But my greatest learning came from being a Scrum Master. It was during this period I learned that I needed a pause from software testing. I realized this when I did not have the energy left to get involved in testing related topics anymore. From someone who passionately discussed testing with everyone who wanted to join I haven’t even spoken to my team about testing during my last 6 months at IKEA.

I am now ready to get back into the game and I am looking forward to my new assignment next year in Denmark.

Stay tuned for my next post…

# 2018 in retrospect – PART 1

## What happened and what is next?

It’s been a while since I did a review of my year. In fact last time I did it was five years ago. It’s scary how time just flies by and you find yourself so caught up in the presence and the future that you don’t give yourself the time to reflect on the past to learn from your actions. So it is time to pause even it is only for a few hours to reflect upon 2018.

To help me process my thinking I drew this timeline:

### Entering unknown territories

Filled with fear and excitement I entered unknown territories in the beginning of this year when starting my own company Black Koi Consulting. One of the reasons for this decision was to be able to have the freedom to choose where I want to spend my time. To be my own boss is something that fits me very well. I had already decided to only use 80% of my “working” week on clients, meaning I often spent Fridays on other things.

This being my first year with my own company I spent my “free” time on things related to my company or things related to the testing community engagement that I have. I also took time to have lunch with new people and old friends and colleagues. Most Friday mornings I went to the gym and I picked up my children early in the afternoon to be able to spend some extra time with them.

#### My takeaways from this episode:

I’ve had the opportunity to learn quite a few new things around accounting, marketing and websites. Realizing I don’t enjoy accounting very much and that it takes too long time to do it on my own I have decided to let someone else do the work.

My patience was challenged when I learned Inkscape to create my company logo. If you have ever tried to use the program you probably understand the frustration I felt from time to time. But it’s free and it is a really advanced tool to create vector graphics. I am very proud over the logo. It’s a special feeling having designed and created it yourself, specially when someone likes it.

In 2019 I will give my website a bit of love. I applied what I preach and launched an MVP to be able to get some information out there. Specially since I am offering training by Richard Bradshaw and Mark Winteringham in 2019 and I need somewhere for people to go to sign up for the training. It was actually pretty hard to launch a microsite and adding to it iteratively. It wasn’t related to skill or technically difficult but personally really challenging. I am sometimes a perfectionist but over the years I have learned to strive for best enough and iterate my work. This is also why this is the first post of several in the series of 2018 in retrospect.

Stay tuned for my next post…

2018 in retrospect – Part 2

# I found it!

PART 3 – of a short series around creative thinking and testing

There it was. Monday, the day before the workshop and an entire day of work meetings and fire fighting before I could put my workshop together. There would be no room for pondering any ideas during the day.  Once back home I locked myself into my small working room with a pen, a paper and a laptop. I scribbled, I tinkered with some of gadgets for my exercises, I went through my stash of stuff I use for teaching, I drew some pictures for my power point presentation and put it together.  Four hours later I was satisfied with what I had come up with and I could finally go to sleep.

Notice how I did not say that I was done. I am never done but I had a good idea of how I would proceed with my workshop.  On the morning before heading to the conference I tossed down some extra stuff in my bag in case (coloring pens, paper, puzzles etc) I would have new ideas popping up in my head for my workshop.

When I got to the venue and had a look at the room for where I would run my workshop I got the shivers. The room was set up with chairs in rows all facing a huge white board where I was expected to project my presentation. This was not setup for creativity so my first job was to change the layout of the room to create a playful space.

I believe the workshop was a success. I had a lot of fun myself, came up with an exercise on the fly and enjoyed the vibe and energy in the room.

So how did I get from a void of ideas and a loss of motivation and energy to a room full of movement, talking, drawing, laughing and test idea generating? Was it magic?

# Where did my creativity go?

PART 2 – of a short series around creative thinking and testing

Part 1 – Boosting your creative thinking

With only a few days left to the workshop and a void of ideas I was starting to get slightly worried about my abilities to come up with anything. I did have a few old ideas up my sleeve but I wanted to do something new and something different. Something I hadn’t done before. I did buy some stuff online which I thought I might have use for, like empty cards to write on and some Marvel Avengers Trading Cards. I do keep a stash of things which might be of use in workshops I design.

However I was exhausted after long working days and could not find any inspiration or energy to immerse in designing my workshop. On top of this I had a company gathering coming up which would keep my weekend busy.

Part of my process is to bounce off ideas with other people. I decided to use the Open Space we created at our gathering to facilitate a discussion on creativity and testing, particularly in how people come up with test ideas. It fit very well with my colleague Carsten’s topic on “Getting creative on demand” so we decided to combine our sessions.

My main takeaways from that discussion were the following:

• My colleagues shared following regarding how they come up with test idea:
• Visualizing by mapping the system
• Using personas
• Collaborate with a colleague
• Using the rubber duck method – talking out load
• Using different heuristics
• Discussion around getting creative on demand
• You need space and time.
• Difficult to be creative on demand.
• You can practice to be prepared when the demand comes up
• One colleague shared how he keeps notes of all kind of things, fragment of conversations, ideas which come up etc.
• Learn how you get creative – your natural mode
• Talking
• Writing
• Moving
• Focus or defocus

The discussion was interesting though I didn’t discover anything which I did not know or had experienced before, except a tip on a video on creativity by John Cleese.

When coming home from the gathering I still did not have the energy to design my workshop. Our gatherings are very intense, but in a positive way.  Instead I decided to watch the  video tip and read some blog posts on creativity. That was Sunday evening and barely two days before my workshop.

On Monday I woke with a twitch. It was crystal clear why my creativity had disappeared. Understanding this, my energy came back as well as my creativity. I was ready to design my workshop!

Part 3 – I found it!