Tag: Values in testing

Categories
Blog posts in English

Wanted: Test Leadership (or why verbs can be better than nouns)

The exceptional testing performance requires something from everyone of us: We are performing in teams, but as individuals we need to be experts in our craft, tools and methods.
That is not all, though. We also need to be expert ourselves.
How can I be myself? That is a question, which philosophers have discussed for thousands of years.
We have to talk and think more about our personal values to become ourselves. I find that knowing and acting on our values is key to our professional performance as testers, and even more as leaders. It requires a rich language.
The problem, I think, is that in the processes of perfecting our software and technology development, and manage our projects, our language has become dull, technical, command-and-control-focused and valueless. Am I right?
Language scientists believe that in the earliest languages, there were no nouns. Verbs existed before nouns.
This indicates that that our ancestors talked about our relation to the world and people around us long before they started naming things in it.
Today we spend almost all our working hours defining and naming things. We discuss whether one noun is better than another. Which is the correct noun to use in a situation. What noun names the best practice.
I find there is far too little talk about what to do with the things named by all the nouns. And more importantly: What comes out of doing stuff, in the world around us.
Naming things isn’t leadership. It is optimization of communication. I want to see more leadership in testing.
We should somehow go back to the roots of our language and start talking about testing values using less nouns, more verbs.
I am running a series of protreptic workshops with my friend Karen in Copenhagen. We bring together a very diverse group of people and talk about values. The setting is informal, but Karen and I facilitate it closely.
The experience is awesome.
One participant wrote to me that it requires a great deal of “brain work”, but is rewarding: “I have met people who are different from me, and that makes the experience interesting because you start thinking: why do I have the attitudes and opinions I have?”
We don’t do psychoanalysis or discuss reactions. We don’t talk about models of the brain either. There is, in general, no cause-and-effect-thinking in the workshop. Only lots of inspiration.
And we inspire each other to talk about worth and personal values. Asking “why do I have these attitudes and opinions?” is one way of discovering them.
Leadership is about the team taking responsibility together, but that is not something that is monopolized with the constituted leader anymore. Taking responsibility is on everyone’s shoulders today, even you and me, the individual team members.
“To lead others, first you have to lead yourself”, my friend Maibritt Isberg Andersen says.
And now, that we are all test leaders, I really hope we will all start talking more about our attitudes and opinions, and why we have them.
It is about inspiring test leadership.

Categories
Blog posts in English

Say "Yes, but…" and remain true to your values

Testers sometimes have to make compromises. We have professional values and beliefs, but they may conflict with values in the contexts we act in.
Isn’t there always someone who matter who has an opinion about what testing is and how it should be performed? 
I remeber a few situations, where I have felt I was tasked to do something in a way that I didn’t agree with. How can I make a difference, then?
This feeling points to something which is a dilemma for every skilled professional: We can sometimes feel that our personal and professional values are challenged, but there is still a job to be done.
How can a I make the compromise, accepting a challenge, while staying true to my values and beliefs? 
It’s about learning and improving.
 
Social responsibility
To me, one of the most important things about being professional and a context driven tester is taking social responsibility. This is an important value to me.
Social responsibility is not about self-critique. As a professional, my personal doubts and worries are valuable.
Instead it is about trying to give customers what they need by understanding their situation and helping them get better with what we are doing together.
That requires what I call personal leadership. But foremost, it requires conversation and negotiation.
 
“Yes, but…”
In his “Improv(e) your testing” talk at Let’s Test 2016, Damian Synadinos @dsynadinos reminded me of a simple and efficient strategy to opening conversations. In improv, a golden rule is to start replies with with “yes, and…”. This helps adding to whatever is happening on stage.
In professional situations we sometimes have to subtract instead:

Yes, I will perform the test and report to you about it, but please explain me how the test case and bug count metrics you ask me to do will be useful?

