Author: Anders Dinsen

Categories
Blog posts in English

Don't shoot Sparrows with Cannons: Reassess Yourself

This is the second blog post sharing inspiration from the Reinventing Testers week.
The WITS Sunday peer workshop that preceeded the conference on Monday and Tuesday had some very interesting discussions over this subject. The first I’ll blog about is one Simon Peter Schrijver started.
What he said sparked my mind on contrasts about “reinventing or reassessing ourselves” in new contexts.
At one point in the workshop, I think we were getting high on our fantastic combined abilities around the table to adapt and reinvent Context Driven Testing. Fortunately Simon brought us back to earth, so to speak, as he shared with us that when changing jobs, projects, organisations and contexts, he found that he is really only reassessing himself.
I challenged him on that, after having looked up stuff online about the meaning of the words, but I later realized he was right: We often “only” reassess ourselves. Only is in quotes here, since it is not trivial.
Let me share my understandings of reinvention and reassession.
Reinvention must have something to do with creativity, which is fundamentally about giving up our preformed solutions and starting over from scratch. The only thing we keep is a guiding image, something we wish to achieve, a problem to solve.
But first we have to return to our newborn states of mind, and listen carefully for new and original solutions our minds could be suggesting.
I have an introspective image of how it works: First I relax, give up on everything I know, and accept that I am vulnerable and fragile. In the next moment, I regain a sense where I am, who I am, and what I’m up to. And that’s when the flow of ideas begins.
Reassessment must be totally different.
Originally, assessment had to do with accounting, where an assessing the accounts involving verifying their validity.
Thus, if I am reassessed, I am reverified. Revalidated could be synonymous.
My introspective image of reassessment of myself in a new context is one of me entering my minds’ inner archive of carefully labeled, preformed solutions, finding those that seems to bear the name of the particular testing problem I have, and then apply them, validating (assessing) in the process that this still works.
It does depend on me having experience, but it also depends on my ability to assess whether the knowledge and experience I dig up works in the particular context.
My experience and knowledge is applied, and I assess it. I don’t apply it mindlessly.
Simon is a great tester and thinker with enormous experience. He reminded us that – in many ways -, changing contexts does not mean throwing overboard what we know.
It is often only the pieces that make up the context, which appear different. They aren’t necessarily really new.
Reinvention certainly has its place, and I’ll get back to that later, but Simon reminded me that we shouldn’t shoot sparrows with cannons.
 

dsc_4325
The WITS workshop was run in LAWST format: personal ERs (experience reports) from the participants, followed by an ‘open season’ – a facilitated group discussion. Simon wore a very nice t-shirt at the workshop.

 

Categories
Blog posts in English

If You See Something, say Something

I have been back in Copenhagen a few days now after Anna Royzman’s excellent fall 2016 testing conference Reinventing Testers in New York during the week of September 25th to 29th 2016. This is the first of probably a few blog posts sharing thoughts and inspiration from the conference.
I am a test consultant. Helping solving clients testing problems efficiently and in meaningful ways is crucial to me. Reinventing and reasserting myself as needed, and staying critical to both my own preformed ideas and towards others’ is necessary.
I need to go to testing conferences. It allows me a break out of my daily social obligations so that I can better stay true to what I believe in.
It is about getting new inspiration, learning and sharing, and eventually about maintaining my performance as a tester and test manager.
During the Reinventing Testers conference, I had some very interesting discussions with James Bach about freedom. He and I agree that personal freedom is fundamental in testing.
“The human spirit should not be put under a hat,” he said at one point during the conference, and I fully agree. But freedom is also about relation.
I walked around Lower Manhattan on Wednesday, and in the window of a bank or insurance company of some sort, I saw a message on a poster: Feeling free is not worrying what your neighbors think.
The message disturbed me as I feel underlying it is a reassertion to the lonely and insecure that other people should not matter: That one is only free, alone.
This is obviously wrong.
True freedom depend on us becoming ourselves, but certainly also on relations towards other people: Shared and differing talents, perceptions, opinions, values, moral codexes.
People are different, but we’re tied together in so many ways.
In technology, freedom relates to safety and quality. I started writing this blog post on the way home on an SAS Airbus A340-300 which was at the time flying more than 900 km/h through the thin air, 12 km above the North Atlantic.
The flight was good and safe, and I was free to think there.
But only because people had worked to make it safe.
And this is important: A good deal of the work needed to make systems safe involves careful testing and as testers we relate to people: Clients, users, stakeholders etc.
We help make them free.
The conference had a special nerve, I think, and I think I can label it.
If you see something, say something, signs say in the New York subway. New Yorkers don’t have to all like each other, but it was obvious to me, that they know that they are only free, together.
And that is a pretty cool attitude to freedom, I think.
 

