Categories
Blog posts in English

The Deep Rationality of Software Testing – EuroSTAR Best Paper award

Software is code, but stakeholders value working software. And software should not just work; it should work well: Have quality. Rational knowlege about quality requires testing.
Anders Dinsen, founder and owner of ASYM APS won the Best Paper Award at EuroSTAR 2019, Europe’s biggest software testing conference for his article on the Deep Rationality of Testing. The article was published as an e-book on January 20th 2020.
In the article, Anders Dinsen redefines software testing as a necessary and best practice in any development project. He starts with the bugs we can find in the code. Based on Kant’s philosophy, he then shows how the thinking, imagining, and rational tester (agnostic of titles) engage the team and educate people on how the software really works. The result is all about quality.
The ideas are based on Immanuel Kant’s philosophy. Kant is probably the greatest of all European philosophers, but has a reputation for being pedantic and difficult.
But we intuitively understand what he says: That knowing things always involves the complexity of experiencing and learning.
The article can be downloaded as a 50 page A5 e-book free of charge from EuroSTAR’s web site

49100972716_cb0350237e_o
Anders was awarded by the committee of the conference during the awards galla in the Zofin palace in Prague

 
DSC_6496
EuroSTAR 2019 took place in wonderful Prague in the impressive Prague Convention Centre

Categories
Blog posts in English

Faked reality

The only real to me is intuition
I fake faking I see real as is
I realize realizing reality is not what I see
These simple truths relates me
And explains how truth is in relation
Not interaction
As interaction is illusion
Only relation is real
Intention too
They’re rich.
A blow of misused trust, and my mind is twisted
That’s all it takes
To turn intuition into illusion
If reality climbs back, I must reject it at first
Shameful of my sin, it’s easier to deny what I just did
To myself
To reality
To relation
To intention
To others
It takes courage to relate intuition to reality
Test the relations
The deeper relations too
It takes seriousness
Rejecting the fakes
Still, faking is real as
The only real to us is our intuitions
We fake faking we see real as is
We realize realizing reality is not what we see
dsc_3787
This robot used to mount computer tape cartridges in tape drives. What was on the tapes. what did its camera see?

Categories
Blog posts in English

Be Serious About Your Testing – or Die

I meet up with the philosopher just outside the city wall of Copenhagen. To the left, the city rises behind it’s wall. To the right is open land. He lives out there, in the quiet fields just outside of the busy city.
“Why do you test?”, he asks me.
Testing is my job, my profession, and I tell him the story of how I made it into testing as a consultant more-or-less by accident, and then became passionate about it.
“But,” he says, “why are you serious about testing?”
I then tell him about how my curiosity drives me, and the information I gather, and how I communicate to people. Also, I learn new things by exploring products, which I like. It feels like science.
“Testing is about curiosity and knowledge,” I say. This I say almost as a declaration, without doubt. I feel certain.
“Let’s talk about your funeral,” he replies. “What will people say about you when you’re not there?”
For a moment I feel a void opening beyond me and fear my words can no longer hold me. I pull myself together, though.
“I want people to remember me for my passion for exploration, that I was motivated, skilled, critically thinking, a modern tester … I want to be known and remembered for that, and…”
The philosopher interrupts me:
“Those things are for people living merely aesthetic lives,” he says.
I look at him.
“I’m a motivated professional“, I reply, “I work with some of the best people in the world, people who are motivated like me, passionate about the things I’m passionate about: Testing, risk, exploration…”
The philosopher looks away. A horse cart passes us, and the strange feeling returns. Where am I? The place looks familiar, yet strange. What am I wearing? Not my usual clothes. The passenger in the horse cart stops the driver to exchange words with the philosopher about his latest publications. I’m eager to continue the conversation and demonstrate my passion and motivation, kill the nagging feeling of fragility and confusion. Finally, the philosopher turns away from the other man, and looks at me:
“Are you serious about your testing work. Or do you just want to be known?” I can’t figure out if the voice is his, or my own voice sounding in my mind.
I wake up with my heart ponding in my chest.