The “yes“-part is about accepting the challenge. The “but” implies that I’m going to stay true to my knowledge, experience, values and beliefs and raise professional doubts about methods I’m asked to use, things I’m asked to report, processes I’m asked to follow.
I’m not asking rhetorical questions. Rhetorical questions shut windows to the world and enclose me in my own thoughts and ideas.
So I keep thought in the back of my mind when I’m asked to do something in a certain way: “Is this really in the best interest of the people who matter: The project stakeholders?”
Replying “yes, but…” enables me to act on my personal values in contexts which have values of their own.
 
Masterclass in New York City
On September 26th, during Test Masters Academy‘s REINVENTING TESTERS WEEK in New York City, I will be doing a workshop titled: “Act on your values!” on values and personal leadership.
As testers and IT-professionals we have to quickly recognize and adapt to ever changing contexts in order to produce value for our employers, clients and various diverse customers. This can be challenging, both on the personal and the professional level. As leaders, team members and individuals we often have to lead ourselves.
The workshop will focus on how our personal and shared values can guide us. It will be based on the principles of protreptic dialogue, which is a philosophical facilitated conversation revolving around the values embedded in what we say, do and think. First described in ancient Greece in the fourth century, professor Ole Fogh Kirkeby of Copenhagen Business School has revived protreptic dialogue as both a concept, a leadership tool, and a coaching principle with the objective to “turn us towards ourselves”.
I plan for the workshop to be a safe space for exploration and learning. Participants are expected to share opinions, thoughts and ideas, and to treat others’ opinions, thoughts and ideas in a respectful and appreciative manner. No prior knowledge of leadership, dialogue, philosophy, or protreptic dialogue is required.
Key takeaways

  • Consciousness about personal values and values of the contexts we work in
  • Strategies for dealing with the dilemmas we face as testers
  • An introduction to protreptic concepts and dialogue

Get tickets here.
28cbe1e4-a4e5-4bc8-860c-3c7584be81d9
 

Categories
Blog posts in English

Value centered dialogue at CPHContext

I’m beginning to get quite excited about speaking at CPHContext about ”Value Centered Dialogue in Context Driven Testing”. It’s not the first time I speak at a testing conference, but I am going to demonstrate a type of dialogue for which there is no firm recipie and I can therefore only plan for mentally. And that is of course a bit exciting 🙂
To settle my nerves, I’m writing this blog to reveal something about what I’m going to tell people.
Recently, a good friend asked me: “What is leadership is to you?”
My answer came quicker than I thought it would: “It is about setting people free to do their best,” I said.
We were talking about personal leadership values.
Heuristics and values
There are many ways to lead people – we could call them leadership heuristics – and while you and I can attend the same courses or read the same books and therefore learn the same leadership heuristics, our personal values shape our actions and therefore the way we apply these heuristics.
Everything I’m going to say in the session will be about basic human values and how I have found a special type of dialogue can bring new energy into context driven testing leadership.
I have my slides ready, and I hope it will be a good experience for everyone attending my session.
A protreptic dialogue
I’d like to give show something about how a protreptic dialogue between me (the guide) and you would start out. I might start with a question to you:
What does it mean to be context driven?
I’ll listen carefully to your answer and depending on what you answer (there is no right or wrong here as it is about you) I might tell you something about the origins of the word context. Words are important in protreptic dialogue.
The word context is orignally latin and comes from contextus which means joining together. The danish word for context is sammenhæng, which means the same, so context is something we are joined to, or maybe even woven into, as the latin origins actually indicate.
Then, what does it mean to be context driven: Can something that we are joined to or even woven into drive us? It might if there is motion in it, so if we want to understand something about how the context is driving us, we should look at the dynamics in it. But perhaps the driving could be reversed: Can our testing set the context in motion?
This question was for you, and again I’ll listen carefully to what you say. If it was me, I might answer myself like this:
Of course we can set the context in motion, and we do, as testers. After all, testers discover stuff other people have not yet discovered, we build trust, create business value, spoil illusions and other things that send motion back into the context.
This is interesting. As a guide, I’ll listen to your value laden words: discovery, trust, value, illusions. In a human value-perspective they have meanings related to the four basic human values: The Good, The Beautiful, The Just and The True.
In the ongoing protreptic dialogue, we will explore these values together, getting very close to what they really mean to you. We might talk about your work or other things in your life, but only if you want to and bring it up. This is not a therapy session.
Protreptic dialogue is meant to be a nice and respectful experience for both. There are no roles to play, we are both ”ourselves”, but we are taking a journey together to discover something about ourselves, in this case about context driven testing.