dsc_4333
James Bach inspecting a piece of abstract art. Could it represent freedom? 🙂

 
 
 
 

Categories
Blog posts in English

Welcome to Oz

It’s fun to arrive in a new country and get a sense of the culture. This is my first time in Austrailia.
”What do you want, mate?”, said the guy in a kebab bar in Sydney. And he looked me directly in my eyes. That blew a fuse in my brain!
If someone in Denmark looks me in my eyes and say: ”What do you want?”, I know I’m in trouble and should get away quick. But I was in Sydney and the kebab guy was just a helpful Australian. He made me a great kebab with fries, which was just what I needed for my jetlagged body.
DSC_0258
Australians are wonderfully helpful… and very direct. A woman asked me if I needed help with my bag when I was walking down stairs. A guy approached me to offer directions for me. ”Thank you”, ”No worries, mate!”
I’m down under, what on earth should I worry about?
I’m here to attend and speak at Let’s Test Oz 2014 taking place in Blue Mountains outside Sydney. What a setting! What a conference! I’ll have to come back to that in a blog post after the conference. For now, I’ll just share my immediate impression of Australian culture.
DSC_0294
Words make a difference. Americans love words of latin origin, I think it makes them feel important. They have ”view points” in the landscape. Aussies call things what they are: Lookouts.
Europeans have ”colleagues”. It makes us feel smart. Aussies are ”workmates”.
“Mate” is a funny word. In the animal world, mates are sexual partners. Dictionary.com lists ”partner in marriage” as the first of seven definitions of “mate”. The word is of German origin, coming from ”gemate” which just means someone eating on the same table.
A porter in Australia will say ”After you, mate” and look you in the eyes, whereas a porter in the UK will say ”after you, sir” and look down.
Walking down to the Opera House on Sunday morning, I saw the sign in the photo below. Note that the someone changed the text, but even if it hadn’t, I’ve never before seen a public sign telling people what kind of language to use:
”The following is prohibited… Use of obscene or indecent language… Penalties apply”
What if someone takes a megafone and starts shouting obscene and indecent language (it’s ok to use your imagination here) from the coast? Would that be ok? I should try, shouldn’t I? After all, I am a tester.
DSC_0261 (1)
In Denmark, we would never put up such a sign. We’d just silently push people off the wharf and leave them to drown in the water if they don’t talk nicely and behave according to our unwritten rules. Yes, we might be the happiest people in the world, but that’s only because we’re ready to exclude anyone who isn’t.
Is there a flipside? I haven’t seen it yet, but I’ve seen and heard enough to notice that testers have the same problems in Australia as in the rest of the world. Also, I’ve been told that organisations are strictly hierachical, according to colonial tradition. Coming from a culture in which organisations are flat and everyone usually has very direct access to managers on all levels, and where colleagues appraise each other for speaking against the manager, that always surprise me.
There may be more to it, however. I’m not sure.
Enough for now. Enjoy Let’s Test Oz if you’re here! I know I do.

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.)

Categories
News in English Nyheder

I'll be at Let's Test Oz in Sydney in September

DSC_0540AI’ll take a 22 hour flight Copenhagen to Sydney in September, where the fourth Let’s Test conference and the first Let’s Test Oz will be held at a resort in Blue Mountains, New South Wales, Austrailia.