DSC_2452.jpg
One sleepless night, about a month ago, I picked up my tablet and found one of Søren Kierkegaard’s books on Google. The one I found was published in 1845 and contained three discourses for imagined occasions. I’ll prefer to call them talks. One of the three is a talk for an imagined funeral, and the subject of the talk is seriousness. Kierkegaard is known for walking Copenhagen and talking to people, and in my imagined dream above, it was him, I met, walking the outskirts of the City as it was about 170 years ago (the walls were since removed, and the city has expanded into the open lands around it).
Kierkegaard was Danish and wrote in Danish. The Danish word for seriousness is alvor. It is pronounced ál-vór and the origins of the word can be traced to old German “alawari” meaning “all true”, “friendly”, “willing”. The individual syllables in the Danish word have meanings: “All ours”. Alvor is more than attitude, there’s really a lot of value in that word.
I’m a free lance consultant, and a successful one. I’ve worked with software testing and test management for 15 years. I’m skilled, valued, and motivated.
A recent brain storm on testing lead me to think what testing can do, and I came up with these: Goal-keeping, learning, proving, checking, validating, exploring, researching, verifying, learning, teaching, educating. (Thanks to Ash Coleman for inspiring this.)
But testing is strange: Dijkstra said that the only thing testing can prove is the presence of a bug, not it’s absence. So how can we keep a goal, prove or educate anything? Am I wrong, or could testing be more than what Dijkstra said? The word alvor and even the English serious to me contain and indication that it can, at least when trying to understand it the way Kierkegaard did.
Søren Kierkegaard says seriousness is not in the subject, attitude, power or anything else that’s explicit or aesthetic. Beauty is our business, Dijkstra said, but Kierkegaard would disregard beauty as serious business, as beauty was to him just an external thing, and what mattered to him was the tacit, internal and relational. Seriousness, to Kierkegaard, can be thought of as a mental state, and we can be serious making a choice, but it is still something that is related to ourselves and the relations we have with others.
Let me try to reframe what I learned reading Kierkegaard’s funeral talk that sleepless night by putting it into a modern context:
DSC_2451
The retrospective
Not all testing is done in sprints, but a lot of modern testing is, and I’d like you to think of a sprint you took part in.
You probably remember some things and have forgotten a lot. My guess is that as of right now, you – as I do when I think back on one – remember certain events like the demo, bugs that were found, and probably more likely the bugs and problems people at the demo pointed out that you had missed.
Thinking back on the sprint, however, is not seriousness. Kierkegaard is clear: It’s only emotion!
Therefore, now I want you to instead think of the sprint you are in now: It doesn’t matter if there’s just a few hours left of it, or several weeks. The sprint is the present, now.
Seriousness, in the way Kierkegaard wants us to think about it is in experiencing time running out as the days until the end of the sprint counts down to 0.
We need to make important choices before it’s too late.
Otherwise, the sprint will end, and after that, all we’ll be left with is emotion about the mistakes we made and shouldn’t repeat.
There’s a further level to this, though.
In death, Kierkegaard says, everyone is equal. Now, this sounds dramatic, but there’s a link to the sprint: In the sprint, we had roles, but after the sprint the roles are just part of history. Death is where nothing happens. Time becomes meaningless to the dead, just as it’s meaningless to the sprint that has ended. Time doesn’t matter to us talking about the sprint that has ended, in fact, time easily becomes a reconstructed illusion, as we try to remember the order of things that happened in the sprint.
Kierkegaard’s point, I think, is that the image we build, our power and influence, number of Twitter followers, likes we got on Instagram, job offers we have received, etc … all those things have nothing to do with seriousness. They are just emotions.
Seriousness is in choosing to be present right now and to care about what we do and especially about how others will experience it after we’re gone.
DK001136
Reading Kierkegaard made me tired. I eventually fell asleep without finishing his talk.
I feel I’m sometimes trying too much to be serious. I can be anxious, and can’t relax. That can make me feel important, but I must be careful: It’s not seriousness. It’s a dangerous state of mind, and I will often end up sleepless, and probably bug others with my overdosed seriousness worrying about details that don’t matter.
So I can be serious, but I still needs rest, breaks, time away, time for doing nothing, even time to be foolish, childish, silly. Happy.
I become serious by choosing myself in social interaction with those to whom my work matter: Teams, colleagues, managers, stakeholders, users. Seriousness is no longer seriousness when it becomes an ego-trip, a battle with colleagues and stake holders. Seriousness, to be what it promises to be in the Danish word “alvor” or the old German “allawari”, is all ours.
I discussed an early draft of this essay with Damian Synadinos.
He has an interesting point on death as he reminds us in his talks on “improv(e) your testing” to contemplate death.
Damian talks about these two phrases in improv: Killing on stage versus dying on stage. He is serious about improv, which he trained for years and used to perform professionally.
What he says, I think, is this: Improv that dies on stage ends with no laughs, no emotions, no narrative. You want to kill on stage. Not literally, of course, but not only emotionally either.
A couple of years ago, Damian and I crazed out to a live band playing AC/DC-songs at Let’s Test 2016 in Stockholm. They sang this:
Shoot to Thrill,
Play to Kill…
I understand Damian this way:
Be serious about the testing you’re doing, contemplate death, and set out to create a meaningful testing event. In other words:
Shoot to thrill
Play to kill;
Don’t let your testing die by your ego-trip.
DSC_1295

Categories
Blog posts in English

Quality is…