Categories
Blog posts in English

Why you should do your job better than you have to

Software testers evaluate quality in order to help others make descisions to improve quality. But it is not up to us to assure quality.
Projects need a culture in which people care for quality and worry about risk, i.e. threats to quality.
Astronaut and first man on the moon Neil Armstrong talked about reliability of components in the space craft in the same interview I quoted from in my last post:

Each of the components of our hardware were designed to certain reliability specifications, and far the majority, to my recollection, had a reliability requirement of 0.99996, which means that you have four failures in 100,000 operations. I’ve been told that if every component met its reliability specifications precisely, that a typical Apollo flight would have about 1,000 separate identifiable failures. In fact, we had more like 150 failures per flight, substantially better than statistical methods would tell you that you might have.

Neil Armstrong not only made it to the moon, he even made it back to Earth. The whole Apollo programme had to deal very carefully with the chance that things would not work as intended in order to make that happen.
In hardware design, avoiding failure depends on hardware not failing. To manage the risk of failure, engineers work with reliability requirements, e.g. in the form of a required MTBF – mean time between failure – for individual components. Components are tested to estimate their reliability in the real system, and a key part of reliability management is then to tediously add all the estimated relibility figures together to get an indication of the reliability of the whole system: In this case a rocket and space craft designed to fly men to the moon and bring them safely back.
But no matter how carefully the calculations and estimations are done, it will always end out with an estimate. There will be surprises.
The Apollo programme turned out to perform better than expected. Why?
When you build a system, it could be an it-system or a space craft, then how do you ensure that things work as intended? Following good engineering practices is always a good idea, but relying on them is not enough. It takes more.
Armstrong goes on in the interview (emphasized by me):

I can only attribute that to the fact that every guy in the project, every guy at the bench building something, every assembler, every inspector, every guy that’s setting up the tests, cranking the torque wrench, and so on, is saying, man or woman, “If anything goes wrong here, it’s not going to be my fault, because my part is going to be better than I have to make it.” And when you have hundreds of thousands of people all doing their job a little better than they have to, you get an improvement in performance. And that’s the only reason we could have pulled this whole thing off.

Categories
Blog posts in English

On the Value of Interested, Dedicated, and Fascinated People

Neil Armstrong, first man to walk on the moon. Photo: NASA.

Some test managers and test consultants are very busy pointing out the right processes, organisational structures and methods to use in software testing.
But no methods, processes and structures can assure great testing. Great testing is created by people.
This quote by Neil Armstrong, which I came across a couple of years ago, is worth remembering whenever we lead people in testing:

“The way […] that made [the Apollo project] different from other sectors of the government to which some people are sometimes properly critical is that this was a project in which everybody involved was, (1) interested, (2) dedicated, and, (3) fascinated by the job they were doing. And whenever you have those ingredients, whether it be government or private industry or a retail store, you’re going to win.”

To me, his message is that as leaders, our aim should be to do whatever we can to make people just that: Interested, dedicated and fascinated by the job we are doing.
Source: Transcript of Neil Armstrong Interview with Stephen Ambrose and David Brinkley

Neil Armstrong, first man to walk on the moon. Photo: NASA.
Neil Armstrong, first man to walk on the moon. Photo: NASA.

Categories
Blog posts in English

Core Values in Testing

There’s something about life that you won’t find anywhere else.
– Ole Brunsbjerg, headmaster.