The conference programme was announced a while ago, and it’s pretty awesome. I’ve attended and spoken twice at Let’s Test in Stockholm. I’m sure the Oz-edition will be as fantastic as its Stockholm counterpart.

I haven’t yet decided on my program, but I’m looking forward to Fiona Charles’ keynote by Fiona Charles and her workshop on leadership
But there’s a lot of promising stuff in the programme

I insist that testing is and should be a value adding activity. As testers, we’re not just finding other people’s mistakes; we make a positive contribution to the project with the knowledge we are collecting in our testing.

To do great testing takes clever thinking, and clever thoughts never live in isolation. They’re shared, bounced and developed into great ideas. Let’s Test is an inspirering conference, a place where great ideas develop, and that’s why I like the conference so much.

My own contribution to the programme this year is a session about politics called “All is fair in love and war”. I commit to context driven testing, but testing can be a driver for change as well. I find that a key to do it is to do clever politics on top of the knowledge we have and collect in testing. Some testers have grown to hate politics, but politics can help us, if we use it wisely: With an ethical standpoint, and with a sound vision of what we want to achieve.

Twice has Let’s Test refuelled my capabilities as a tester, a test leader, a test manager, and a test analyst. Twice has Let’s Test inspired me and given me new friends and acquaintances. I’m looking forward to my third Let’s Test, this time down under, where I expect to meet some great testers from the southern hemisphere, take time for a good talk, do some testing, have a beer or two, take a walk in nature…

You can register for Let’s Test Oz here.

Categories
Blog posts in English

"A demain!" – story about dealing with a sales-focused vendor

Have you worked with a service vendor which consistently did not meet dealines, yet you still kept buying services from them?
This is a story about a car manufacturers’ service organisation being geared towards sales – not service. I’m sharing it here because it has analogies to what’s happening in the software industry. So I hope you’ll stay with me:
My Renault Espace broke down on a vacation in France. It’s a great car, usually very reliable, but like anything else, it has its weak points. The gearbox is one of them: I’ve seen numerous reports on failing gearboxes. Mine did 277,000 km before failing. Not bad, considering…
I delivered the car to a large Renault operation in the city of Frejus on the Côte d’Azur. I was well received, there was even a girl speaking English. I felt comfortable, and got a chance to look at the new cars.
Repairing an automatic gearbox is a specialist task, but replacement gearboxes are available. I started looking at the various options for repair – and for getting the family home to Denmark before our vacation ended.
So I asked the manager at the garage two questions:

  • How much will a repair be?
  • When will the car be ready?

Now, I’ve done a bit of work on my cars over the years, and I know that unplanned things can happen, so I was happy that he gave me a conservative time estimate that would allow for delays in the process. I was most worried whether a new gearbox was in store somewhere in the Renault network, but there was one in Paris, so I accepted.
And with the replacement gearbox arriving from Paris just a few days later, I was happey. When I checked with the garage, they told me they’d start working the same day, and I could have the car two days later. That would be one day earlier than promised.
”Sounds good, we’re ahead of plan,” I thought, and since buffers are always good to have, and I felt I could accept the optimistic estimate. I still trusted them.
But I was in for a surprise when I called two days later to ask about pick up. The answer was ”a demain!” – tomorrow. Any problems?, I asked. No, no problems, they said, ”a demain”.
I went to see the car later the same day, and the picture here shows what found: Note that the old gearbox is still in the car. The mechanic had obviously not started working on my car the day they said he would do it.
IMG_8259-3-SMALL
”C’est possible,” they claimed next day when the mechanic was still busy reassembling the car. I didn’t trust that, as the car obviously needed more work than was available on that day only. A sound test drive, for example!
As I’m writing this, I’m waiting for my car, sitting next to the service counter, where cars are registered for repairs. There’s a large poster showing the people working in the garage – and then there are all the new cars here. I like the electric vehicles Renault is offering, and everyone here is smiling and polite, even the service people. I feel comfortable here.
Renault’s business model is 100% sales oriented: They want me to buy services, buy a new or newer car instead. They smile and tell me all sorts of apparantly good reasons why the repair was delayed – they have even apologized to my family.
But there’s one thing they haven’t told me yet: They prioritized someone else’s car over mine, and they didn’t start working on it until there was no slack in the plan anymore.
This could be an example of french ”laissez faire” attitude, but I don’t think so. I’m not at all worried about the quality of the repair itself, as I saw the mechanic several times while he was working on the car. I know how Renault train their mechanics, and it was obvious that he was doing a really proper job.
No, It’s the planning that sucks. they didn’t know when they’d be done, so they didn’t call me to let me know the plan was in jeopardy. They just hoped. Even today they said: ”Dix heures”, and it’s now 09:59.
The interesting thig is that this is supporting their sales! It’s obvious that Renault has tuned even their flawed, but kind service organisation towards new sales.
How is YOUR vendor tuned?
PS: I’ve got the car now, and it’s as great as ever. Ready for at least another 150,000 km!