In a recent post, Anne Marie Charrett discusses quality as an emergent property.
I see quality as a term for value, and it is in itself complex. It can be read as being synonymous to aesthetics, beauty, and probably even to complexity, but it can also – as a term – refer to existential properties such as safety, existence, life etc: doing no harm is considered a fundamental quality in health care, for example. In the real, especially in the reality of projects, quality is indeed emergent: The product begins its life as an idea, we assemble the parts, and in the end the whole becomes something of greater value than the sum of the individual pieces.
But no matter how it emerges, quality, to me, is fundamentally tied to the human. We can define metrics for quality if we work hard, but even the best metrics will never be more true that the humans who relate to quality. This perspective can be debated, but as a premise for my work, I don’t want to engage in such a debate. Rather, I’m interested in debating how to make the human perspective operational in my work with quality and testing software systems.
And for that I have 12 models that can be applied, on three levels in four dimensions each.
I draw it like this (explanations follow, and yes, it’s a pyramid):
_20181206_1841394306266375574636519.jpg

First order quality

Quality is something to someone, somewhere at some time. What is that something then composed of. Based on Ole Fogh Kirkeby’s “Greek Square” as described in his books on proptreptic value based coaching, Cynefin’s domains and Kant’s categories of terms, I think of quality as something on a compass disc with four corners:

  1. Quality as factual, obvious and true. Correctness is a quality in arithmetics, and subjecting a pupil to a number test with a number of addition assignnents allows us to evaluate how good she or he is adding numbers simply by comparing based on the fact that given a+b=c, given a, b being numbers of a known number system, c is a defined value. Sometimes, facts require more than algorithms, as in evaluating “North is that way”, but the principle is still the same, that a presupposition can be proven right or wrong given a concrete context of testing using someone, somewhere at some given time.
  2. Quality as relational, as when we for evaluate fairness and agreement with something or someone. Still in the context of someone in a given time and place, this kind of quality is relatively simple: We can ask the person, or we can put ourselves in her shoes, understand her, and evaluate for her. Agreement can probably always be evaluated mechanistically, but we still have to make sure that we know what to evaluate against: is it under our control, or a moving target? Fairness is more difficult, as even legislation needs to be interpreted in terms of both its written word, and its intention and ‘spirit’.
  3. Quality as an emergent, aesthetic, complex property is what we see in software Projects, especially if we look at the human values of the software. In that, people experience wealth of experiences existing on a continuum ranging from bad to good, ugly to beautiful.
  4. Finally, we sholdn’t rule out the safety aspect of quality. Even when we consider quality in the most personal and individualistic view, one that is rooted in a single persons’ experience with the product, we should not rule out the anxiety present: Will it destroy my idea (WordPress’s App deleted most of this blog post while I was editing it)? Will it destroy my day? Will it destroy me? As I mentioned above, a quality in healthcare is not harming patients. It’s fundamental, but it’s important, and a basis for ensuring that cure can emerge.

That was the first four models of quality. There are four more one level up:

Second order Quality

When I was a child, I played for my own sake. The quality of my play emerged, but it was personal. As I grew up, I began playing with others, and for them: At work, and as a parent, what I do is more serious: Part of growing up is learning to do things for others. Part of learning product engineering (which I did) is learning to engineer things for users.
The second level in the model is tied to the group of users, the team, an organization, the stakeholders etc. Quality is social here, but still bounded. But it can refer to the different domains in which the product has value: In the project, to sales, and to users. There are several ways to move to this level of abstraction, but we need to know what kind of abstract level we’re moving to for this to work.
My experience is that we can only move our thinking to this level if we know what we’re addressing. It doesn’t require absolute certainty, we can create props to represent users by describing them, or we can describe users in abstract terms. But there needs to be some kind of concrete knowledge available about the target of our idea of quality before we can talk rationally about quality at this levels.
But once we have that, we can start working with quality within the same Compass system of fundamental quality values I described above: Factual, relational, and emegergent quality, and safety. (Or as they are named in the Greek Square: The true, the just, the beautiful, and the good.)

Universal quality?

At the top of any pyramid is a smaller pyramid. In this case, this is where we move to the universal perspective, the quality that applies to everyone, everywhere, at all times. This would be God’s view on quality.
Factual qualities are often easy to work with, even at this level. Take math for example, which doesn’t depend on neither time, space or humans. Math is a thing in itself, it seems. Therefore it makes perfect sense to judge an attempt to solve an equation as universally good or bad depending on simple correctness:
2 + b = 4 <=> b = 3
The above is obviously incorrect and false.
It get’s much harder when we move further around in the value compass: Can we talk about good relations in a universal context? Is “the just” a universal thing? It’s not as easy as the above example, and I think this is where we really need to call in an expert who has done research in the quality of relations, or someone who knows about law and justice.
Even worse about emergence, complexity, aesthetics: Is there such a thing as universal beauty? I think there is research supporting this, but as a tester, I’ll skeptical about it: I’d rather test with a group of potential users, i.e. stay on the lower level, than employ rules for verifying aesthetic or emergent properties of a thing. Also, I would always suspect such rules are heuristic in nature, not universal.
Safety seems more obvious: Avoid chaos at all cost, and chaos is a reasonably well defined thing, I think, perhaps even mathematically.
But still: In the real it’s complicated. The Picture below is of the UN Building in New York. This is where universal rules for everyone on the earth are negotiated, but even those that have been decided on are often up for debate: We agree we want peace, but how? We agree we don’t want climate change, but at what cost, and who should do it? It’s hard, and as a tester, I want to avoid talking about this level, except as an abstract level I should avoid expressing myself too concretely about.
But that’s all right: I can say a lot of other things. Most of the quality pyramid is readily accessible in my work testing software and the relations real humans have with it.
DSC_3317