The Copenhagen Context Driven Testing meetups are becoming a tradition thanks to the work of Carsten Feilberg and Agniezka Loza. In June, I chaired a workshop in Ballerup near Copenhagen during one of the meetups. 16 testers shared ideas about values in software testing.
There are four or five basic human values which everyone shares. The good, the beautiful, the true and the just. Freedom relates to these four. We express and rate them differently and they are intrisic to us, subjective, but still shared among humans.
My personal human values shape my actions, words and thoughts, and thus also the words and expressions I use in my daily language. My language can tell you about my values and therefore something about who I am.
Workshop and procastination
In the workshop I chaired in June, I asked the participants to pick picture cards to illustrate thoughts about testing. Then they spoke about the picture and about testing. We shared our words and statements on post-it’s and I collected them.
I was busy at work after the workshop, and the box with the words ended up on my desk. Summer and vacation came, and I procastrinated opening it. One of the last days of vacation, I finally read the words on the post-it’s.
Here are the words:

Knowledge; Information; Curiosity; Exploration; Investigation; Fight :-); Courage; Confidence; Balance; Collaboration; Evolvement; Surprise; Order; Performance; Discovering stuff, that others have not (yet) discovered; beautiness. Usability (easy/better ways of using stuff). Universatility. User experience design; Good (better) end user experience; user needs; user satisfaction; Sustainability. Creativity. Responsibility. Curiosity; Easeing somebody else’s job; Striving; Alertness; Communication; Added communication; added collaboration; information sharing; Building bridges; (Make it) fun; Excellence; Any word / anything; Getting a kick; Covering / exploring; Contradictions / paradoxes; Building trust; Finding (new) ways; Getting to know; Helping; Revealing; Avoiding losses; Whole solutions; Support descisions; Transparancy; Quality; Assessing quality; Avoid scandals; Improvement; Business needs; Filling gaps; People; To spoil illusions (own and others’); Digging for something deeper; Truth; Structure; Growth; Responsibility; Team work; Exploration; Progress; Seeing/finding possibilities; Erkendelse/Erkenntnis/realisation; Business value; Honesty.

DSC_1239
Truth and testing
It’s interesting to note that many of the words above relate to the value ‘truth’. Testing implies couriosity, gives a kick, spoils illusions, happens through exploration etc.
I consider ‘truth’ to be the fundamental core value in testing. Truth as a term is a complex thing, but when we use words that relate to the value ‘truth’, it’s easier to see.
As a tester, I prefer things that are true and don’t accept stories that can’t be verified. I rate things that are more true than other things. For example, I tend to dislike reducing truth to numbers, and prefer a more nuanced understanding of subjects.
I do have beleifs, hyphotesis, and test ideas, but at the end of the day, the ideas only prove their worth when they have been evaluated.
More than truth?
But look again.
Many (most?) of the words deal with things that are not related to ‘truth’: Reponsibility, easening other peoples jobs, evolvement, user experiences, whole solutions, improvement, business value etc.
This reminds us that testers are not just concerned with ‘truth’, i.e. testing, but also value how testing is used and the results that the whole team or company achieves.
What does this tell me as a testing leader?
It tells me that in my leadership, I cannot only focus on testing ideas, spoiling illusions, and telling the truth if I wish to motivate and encourage our teams to work efficiently and independently doing their testing.
I have to consider how the testing contributes to achieving other goals and higher goals.
I have to consider that coorporation with colleagues work well. That the product we somehow help with is something that makes users happy. That there are bottom line results because of our testing. That disasters are prevented.
These things are not just ‘context issues’. They are core to testing leadership.
Word play
I have played with the words on the cards and come up with a mission statement for a hypothetical testing team. The mission statement somehow expresses this.
Feel free to play with the words yourself.

We are testers. We are ready to spoil illusions, both our own and others’. We have courage to do so and generally like to be surprised. So we always dig for something deeper, a deeper understanding, a realization, an ‘erkenntnis’. We get a kick when that happens. Through testing, we seek truth, but we also feel a responsibility to make our testing useful to create user friendly and whole solutions, support growth and improvement, and sustainability. Our testing thus aims to assist the creation of pleasing and aestethic solutions, to serve other peoples needs and hopes, and in general to do good.