Categories
Blog posts in English

Speaking to Management: Coverage Reporting

Test coverage is important. In this post, I will reflect about communication issues with test coverage.
The word coverage has a different meaning in testing than in daily language. In daily language, it’s referring to something that can be covered and hidden completely, and if you hide under a cover, it will usually mean that we can’t see you. If you put a cover on something, the cover will keep things out.
Test coverage works more like a fishing net. Testing will catch bugs if used properly, but some (small) fish, water, plankton etc. will always pass through. Some nets have holes through which large fish can escape.
What’s so interesting about coverage?
When your manager asks you about test coverage, she probably does so because she seeks confidence that the software works sufficiently well to proceed to the next iteration or phase in the project.
Seeking confidence about something is a good project management principle. After all: If you’re confident about something, you are so because you don’t need to worry about it. Not having to worry about something means that you don’t have to spend your time on it, and project managers always have a gazillion other things that need their attention.
The word is the bug
So if confidence comes out of test coverage, then why is it that it managers often misunderstand us when we talk about coverage?
Well, the word actually means something else in daily language than it does when we use it in testing. So the word causes a communication “bug” when it’s misunderstood or misused.
We need to fix that bug, but how? Should we teach project managers the ”right” meaning of the word? We could send them to a testing conferences, ask them to take a testing course, or give them books to read.
That might work, but it wouldn’t solve the fundamental communication problem. It will move higher up in the organisational hierarchy.
An educated manager will have the same problem, not being able to make her peers and managers understand what ”test coverage” means. After all, not everyone in the organisation can be testing experts!
STOP mentioning coverage
A good rule of thumb in communication is: When your communication is likely to be misinterpreted, don’t communicate.
I, as a tester knows what test coverage means and more importantly what it does not mean, but I cannot expect others to understand it. Thus, if I use the word, I will probably be misunderstood. A simple solution to this is to stop using the word. So I won’t say sentences like: Our testing has covered some functionality.
The thing I can say is: We have carried out these tests and we found that.
This will work well until someone asks you to relate your testing to the business critical functionality: Ok, then then tell me, how much of this important functionality do your tests cover?
Uh oh!
Stay in the Testing Arena – or be careful
American circuses have enormous tents and two, three or even four arenas with different acts happening at the same time. A project is always going on in different arenas as well: For example we might have a product owner arena, a development arena, a test arena, and a business implementation arena.
Some people play in several arenas: I think most testers have at some point in the career made the mistake of telling a developer how to code. Likewise, we can probably all agree that there’s nothing more annoying than a developer telling a tester how to test.
Confidence belongs in the product owner arena, not in testing. This is because testing is about qualifying and identifying business risks, and since confidence does not equal absence of risks, it’s very hard for us to talk about confidence. And coverage.
This doesn’t mean you can’t move to another arena.
You can indeed look at things from the product owners perspective, that’s perfectly ok! Just make sure you know that you are doing it and why you are doing it: You are leaving your testing arena to help your product owner make a decision. Use safe-language, when you do.
Talk facts and feelings
Confidence is fundamentally a feeling, not a measurable artefact. It’s something that you can develop, but it can also be communicated: Look confident, express confidence, talk about the good stuff, and people around you will start feeling confident.
Look in-confident, express worry, talk about problems, and people around you will start feeling worried.
Testers always develop feelings about the product we’re testing, and we can communicate these feelings.
I know two basic strategies in any type of test result communication:

  • Suggest a conclusion first, then tell’m what you’ve done
  • Give them all the dirty details first, then help your manager conclude