Categories
Blog posts in English

A Stage Performance

I did a talk at TestBash Germany last week that sparked lots of positive response, but also some critique. Critique is fair: It was a 30 minute inspirational talk in which I wanted to explain why Immanuel Kant’s work “Critique of Pure Reason” matters to testers. Quite a few people found me afterwards, asked me questions, and commented: Critique. Job well done (I’m padding my own shoulder here).

Categories
Blog posts in English

Immanuel Kant and the Hallucinating Tester

Quality is an illusion. That may seem like a bold statement, but there is a deeper truth to it that I will discuss in this blog. I’ll also discuss how we can approach the real.
We can think of testers as doctors, scientists, or researchers whose job is to research, explore, or examine some software, gather, analyze, and communicate factual knowledge based on observations.
But science teaches us that when we research and observe things, including software, what we “see” is not reality. At TED 2017, University of Sussex neuroscience professor Anil Seth called what we see “hallucinations”.
This gives the hopefully scientific tester some severe epistemological challenges: As she is a person, and is hallucinating, how can she (or we) trust her observations?
The problem for her is that the images that she experiences as real are a synthesis, an intuitive product of her observances based on a minimal amount of sensory data. The critical mindset is important in testing but doesn’t help by itself.
Fortunately philosophy has a solution for her (and us). Before I explain it, let me share a daily life story about intuitive illusions and assumptions.
 

Walking on Black Ice

I was out walking my poodle Terry a few days ago. A car came against us, but as we were on the sidewalk and the car on the road, the situation was intuitively safe.
Unfortunately, my intuition turned out to be wrong as only a moment later my foot slipped on the sidewalk and I realized that the wet road was not wet; both the road and the sidewalk were covered in black ice.
When another car approached I was aware of the danger, and made sure to keep myself and my dog safe.
There could be a moral in this story about always being cautious about cars and roads, but it might end up in over-cautiousness of the type that grandmothers sometimes impose on their grandchildren.
Instead I consider it a reminder that we don’t see things as they are: The road was wet until my foot slipped and I realized it was icy.
Already the Stoic philosophers in Rome 2000 years ago had figured this out.
 

Immanuel Kant’s Model of Mind

In 1781 the German philosopher Immanuel Kant published his mammoth work Critique of Pure Reason in which a key concept is the transcendental, which can be thought of as a bridge between the real and the hallucination.
Let me explain: Something that is only realized by intuition, dreams, myths etc, and which doesn’t link to experience, is transcendent. Something realized by pairing sensing and experience is transcendental.
Kant’s model is simple and straightforward, as Kant was pedantic, but it still needs some explanation:
Outside us is of course the objects which we sense. Kant calls them “the things in themselves”. It could be the road I was walking with my dog.
Kant thinks of us as rational beings who act on the basis of the thing in itself, and that has caused much debate. Skepticism will claim that the thing in itself is not available, and that there is only the subjective experience. Logical positivism will claim that the thing in itself doesn’t exist at all. Realism will doubt the subjective. We can probably all appreciate that the always rational human doesn’t exist.
But Kant’s bridge is interesting. What he says is that even though “the thing in itself” is not available to us, we can still say rational things about what we see.
So the mind is connected to the real in a way so we can gain and share experience. Does it sound weird? In a way it is, but Kant’s arguments has generally stood the test of time and critical philosophers – and even neuroscience.
So let me tie this to testing.
 

Belief as a Premise

There are different ways to test: In exploratory testing, we do it interactively by operating and observing the software. In automated testing we “outsource” the actions to another piece of software, and our task is then reduced to making sense of data from the tests and suggest and possible implement changes to the test-software. Scripted and chartered testing sits somewhere in-between the two “extremes”.
However,no matter how we practice testing, we need to make sense of what is observed. And since observing is subjected to sensing, the only thing we have available is our intuitive image about the thing we are testing.
James Bach is quoted as saying “Belief is a sin for testers.” I like the quote as it is an important reminder to be careful what we think: It’s not reality. The road might not only be wet. The software probably doesn’t always do what it did this time. I probably missed something. My mind is hallucinating.
So with a bit of wordplay in Kant’s home language, German, I’ll say that “die Sinne ist die Sünde.”
Our senses are the sinner, but as they are also our only hope to see some tings about reality belief is not an option. It’s a premise.
But since we know, we can establish the transcendental: Think the real rationally by testing our beliefs.
In other words: The realist approach to testing is to test the product. The transcendental approach is to test beliefs.
 

