Magnifiant: exploring software testing

How you can build skills and grow using your mindset: Mindset part 4

August 31, 2020 / / 1 Comment

This is the last part in a four-part series of blogposts on mindset. In part 1 (Mindset – The book) Nicole and I summarized the book “Mindset”. In part 2 (Looking Back on Perfection and Burnout), we talked about how we suffered from our fixed mindsets. In part 3 (Dealing with mindsets), we shared stories on how we dealt with our mindsets. In this last blogpost we want to help others deal with their own mindset. We share how you can find out what mindset you have and how can you change a fixed mindset into a growth mindset.

We know that mindset is important. A growth mindset is the key to success and more happiness. Or as learner lab taught us “Skills are built, not born.” People are designed to continuously improve! Absolutely everyone has the capacity to be better at virtually everything!

Growth mindset makes you a better and happier person

Research shows that if you have a growth mindset you will be more self-confident, you will allow yourself to make mistakes, you will ask for help more and you will believe it’s okay not to know something. This helps you to be a better learner because you will actually be learning from the feedback and criticism you receive. You also learn to deal with setbacks and you will not give up as easily. This makes you more resilient, will reduce stress and will help to improve relationships because contact is deeper. All of this will make you a better and happier person.

So, what about you? We advise you to learn about mindset. After that, do an introspection to learn about your own mindset. With this knowledge you can deal with your mindset and take steps to change it.

Learn about mindset

First and most important: read the book (or our summary here). The book is easy to read and contains many examples that will give insight in how fixed and growth mindsets work. These visuals also give a bit of understanding about how fixed and growth mindsets work:

Graph by Nigel Holmes (http://nigelholmes.com/)

Graph by Learner Lab (https://thelearnerlab.com/growth-mindset/)

There are also many videos you can watch. On the website of Mindset Works you will find a page full of links to amazing videos.

One of the most important things to take away while learning about mindset is simply the fact that traits are not fixed and that you can, in fact, teach an old dog new tricks! We are not born with a finite amount of intelligence, a fixed personality, or a certain amount of artistic talent. Everyone can change and grow – and that opens up a world of possibilities.

Determine Your Mindset

After learning about mindset, it’s time to determine your own mindset. Which mindset do you have? Remember that mindset can differ in different situations. It is perfectly possible that you have a growth mindset in one situation and have a fixed one in other situations. Our mindsets are constantly shifting and changing. There are several tests online you can take to help you gain insight. On the website of Mindset Works, you can find this one. In the book you will find a test too:

Answer these questions about intelligence. Read each statement and decide whether you mostly agree with it or disagree with it.

  1. Your intelligence is something very basic about you that you can’t change very much.
  2. You can learn new things, but you can’t really change how intelligent you are.
  3. No matter how much intelligence you have, you can always change it quite a bit.
  4. You can always substantially change how intelligent you are.

Questions 1 and 2 are the fixed-mindset questions. Questions 3 and 4 reflect the growth mindset. Which mindset did you agree with more? You can be a mixture, but most people lean toward one or the other. Now look at these statements about personality and character and decide whether you mostly agree or mostly disagree with each one.

  1. You are a certain kind of person, and there is not much that can be done to really change that.
  2. No matter what kind of person you are, you can always change substantially.
  3. You can do things differently, but the important parts of who you are can’t really be changed.
  4. You can always change basic things about the kind of person you are.”

Here, questions 1 and 3 are the fixed-mindset questions and questions 2 and 4 reflect the growth mindset. Which did you agree with more?

(Source: Carol Dweck. “Mindset – Updated Edition: Changing The Way You think To Fulfil Your Potential)

Changing your mindset

“The key to changing your mindset lies first and foremost in self-awareness”, says Scott Jeffrey of CEOsage, who published a great self-help guide called “A Complete Guide to Changing Your Fixed Mindset into a Growth Mindset“. And we totally agree. We suggest you to begin writing things down on a regular basis, a process called journaling. In this blogpost written by Huib you find more information about reflection and journaling. How do you react in certain situations? What do you feel? What is the inner dialog going on inside your head when a particular situation arises? Write down your observations. It helped us to recognize patterns and feelings.

In our experience after finding out about the importance and influence of mindset, we dealt with our mindsets better. Also learning about neuroplasticity made us see that there is a way to change our mindsets. It is important to do an introspective to find out in which situations your mindset is fixed and not helping you. It opens up possibilities to change and grow.

Step 1: in the book Dweck advises us to accept that we all have both mindsets. The first step is to recognize and embrace your fixed mindset.

Dweck suggests to give the persona a name. And we think it is actually a good idea we had never thought of. Huib named his fixed mindset “Randall Flagg” after the villain from Stephen King’s book. Also as a pun to flag when his fixed mindset pops up. Nicole named hers “Marie”, which is her middle name. It helps remind her that her fixed mindset is always there, waiting to appear.

Step 2 is to learn what triggers our fixed mindset. Failures? Criticism? Deadlines? Disagreements? When is your fixed mindset a problem? Understand what happens to you when your persona shows up. Learn about yourself, your feelings and the fears that activate it. As you come to understand your triggers and get to know your fixed mindset persona, don’t judge it. Just observe it.

Step 3 is to recognize that you have a choice. Remind yourself that it is “just” fear. Your beliefs and your thinking are sabotaging your growth and giving you stress. When you recognize your fixed mindset, remember it is just a mindset. And mindsets can change. Accepting your fear will make it easier to deal with it.

Your brain can change due to neuroplasticity. Neuroplasticity is the ability of the brain to undergo changes. Research shows that many aspects of the brain can be altered (plasticity means changeable) even through adulthood! Actually, our brain is built to change. By practicing, you can change the pathways in your brain. Watch this video or read this article to learn more.

 Step 4: the last step is to switch to a growth mindset when those triggers occur. Here it is key to understand that it is all about how you think. Your belief is the most important factor. Focus on what you learned about mindsets. Hold the belief that you can change your mindset. Learner lab taught us: to build a growth mindset, focus on the belief, and the actions will follow. Challenge the fixed mindset persona by asking questions to guide your thoughts. Open yourself up to growth. Take small steps. Don’t expect too much and realize it will take time and effort to change your mindset. Experiment and try different approaches. Find a way that suits you.

Scott Jeffrey made a great list of questions that might help you activate a growth mindset:

  • What can I learn from this?
  • What steps can I take to help me succeed?
  • Do I know the outcome or goal I’m after?
  • What information can I gather? And from where?
  • Where can I get constructive feedback?
  • If I had a plan to be successful at [blank], what might it look like?
  • When will I follow through on my plan?
  • Where will I follow through on my plan?
  • How will I follow through on my plan?
  • What did I learn today?
  • What mistake did I make that taught me something?
  • Is my current learning strategy working? If not, how can I change it?
  • What did I try hard at today?
  • What habits must I develop to continue the gains I’ve achieved?

When you are facing a problem or situation that you are trying to apply a growth mindset solution to, Dweck suggests to make a concrete plan: “These concrete plans (plans you can visualize about when, where, and how you are going to do something) lead to really high levels of follow-through, which, of course, ups the chances of success.” Once you have that plan, stick to it.

Change is hard

Remember that change is hard. We make changing your mindset sound easy on paper but like any other change, it is a journey. It doesn’t happen overnight. You will have setbacks. The key is to approach these setbacks using your growth mindset: what can you learn from them? What will you change the next time you are in the same situation? Adjust your growth plan as needed. You will also have successes. Learn from them as well! What can you take away from them to continue to grow? Keeping setting goals for growth. If one approach doesn’t seem to work, readjust and try another.

Keep at it. As Dweck says, “Mindset change is not about picking up a few pointers here and there. It’s about seeing things in a new way.” Keep taking the growth-oriented action. Eventually with time and repetition, it becomes habit. Changing your mindset takes effort, but it will open up all sorts of doors to new opportunities.

We love to hear from you

Good luck working on your mindset. We are curious to learn how it goes for you. If you want to share your stories, need some help or just want to talk, let us know. We are happy to talk to you! Find us on Twitter (Huib and Nicole) or LinkedIn (Huib and Nicole). Start today, don’t think it will get better by itself. Because it won’t. It requires work. A lot of work. But it will make your life a whole lot easier. If you need some support in your journey, just reach out.

Resources:

Dealing with mindsets: Mindset – part 3

August 11, 2020 / / 1 Comment

In our first blog post in this series on mindset Nicole and I summarized the book “Mindset” by Carol Dweck. In the second blog post “Looking Back on Perfection and Burnout” we shared our personal history with growth and fixed mindsets. This blog post we talk about how we dealt and currently deal with our mindsets. We also talk about how we changed the way we think. 

Nicole’s story:
When Huib suggested that in the third part of our blog post that we talk about how we started to change our mindset, I knew that it was going to take a bit of work and a lot of reflection. The shift in mindset for me was not necessarily a conscious effort until, of course, I read the book. For me, the shift started with a burnout…and with therapy.

As I mentioned in the previous blog post, I used to work in a forensic crime lab. The training I went through was intense – they make it harder than it really is because then you are prepared for everything that might come your way. But looking back, I think that training exacerbated my already perfectionistic tendencies. I had to do everything right or a case might get thrown out. I put a lot of pressure on myself to not make any mistakes. As you might imagine, this caused an intense amount of anxiety in my life. There were days I had to go down to my car in the parking lot to just get away from work for a bit. While I was in the car, I would break down and cry. At some point, I realized that this wasn’t healthy – I couldn’t go on living my life like this. I needed to make a change.

At the same time, I had started going to therapy. This was not the first time I had been in therapy – I had been in it in the past to deal with some issues with relationships in my life. But this time I was in to try to deal with my anxiety – I was diagnosed with generalized anxiety disorder and started medication in addition to the therapy. One of the most important things I discovered during therapy was my need for people’s approval. I held the belief that everyone should like me. The most profound insight and driver in the change in the way I thought was a simple question posed to me by my therapist: “Do you like everyone?” And of course, I said no. To which she said, “Of course not. And not everyone is going to like you.” That message struck a chord and has stuck with me. There’s no need to try to prove myself to people, or even to myself. Trying my best and doing the right things in life were all I needed to do. I won’t say that I don’t still think about people’s approval – as with anything, it is a life-long learning curve. But I sure care less about it now than I did back then. I think that was the first step on my journey of shifting away from a fixed mindset.

The second step goes back to that change I said I needed to make in my life. I decided to go back to what I originally wanted to do in life, my true passion: work with animals in some capacity. So, with the help and support of my partner, I changed my hours at the lab to part-time and spent the other half of my time volunteering at the local zoo. Soon that transitioned into a part-time zookeeping job that eventually led to the job I’m in now – a combination of computers and animals, two of my favorite things. I love my job. And I think part of the reason I am not afraid to fail and take on challenges in this job is because of how much I love it. I know I have room to grow and I want to continue learning. Instead of worrying about negative feedback, I seek out feedback so that I can learn what I need to improve upon. I think finding something I truly enjoy was instrumental in starting to move towards a growth mindset and leaving the negative parts of perfectionism behind.

The “last” step of course was reading the book Mindset. Learning about mindset – putting meaning to what it is, what it drives, where it comes from – brought everything together. This lead to the awareness of having a fixed mindset in certain situations, but a growth mindset in others. My mindset change is still very much a work in progress. But now I have the advantage of knowing that it exists and am learning what things tend to trigger my fixed mindset so I can work on taking on those situations with a growth mindset instead. I think at one point in time I would have said that there are certain things you can’t change about yourself – perfectionism being one of those things. But now I think while my perfectionism may never go away, I can change how it drives and affects me. I think you can strive to be your best, and even strive for perfection, as long as you realize perfection is impossible to achieve. But it can motivate you to work hard and aim high, as long as you can use your setbacks and failures as learning experiences on the path to get better. I think that is what having a growth mindset is all about – being willing to take risks and embracing challenges in order to learn, grow, and become better. I look forward to seeing where my growth mindset can take me. 

Huib’s Story:
Changing your mindset is hard! But it starts with recognizing that your mindset is getting you into trouble in the first place.

My journey in dealing with my fixed mindset started when I was 27. Before that, and especially in my teens, I had many depressions caused by low self-esteem and making myself crazy with thoughts. My father and his partner took me in their house when I had my burn-out in 1997. I stayed with them for 3 months and took my first steps in adult therapy and dealing with my mental issues. I got therapy from a nice psychologist who helped me recover from my burn-out. I didn’t let him too close because I was afraid of what would surface and thus, nothing really changed. After a while gradually my old thoughts and behavior came back.

When I grew in my career into lead roles and later into management positions, I ran into more problems. I became responsible for the work of more people and my perfectionism made me feel bad if they underperformed or did not succeed. I wanted others to not make mistakes and by mentoring and coaching them, I tried to help them – sometimes literally inflicting help upon others. I struggled with self-esteem and my mind was always busy. As a pretty emotional person, I had to deal with my emotions. But I felt that emotions were stupid: I told myself I shouldn’t be influenced by them. So I was hiding my emotions constantly. I fooled myself that it’ll go away on its own when I knew it wouldn’t. I’m good at making others believe that I’m okay.

Because I knew how to recognize my dips, I didn’t become as depressed as I used to before my burn-out; a sign that I was learning. I had a sort of periodic cycle of being too busy, stressed, and taking on too much work that caused me to not sleep very well. Because of not getting enough sleep, I wasn’t able to control my negative thoughts, which made it worse and got me even less sleep. After a couple of weeks, I would be drained. I often would call my doctor to get some sleeping pills. This would help me sleep well for a week or two and that was just enough to get my thoughts under control before sliding into another burn-out or depression.

This went on until I became manager at a bank, where I ran into trouble when things would get difficult. I couldn’t deal very well with resistance or situations where things didn’t go the way I wanted them. I had trouble dealing with feedback and I became defensive quite fast. If people would ask a lot of questions about my proposals, it felt like I wasn’t clear enough and I blamed myself for this. My manager recognized this was happening and he suggested coaching. My coach helped me a lot with dealing with resistance, reaching goals, dealing with emotions, being okay with not knowing stuff, and acting less defensive, amongst other things. My coach recommended me to take therapy and deal with my underlying problems. He was right, deep inside I knew that, but I got scared and stepped away. I told myself I didn’t need to work on my myself anymore since things at work had improved quite a lot.

In 2015, I got an assignment as an interim manager at a financial service company. I had a huge team of 100+ people with too many direct reports. It was a challenging organization with a toxic management culture. I worked extremely long days because I wanted to prove myself and at home, I was preparing meetings for the next day. After a two-week holiday, I came back to work with my battery not fully charged and a new burn-out was approaching fast. I hit the brakes just in time, so I recovered in a couple of weeks instead of months. In my recovery, I went to see a haptonomist. She helped me recover from the burnout and after that, I stopped seeing her. A year later I went back to her because I needed to get rest in my head. I was getting sick and tired of always being busy and not being able to turn my head off. I tried mindfulness, and of course people recommended things like meditation and yoga, but that didn’t feel like it was something for me. I told myself it was too vague and wooly for me. My haptonomist taught me to sit still and do nothing for a while. After working with her, I was able to just sit and not react to anything happening around me.

Being able to do that helped a lot and I felt strong. Until a while later the cycle started again: too much stress, bad sleep, etc. So finally in 2019, I took a big step in dealing with my issues (see: blogpost “mastering my mindset“). I finally was done with my mental issues and ready to face the underlying problem. So I decided to go for therapy. I wanted to learn how to deal with my insecurity, my fear of failing and to get rest in my head. Looking for a therapist, I wrote down my issues and the things I wanted to change. I also wrote my “mental resume” with the issues I dealt with in my life and what I had done to overcome them. This gave me a lot of insight into myself. I saw a pattern of dealing with symptoms instead of dealing with the real problems, running away when things got too hard, and a lot of fighting. Fighting with myself, but also fighting and pushing other people, which had brought me problems several times in my career.

My therapist made me work hard and I reflected on many things. I learned that mainly it was my (negative) thoughts that were getting me into trouble. Reading the mindset book helped me understand where my fear of failing came from. In therapy I learned where my problems come from and I got enough insight to work on them. I learned to accept myself as I am and to let go of the past. I know what I still have to work on in myself in the future to reduce my fear of failure.The most important lessons for me are: being authentic is important. It saves a lot of energy if you can just be yourself. Emotional intelligence is key to dealing with your mindset. It helps understanding, expressing and managing emotions. I had to change my thinking and behaviour and in doing this, I ultimately changed my mindset. I am working on being vulnerable more often and showing empathy to build trust and relations which helps me to be a better teacher and coach but also a better person.

These positive emotions help me to think more clearly and be more present. I became a better listener, showing more interest in others, asking better questions and being more open to learning about others’ experiences. I am more self-aware and that is a good starting point.

“You have to name things in so many words. Something must be allowed to exist first and then leave it behind.”
(Griet op de Beeck in Dreamschool)

How do you find out what mindset you have and how can you deal with a fixed mindset? In our next blog post we will talk about that.

Looking Back on Perfection and Burnout: Mindset – part 2

August 3, 2020 / / 3 Comments

In our last blog post Nicole and I summarized the book “Mindset – Changing the way you think to fulfill your potential” by professor Dr. Carol Dweck. In this blog post we share our personal history with growth and fixed mindsets. How we currently deal with our mindset and how we changed the way we think, is the topic for our next blog post.

Nicole’s story:
Looking back to my school days, probably from early primary school all the way through undergraduate college, when it came to my education, I had a very fixed mindset. I think the same was true when I played sports, which was mainly in secondary school. It was about getting good grades and winning the game. While reading Mindset, I reflected on this and where my mindset might have come from. Was it my parents? Teachers? Coaches? Dweck talks about the types of praise we give children – she says “Praising children’s intelligence harms their motivation and it harms their performance.” Instead, we should praise effort, persistence, and good strategies.

I don’t know how my mindset exactly got formed, to be honest. My parents never pushed me to be perfect in school or sports, and if anything, they were constantly telling me to not be hard on myself. If I was upset at losing a game, they were the first to remind me how hard I played and that I gave it my best effort. Was it my teachers? Maybe some of them. Our educational system (speaking in my case about the United States) definitely rewards good grades and test scores. Want to get into a prestigious college program? Better get a high GPA and test score on your ACT/SAT. So I pushed, and I did it. And then I got to college and I thought, now you can’t expect to get straight A’s because it is so much harder. But then I got straight A’s my first semester, and the same mindset of “you have to keep doing that” set in. Only it WAS harder in college and took much more effort to keep it up. This lead to a large amount of stress and anxiety so bad that my stomach would flop as soon I came back into my college town after a break. Looking back, there was so much more I could have actually learned in college and certainly had more fun doing so had I not been so focused on perfection. 

I think my fixed mindset continued into my first job. Not to get straight A’s of course, but to maintain perfect. To make no mistakes. I worried about making the slightest mistake because I worked in a crime lab – a mistake could mean that a criminal might get away. It wasn’t until I burned out (surprise) and switched careers to something I loved that my mindset began to change. I finally realized that striving for perfection was not only impossible, it was causing me more harm than good. Now, I truly love both learning and my job. I don’t expect myself to know everything or to never make a mistake. I crave problems and figuring them out – I think I always did, but now there is only joy with no anxiety mixed in. Of course my fixed mindset is still here, lurking, and pops up in certain situations. Reading the book helped me realize that and now that I’m more aware of it, I want to embrace it and lean into those situations to encourage my growth mindset to take over. I still have a lot of growing left to do but I’m confident that embracing the growth mindset I have found will help me get there.

Huib’s story:
As a kid, I grew up in a pretty competitive environment. Both of my parents were very competitive and my brother and I were also always competing with each other. I was a smart kid and in school I was one of the top performers. I was also a very curious kid and I had a broad interest and read a lot. Unfortunately, I had too much energy and got distracted pretty fast. That made me not one of the most popular people in elementary school. I guess I had to prove myself in another way. Being the smartest or the best in class was important to me. I wanted to prove that I was smart all the time. It made me unhappy and it made that I was a sort of geek. I am not sure how I was praised back then. All I can remember is that I was a bad loser and I was focused on results and wanted to be seen.

I also developed a big “defensive” wall around me. Scaring away from things that I felt I could fail and over-shouting myself to show the world how invulnerable I was. I became good at talking myself out of dangerous situations where I could fail making a fool out of myself. I made other people believe I had it all under control. As said in my earlier blog post “mastering my mindset“, people perceive me as extremely confident and fearless and it started right after elementary school were I developed this incongruent behaviour. The results were that I got seriously depressed once or twice a year, dropping out of school for sometimes two or three weeks.

I remember doing central exams in High School. They made me super nervous and literally made me sick. Those weeks were horrible for me. Each morning I woke up not being able to eat or drink and anything that I would eat or drink would come out not long after. My fear of failing in combination with a fixed mindset telling me I had to get good grades was killing me. I graduated without taking any re-exams, but only because my grades were very good before taking the central exams.

In sports, I had the same mindset. I had to be the best in everything I did. My father taught me and my brother to play chess. But after a few years, my brother became way better than me and I quit playing because it was not fun anymore. I was a keeper at (field) hockey and here my “not wanting to lose mentality” kicked in driving me to be better. I became keeper in the first place because that way I could not be compared to other people on the field, a safe choice. I remember standing in the goal with tears in my eyes because the opposing party scored a goal. I told myself that I had to be perfect. No ball should pass me, which of course is a crazy thought.

Asking for help has often been a thing for me during my career. When I started working, I had to be good at what I did. Asking for help I considered to be a sign of weakness. This caused a severe burn-out when I was 27. I was developing software and I was responsible for everything: design, coding and testing. There was no team, I was the team, and the customer wanted a lot of new things. In stead of asking for help, I started doing overtime. This resulted in a lot stress, which made me sleep worse. After a couple of months, I couldn’t go on anymore and I collapsed.

Even recently when I took guitar lessons for a year in 2018/2019, my fixed mindset kept showing up. I kept asking questions to my teacher to keep him talking and playing instead me playing for him. I used excuses not to record my playing (which was a regular part of what he did with other students) and I didn’t really enjoyed practicing. Playing a musical instrument makes mistakes very easy to spot, you hear them instantly. My perfectionism and fixed mindset concerning playing guitar made me eventually stop playing. I will pick it up later, because I like playing music, but back then it just didn’t really work for me.

Currently I think I have a combination of a growth and a fixed mindset. My growth mindset is getting more and more dominant and I like that. I worked hard on my mindset and it’s paying off now. Because of my learning about mindset, I am able to recognise when my fixed mindset shows itself. When that happens I take a step back and reflect on why this mindset is there and what caused it. Often it is system 1 (ref: Daniel Kahneman  Thinking Fast vs. Thinking Slow), a learned habit possibly linked to a fear deep inside myself. But eventually I am learning how to deal with it.

In our next blog post we will talk about how we currently deal with our mindset and how we changed the way we think.

Mindset – The book: Mindset – part 1

July 26, 2020 / / 4 Comments

I am fascinated by mindset. As a lifelong learner I have read piles of books, done many courses and been to over a 100 conferences. When I started coaching people I learned about the power of thoughts. I took a learning pathway in coaching that consisted of 15 days training in a two year period and I learned about how to be a good coach. But I learned even more about myself. In 2019 I started working with bureau Idee and learned how to work on my own mindset. Until then I never fully realised the impact of my thoughts and inner beliefs on my behaviour and mental health. You can read more about that journey here on my blog.

One of the most interesting books I have read is “Mindset – Changing the way you think to fulfil your potential” by Professor dr. Carol Dweck. Me and my learning buddy Nicole Errante read the book together as part of our learning pact. This blog post is our summary of the book. In our next blog post we will discuss our personal experiences with growth and fixed mindsets.

Summary Mindset

Mindset is a way of thinking, a mental attitude and self-conception that you carry with you through your life. People are all born with a love of learning, but somehow, somewhere in our lives it gets undone for some. Some people love challenges, others hate them. This is caused by their mindset. Carol Dweck researched human motivation. Why do people succeed? She found out that mindset plays a big role in creating the love for learning and resilience. Our conscious and unconscious thoughts and beliefs affect how we perform. Changing our beliefs can have a powerful impact.

Dweck talks about mindset being a belief about yourself. Through her research, she discovered there are two types of mindsets: the fixed mindset and the growth mindset. In the fixed mindset, people believe that the qualities they possess (such as intelligence or personality) are set in stone. But in the growth mindset, people believe that their qualities are capable of changing through effort, strategy, and help from others. Why is this important? Your mindset affects how you deal with life and the challenges that come along with it. When you are in a fixed mindset, you want to look smart, you are trying to prove yourself over and over. Taking on risks means being vulnerable to failure, and that is not acceptable. Any perceived deficiencies in yourself must be hidden. So you simply avoid risks and stick to easy tasks you know that you can accomplish. You give up easy and get defensive often. But with a growth mindset, you welcome challenges as an opportunity to grow and learn, even if you fail. Inadequacies are seen as something that you can work on and overcome. Even in the growth mindset, failure can be a painful experience. But it doesn’t define you. It’s a problem to be faced, dealt with, and learned from, which makes you more anti-fragile.

In business, leaders with a fixed mindset don’t listen to others and they make subordinates feel bad. They want to feel powerful by highlighting their own superiority. So instead of trying to make good products or services, employees want to please the leader. This can result in the whole company having a fixed mindset. This kills creativity and innovation. It will cause groupthink; group members conforming to group values. Everyone in a group starts thinking alike. Nobody disagrees with the leader. In personal relations, mindset is also important. People with a fixed mindset think that good relations do not need work; they expect their partners to know what they need without talking or asking. They perceive feedback or rejections as proof of their bad personality, where people with a growth mindset work on the relation based on the feedback they get. When people in a growth mindset have a fight, no partner gets full blame in the dispute. They work together to solve the problem.

The beautiful part is that you can change your mindset. It is, after all, just a belief and beliefs can be changed. Dweck does remind us that changing your mindset is not like a knee replacement – you don’t just swap the bad knee (fixed mindset) for the good one (growth mindset). “Instead, the new beliefs take their place alongside the old ones, and as they become stronger, they give you a different way to think, feel, and act.”

How do you build a growth mindset? It starts with accepting that we all have both mindsets! Learn to recognise what triggers our fixed mindset. Failures? Criticism? Deadlines? Disagreements? As you come to understand your triggers and get to know your fixed mindset persona, don’t judge it. Just observe it. Give the persona a name. Then understand what happens to us when our fixed mindset persona is triggered. This will provide insight in the feelings the fixed mindset triggers and the fears that activate it. The next step is to learn to remain in a growth mindset when those triggers occur. Then continue to find opportunities to learn and grow.

Also her TED talk “The power of believing that you can improve” is very inspiring:

How do you build a growth mindset? This video “Developing a Growth Mindset with Carol Dweck” gives some clues:

In our next blog post we will discuss our personal experiences with growth and fixed mindsets.

Do we need testers?

May 17, 2020 / / 2 Comments

The first version was first published on linkedin on February 5, 2020 titled “Do we need testers? No! Do we need skilled testing? Yes!”. I added my new insights to this blogpost.

Last week I did a talk at Agile, Testing & DevOps Showcase in Amsterdam. My topic was “Testing in modern times“.

In agile and especially DevOps approaches the motto is: automated everything! Companies like Facebook claim they do not have testers at all. Microsoft only has SDET (software development engineers in Test), other companies are T-shaping developers to do the testing. New kid on the block is AI and machine learning, that will definitely replace testing I hear people claim. What is really happening globally?

Do we no longer need testers? I am not sure anymore. Why? Because testers have a bad name. If you cannot automate nowadays, you are no longer valuable, people say. That makes me sad. I think skilled testing is super important! Testing informs decisions about value, quality and risk by learning about the product (and a serious professional tester also will give you insight in the status of the project or team they are working in). Modern technology and tooling is reducing the need for dedicated testers. Not by replacing testers, but by reducing certain types of risks we used to test. More and more people are getting obsessed by “automate everything”. Sadly even some testers I meet are obsessed by trying to automate everything they do…

How can we make valuable software for our clients? I believe that personal leadership and collaboration ultimately makes the difference. The quality of software is crucial nowadays. Therefore I like to focus on an integrated quality approach. As a tester, a mentor and a coach, I help people and teams learn effectively and continuously develop with attention to sustainable adaptability that leads to improving (team) results and way of working. It enables teams to create more customer value by building quality solutions!

In IT we need insights in risks. Risks and value. For that we need to learn continuously. And I think we need smart people who do skilled testing, determined to find problems that matter. Teams need to create insight and overview in the risks we take by creating, releasing and using (IT) products. Often people with excellent testing skills excel in doing this… I hear new job titles as “Quality coach” and “Quality Engineer”. Is this the way to go? Well if that solves the problem of “automation obsession” and a lack of testing skills in teams? I am game. 

So far the original post on linkedin. Recent events make me doubt if we ever get to a point where we do not need dedicated testers.

Dan Ashby reacted on linkedin:

"It's a really interesting question. My take: yes, we need testers... because we need skilled testing, and the Dev communities haven't kept up with what skilled testing is and how to do it. One thing too: Facebook use offshore testers (lots of them via a tester contracting company - I know people that work at FB and at the 3rd party testing company). Also MS have done a U-turn too, and they also employ testers again as well as SDETs. They also have test manager roles again too. Maybe lots of the big companies have hit that realisation that they needed good testing (and hence needed the testers who have those skills)? If so, hopefully the smaller companies that tend to imitate the big companies will soon follow suit. 😁"

I like what he says here: “we need testers… because we need skilled testing.” Although there are some developers who have really good testing skills, many are not interested in testing nor learning to do skilled testing. So I think he has a point there. But dedicated testers alone do not solve the problem. We need better testers and better thinking about testing too! 

I see a huge fixation on “test automation” and this is causing us to lose connection with the human, social purposes of software development and testing. The essence of software development is that during development, we learn about what we need, what the customer really wants and how the product we are building actually works. This is research and development, learning along the way, and needing sense making and feedback to get it right.

This “Vision on the Future of Software Testing” has nothing to do with skilled testing. This shows that even an institute like ISTQB does not understand IT in general nor testing. That makes me so sad!

Test approaches like TMap and ISTQB are neglecting the human aspects of testing. They try to approach testing with mechanistic thinking and are not dealing with the complexity and uncertainty that developing software and dealing with people brings. Leading test experts told me we cannot make testing too complicated or else testers will not understand.

Recently the new TMap book was published called “Quality for DevOps teams”. Reading how TMap deals with risk analysis and test strategy gives me goosebumps. The risk analysis is just a list of quality attributes with a simple calculation (possible impact x chance of failure) and based on the number we assigned a “risk class” (high, medium, low). And based on the risk class we assign the test intensity in dots. See for yourself what it looks like here and here. Now let’s look at some quotes from the book that made my eyes roll.

Chapter 47 “Experience-based testing”

“Exploratory testing is an experience-based approach of testing, the most important approach of experience-based testing in our opinion. We distinguish coverage-based and experience-based testing. Others use terms like scripted testing and free-style testing, but we prefer the division in focus on either experience or coverage.”

All testing that you do uses experience, because there is no way you can shut it off. And doing any test will give you some coverage. I guess they just do not know how to talk about coverage in a way that makes sense.  Why make this strict distinction in only two categories? There are so many more ways to classify test techniques (note: what TMap calls “approach” is called “technique” in BBST).  There is no strict distinction between test techniques. See slide 62 of BBST Test Design “Every test addresses all of these. A specific technique typically addresses 1 to 3 of them, leaving the rest to be designed into the individual test“. Personally I like the way BBST classifies techniques looking at the driving ideas behind the testing.

“The main downside of applying error guessing is the lack of documentation. Therefore, tests are not reproducible. This may result in a developer not being able to investigate an anomaly, the tester not being able to retest a fix, and the test cannot be added to a regression test set.”

Why do tests need to be reproducible? If a tester is capable of telling or showing the developer what goes wrong, you do not need any documentation. I think with enough product knowledge, it is not that difficult to retest. So we are solving a problem in the wrong way, aren’t we?

Chapter 48 “Is there any value in unstructured testing?”

“Any testing lacking a plan containing what to do and what to expect of a system, or lacking preparation of the test, is unstructured. This is also called ad-hoc testing. Some people see a great advantage in unstructured testing because, as they say: “You can start testing right away.” That is, without “losing” any time on preparation.”

The only structure TMap knows is plans and test cases. Structure is “the arrangement of and relations between the parts or elements of something complex”. Michael Bolton wrote about this here. Testing is about learning and learning involves mental models. TMap seems to have no attention at all about how people learn. Deep learning in the beginning is a confusing process, but it gets clearer along the way. By letting it rest (defocus), we give our brains the chance to process the learned information and integrate it with the models we have in our heads. So good (mental) models are important. These “mechanistic test approaches” forget the whole learning part.

“When you have an IT system that is of good quality, the testers do their unstructured testing and don’t encounter any faults or failures. Can they now say the quality is good and that there are no significant risks? Did they really measure the quality and risks? No, the only thing they can truly say is they did “some” testing and didn’t find any problems. However, they cannot explain which requirements or quality risks have been covered. They are not even sure which parts of the system have been covered.”

This is an interesting approach taken by TMap here which is called an “appeal to ignorance”. The testers cannot explain so the approach must be wrong! But is the approach the problem or are skills of the testers the problem here?

7 Rules for Positive, Productive Change – a book review

May 17, 2020 / / 0 Comments

At Agile Testing Days 2019 during the keynote “I can’t do this… alone! A Tale of Two Learning Partners” by Lisi Hocke and Toyer Mamoojee I got inspired by their story about learning pacts. During the keynote Nicole Errante and I started a learning pact too. In our first call we created a plan. One of the books I added to our pact was “7 Rules for Positive, Productive Change – Micro Shifts, Macro Results” by Esther Derby. In this blog post Nicole and I share a summary and our learnings from the book. 

Huib: The book is about change and from the first page on it resonated with me. Esther opens with: “People hire me because they want different outcomes and different relationships in their workplaces. My work almost always involves change at some level…” and that is exactly what I do and have been doing for many years now. While reading and discussing the book with Nicole I recognized so many things from my own experience. The introduction talks about change as a social process! Work and life in general is heavily influenced by social processes and everything we do has major social aspects to it. An aspect that unfortunately often is underexposed especially when people want to be in control. Best practices do not work in complex situations in which we find ourselves in IT often, we know that from the work of Dave Snowden and the cynefin framework. This is why I got so inspired by Context-driven testing years ago. Finally I found people who were taking the human aspects in testing and IT seriously. Not trying to approach (testing) problems with mechanistic thinking, not seeing IT as technology centered, not striving for certainty but being okay with uncertainty and a community where human interaction and feelings played a prominent role in solving problems. This book takes the same approach with change. Change is a social thing. Esther’s book hands you the interventions she calls rules to improve and help change to happen. The rules are heuristics or guidelines that will help change to happen. 

Nicole: Change in life, whether work or personal, is inevitable. The philosopher John Locke said “Things of this world are in so constant a flux, that nothing remains long in the same state.” But we, as humans, tend to be resistant to change; we like stability, routines, and the known. However, maybe we would be less resistant to change if it was implemented in a way that considered this human side of it. That’s one of the things I love about Esther’s book – it constantly keeps people in the focus of the change process. The success of the change is not just about the process but about the people in it. I have been lucky enough to work at the same company for the past 13 years but that means my experience is a bit more narrow than Huib’s when it comes to experiencing change in the workplace. However, a few years ago our company wanted to make the move from a very waterfall-based software development process to one that was more agile. I think most people at my company would agree that the change was more painful and took more time than anyone expected. It is through the lens of that change that I read this book – what could we have done to make the change process better? And what lessons can we learn for future changes?

Summary: The introduction ends with Lessons Learned from a project Esther did. Many of those I recognized and made me want to read the book even more. The lessons are: 

  • Skill and will aren’t always the problem
  • Training is useful and necessary, but it’s not sufficient
  • Standardizing nonstandard work may make matters worse
  • Long feedback loops delay learning and improvement
  • Observed patterns result from many underlying influences

The first chapter deals with change by attraction. If you try to force change upon people, they will react with resistance. Mandating change makes people feel a loss of control and they have no personal buy-in to the change. Esther says “At best, coercion, rewards, and positional authority result in compliance, not engagement…” You don’t want people just going through the motions, you want them actively involved and eager to give things a try. In order for change to happen, things need to be learned and other things need to be unlearned. There is no best practice that works in every situation in knowledge work, quite the opposite: we need to experiment to find out what works and what doesn’t. It is a matter of responding to people, adapting to their needs and attracting and engaging people instead of pushing and persuading. 

  1. Strive for Congruence

Congruence is an alignment of a person’s interior and exterior worlds, balancing the needs and capabilities of self, others, and context. Ignoring other people’s needs and capabilities is probably the most common cause of incongruence. When this incongruence happens, you are in a stress state. When people are stressed, it is hard to think, learn, or engage. You cannot have successful change when learning and engagement are suppressed. Congruence is essential for change by attraction. Congruence contributes to safety, which is essential for people to solve problems, to learn and to speak up about mistakes and things they don’t know. Being empathetic will help you understand where someone else is coming from and what they have to lose by changing, thus avoiding ignoring the context of others in the process of change. Empathy helps people feel safe and understood. Empathy and congruence go hand-in-hand and are essential for making long term changes. At the end of chapter 2, Esther lists a couple of questions you can use to be more congruent.

  1. Honor the past, present and people

When implementing change, it is important to show respect to existing belief systems, the experiences and knowledge people have, and the effort people have made to keep things going with the system currently in place. Build trust and relationships before coaching others. People seldom think that they themselves are wrong. They also may want to improve but most do not want to hear from an outsider that they are doing it wrong. So we have to choose our language with care. Remember that while you have ideas of how things can be better, the people you want to change know things that you don’t know that will be important in this process. By acknowledging and exploring the negative space of change, we prevent unpleasant surprises along the way. Again Esther has a great list of questions to discover what lives in this negative space. People don’t resist change, they respond to its implementation. You can learn from reasons behind the responses to help adapt the change. Use Transformational Communication (inquiry, dialogue, conversation, understanding) instead of Convincing and Persuading (advocacy, debate, argument, defending) to gain openness, trust, and shared understanding. Finally, don’t take for granted what works by only focussing on the problem. Build upon what already works.

  1. Assess what is

Every system is perfectly designed to get the result that it does (W. Edwards Deming). Change starts from where you are now and paying attention to the context increases the change problems will get solved. How did the existing conditions in the organization produce the current patterns and results? This chapter introduces 3 techniques intended to look beyond symptoms and find influencing factors: 

  1. Containers, differences, and exchanges (CDE), it describes the three conditions that determine the speed, direction, and path of a system as it self-organizes. This will help discover both the formal structures and invisible structures that factor into the behavior of the organizational system.
  2. SEEM Model: Steering, Enabling-and-Enhancing, Making. This model shows the different perspectives of people in the organization on the basic set of concerns each company has: how to achieve clarity so people know what to do, what conditions are needed for people to do good work, and what productive constraints will streamline decision making and guide actions and interactions.
  3. Circle of Influences: to see how the factors influenced one another and where to find virtuous and vicious loops. This method helps to find the many influencing factors that result in problems, instead of focussing too much on the problems itself. Find factors that have influence on several others as possible places to run experiments on.
  1. Attend to networks

An organisation has a formal and an informal side. Informal social networks within the organisation have great influence and cannot be ignored, although they are not visible on the org chart. The most important social networks for change are those that people turn to and trust for advice. That is why Esther suggests to map the networks within the organisation to be able to use them productively and not to break them inadvertently. You can also enhance existing networks by reducing the number of hops between people that are not directly connected to reduce bottlenecks. Networks can also carry rumors. Esther suggests to capture them to find out what people worry about using a rumor control board. Finally, if people do not want to change something, just do it with other people that do (change by attraction). The resisters will probably follow when they see that other people are doing it. This is the fear of missing out in action.

  1. Experiment

Solving big complex problems is not easy because many factors are involved and they cannot be solved independently. Trying to solve them in big changes will cause big disruptions and that’s risky. Small experiments foster learning and will engage the people you work with. Experiments are FINE (Fast feedback, Inexpensive, require No permission and are Easy). Landing zones make big changes small by defining intermediate states to which the organisation can evolve. After reaching the landing zone, you can reassess whether your bigger goal is still relevant and course correct as you need. Safe to fail probes are good examples of experiments. Find something that you can try without asking for budget or permission. Don’t worry about failing – keeping the experiment small means any risk should be contained and you can learn from what went wrong. Esther lists a great set of questions to assist in shaping the experiments and another set to test assumptions. Reflecting on what works in the experiments involves double-loop learning. 

  1. Guide and allow for variation

Knowledge work and complex organizations need to allow for variation and emergence to perform effectively. Unnecessary standardization will lead to inefficiency and suboptimal behavior. Coherence is more desirable than consistency and that is why Esther suggests using boundary stories: to help people focus on gaining a similar outcome. Boundary stories give people a guideline on reaching the outcome you want (and avoiding those you don’t) while allowing people to mindfully decide how to get there based on their unique situation. Also change will be evolutionary: small evolutionary steps towards the end goal. Landing zones are useful, so is a horizon map: a thinking tool where you start with the desired outcome and work from right to left filling in conditions and constraints needed for the change to take place. Since change is social, it requires changing habits of thought and cognitive frameworks. Change will happen if we manage to influence metaphors and narratives within the organisation. Explain the outcomes you want and why, then add some boundary stories as a guide to how to get there. This will allow people to refine the change based on their knowledge and experience, thus owning the change rather than being forced into it.

  1. Use your self

People bring their personalities, characteristics, belief systems, and life experiences to work and this influences what they do and how they do it. This includes you, the person involved in bringing the change. Change is a social process which needs personal connection with the people involved. This works best using empathy, curiosity, patience, and observation. These skills can and must be practiced. A nice list of questions to help prompt empathy is given. Esther also supplies nice overviews with types of questions and how to focus questions to be curious and patient. These questions help to avoid why questions, which often make people defensive. The question and how you ask it, determines the answer you get. Making sense of your observations requires bias awareness and testing your observations. Be generous when trying to interpret the motivation behind what people do and the results they achieve.

Learnings Huib

It was fun to work with Nicole and read the book together talking about two chapters each time we met. Sharing our stories and experiences with change and discussing situations at work helped to understand what the book is about and to get ideas where we could try the things we were reading. The parts on empathy, curiosity and patience really resonated to me. Like I described in my blogpost “Mastering my mindset” I become more and more aware that growth, learning, improving and change needs empathy. I am working on that. This book gave me more tools and inspiration to get there. I already used several questions from the lists in the book and I enjoy using them. The landing zones are a great way to create small steps of change. I’m now working on a horizon map with a scrum master to get insight into what is going on in his team. I cannot wait to work with the team on the map.

Learnings Nicole

I agree with Huib that the method we used to read the book a couple chapters at a time and then discussing really was a fun way to read a book.It really helped reinforce the learnings of each chapter as well. Being able to share what we thought and our experiences helped not only make things clearer but also gave insight on where to apply it to our work. When our organization went through the big agile change, the main reason I thought it went rough was that people didn’t understand the reason behind the change. While that is true, Esther’s book also helped me realize there were other factors involved as well. The change we bit off was too big: we should have started where we were at and done smaller experiments to learn and adjust along the way. People’s knowledge, experience, and feelings should have also been considered in order to get them actively involved in the change. I look forward to being able to apply the lessons in this book to future changes in our organization. I also want to incorporate some of the questions from the book to help work through the day-to-day challenges that we face in our team.

Finally

The book is easy to read and has some great stories in there to illustrate the rules and lessons. It has many valuable and ready to use lists of questions and methods that will help in experimenting with change. Every chapter ends with a great set of takeaways which summarizes what you just read in different wording. We absolutely recommend this book to anybody dealing with change in their work.

Mastering my mindset

March 4, 2020 / / 31 Comments

Dutch version is here

People perceive me as extremely confident. One of my personal mentors once said: “you are fearless”. That is only the outside. Inside I am soft and insecure like most people are. I have fears, quite a few to be honest. My behavior and my inside weren’t congruent.

In my life, I like challenges and when I want something, I go for it. In those cases my determination and will to learn or to achieve something are just bigger than the fear of failing. Personal leadership is important in my life. I am trying to become a better version of myself every day. I want to be an even better person. My passion and energy in combination with being a fighter brought me where I am today. But it had a lot of “collateral damage”. Since my youth I have been struggling with depression, low self esteem and restlessness. Over time I got much better in dealing with them. But I still suffer from burn-out and depression complaints and mental health issues once in a while. My pitfalls are: fighting all the time, pushing people too much, going in debates to win, not able to turn myself off. In September 2019 I started a new episode in my life: I started working with Bureau Idee in Haarlem after an anxiety attack. Working with Peter Spelbos was like coming home. He helped me reflect and made me aware of aspects of myself that I have known for long, but never realized the impact of my thoughts and inner beliefs on my behavior and mental health.

On one hand, I am someone who is always ready to help others. A good and dear friend who is very good at his job. On the other hand I am afraid of many things because of my fear of failure in combination with perfectionism. Having a low self-esteem drains energy because you have to deal with the fact that you care about what others think of you. I see patterns where I put on a mask and hide my real self. Another personal mentor told me that “I am good at breaking down the walls of others and with those stones making my own wall higher and stronger”. I find it difficult to make myself vulnerable. I also see a pattern of running away from problems when it gets too difficult. My head is full of negative thoughts, all the time.

But I am dealing with them. Together with my therapist I gained deeper knowledge about myself, my inner beliefs and he helped me reflect on what to work on. He helped me to take matters into my own hands. By writing this, I feel strong and confident that I will overcome my issues and become a better version of myself. I am already reaping the fruits of my efforts.

As a coach, I teach people that vulnerability and self-reflection is important. By sharing this, I want to be a role model and show that having mental issues is okay as long as you work on them. Being vulnerable is nothing to be ashamed of; it is a super power. I believe that personal leadership and collaboration ultimately makes the difference in work and in your personal life. Mindset is the most important thing to become the best version of yourself. Vitality is key in that! To do the best work and to live the best life, physical and mental health are important and they are directly related! I learned that I need to become mentally strong by being less aggressive and more assertive (have a look at this awesome video). I started guarding my limits and borders, reasoning from my position and being less judgemental, becoming a better listener, being more humble and thankful, started meditating and practicing tolerance. I found a lot of inspiration in the Dutch book “Master your mindset” by Michael Pilarczyk.

I am mastering my mindset. I am dealing with it! It feels good and it makes me feel strong.

Watch your thoughts, they become your words
Watch your words, they become your actions
Watch your actions, they become your habits
Watch your habits, they become your character
Watch your character, it becomes your destiny
― Lao Tzu

Meester over je gedachten (Master your Mindset)

Mensen ervaren mij als extreem zelfverzekerd. Een van mijn persoonlijke mentoren zei ooit: “je bent onbevreesd”. Dat is alleen de buitenkant. Binnen ben ik zacht en onzeker zoals de meeste mensen. Ik heb angsten, nogal wat om eerlijk te zijn. Mijn gedrag en mijn binnenkant waren niet congruent.

In mijn leven houd ik van uitdagingen en als ik iets wil, ga ik ervoor. In die gevallen zijn mijn vastberadenheid en wil om iets te leren of te bereiken gewoon groter dan de angst om te falen. Persoonlijk leiderschap is belangrijk in mijn leven. Ik probeer elke dag een betere versie van mezelf te worden. Ik wil een nog beter persoon zijn. Mijn passie en energie in combinatie met de straatvechter in mij, brachten me waar ik nu ben. Maar het had veel “bijkomende schade”. Sinds mijn jeugd heb ik te kampen met depressies, een laag zelfbeeld en rusteloosheid. Na verloop van tijd wist daar ik steeds beter mee te dealen. Maar ik heb nog steeds af en toe last van burn-out en depressie klachten en daardoor psychische problemen. Mijn valkuilen zijn: de hele tijd vechten, mensen te veel pushen, debatten aangaan om te winnen, mezelf (mentaal en lichamelijk) niet kunnen uitschakelen. In september 2019 begon ik een nieuw tijdperk in mijn leven: ik begon te werken met Bureau Idee in Haarlem na een angstaanval. Werken met Peter Spelbos was als thuiskomen. Hij hielp me nadenken en maakte me bewust van aspecten van mezelf die ik al lang ken, maar nooit de impact van mijn gedachten en innerlijke overtuigingen op mijn gedrag en mentale gezondheid besefte.

Aan de ene kant ben ik iemand die altijd klaar staat om anderen te helpen. Een goede en dierbare vriend die heel goed is in zijn werk. Aan de andere kant ben ik bang voor veel dingen vanwege mijn faalangst in combinatie met perfectionisme. Het hebben van een laag zelfbeeld verspilt energie omdat je je druk maakt om wat anderen van je denken. Ik zie patronen waar ik een masker op zet en mijn echte zelf verberg. Een andere persoonlijke mentor vertelde me dat “ik goed ben in het afbreken van de muren van anderen en met die stenen mijn eigen muur hoger en sterker maak”. Ik vind het moeilijk om mezelf kwetsbaar op te stellen. Ik zie ook een patroon van weglopen van problemen wanneer het te moeilijk wordt. Mijn hoofd is altijd vol met negatieve gedachten.

Maar ik ben ermee aan de slag gegaan. Samen met mijn therapeut heb ik diepgaande kennis over mezelf en mijn innerlijke overtuigingen ontdekt. Hij heeft me geholpen na te denken over waar ik aan moest werken. Hij hielp me het heft in eigen handen te nemen. Door dit te schrijven, voel ik me sterk en zelfverzekerd dat ik mijn problemen zal overwinnen en een betere versie van mezelf zal worden. Ik pluk nu de vruchten van mijn inspanningen.

Als coach leer ik mensen dat kwetsbaarheid en zelfreflectie belangrijk zijn. Door dit te delen, wil ik een rolmodel zijn en laten zien dat het hebben van mentale problemen prima is zolang je eraan werkt. Kwetsbaar zijn is niet iets om je voor te schamen; het is een superkracht. Ik geloof dat persoonlijk leiderschap en samenwerking uiteindelijk het verschil maakt in werk en in je persoonlijke leven. Mindset is het belangrijkste om de beste versie van jezelf te worden. Vitaliteit staat daarbij centraal! Om het beste werk te doen en het beste leven te leiden, is fysieke en mentale gezondheid belangrijk en die zijn direct aan elkaar gerelateerd! Ik heb geleerd dat ik mentaal sterk kan worden door minder agressief en meer assertief te zijn (bekijk deze geweldige video). Ik begon mijn grenzen te bewaken en aan te geven aan anderen, vanuit mijn eigen positie te redeneren en minder oordelend te zijn, een betere luisteraar te worden, nederiger en dankbaar te zijn, begon te mediteren en tolerantie te oefenen. Ik vond veel inspiratie in het Nederlandse boek ‘Master your mindset‘ van Michael Pilarczyk.

Ik ben bezig om mijn mindset te trainen. Ik werk aan mijn manier van denken! Het voelt goed en ik voel me sterk.

Let op je gedachten, ze worden je woorden
Let op je woorden, ze worden je acties
Let op je acties, ze worden je gewoontes
Let op je gewoonten, ze worden je karakter
Let op je karakter, het wordt je bestemming
- Lao Tzu

The art of reflection

July 22, 2019 / / 2 Comments

“Once is coincidence
Twice is striking
Three times is pattern”

October 19-21 2018 DEWT held their 8th annual peer conference with “Developing expertise in software testing” as theme. I had the honour to open the conference with my experience report called “Mentoring and coaching to develop skills”. In the open season after my experience report and during the rest of the peer conference we talked about reflection on several occasions. I think one of the most important skills in learning is reflection.

My vision on learning
Learning is the process of acquiring new or adapting existing knowledge, behaviours, skills, values ​​or preferences. Learning is much more than knowing: putting the learned into practice and gaining experience with it is important to truly internalise real knowledge and to gain skill. Learning must be linked to experiences from daily practice. By reflecting on knowledge and skills, so-called learning loops are created.

Learning is an ongoing process: the world is changing fast and to be excellent in your role requires many skills. So it is important to keep up! To learn effectively, learning should come from yourself, with intrinsic motivation and personal responsibility.

Learning requires a positive and open learning environment in which you can safely come out of your comfort zone to try new things. The safe environment gives confidence to make mistakes and to experiment with new knowledge and skills. It also demands a certain degree of challenge. How big the challenge is, is different for everyone. It is not that you always have to come out of your comfort zone radically. Right outside of your comfort zone, in your stretch zone,  you learn best.

Effective learning requires focused learning with clear learning objectives and preferably evaluation criteria. It should be clear what you want to learn and how you can measure that. Where do you want to grow? And how do you know that you have made a step? By setting clear learning objectives, you focus on learning.

Levels of learning
There are different levels of learning: (ref: Joris van de Griendt)

  1. In single-loop learning (improvement, behavioural improvement), it is about the visible and concrete behavioural level (what): you do something and that has a certain effect. This effect may be desirable or not, and based on that assessment, you can adjust your behaviour or not.
  2. Double loop (reframing, behavioural renewal) If you want to change your behaviour permanently, there is double-loop learning: researching which patterns the behaviour involves (how). Which patterns and mechanisms are behind the behaviour? Which helpful or obstructing thoughts are involved? Insight into this can provide a more well-founded choice to change behaviour.
  3. Triple-loop learning (transformation, behavioural development) goes even deeper. You involve your values, your purpose, the why question: why do I really want to change this behaviour? What important values ​​in me support this and what stops me?

What is reflection?
Reflection is a process of exploring and examining ourselves, our perspectives, attributes, experiences and actions / interactions. It helps us gain insight and see how to move forward. (ref: University of Edinburgh).

When we reflect, we deeply consider something that we might not otherwise have given much thought to. This helps us to learn. Reflection is concerned with consciously looking at and thinking about our experiences, actions, feelings, and responses, and then interpreting or analysing them in order to learn from them. (ref: The Open University).

Reflection is looking back at your behaviour in a certain situation. You reflect on that situation by asking yourself meaningful questions to make you think about the situation. The difference between just thinking and reflection is the intention to learn. There is a difference between evaluation and reflection. Evaluation means making a judgement about something you did. For example: did you reach your goal? Did I do the right thing? While reflecting means creating a safe space to investigate behaviour without making a judgement with the intention to grow.

Like learning, there are different levels of reflecting:

  1. Single-loop reflection focuses on behaviour and actions and is very close to evaluation.
  2. Double-loop reflection means trying to get hold of underlying convictions that interfere with the adjustment of interaction and behaviour.
  3. Triple-loop reflection is about motives and matters that touch on their own identity. There is often a relationship with issues at a higher level, that of the organisation or even of an entire system.

Iceberg

(image credit: Dutch Vision Institute)

Above the waterline behaviour is perceptible and statements are audible. But opinions, beliefs, feelings and emotions are not visible; they are below the waterline. These invisible elements, however, are often the motives for visible behaviour. An important part of the reflection will therefore consist of researching these deeper layers of the Iceberg.

By not addressing all layers within one’s competence management, you allow the coachee to act for incongruously (say A and do B, or vent a belief that contradicts his own motivation); just like external fragmentation (non-integration in the context), internal fragmentation (in the context of do-thinking motives) also leads to a real risk of energy loss.

Korthagen

(ref: How do I use the Korthagen reflection circle diagram?)

Korthagen’s reflection cycle is a tool or a strategy to be followed for learners to gain insight into their educational performance and to improve this. By applying this cycle step-by-step, one learns to systematically reflect a skill to be learned.

Phase 1: Describe the experience/situation you wish to reflect upon. What was the actual situation? You can do this by using the STARR(S) method: Situation-Task-Action-Result-Reflection-Strengthen (see appendix).

  • What did I have to do in this situation?
  • What action did I actually take?
  • What was the outcome of this action?

Phase 2: Looking back: What exactly happened?

  • What did I see?
  • What did I do?
  • What did I think?
  • What did I feel?

Phase 3: Awareness of essential aspects

  • What does that mean to me now?
  • What is the problem (or the positive discovery)?
  • What has all that caused? What does it involve?

Phase 4: Alternative methods

  • What alternative methods do I see (solutions or ways of making use of what I have discovered)?
  • What are their advantages and disadvantages?
  • What will I remember for next time?

Phase 5: Trial/action

  • What do I want to achieve?
  • What should I watch out for?
  • What do I want to try out?

Danger of thinking too much

Reflecting is an active activity that demands skills. It often happens that professionals think they reflect, while they are actually worrying.

This points out the important differences:

Worry

  • Involved in itself, looking from our own perspective, alone
  • Focused on mistakes
  • Focused on judging and condemning
  • Global approach
  • Mono causal approach

Reflection

  • Involved in the problem, also looking at a perspective outside of oneself, in contact with others
  • Focused on solutions
  • Focused on understanding
  • Analytical approach
  • Multi causal approach

Tips for reflecting

You can reflect on every situation and every problem that concerns you. You can learn a lot from that, but the pitfall is that you will be overwhelmed by the information and will keep looking back endlessly. Another danger is that you may feel that you are actually doing a good job – the work is going well, there is no criticism from colleagues or your supervisor – and so you see no reason to reflect. Yet it can also be very instructive to reflect on yourself and your way of acting.

The following tips can help you reflect:

  • Choose a concrete situation and look back on that specific moment and your course of action
  • Reflect regularly and ‘schedule’ at least once a week a reflection moment, preferably at a fixed time
  • Ask yourself open questions
  • Explain judgments about yourself; first see what really happened before judging yourself
  • Reflect in a methodical way, for example by going through a list of questions or use a reflection model
  • Reflect not only on problem situations but also on success experiences
  • Use feedback from others to reflect from that point of view
  • Read more about reflection to get inspired. This is a nice blogpost about reflection: How Self-Reflection Gives You a Happier and More Successful Life. For more inspiration read this: Tools to help you with self-reflection

Together you learn even more

It is already very instructive to consider your own functioning in this way, but it can be even more profitable if you do this together with others. Do not try to judge here either. Not about others, nor about yourself: you feel free to tell everything. For example, start doing intervision with peers or colleagues. More about intervision here: Intervision: what is it about?

Start a journal

Writing in a journal regularly (preferably daily on a specific time) helps to analyse your professional and personal growth. Journaling can give you a different perspective on things. Writing in your journal is a very useful tool to help you understand yourself and the world around you. Write down activities, thoughts, ideas, reasons, actions, techniques and reflections on specific topics or skills you want to improve. By writing in a journal you get an overview of your thoughts in which you can identify patterns. Journaling helps you to get thoughts and ideas out of your head but more important it enables making sense of things that happened. After doing something related to your learning goal, take notes on your observations, summarise facts and experiences. Also write down how it makes you feel.

More about reflective journaling in this article: Reflective Journals and Learning Logs.

 

Here are two helpful checklists to help you reflect:

Considerations when testing a software application in a context-driven way

October 29, 2018 / / 4 Comments

Written by: Joris Meerts (main author), Huib Schoots and Ruud Cox all working at Improve Quality Services in the Netherlands.

 Introduction
One of the cornerstones of context-driven testing (Lesson learned in software testing by  Kaner, Bach, & Pettichord, 2001) is that the way of working when testing software is determined by the situation in which the tester finds himself. A good approach is not driven by a prescribed process or by a collection of steps that one habitually executes. Instead, it arises from the use of skills that ensure that testing matches the circumstances of the software project. Within the framework of context-driven testing, a wide range of skills is discussed, including critical thinking, modeling and visualization, note-taking and applying heuristics. It is not easy to learn these skills. One way to sharpen them is to do exercises and discuss the results. This was the purpose of a meeting of four testers at Improve Quality Services. In the following report we will elaborate on the exercises that were done during that meeting and on the results.

Purpose of this report
As we pointed out in the introduction, it is not easy to learn the skills associated with context-driven testing. Practitioners of context-driven testing regularly refer to professional literature that describes these skills. But applying these skills is a process of trial and error. That is why it is important to simulate real life situations and learn from exercises we do. That was the purpose of the meeting. In this report we share the steps we took and the results of those steps, for example in the form of notes, sketches or models. We also share our experiences to make it easier to apply the skills in practice.

The meeting
The meeting was held on February 14, 2017 at the office of Improve Quality Services in Eindhoven. The participating testers, Jos Duisings, Ruud Cox, Joris Meerts and Huib Schoots are all employees of Improve Quality Services.

Background information
Date: 14 February 2017
Location: Improve Quality Services Eindhoven
Start: 9 am
End: 5 pm
Team A: Jos Duisings, Ruud Cox
Team B: Joris Meerts, Huib Schoots

The assignment

The assignment of the meeting is to select and execute tests on a software application. It is carried out by two teams of two testers each. This makes it possible to take different approaches and to provide feedback from one team to the other.

Division in sessions
The meeting is divided into sessions in advance. The sessions each have their own goal and their own evaluation.

  • Welcome & introduction
  • Creating a coverage outline (per team)
  • Debriefing the coverage outline
  • Drafting a test strategy (as a group)
  • Debriefing the test strategy
  • Selecting a few charters
  • Performing a test session (charter) per team.
  • Debriefing the test session
  • Retrospective

Introduction of the application to be tested
The application to be tested has been selected prior to the meeting. We choose the application Task Coach (Task Coach, 2018), an open source to-do list manager. This software is publicly available and runs on multiple platforms (Windows and Mac OS). The application is relatively simple but still offers sufficient complexity to be able to test thoroughly. According to the description on the website, Task Coach is ” a simple open source to-do manager to keep track of personal tasks and to-do lists. It is designed for composite tasks, and also offers effort tracking, categories, notes and more.” The participants have not worked with Task Coach before and are therefore not familiar with this specific piece of software.

Creating a coverage outline
Because Task Coach is new for all participants, the software will have to be explored. Only then can we say more about what can be tested in the given time. Such an exploration of the product can be done in many different ways. During the meeting we chose to make a ‘product coverage outline’, inspired by the Heuristic Test Strategy Model of James Bach (Bach, 1996). The product coverage outline provides an overarching view of the product in which the functionality of the software is divided into seven different categories. The categories are described in the mnemonic SFDIPOT. The software tester is reminded by this heuristic that when mapping a product he can look at Structure, Function, Data, Interfaces, Platform, Operations and Time. By looking at the application from these perspectives, a relatively complete sketch is created of what the software product is and what it can do. However, the mnemonic does not only serve for exploration. The ‘map’ of the application that is created in this way can also be used to visualize the coverage of the tests and to select the tests to be carried out.

The exercise
We decide that both teams will be given half an hour for creating a product coverage outline and that each team is free to decide which in which format the outline is presented. The choice of a half-hour time limit is mainly motivated by the fact that the software must also be tested before the end of the day. There is no room to spend much more time making the product outline.

It turns out that half an hour is not enough time for mapping an application that, despite the fact that it claims to be simple, still contains a lot of functions. Team B decides to create a mind map in which the seven categories are elaborated. This mind map is not finished after half an hour. Especially the branch ‘Function’, in which the functions of the application are described, is very large and has a deeply nested structure. To build this structure, team B explores the application by clicking through it and captures the functionality (in text or in image) in the mind map. Due to time constraints, team B presents a product sketch that is not finished. This triggers a discussion about what we expect the mind map to look like given the available time. The expectations, such as completeness, can be related to the purpose of the mind map. Through a discussion it becomes clear that no clear goal has been defined for drawing up the product sketch and that the result of the assignment is difficult to assess.

Preference for the mind map
A mind map is a tool that is used by software testers on a regular basis to create a product outline. The tree structure of the mind map lends itself to classifying (grouping) properties. It is easy to start with an empty mind map, enter the categories from SFDIPOT and expand these. Moreover, a navigable structure is created in this way. The mind map forms a kind of geographical map in which you can choose to zoom in and zoom out to determine the location of something in relation to the whole. Software essentially consists of zeros and ones and the software product is an abstract concept. By making the ‘map’ the abstract software gets a concrete shape. A mind map can also be used as an instrument for reporting on the results and the progress of the tests. So there are a number of good reasons to work with a mind map from the beginning.

Team A starts the session by creating a mind map but after a short time it switches to a different form. When studying Task Coach, the team finds out that there is a help file in the application. After a short study, the help file appears to describe a large part of the application. The categories from SFDIPOT all come back in the file to a sufficient extent and so Team A chooses to use this file, converted to Word format, as a product outline. By marking the categories in the document with different colors, structure is added to the document. In addition, the table of contents provides a global overview of the functionality in the application; the details are mentioned in the paragraphs. In this way, team A delivers a product sketch that is relatively complete within the stipulated time.

Drafting the test strategy
The result of the first session is a product outline. With this product sketch and the knowledge gained during the exploration of the software it is easier to discuss a test strategy. Because exhaustive testing of an application is not feasible for the majority of software applications and because exhaustive testing in many cases does not yield better information, it is desirable to make choices with regard to the test work to be performed. We find these choices in the test strategy.

By making the product outline we have gained insight into a number of aspects of the application. We take these aspects into account and we hope to indicate per category whether this category needs to be tested and if so with which depth. The most decisive factor in that decision is the risk the company encounters when the software is put to use. Risk is a multifaceted concept and can only be determined if the software product is highlighted from different angles. In any case, the perspective of the tester alone is not sufficient to get a good picture of the risks of a software product. During the second session it becomes clear that a representative is missing who can reason about risk from the perspective of a user or of the organization. This point is also discussed in the debriefing of the second session and we conclude that for that reason the risk assessment is incomplete.

Assessing risk
In the Heuristic Test Strategy Model three dimensions are discussed that influence a test strategy. These dimensions are the project, the product and the requirements that are set for that product; the quality characteristics. Risks play a role in each of these dimensions. In the exercise, we decide not to look at the project risks. As far as product risks are concerned, we make our own assessment with regard to the categories of the product. We consider categories that are used the most, are the most prone to errors and categories where a possible error has the most impact. Because there are no users involved in the exercise, we try to place ourselves in the role of the users. This way the following product categories are discussed.

  • The primary process from the Operations category. This will tell us which functionality is used the most.
  • Using the application by multiple users from the Operations category. We recognize risks associated with synchronization: tasks are not updated properly.
  • The importing and exporting of tasks from the Interfaces category.
  • Dealing with reminders from the Functionality category. Reminders are crucial for not missing appointments.
  • Dealing with date and time from the Time category. Date and time play an important role in planning tasks, they touch the core of the application.

After we have identified the categories of the product, we try to assess which quality aspects of the product are the most in demand. Here too, it has been decided to use our own assessments as a guideline. The following quality aspects are named:

  • Functionality,
  • Usability and
  • Charisma

Coverage
We briefly discuss the coverage of the tests that we want to carry out. Since the tasks that are maintained in Task Coach can have different statuses, the tester can, from the perspective of state transitions, visualize the coverage level of the tests carried out. The state transitions are covered in the different paths through the application that a user travels. These paths are helpful when mapping the coverage. Furthermore, coverage can be looked at from the perspective of the test data used.

Drafting the charters
We decide to make two charters (Session Based Test Management) and to execute them. We prioritize the product categories mentioned in the risk analysis based on our own insights. From this we conclude that ‘the primary process’ and ‘dealing with date and time’ are the two most important product categories. We translate these two categories into charters. In one charter we will look at the primary process, in the other charter the handling of date and time will be investigated. Each team selects a charter. After the charter has been executed, each team reports the work done to the other team in a debrief session. During this short evaluation, the tester will tell his story and answer any questions. The evaluation has several goals, such as assessing whether the mission is successful, translating new insights into follow-up sessions, looking at notes and descriptions of findings and coaching the tester. Due to the debrief, the understanding of the application under test grows.

The charter for testing the primary process
To formulate a starting point for this charter, we look at the risks that can be associated with the execution of the primary process. There is a risk that no task can be created. Or it could be that the task is created but errors occur when saving or modifying a task or changing the status of a task. These considerations lead to the following mission that serves as the starting point for the charter: “Explore the basic flow of tasks using CRUD to discover/test the life cycle of a task”.

The charter for testing the handling of date and time
Prior to drafting the charter for testing the handling of date and time, the following test ideas are mentioned:

  • Start and end times are the same
  • The end time is before the start time
  • The date of a task is far in the past or far in the future
  • System time
  • Work in different time zones
  • Dealing with winter time and summer time
  • Different date formats

With these test ideas in mind, the following charter is drawn up: “Explore tasks using date/time to discover date and time related bugs”.

Execution of the charters

Testing the primary process
The charter for testing the primary process (basic flow) begins with the creation of a task. Several tasks are created using the button on the taskbar. Subsequently, several underlying tasks are created for a single task, up to 8 levels deep. Under one of the underlying tasks, a new tree structure of underlying tasks is created. During the creation of the task structure, questions arise about the maximum depth of the task structure and about the sorting of the underlying tasks. In addition, it is found that it is possible to delete underlying tasks and then to undo these deletions. It is proposed to further investigate this functionality in a separate charter, since it is suspected that this is not always going well. The resulting tree structure is removed by means of the ‘Delete’ button on the taskbar. After this, all tasks have disappeared.

On the taskbar there is also a button that offers the possibility to create new tasks from a template. There are two default templates available. Tasks are created with these templates. It appears that it is not possible to create underlying tasks from a template. The question is why this functionality is not available for underlying tasks. Finally, the created tasks are deleted.

To get a better picture of how templates work in the application, the help text is read over templates. Furthermore, the team explores the menu structure in search of more functionality that could be related to the use of templates. From the ‘File’ menu it is possible to save tasks as templates, to import templates and to edit templates. A template is created.

From the dialog that appears when choosing to import a template it appears that template files have the extension ‘.tsktmpl’. But when a task is saved as a template, it is not possible to find out whether a template file is created from this task and, if so, where this file is stored. The newly created templates are visible when one chooses to create a new task based on a template from the toolbar.

A task is created, saved and checked if this task can be imported. Again, all created tasks are deleted by selecting the menu option Edit > Delete. The team looks a bit further at the options for removing tasks. It appears that there is a shortcut combination for removing tasks. The combination is Ctrl + DEL. The team wonders why it is not possible to simply use the Delete key.

In summary, this session looked at creating, viewing, editing and deleting tasks and underlying tasks. A finding has been made regarding the undoing of changes. It turns out that undoing the removal of tasks in a tree structure of tasks and underlying tasks does not produce the same structure as the original structure. Following the session, it is proposed to look more extensively at the use of templates in new charters. Also the functionality for creating, viewing, editing and deleting tasks and underlying tasks deserves more attention, especially because this functionality can be called from many different places in the application. The various possibilities have not all been tested in the first session. Furthermore, a charter could be made for creating a task depending on another task.

Feedback
At the end of the session, the report of the session was discussed with a member of the other team with the aim of obtaining feedback about the course of the session in a debrief. The feedback shows that there was not enough time to complete the charter. To complete the charter another thirty to sixty minutes would be needed. It is noted that the description of the detected bug is not clear enough. It also becomes clear that not all possible statuses of a task have actually been addressed in the session. Finally, a new charter is suggested for testing filtering and sorting.

Testing the handling of date and time
The session is started with a clean installation of the application. First a new task is created. Attention is given to the Data tab on which various data can be entered. The date and time can be changed in separate input fields. The time can be changed by means of a dropdown or by using the arrow keys on the keyboard. It turns out that ’00:00′ cannot be used as time. It appears that the range of time can be set under the ‘Preferences’ menu. After an adjustment, ’00:00′ can be entered.

It is noted that the planned start date and the planned end date are not included in the calculation of duration. But it is unclear what this data will be used for. When the planned end date is in the past, the task will turn red. When the planned end date is in the future, the task will turn purple. It is remarkable that the planned start date can be after the planned end date. Apparently there is no validation on the order of data. Dates that are far in the future are accepted as valid dates. To change a date, the task will first have to be closed and then opened again.

An interesting finding occurs when, at the planned start date, the year is set for 1900. If this is the case, the planned start date cannot be changed after closing and reopening the task. During the study of this finding, the team finds out that the application creates a log file (in the Documents folder) in which any errors are logged. The attempt to adjust the planned start date results in the following error message: “ValueError: year = 1853 is before 1900; the datetime strftime () methods require year> = 1900”. After this finding, further attention is paid to other functionality around time and date. For example, a reminder on a task is set to 5 minutes. The reminder works.

In addition to planning tasks TaskCoach can also be used to keep track of the time spent per task. After some research it appears that this functionality is complex and that it is not easy to find out how TaskCoach deals with time spent. Time tracking can be started with a button, but can also be done by increasing the time spent in a separate tab. The team notices that when entering an hour of time spent, the actual time spent shown on the tab is just a few seconds. It is possible to aggregate time spent at month level. If we do this, we see that the descriptions that we have listed for each entry are combined in a single text field.

The time that an application uses depends on the time setting on the system. For this reason, the team manipulates the system time of a MacBook Pro. The calendar is changed to a Coptic calendar. This adjustment causes the application to crash after startup. In the log a line appears mentioning an error relating to an invalid date format.

Finally, the team looks at the connection between the budgeted time and the time spent. TaskCoach is able to calculate the remaining time on the basis of the variables mentioned. Some tests are performed with variations in hours, minutes and seconds. TaskCoach handles all these variations correctly.

Feedback
A team member verbally reports on the session to a team member of the other team in a debrief. The feedback shows that this report contains a lot of detailed information. To be able to place the detailed information, a framework is needed. The product outline could have been used as a framework. One new charter emerges from the feedback, namely the testing of the synchronization of tasks between systems with different system times.

Conclusion
The meeting is concluded with the completion of the test sessions. Looking back we conducted, in a day with two teams, a number of tests on an application that was unknown beforehand. We have shown that techniques and methods exist that help the tester to acquire knowledge about the application, develop a strategy and perform tests. Exploring the application provides insights that serve as a starting point for risk assessments and for conducting test sessions with a well-defined goal. By quickly arriving at concrete and well-substantiated tests, the tester provides valuable feedback on the application in a short period of time. The test sessions are debriefed and this provides starting points for further deepening where necessary.

Due to the popularity of agile methods, it is common for the tester to be asked to test something, while at that moment he has incomplete insight into the functionality of the application. Moreover, the tester is expected to deliver results within a limited time. It requires an approach in which the tester quickly draws up and executes a strategy by modeling, thinking critically, discovering and investigating. This is the approach that we applied during the meeting described above.

A Clash of Models
The creation of the product coverage outline led to quite different outlines being delivered by the teams. These differences and their possible causes are discussed in a separate article, written by Joris Meerts and Ruud Cox. The article is called A Clash of Models.

References
Bach, J. (1996). Heuristic Test Strategy Model.
Kaner, C., Bach, J., & Pettichord, B. (2001). Lessons Learned in Software Testing. John Wiley & Sons.
Task Coach. (2018). Retrieved from Task Coach: http://taskcoach.org/

Let’s stop talking about testing, let’s start thinking about value

October 18, 2018 / / 6 Comments

This year Alex Schladebeck and I did two keynotes titled “Let’s stop talking about testing, let’s start thinking about value” at QA Expo in Spain and TestNet in the Netherlands. This blogpost has the most important points we made in our talk.

The keynote was inspired by some of our frustrations: “Testing is under appreciated” (Alex) and “Most testers are unable to explain what we do” (Huib). I wrote about my frustration back in 2016 already. This blogpost is about my frustration that most testers cannot come up with a decent definition of testing. And even worse: a big majority of the people who call themselves professional testers are not able to explain what testing is and how it works! They have trouble explaining what they are testing and why they are doing specifically the thing they are doing! How can anybody take a tester seriously who cannot explain what he is doing all day?

Alex’s frustration is that testing is not valued by others. Developers are seen as the rockstars of the project because they create the software that adds value. But why are testers often not valued?

  • Lowered expectations for testing expertise by stuff like ISO standards and ISTQB: I wrote about certification and standards before. ISTQB and standards put too much emphasis on process and documentation, rather than the real testing. By assuming there can be a standard, you say that there is one best way to organize and document your testing. But isn’t your test strategy heavily dependent on its context? When using standards we tend to focus on complying with the standard, and lose sight of the real goal. This sort of goal displacement is a familiar problem in many situations. Also, the idea that you can learn how to test is a couple of days of training is dangerous. Remember lesson 272: if you can get a black belt in only two weeks, avoid fights (Lessons Learned in Software Testing: A Context-Driven Approach by Bach, Kaner and Pettichord).
  • Avoiding controversy: nowadays more and more people advocate to be nice! I think that we confuse being nice, with being kind! An interesting article about this phenomenon is written by Marcia Sirota. Of course we need to respect other people, but to push the testing craft forward, we need to have firm discussions and disagree with others way more often. Being nice doesn’t help. Serious feedback does!
  • We devalue our own work by becoming tool jockeys: unfortunately there are too many testers (and teams) out there who focus too much on automation as much as possible. Why? Because they can! The testers in those teams are often so busy doing automation that they do not have the time to test anything…
  • We do not stand up for our craft: we do not fight back enough when other people say they do not need testers, or if they tell us how to do our jobs to name a few examples. We have to learn “testers self-defence: to stand up to people who try to dictate how do our jobs. We have to learn how to organize effective (and efficient) testing. And we need to learn how to talk about our work in a way others understand. This requires practice!
  • We do not learn or practice enough: testing is difficult! We have to deal with complexity, ambiguity, change and people. Testing is a craft, not something you do as a hobby. To become a craftsperson, you have to practice (also see my blogpost: a road to awesomeness).
  • We don’t know how to talk about testing: as said before: how can anybody take a tester seriously who cannot explain what he is doing all day? To be really valuable, testers need to learn to talk about their testing in a way others understand and find valuable.

So looking at these things, are we okay with this? I don’t think so. But what can we do about it? We are trapped in this vicious circle: we need to talk about testing! It is good for our soul to explain what I did and why, but we don’t know how to talk about our testing in a way that others understand.

Alex and I listed some traps:

  • Stories decay into Numbers: testing is about providing information to enable others to make informed decisions. The number of test cases or the number of bugs do not really matter. It is the story about the product and the risks involved. Those numbers might back up your story, but they do not tell the story!
  • A performance decays into Deliverables: testing is about finding problems, collecting information, exploring and experimenting to discover new information. Sure, documents and stuff sometimes help us, but testing is a performance. (James Bach talks about that here: a test is a performance and here: Test cases are not testing: towards a culture of test performance).
  • Test strategy decays into Test execution: when was the last time you saw a really good test strategy? In many cases I find master test plans where everything is described except the strategy. It is hard to create a test strategy and it is even harder to write it down or visualise it. Many testers I meet focus on test execution: creating test cases and scenarios and calling that the strategy.
  • Tool supported testing decays into Automation: testing using tools is a great idea. It gives us more opportunities to test and improves testability. But as said earlier: it becomes a problem when we focus too much on automation or even try to automate all our work. We cannot automate testing.
  • Many kinds of coverage decays into One kind of coverage: testing benefits from diversity! You find a certain type of bug with a certain test technique or approach. By using lots of different views, approaches and techniques, we find more problems.
  • Learning activity decays into Formalized static tasks: testing is learning about the product for our stakeholders. It’s not about verification and validation, there is much more to it. I like to replace such words with challenge the belief that (verify) and investigate (validate). Those activities provide the valuable information we need.
  • Balance risk and uncertainty decays into Certainty: people like to be comfortable and we like to give other comfort as well. But as testers we need to stay unsure, when others are sure. It is our job to keep asking critical questions. We are not here to give confidence or comfort, we are here to demolish unwarranted confidence! Also keep in mind that to find new unexpected problems, we have to go where nobody has thought of and nobody went before us. That will cause confusion which feels uncomfortable for many. I learned to be okay with confusion, since this is essential for learning new things.
  • Business Impact decays into Bugs: some testers are frustrated when bugs aren’t fixed. But that is part of the deal: some things that bug us, are just not important enough.
  • Product story decays into Testing jargon: I think this is the main problem for people not listening to testers. We talk jargon and about what we do in detail too much. We say stuff like: “We’ve executed 17 test cases in the system test, we’ve automated 50% of the test cases for area C and now have 30% code coverage. We found three major and five medium bugs”. And we are surprised that nobody will listen. We need to talk about the product! So you have found 8 bugs? Who cares? Talk about the risks involved, about the threats to the value of the product.

So maybe testers need to stop talking about testing?
Well, not exactly. We need to remember that the information from testing enables other people to do better work! So the testing itself isn’t always interesting, but the story about the results and the impact on the business is!

Just imagine a conversation between a tester and the PO.
Tester: The testing is going well!
PO: Okay, great. How is the product?
Testers: It sucks!

The role of testers

What is the role of testers? Testers see things for what they are. Testers help others make informed decisions about quality, because we think critically about software. This means creating awareness about the state of the product by staying sceptical when everybody else is sure. So we have to know what our clients want from testing. What information do they need to take these decisions? Project managers have one big question to be answered: are there problems that threaten the on-time, successful completion of the product?

Product Risk Knowledge Gap

I like to explain testing using the “Product Risk Knowledge Gap” like we teach in RST. Knowledge Gaps are the things that we need to learn in order to make good decisions. We need to learn about the product to close the knowledge gap. The more we know, the less risky our decisions will be. Testers should focus on questions like: what does the client need to know right now? What might hinder the successful completion of the product? What role do I need to take on in this situation to ensure we achieve our aims? Does this information matter? To whom?

But there is a way to avoid talking about testing. Just find enough questions and problems so that your stakeholders simply won’t have time to ask you questions back! Also, if you tell a credible story and give them the information they need, nobody cares how you got the information in the first place. In this case you need to stand your ground: tell people what they need to hear despite what they want to hear. Again: it’s your job to see things for what they are. If you give people the chance to doubt what you are doing, because you do not deliver the information they need, they will start asking questions about how you do your job. And if you have to talk about how you do your testing, then prepare to be able to tell a damned good story about your testing. Something they can understand and relate to.

The testing story

The testing story by Rapid Software Testing can help you tell that story. Tell a story about the product, what you saw, what you did to gather that information and how valuable that information is. (See “Braiding The Stories” by Michael Bolton). The testing story contains three stories that feed into each other:

  1. The product story: a qualitative report on how the product can work, how it fails, and how it might fail in ways that matter to our clients.
  2. The testing story: to make the product story credible, the testing story is about how we configured, operated, observed, and evaluated the product; what we actually did and what we actually saw.
  3. The quality of testing story: to make the testing story credible, tell a story about the quality of the testing. Describe why the testing we’ve done has been good enough. It includes details on what made testing harder or slower and what we might need or recommend in order to provide better, more accurate, more timely information.

Modern testing
As testers we do way more than only testing. We are enablers of testing by doing all kind of other things to be a service to the team and our clients. Researching this, Alex and I found the Modern testing principles by Alan Page and Brent Jensen. There is a lot of good stuff in there, and yet we feel that there is not enough focus on the actual testing in their principles. Furthermore, we think that the seventh principle “We expand testing abilities and knowhow across the team; understanding that this may reduce (or eliminate) the need for a dedicated testing specialist.” is formulated too negatively. We do not talk about dedicated test specialist as a function. But we like to talk about testing skills. And although we think there should not be a need for a dedicated testing specialist, we see too many people in teams who do not like testing. Passion (or at least motivation) for what you do, is conditional to become good at anything. So we created our own testing principles (inspired by the modern testing principles of course):

  1. Deliver insight into status of the product
  2. Practice (and enact) critical thinking
  3. Enable testing: lead, coach, teach, support
  4. Discuss testability
  5. Explore & experiment
  6. Promote waste removal / avoidance
  7. Help to accelerate the team
  8. Advocate continuous improvement
  9. Foster quality culture
  10. Keep critical distance and close social distance

Stop talking about testing?

So do we need to stop talking about testing? Not really. But we need to talk about the product, risks and value more. We can talk about actual testing only to back our story up or if they ask questions. And even then, we need to make our story understandable and relatable to others. Make sure you are a service to the team. We created our own testing principles to explain what value we add. We also have a pretty clear story on what testing is and how it adds value. We did this by practicing our stories many times. But we also figured out our own testing paradigm. That makes is easier to talk about what we do and how we add value.

Software Development is research & development: a series of experiments that ultimately lead to a suitable solution. We are dealing with customers who do not know exactly what they want. Furthermore, we are dealing with the complexity, confusion, changes, new insights and half answers. That requires research. As we team we are looking for what works and what doesn’t. Testing is of great importance for this! Testing provides insight and overview. Testing shines a light on the actual status of product and project. These insights enable others to make better decisions and eventually make better products.

The slide are here.

Note: this is an Alex Schladebeck and Huib Schoots co-production and this blogpost was co-authored by Alex. So where you read I, you could read Alex and I.
« Older posts

My website

http://www.huibschoots.nl

© 2024 Magnifiant: exploring software testing

Theme by Anders Noren — Up ↑