Which communication strategy you pick should depend on the context, e.g. your relation with the manager. If everything looks pretty much as-expected (whether that’s good or bad), your manager has trust in you, and you have good knowledge of the business risks, then I wouldn’t worry too much about serving the conclusion first, and then offer details later mostly to make sure you and your manager doesn’t misunderstand each other. And that nobody will later be able to claim that you kept silent about something.
But if something is way off, or your manager doesn’t trust you (or you don’t trust her), peoples lives may be at stake, or you just have no idear what’s happening, then stick to the details – do not conclude. And that, I think, implies not using the term ”testing coverage”.

Categories
Blog posts in English

A Sustainable Mission for Context Driven Testing?

This image changed the world. It was taken from Apollo 9 in 1968 and shows the blue Earth rise over the grey and deserted Moon. Our world seems fragile.
This image changed the world. It was taken from Apollo 9 in 1968: “The vast loneliness is awe-inspiring and it makes you realize just what you have back there on Earth,” astronaut Command Module Pilot Jim Lovell said. Image credit: NASA.

I have lately become worried about certain developments in society.
For years, scientists, politicians and others have warned us that we’re responsible for irreverisble changes to our planet: Climate changes, most notably. They’re telling us we need to change to sustainable energy sources.
Sustainability is about more than energy, and I’m worried that in the society changes imposed upon us by the combined effects of globalization and the need for serious resource conservation, we are at the same time becoming increasingly indifferent about the lives of certain groups of people. I remember how many used to be develop deep feelings of indignation when pictures of hungry or poor children were shown on tv. It has changed and such pictures don’t have much effect any more. And worse: We genrally don’t even care about poverty close to ourselves.
I feel this may be linked to a macroeconomic pattern we’re seeing almost everywhere in the world: The rich are getting richer, but the poor are still as poor as they used to be. In Southern Europe, we have enormous unemployment among young people. Economists are raising a warning that we are about to loose a whole generation.
Does this affect testers too? After all we’re safe, working in IT, technology of the future?
Well inequalities in income and life conditions are growing on our planet, and this is worrying, since inequality has historically been a trigger of wars and revolutions, and has always been damaging to democracy and society as a whole. So yes, I think we have very good reasons to be worried about the future for ourselves, our families and for our societies.
James Bach recently published a blog post which has inspired me. Testing is a performance, not an artifact, he says. It made me think about how I differentiate the great testing performance from the poor performance. Is it only a subjective measure (aka ”the music performance was good”), or could there be some objective measures in play?
I think we should judge the testing performance by the artefacts it produces: Knowledge artefacts which are valuable in the business context in which we’re testing, income artefacts to me as a tester, and entertainment artefacts (testing is fun).
But I’ve realised that there is something missing: The performance should also be judged by its contribution to society as a whole. Testing should somehow contribute to sustainability in order to be a meaningful profession for me, social sustainability as well as energy and materialistic sustainability.
This can be taken as a strictly political point of view, and I could choose to execute it by only accepting jobs in socially responsible companies and in organisations and comapnies which are making sustainable products.
But it can also be seen as a mission for our craft as a whole. Like science itself has had to face the fact that it is not just a knowledge producing activity, but has to face the fact that it is changing society by the knowledge it is producing, we as testers also have to face the fact that the knowledge we are producing is applied by certain ways. Being a responsible tester does not mean that I’m only responsible for testing.
Therefore, I think that we should take on the endavour to develop our craft from being just a knowledge producing performance, to be a wisdom producing performance.
Philosopher Nicholas Maxwell is the author of ”From Knowledge to Wisdom” in which he outlines a revolution in science. In the introduction to the second edition he writes (p 14, second ed. 2007):