On Common Terms

There is something missing in the above as so far I’ve only talked about sensing, imagining, and experiencing. The brilliant part of Kant’s philosophy is that he explains how we can collect experiences.
Kant develops four categories of terms that we think by, and argues how they are given to us a priori, i.e. before we experience anything. He argues how they come from the existence of time and space. Back in his time Newton had just published his theories. Today, we’ve progressed, and it probably makes better sense to think of the terms as a result of the experience of space and time.
But what’s important is that although our experiences vary, we’re on common terms, so to speak.
This is important as it means we can think and express our knowledge about experiences generally.
Let me give some examples: I told you about the black ice on the road above, and while cannot be certain what I said is true, you can understand my experience. I can also share a testing problem, and we can imagine solutions together. I can try them out afterwards, and share experiences with you. We can even talk about testing in general, and imagine solutions to certain testing problems in general.
In other words: The terms allow us to relate, connect, discuss, collaborate, learn, reflect, prospect etc.
This makes the transcendental model of experience complete: We can sense, imagine, think, and express our thoughts into words and actions that we can share with others, who can do the same.
 

The Two Things I Want to Say

So what do I want to say with all this? I want to say two things:
The first is that yes, we are trapped in hallucinating minds. We might theoretically be able to escape them if we subject our testing to strict scripted procedures, make sure what we do is repetitively accurate, and only communicate what we can verifiably record and therefore objectively observe. But we’ll essentially be turning ourselves into machines and miss intuitive and tacit knowledge. And one way or another, we’re still stuck in a mess where at every and any judgement and decision made will be based on hallucinations.
But we’re not lost as we can explore the product and our intuitive ideas about it transcendentally, i.e. by realizing that both are in play when we test. Although we can’t get access to the “thing as it is”, we can experience it. Our expeirences do not have to be transcendent, i.e. disconnected from real, but can be transcendental.
And this is the second thing I’ll say: Since we are not alone in the trancendental, our roles as testers become clearer.
People are different, but I think a fundamental, perhaps even genetically coded, qualification for testers is to be sensitive people with intuitions which are easily disturbed by reality. On top of that, great testers need critical thinking skills, i.e. courage to doubt intuitive illusions, and creativity to come up with test ideas useful in the context. The rest is about interaction and communication with teams and stakeholders so that the good hallucinations about the software that we develop through our testing are shared.
 

Testing Transcendentally

In the spirit of Anil Seth, the neurology professor, let’s be honest: Software quality is a hallucination.
We can’t escape our minds and the apparent mess created by the hallucinations we think of as real. But we can experience quality transcendentally by testing.
To me testing is not so much an exploration of a product.
I see testing first and foremost as the transcendental practice of exploring of our own, and our team colleagues’ and stakeholders’ hallucinations about the product.

References

Categories
Blog posts in English

With Cynefin, I can justify skepticism about inappropriate approaches and co-create better ones

As testers we need to better understand and be explicit about problems in testing that don’t have known, clear, or obvious solutions. Cynefin can help by transforming the way we, our teams, and our stakeholders think about testing problems.
Ben Kelly and James Christie has written very good blogs about Cynefin and testing. Liz Keogh was one of the first to write about Cynefin in development. At the bottom of this post, I have included a video with David Snowden and a link to an article I found interesting when I read it.
With this blog post I’m sharing elements of my own understanding of Cynefin and why I think it’s important. I think of Cynefin itself as a conceptual framework useful for comprehending dynamic and complex systems, but it is also a multi faceted “tool” which can help create context dependent conceptual frameworks, both tacit and explicit, so that we can better solve problems.
But before diving into that (and in particular explain what a conceptual framework is), I’d like to share something about my background.

Product design and the historic mistakes of software development

I used to study product design in university in the early 90’s. Creating new and innovative products does not follow obvious processes. Most engineering classes taught us methods and tools, but product design classes were different.
We were taught to get into the field, study real users in their real contexts, develop understandings of their problems, come up with prototypes and models of product ideas, and then try out these prototypes with the users.
Discussing an early draft of this post with James Christie, he mentioned that one of the historic mistakes of software development has been the assumption that it is a manufacturing process, whereas in reality it is far more like research and development. He finds it odd that we called it development, while at the same time refusing to believe that it really was a development activity.
SAFe, “the new black” in software delivery, is a good example of how even new methodologies in our industry are still based on paradigms rooted in knowledge about organizing manufacturing. “The Phoenix Project”, a popular novel about DevOps states on the back cover that managing IT is similar to factory management.
What I was taught back in the 90’s still help me when I try to understand why many problems remain unsolved despite hard work and many attempts on the opposite. I find that sometimes the wrong types of solutions are applied, solutions which don’t take into consideration the true nature of the issues we are trying to get rid of, or the innovations we’re trying to make.