PS: The quote from my uncle Ole Brunsbjerg at the top of this article is to remind us that there is more to life than testing. Or anything else. Life is very rich and as humans, we value all of it.

Categories
Blog posts in English

Do it right: A value in Context Driven Testing

The problem with me is that I’m really bad at following instructions. When people tell me to do something in a certain way, I do it differently.
It’s a problem when I cook, because I‘m not particularly good at cooking. So I have to follow recipies, and I often mess it up slightly. I’m improving, learning strategies to remember, but this is a fundamental personality trait for me.
And not one I’m sorry about. Because it’s not a problem when I test!
I always wanted to be a great tester.
I tend to become really annoyed with myself when a bug turns up in production in something I have tested. ”Why did I miss that?!” I feel guilty. You probably recognise the feeling.
The feeling of guilt is ok. The fact that we can feel guilt proves that we have consciousness, empathy and do the best we can. People who don’t care, don’t feel guilt.
But in testing, finding every bug is fundamentally impossible, so we have to get over it and keep testing. Keep exploring!
Even before I learnt about Context Driven Testing, I knew that great testing could never be about following test scripts and instructions. I noticed that I got bored and lost attention when I executed the same test scripts over and over again, but I also noticed that I missed more bugs when I only followed the instructions.
So I stopped following the instructions. This gave me an explanation problem, however: “Uhh, well I didn’t do quite what I was asked to do…. but hey you know, I found these interesting bugs that I can show you!”

Can you hear it? That won’t impress old-school project managers with spreadsheets to check and plans to follow.

Context Driven Testing has helped me greatly in becoming a better tester. The thing is that CDT teaches me to do a great testing job without instructing me exactly what to do. Instead, the community shares a lot of heuristics I can use to help me do a great testing job, and through thinking-training and inspiration from others, it’ll help me develop my capacity to do great testing in whatever contexts in which I’m working.
It may be a bit difficult to grasp at first. A little worrying, perhaps.. But CDT is a really, really powerful testing approach.

And CDT has helped me explain what I do to my project managers. Even the old-school types!

Social services and testing

A few days ago, I read an article about quality in social services in which the following statement from the vice president of the Danish social workers union caught my attention: ”It’s about doing it right, not about doing the right things.” He was speaking of how the authorities try to help vulnerable children and their families.
The statement resonated with me, and a bit later it occurred to me that it even sums up what CDT is about:
Context Driven Testing is about doing it right, not about doing all the right things.
Note that I’ve added the word ‘all’ here.
There’s more to CDT of course, but this is the core of CDT – to me. Some readers may lift their eyebrows over the ”doing it right”-thing: ”Does he mean that there is ONE right way to do it?” Read on…
The past 10 years, I’ve worked in contexts where CDT is not really the thing we do, and if I was to be as context driven as managers in my context had asked me to be, I would not really have been context driven. You get the picture, I’m sure.
But with CDT in my briefcase, I can work to make changes and improving things in the specific context in which I’m working. As a consultant and contractor, I’m usually hired to fix a problem, not to revolutionize things, and I’m expected to do a “good job” fixing it.
”Doing it right” is of course about doing a good job, and ”doing a good job” should really not be taken lightly. CDT helps me do a good job, even when I’m not working in contexts that actively supports CDT. That’s because CDT is flexible: It empahsizes that testing should never be driven by manuals, standards or instructions, but by the actual context in which it takes place, and that’s actually quite difficult to disagree with, even for old school project managers!

Further, if my context (i.e. project manager) ask me to do something, I do it – even if it’s in a standard. Sometimes there’s a good reason to use a standard.

Context driven testing is not defined by any methods or even by a certain set of heuristics. Nor is it defined by a book, standard or manual. Neither is there any formal education, certification or ”club” that you have to be a member of in order to call yourself Context Driven.
Instead, Context Driven Testing is about committing oneself to some core values, and to me the most important value in CDT is contained in the sentence:
It’s about doing it right, not about doing all the right things.

Why would anyone wan’t anything else?

(Thanks to @jlottossen for reviewing this post and for suggesting several changes to the original version.)