There is thus, I claim, a major intellectual disaster at the heart of western science, technology, scolarship and education – at the heart of western thought; and this long-standing intellectual disaster has much to do with the himan disasters of our age, our incapacity to tackle more himanely and successfully our present world-wide problems. In order to develop a saner, happier, more just and humane world it is certainly not a sufficient condition that we have an influential tradition of rational inquiry devoted to helping us achieve such ends. It is, however, I shall argue, a necessary condition. In the absense of such a tradition of thought, rationally devoted to helping us solve our problems of living, we are not likely to resolve these problems very successfully in the real world. It is this which makes it a matter of such proound intellectual, moral and social urgency, for all those in any way concerned with the academic enterprise, to develop a kind of inquiry more rationally devoted to helping us resolve our problems of living than that which we have at present.

Should this apply testing, as well as “science, technology, scolarship and education”? Yes, it certainly should. Will it be easy to adopt this thinking in testing? No, not at all.
First of all, we shouldn’t start throwing away any of the good things we’ge learnt and developed. Like the ”scientific method” is still a necessary but not suffucient condition for the progress of science, our values and ideas about great testing are still all-important in testing. They are just not sufficient.
I think we who belong to the Context Driven Testing school are far better equipped than other testing schools to accept the sustainability point of view. After all, we’re already successful developing testing into a sustainable performance. Other testing schools still struggle with their explicit or implicit underlying short-term profit-making ambitions.
And although we’re obviously playing a polyfonic music piece, speaking many voices, not saying or meaning exactly the same about testing or CDT, it seems to me that everyone in the CDT school share the mission of developing testing as a craft as a creative, value producing performance, where value is what matters to stakeholders of the product under test. Let me call this our shared mission.
This is a wonderful mission, but in the new context, it has to give way for a better one: We’re only percieving the craft of testing in isolation or in its immediate context, and we have to raise our heads and relate our craft to the greater context of society.
So I propose that we in the Context Driven School adopt the mission to develop testing towards being a wisdom enhancing performance, where wisdom is knowledge that helps build a sustainable society.
What do you think?

Categories
Blog posts in English

Testing Hopes for 2014

DSC_0540A
Christmas is a ”Lichtfest” for us in the North. Daytime, at this time of year, only lasts a few hours and the sun never really rise on the horizon. Christmas reminds us that light days will return and it’s time to look ahead on the year to come.
I have two hopes for software testing for 2014:

  1. I hope we will stop looking for simple explanaitions why something failed: The product, the testing, the development.
  2. We cannot expect all managers to be testing experts, so we need better documented and qualified testing practices (in various contexts) in order to support better top management software testing decisions.

Looking back on 2013…

I had a busy 2013, privately as well as professionally. Let’s Test in May was fantastic! A few weeks later, I gave a successful lecture on Context Driven Testing in IDA-IT.
I have for long wanted to link my favorite philosopher Niels Bohr to testing. Denmark celebrated the 100 year anniversary of Niels Bohrs articles on the atom model this year. Niels Bohr was a Nobel Prize wining physicist, but more than anything, he was a philosopher – my favorite philosopher by far.
My second favorite is Nassim Taleb. Taleb published his new book Antifragile in late 2012, and I read it this year. But it was his previous book Black Swan that made me a fan.
In chapter 12 of Black Swan, Taleb criticizes historicism: Always wanting to find causes of why things happen. That happens a lot in testing too:

  • ”Why was that bug in the system!?”
  • ”Why didn’t test find it!?”
  • ”Who blundered!?”