Knight Capital Group, a testing failure

The case of Knight Capital Group is interesting from both innovation, risk and software testing perspectives, and I think it exemplifies the types of problems we get when we miss the complexity of our contexts.
Knight Capital Group was one of the more aggressive investment companies in Wall Street. In 2012 they developed a new trading algorithm. The algorithm was tested using a simulation engine, I assume to ensure to that stakeholders that the new algorithm would generate great revenues.
The testing of the algorithm was not enough to ensure revenues, however. In fact, the outcome of deploying to algorithm to production was enormous losses and the eventual bankruptcy of the company after only 45 minues of trading. What went wrong?
SEC, Securities and Exchange Commission of the U.S.A.:

[…] Knight did not have a system of risk management controls and supervisory procedures reasonably designed to manage the financial, regulatory, and other risks of market access […] Knight’s failures resulted in it accumulating an unintended multi-billion dollar portfolio of securities in approximately forty-five minutes on August 1 and, ultimately, Knight lost more than $460 million […]

But let’s assume a testing perspective.
It think it’s interesting that the technical root cause of the accident was that a component designed to be used to test the algorithm by generating artificial data was deployed into production along with the algorithm itself.
This test component created a stream of random data and was of course not supposed to run in production since it was designed to generate a stream of random data about worthless stock.
I find it strangely fascinating that the technical component that caused the accident was designed for testing.
Why didn’t someone ensure that the deployment scripts excluded the testing components?
Was it software testing that failed? It is not uncommon that software testing is entirely focused on obvious, functional and isolated performance perspectives of the system under test.
The component did it’s job: Helped test the new product. The testing strategy (probably undocumented) however, obviously did not consider possible side effects of the component.
I think Cynefin could have helped.

Cynefin transforms thinking

Let’s imagine we’re test managers at Knight and that we choose to use Cynefin to help us develop the testing strategy for the new algorithm. 
David Snowden talks about Cynefin as a ‘sensemaking tool’ and if you engage Knights’ management, financial, IT-operations, and development people in a facilitated session with a focus on risks and testing,
I’m pretty sure the outcome would be the identification of the type of risk that ended up causing the bankruptcy of the company, and either prevented it by explicitly testing the deployment process, or made sure operations and finace put the necessary “risk management controls and supervisory procedures” in place.
I think so because I have observed how Cynefin sessions with their brainstormings are great for forming strategies to deal with the problems, issues, challenges, opportunities etc that we are facing. It helps people talking seriously about the nature of problems and issues, transforming them into smaller chunks that we can work with, and to help escalate things that require escalation.
Cynefin seems to be efficient breaking the traditional domination of boxed, linear and causal thinking that prevent problem solving of anything but the simplest problems.
My interpretation of what is happening is that Cynefin helps extend the language of those participating in sessions.
Decision makers a Knight Capital did not think about possible negative outcomes of the testing software. They had a simplistic view of their business risks. Cynefin could have helped them by extending their ‘sensemaking’ to more complex risks than those they were focusing on.
In the following I’ll dive a bit more into why I understand the sensemaking part of Cynefin to be a language-extending tool.

Language and Conceptual Frameworks

Language is an every-day thing that we don’t think much about.
Yet it is the very framework which contains our thinking.
While we can know things we cannot express (tacit knowledge), we cannot actively think outside the frame language creates.
Many philosophers have thought about this, but here I’d like to refer to physicist Niels Bohr (1885-1962) who in several of his lectures, articles, and personal letters talks about the importance of language in science.
Science is in a way about sensemaking through knowledge gathering and poetically (paraphrasing from my memory) Bohr describes language as the string that suspends our knowledge above a void of endless amounts of experiences.
In “The Unity of Science”, a lecture given at Columbia University, New York in 1954, Bohr introduce language as a “conceptual framework”:

“[it] is important […] to realize that all knowledge is originally represented within a conceptual framework adapted to account for previous experience, and that any such frame may prove too narrow to comprehend new experiences.”

And:

“When speaking of a conceptual framework, we merely refer to an unambiguous logical representation of relations between experience.”

Bohr was the father of quantum physics, which is more than new laws about nature. It introduced new and complimentary concepts like uncertainty, and non-deterministic relations between events. The extension was made for quite practical purposes, namely the comprehension of observations, but has turned out to be quite useful:

“By means of the quantum mechanical formalism, a detailed account of an immense amount of experimental evidence regarding the physical and chemical properties of matter has been achieved.”

The rest is history, so to speak.
This is relevant to software testing and Cynefin because I think that the conceptual frameworks based on the thinking developed during industrialism are far from capable of explaining what is going on in software development and therefore also in testing.
Further, Cynefin seems to be an efficient enabler to create extensions to the old thinking frameworks in the particular contexts in which we use it.