Taleb points out that explaining an event is just as difficult as predicting the future. He argues that any logical deductions and computations involved in analysing an event will yield random results.
Good managers knows that appreciating and handling a team’s frustration over something not going as planned is important, but we are too often committing the error of turning a psychological healing process into a development system, mindlessly making up apparently deterministic explanations for the unexpected – the random.
Randomness and historicism
Randomness is actually two different things: (1) Indeterministic mathematical radomness. (2) Something that is acting chaotically, but still according to deterministic laws.
The ”butterfly in india” is an example of a chaotic, but deterministic chain of events: It is said that the beating of a butterfly’s wings in Delhi can cause a thunderstorm in North Carolina.
According to Newtonian and relativistic physics, determinism is a fundamental property of nature, but since most of the events involved in the forming of the thunderstorm are outside our reach, we won’t be able to reconstruct the event completely anyway.
This is perhaps where Taleb and Bohr might disagree, since Bohr did not believe in determinism as a fundamental property of nature.
With quantum physics, Bohr, Heisenberg, Pauli and other pioneers were able to show that events on the nuclear level do not follow rules of causality. An electron, for example, moves from one energy level to a lower, releasing a photon, spontaneously.
”So what? We’re not living in microcosomos. Butterflies don’t move electrons, they set complete molecules in motion. Causality should still apply on any observable level.”
This is a valid counter argument, but Bohr, in several of his philosophical writngs, points out that the lack of casualty on the subatomic level does in fact affect the macroscopic level: There are many amplification systems in nature, which amplify single quanta of energy into macroscopic effects. One such is the human eye, which can detect single photons and amplify it as a stream of information sent to the brain, where it can trigger actions. Obviously there are lots of such amplification systems in the brain and our bodies, so maybe there’s no such thing as determinism in people? And in nature in general, for that matter.
Does having a bad childhood make someone bad?
Se we’re essentially left with a world of repeatable patterns. Statisticians know that children of poor parents will usually be poor themselves. That is a well known pattern, but does it work the other  way too? Does a bad childhood make you a bad person?
Obviously no. The pattern cannot be linked to the individual, per se.
But that doesn’t mean patterns aren’t useful: Patterns simplify reality, and simplification is necessary in all planning and management.
Many projects have contracts which are negotiated several years before the testers start. Such contracts often specify which kinds of testing should take place e.g. how acceptance testing should be carried out.
Now, we can’t expect all IT contract managers to be testing experts, but if we can document research evidence of the usefulness of e.g. exploratory testing, we’re much more likely to be able to convince them to use it constructively, even when they’re working on the early planning phases.
Happy 2014!

Categories
Blog posts in English

Integration Testing and Technology Convergence

I have grown to like my Android smartphone quite a lot. It’s about a year old now, but I’ve had a few smartphones over the last couple of years. This one, however, is the first where I feel it is making my life slightly better. The thing I really like is that it has ‘everything’ inside it, and that it all works reasonably well: In addition to being a phone and a communication device, it’s a torch, a camera, a map, a calculator, a travel booking service, a map, and it allows me to stay in touch with my good friends no matter where I am.
All my previous Android and Windows CE based smartphones sucked with everything they did, except texting, calling and playing the odd game.
Convergence is changing the way we use and perceive technology: Where the selling points of a product used to describe the product itself (e.g. megapixels in a camera), features which allow products to integrate with each other are becoming more important to customers (e.g. wifi in a camera). This is because customers have observed how these ‘meta-features’ make things smarter and allow us greater flexibility of how we use the products.
I’ve been working as a tester on busines systems for the past 10 years, and I’ve observed a similar trend: Testing is transitioning from having a product focus into having an integration focus. So the changes that we’re seeing due to technology convergence in consumer electronics, seems to be happening broadly in IT.
Integration testing is playing a much more prominent role in software projects today than it was just a few years ago. Where integration testing used to be regarded as a ‘phase’ in large scale projects, we are now more and more carrying out integration testing on a continous basis throughout projects. I’ve seen this change in the projects I’ve been working on, and I have had it described to me by firneds and colleagues.
Project managers seem to have realised that system integrations are just too critical to postpone testing until the last days of a project or project cycle.
Niels Bohr said: ”It’s difficult to make predicitions – especially about the future” I’ll try anyway: I think we’re at the beginning of a development which might completely be changing the nature of testing: In the future, software testing will be predominantly focused on interoperability, system integration, robustness and other factors buried in the structure of the products we’re testing. Functionality will be much less important.