Cynefin and software testing

Software development is generally not following simple processes. Development is obviously a human, creative activity. Good software development seems to me to be much more like a series of innovations with the intention to enable someone doing things in better ways.
Testing should follows that.
But if language limits us to different types of linear and causal thinking, we will always be missing that there is generally no simple, algorithmic or even causal connection between the stages of (1) understanding a new testing problem, (2) coming up with ideas, and (3) choosing solutions which are effective, socially acceptable, possible to perform, and safe and useful.
Experienced testers know this, but knowledge is often not enough.
James Christie added in his comments to the early draft mentioned above that as testers, with Cynefin we can better justify our skepticisms about inappropriate and simplistic approaches. Cynefin can make it less likely that we will be accused of applying subjective personal judgment.
I would like to add that the extended conceptual framework which Cynefin enables with us and our teams and stakeholders further more allow us to discover new and better approaches to problem solving

David Snowden on Cynefin

This video is a very good, quick introduction to Cynefin. Listen to David Snowden himself explain it:

 
AI personally found this article from 2003 a very good introduction to Cynefin:
The new dynamics of strategy: Sense-making in a complex and complicated world (liked page contains a link to download the article)
 

Categories
News in English

Chaos to Kairos – NYC May 1st session on playful testing skills with music and philosophy

Jessica Ingrassellino and I will perform a workshop at the NYC Testers Meetup on Monday May 1st during the Test Leadership Congress. Join the meetup to participate.
The session will be based on the workshop we did at CounterPlay, an international play festival which took place in March in Aarhus, Denmark. Titled “Playful Software Exploration” the topic was value driven improvisation skills in testing. Together with the participants we tested, performed music and formed a philosophical, protreptic circle
The somewhat disturbing background of the workshop is that in a performance oriented and individualized tech industry, we are expected to drive ourselves to be the best in a complex or even chaotic reality. Remaining true to our professional and personal values while staying sane and ready to act and perform every day can be very challenging.
Our CounterPlay workshop was a success. Collaboratively we gained sense of and got to the core of important values in testing. We were even interviewed for the popular show “The Harddisk” on Danish national radio.
This time we would like to playfully explore the significance of Kairos in testing.
Kairos is Greek and means the supreme moment in which the future is transformed to the past with a particularly fruitful outcome. Kairos is important in rhetorics because while there are rules of good communication, there are moments in which speaking and acting is particularly fruitful: There is a time and space for the good talk. And even the best performance will fail if kairos is not considered.
This is an aspect of all improvisation and play, and good testing is in many ways always an improvised, playful act.
We know it when we perform exploratory testing.
But even when testing is turned into a controlled and scripted process, it makes sense to perceive testing in the microscope as a playful exploration and experimentation with potential and actual outcomes – even outcomes beyond the directly observable testing results: E.g. learning points for developers and management.
At the core is that testing makes a difference for people around us, even those who are not directly involved in testing and developing.
So let’s think beyond the processes, and functional and technical perspectives on testing, and explore software testing as a playful and human event with potential to create order in due time.
No prior knowledge or talents are required to join the workshop. But bring curiosity about values in testing, and be ready to play and improvise, introspect and think and reflect abstractly.
Best,
Jess and Anders

Categories
Nyheder på dansk

Kunsten at tvivle: Proptreptisk samtalesalon nr. 8

Det er videnskaben, der bærer vores samfund i dag, og med den følger søgen efter forståelse. Med forståelse kan vi skabe nyt og blive rigere og sundere.
Forståelse indebærer, at vi indtager et standpunkt, altså står ét bestemt sted. Dermed stiller vi os i modsætning til andre standpunkter: Forstår vi noget, kan vi ikke indtage flere modstridende standpunkter om det, vi forstår.
Så med forståelse følger holdning.
Holdning baseret på forståelse virker vigtigere end noget andet, når vi skal tage store beslutninger. Hvordan mon statsministeren eller præsidenten tænker, når han skal sende sit land i krig: Tvivler han og ryster på hånden? Eller har han læst og forstået situationen eksakt og præcist og udmønter derefter forståelsen i handlekraft?
Visheden, der følger med forståelsen, giver sikkerhed og signalerer styrke. Dens modstykke, tvivlen, kan være tegn på uduelighed og svaghed.
Men måske rummer tvivlen alligevel noget godt?
Mange krige har i eftertidens dom vist sig meningsløse og måske mest baseret på rygter og løgne. Vi ved det egentlig godt: Tit søger folk jo ukritisk efter vished og giver måske sig selv og andre indtryk af sikkerhed og styrke men snyder i sidste ende kun sig selv og andre.
Måske findes der en værdifuld, reflekterende tvivl, en dyd, som vi som ledere og mennesker bør kende og opdyrke for at bevare og udvikle kritisk sans og en sans for de sandheder, der rummer nuancer, der ikke kan måles videnskabeligt og sikkert?
Det kræver mod at tvivle, men tvivlen må i alle tilfælde være nødvendig, for at vi personligt og organisatorisk kan mestre de irrationelle psykologiske for-forståelser og mavereaktioner, som alle mennesker trækkes med.
Ja måske er tvivlen ligefrem en forudsætning for at kunne handle empatisk og begavet i det daglige?
I denne ottende samtalesalon vil vi derfor lede efter værdier i og omkring tvivlen, ja dyrke selve kunsten at tvivle.
Tilmelding er obligatorisk – og det er afmelding i øvrigt også, hvis du bliver forhindret. Hvis vi har tomme stole, vil vi nemlig gerne kunne give dem til andre interesserede.
Vi glæder os til at se dig!
Dato: 15. maj 2017
Tidspunkt: 16.00 – 18.30
Sted: Gjesing Coaching, Prinsesse Charlottesgade 31, kld, 2200 København N
Tilmelding til: karengjesing@privat.dk (obligatorisk af hensyn til forplejning)
Kærlige hilsner
Karen og Anders

Categories
Blog Blog posts in English

Playful Software Testing

I met with and enjoyed a very good conversation with Jessica Ingrassellino in New York back in September. Jessica presented a workshop on playful testing during the Reinventing Testers Week (I presented at the conference about “Testing in a Black Swan Domain” which, unfortunately, I have not had time to write about yet).
We talked mostly about philosophy.
Jessica is quite a multi-talent: Plays the violin virtously, is an educated music teacher, has switched career to testing, taught herself Python, authored a book on Python programming for kids, and is teaching Python classes at a local community college, as well as music classes.
She has a vision of making testing playful and fun.
Structured work govern testing in professional settings, work which has nothing to do with play. So why is play important?
Jessica puts it this way:

When the power of play is unleashed in software testing, interesting things happen: The quality of the testing performance becomes noticeably better, and the outcomes of it too. This results in better software systems, higher product quality.

I have a product engineering background and play is important for me too. Engineers have methods, calculations, and procedures, but great engineers know that good solutions to problems are not found by orderly, rational processes. Good solutions depend on creativity and play.
Friday December 9th, I met with Mathias Poulsen in Copenhagen. Mathias is the founder of CounterPlay, a yearly conference and festival on serious play in Aarhus, the second largest city in Denmark.
About three years ago, Mathias got the idea for the conference.
In the first year, 2014, it was an immediate success with more than 20 talks and workshops in 3 tracks on “Playful Culture, Playful Learning, and Playful Business”, and more than 150 participants. This year (2016), the conference had 50 scheduled sessions: keynotes, talks, workshops, mini-concerts and open sessions.
Mathias explains (about 0:30 into the video):

Counterplay is basically an attempt to explore play and being playful across all kinds of domains and areas in society. We are trying to build a community of playful people around the world to figure out, what does it mean to be playful and why do we think it is beneficial?

Processional IT has so far not been represented at the conference, Mathias told me. I found that a bit surprising, as at the moment almost everything in IT seems to be buzzing with concepts promising joy and fun – play.
Sometimes, however, there is an undertone to all the joy. Agile and DevOps have become popular concepts even in large corporations, and to me, both strive to combine productivity with playfulness. That is good.
But is the switch to Agile always done in order to pass power to developers and testers, allowing them to playfully perform, build and test better solutions? No, not always.
Play facilitate change and breaking of unhelpful patterns, but sometimes play is mostly a cover for micromanagement. There is a word for this: In a recent blog post, Mathias talks about playwashing:

Playwashing describes the situation where a company or organization spends more time and money claiming to be “playful” through advertising and marketing than actually implementing strategies and business practices that cultivate a playful culture in said organization.

A question is therefore how we genuinely support play? Are there methods or processes that better accommodate playfulness at work?
I believe there is. Processes need to leave space for exploring context, knowledge sharing and actual interaction with customers, stakeholders and team members.
But processes or methods will not do the job alone. In fact, putting play under the examination of psychology or cognitive sciences will never be able to grasp what play really is.
Play is more like music and poetry, where ideas based on assumptions about order, rational choice, and intention cannot explain anything.
Philosophy and especially the dialectical exploration of what it means being a playful human is much better at embracing what play means to us and how to support it.
Jessica and I are working on a workshop about playful and artful testing. It will combine ideas of playful testing with philosophy.
We are certain that breaking out of patterns will help testers, and breaking out of our patterns, participating in a conference which is fully devoted to play will teach us a lot.

dsc_5398
I took this photo in the local forest on a walk with our dog Terry (the black poodle). It is obvious, when dogs play well, that they have fun and learn a lot through play. Play seems a fundamental capacity for mammals.