Delivering the message

We are testers. We communicate, collaborate and report. We are the headlights of a project. We light the way, break the news, deliver messages – and they’re not always pretty. How do we make sure our point is taken? It all boils down to adapting our style of delivery depending on the content and the audience. Context is indeed everything.

The delivery of a speech is mostly done through the nonverbal channel (whereas the content itself is verbal). This includes all speech elements other than the words themselves: eye contact, voice, articulation, gestures, facial expressions, body language – even appearance. Using all of these effectively requires timing and practice, lots of practice. An additional problem is that there is a wealth of delivery styles to choose from. How do we get the message across in the best possible way?

A really smart person once said: “Smart people learn from their mistakes, but REALLY smart people learn from other people’s mistakes.”

I think that’s true. In the video below, councillor Phil Davison – a candidate for the position of Republican treasurer for Stark County, Ohio –   delivers a passionate nomination speech in front of a receptive audience. His delivery style is – well… – pretty peculiar. 

Spoiler: he wasn’t  elected.

The importance of discussion

Feynman on the importance of discussion

While I was on holiday, I immersed myself a bit more in the Feynman universe. And I must say – the combination of simmering French sun, lazy poolside-lounging and Feynman’s scientific and philosophical subjects worked surprisingly well. The result was like a tasty cocktail – the kind that gives you a light buzz in the head and that leaves you wanting for more.

Consuming too much of it would have probably given me a nasty headache too, but that didn’t really happen. The only lasting thing I got out of it was the desire to write some of the stuff down before I forget. So here goes…

In his 1964 lecture called “The Role of Scientific Culture in Modern Society”, Feynman states:

 “I believe that we must attack these things in which we do not believe.”

“Not attack by the method of cutting off the heads of the people, but attack in the sense of discuss. I believe that we should demand that people try in their own minds to obtain for themselves a more consistent picture of their own world; that they not permit themselves the luxury of having their brain cut in four pieces or two pieces even, and on one side they believe this and on the other side they believe that, but never try to compare the two points of view. Because we have learned that, by trying to put the points of view that we have in our head together and comparing one to the other, we make some progress in understanding and in appreciating where we are and what we are. And I believe that science has remained irrelevant because we wait until somebody asks us questions or until we are invited to give a speech on Einstein’s theory to people who don’t understand Newtonian mechanics, but we never are invited to give an attack on faith healing or astrology–on what is the scientific view of astrology today.”

“I think that we must mainly write some articles. Now what would happen? The person who believes in astrology will have to learn some astronomy. The person who believes in faith healing will have to learn some medicine, because of the arguments going back and forth; and some biology. In other words, it will be necessary that science becomes relevant. The remark which I read somewhere, that science is all right so long as it doesn’t attack religion, was the clue that I needed to understand the problem. As long as it doesn’t attack religion it need not be paid attention to and nobody has to learn anything. So it can be cut off from modern society except for its applications, and thus be isolated. And then we have this terrible struggle to explain things to people who have no reason to want to know. But if they want to defend their own points of view, they will have to learn what yours is a little bit. So I suggest, maybe incorrectly and perhaps wrongly, that we are too polite.”

It strikes me how relevant this out-of-context quote still is after almost fifty years.

We cannot overestimate the importance of a critical mindset. Testers may need that even more than anybody else. Sometimes we just need to attack common beliefs that have become axioms in a way. I think it was Mark Twain who once said “It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” 

So, we need more discussions in our line of work – they’re a surefire way to advancing the testing craft. True, there’s plenty of discussions and controversies within testing already – the different schools of testing come to mind.  But what I feel lacking sometimes, is a desire to understand where the “other side” is coming from. Why are they thinking the way they think? What are their beliefs and motives? Can we prove their beliefs to be false?

I think I’ll make this my personal mantra:

  • Attack, but don’t attack what you don’t understand
  • Be credible
  • Be reasonable

Feynman on naming

How Feynman’s take on naming things is applicable to testing

Feynman’ s father Melville played a big role in shaping little Richard’s way of thinking. He used to read bedtime stories from the Encyclopedia Britannica.

“See this Tyrannosaurus Rex over here? It says here that this thing was 25 feet high, and the head was six feet across. That means that if it stood in our front yard, it would be high enough to put his head through the window, but not quite because the head is a little bit too wide, it would break the window as it came by”.

He always tried to translate things into some kind of reality, so little Richard would be able to figure out what it really meant, what it was really saying.

Melville would also take his kid for long walks in the Catskill mountains, telling him about nature and explaining that in order to really *know* something, you should start observing and noticing instead of merely naming (a thing most of his classmates seemed to do):

“You can know the name of a bird in all the languages of the world, but when you’re finished, you’ll know absolutely nothing whatever about the bird… So let’s look at the bird and see what it’s doing — that’s what counts. I learned very early the difference between knowing the name of something and knowing something.”

From “The pleasure of finding things out” (1981)

I think the above quote illustrates a phenomenon that occurs all too often in software testing: the nominal fallacy. Basically, this means applying a label or name to something and thinking you have explained it.

What about boundary value testing (or domain testing), for instance?

“First, we identify the boundaries, then we identify tests at each boundary. For example, one test each for >, =, <, using the first value in the > range, the value that is equal to the boundary, and the first value in the < range”.

A pretty straightforward and effective technique, right? We think we master it, until we realise that most textbooks are only talking about known and visible boundaries. What about the boundaries that are not known, not even by the developers that wrote the code? Most of the time, the software’s complexity stretches far beyond our imagination.

In case you need convincing: let’s revisit the ParkCalc exercise that took place a couple of months ago (here‘s a good write-up of that event by Selena Delesie). Matt Heusser put out a challenge to test ParkCalc, a small app on the Grand Rapids Airport website to calculate parking fees. The site provided entry and leaving times, date pickers and five different kinds of parking to choose from. Quickly, an instant test-flashmob formed via twitter. Testers from all over the globe jumped on the bandwagon. James Bach joined in and challenged everyone to beat his highest total parking fee. Extreme testing ensued. What followed was a good exercise in factoring, investigation and on-the-fly test design. And it happened to illustrate the complexity of boundary value analysis as well. 

To get an even better idea of this complexity, there’s always Cem Kaner‘s online course on domain testing. Do we know boundary value analysis because we know its most basic definition?

I’m not trying to open Pandora’s box here, but these nominal fallacies also apply to a testing certification that mainly focuses on definitions. Naming things isn’t enough. As Feynman put it: knowing something requires practice and observation. The benefit? No need to memorize anything anymore when real understanding kicks in. 

Of course, all this isn’t new. Half of the starr-cross’d lovers were already aware of this, way back in the late sixteenth century:

“What’s in a name? That which we call a rose
By any other name would smell as sweet.”

(Juliet Capulet)

Exploring Feynman

On my intention to start exploring Richard Feynman (1918-1988)

The Plan

I’m planning to do a little blog series on the late Richard Feynman to record some of my impressions and learnings while I work myself through this intriguing oeuvre of his. No, that summer heat is not getting to me, yet. I’m not exactly planning on processing his massive back catalog – I’m not really into path integral formulation or the behavior of subatomic particles, let alone the superfluidity of supercooled liquid helium. I do value the sparse free time that I have – time is on my side, yes it is. Rather, I’d like to document my exploration of his more popular works, audio and video recordings.

Exploratory learning, as you wish. Dipping into it all and savoring the juicy bits, spitting out the others. And relate things to testing, of course.

Why Richard Feynman?

Feynman intrigues me, and I have nothing but deep respect and admiration for the man. He was witty, brilliant and had this perpetual curiosity to discover new things (Tuvan throat-singing, anyone?). He opposed rote learning or unthinking memorization as teaching methods – he wanted his students to start thinking, for a change. How great is that?

On occasion, he was a totally nutty professor – a flamboyant geek. But he also happened to build a truly astonishing career which eventually earned him the Nobel prize in physics in 1965. 

I’m planning to gradually learn about him and post my progress here. Stay tuned!

Metrics – perverse incentives?

Trivia time! What do following events have in common?

  • In the American Southwest in the 1850s there was a high reward for the scalps of members of violent and dangerous Indian tribes. This led scalp hunters to slaughter thousands of peaceful agricultural Indians and Mexican citizens, women and children alike, for their valuable scalps.
  • In Vietnam, under French colonial rule, there was a program paying people for each rat pelt handed in. It was originally intended to exterminate rats, but it led to the farming of rats instead.
  • In the 19th century,  palaeontologists traveling to China used to pay peasants for each fragment of dinosaur bone that they produced. The measure was an instant success! It took them a while to discover that peasants dug up the bones and then smashed them into multiple pieces to maximise their earnings.

All these are examples of perverse incentives:  measures that have unintended and undesirable effects which go against the interest of the incentive makers. They become counterproductive in the end.

I’m probably suffering from an acute case of testing analogitis again, because over the years I have seen these things happen in testing as well:

  • Managers evaluating testers by the amount of bugs found.
    This resulted in the submission of tons of trivial and low-priority bugs. People that used to thoroughly investigate bugs and put a lot of time in pinpointing started lowering their standards. 
  • Managers evaluating testers by the amount of test scripts executed.
    This resulted in testers only focusing on scripts, not allowing themselves go off-script and investigate. This often meant going against their intuition for suspicious “smells” in the software, and it certainly did not encourage the use of exploratory testing.
  • Managers evaluating testers by the amount of “rejected” bugs.
    The rationale behind this was: less rejections mean more valid bugs, better bug descriptions and better researched bugs. But the result of the metric was that testers were reluctant to enter complex, difficult or intermittent bugs out of fear of them being rejected. But these are the bugs we want the team to tackle, right? 
  • Managers evaluating testers by the quality of the software.
    First of all, what is quality? If we use Jerry Weinberg’s definition, “value to someone (who matters)”, it becomes clear that any manager’s assessment of quality is highly subjective. If the rewards for testers depend on the quality of the software, that is highly unfair. We are no gatekeepers of quality; we cannot assure quality, because we do not control all aspects of it. The only thing such an incentive achieves is a highly regulated cover-your-ass culture with formal hand-offs, and certainly not team collaboration, continuous improvement or better software. 

These are all examples of metrics used as incentives for testers, but in most cases they just ended up creating a blame culture where quantity and pathetic compliance is valued above quality and creativity.

Dear managers, I’d say: focus on collaboration and team achievements, set goals for the team. Make the whole team responsible for the quality and the product. Then see what happens.

A Eurostar interview

A Eurostar interview

A while ago, there was this little announcement on the Eurostar blog:

“As a new addition to the EuroSTAR community, we will be interviewing prominent testers from across the globe”

I thought that was pretty cool. There is lots to learn from experienced people. It’s nice to hear all these different takes on the sofware testing craft. They already published interviews with Isabel Evans, Mats Grindal, Tim Koomen, Michael Bolton, Martin Pol and Anne Mette Hass. Interesting stuff.

Several months later, I received an email from Kevin Byrne from the Qualtech/Eurostar team asking if I would be interested in doing an interview with them on testing (and other things as well). It took me a while to properly connect the term “prominent tester” with my own name. But I was honoured of course, so I accepted their offer.

And there it is. They even call me a ‘prominent Belgian tester’ in the introduction, which made me smile because it reminded me of the phrase “being big in Belgium” – often used interchangeably with being “big in Japan”, meaning as much as “totally unimportant”.

In the 1992 movie Singles, Matt Dillon plays in a band that claims to be “big in Belgium” – subtext: “what a bunch of forgettable losers”. Similarly, the legendary rock group Spinal Tap (the 1984 mockumentary This is Spinal Tap is hilarious, by the way) ended up being big in Japan, which basically meant “pathetically uncool and ridiculed at home”.

But I digress. I might not be all too prominent, but I am a Belgian tester allright. Here’s the interview:

http://www.eurostarconferences.com/blog/2010/5/18/an-interview-with-zeger-van-hese.aspx

On Google Insights, Indians and testing

On Google Insights, Indians and testing

I have been playing around with Google Insights for Search lately. It’s a nifty tool that allows you to compare search volume patterns across specific regions, categories, time frames and properties. The search results are presented in a textual manner, but there is also a map representation allowing you to drill down on regions and countries.

An explorer’s and system thinker’s walhalla! It didn’t take long before I found myself throwing some testing-related lingo at it:

I wonder what happens when “Software testing” is thrown into the mix?

Mmm… and what about “Agile testing”?

 wOOt! “Testing conference”?

 This can’t be. Let’s try ISTQB…

 Same old, same old. Is this some kind of caching problem? Let’s park the testing stuff and throw in Alaska’s finest, “Sarah Palin”.

 Okay, this actually makes sense. Let’s zoom in on the US. Drill baby, drill!

 And sure enough, the top number of searches comes from the place she could see Russia from on a clear day.

Google Insights wasn’t messing with me. It’s real. The highest search volumes of almost all software testing-related terms seem to come out of India. Look who’s on a quest for knowledge.

Are Indian testers heavier google-users than the average Westerner? Is that because other sources of testing-related information are lacking? I’d love to hear the opinion of Indian testers on this.

Although this trend is remarkable, it’s not surprising. If the nature of many Indian testing blogs is something to go by, a lot of Indian testers *are* inquisitive and critical. It’s the birthplace of Weekend Testing, too. And the sapient tester virus is spreading rapidly: if you take a look at the blogs of Ajay Balamuragadas, Dhanasekar S, Parimala Shankaraiah, Pradeep Soundararajan, Shrini Kulkarni, Manoj Nair, Debasis Pradhan, Santhosh Tuppad, Sharath Byregowda, Mohit Verma, Jaswinder Kaur Nagi, Santosh Shukla, Nandagopal and Madhukar Jain, their enthousiasm and sheer passion for the craft are contagious.

I like the way many of them are taking skill development into their own hands. Bhārat, the home of continuous learning and improvement! 

I wonder how long it would take to put Belgium on that Google Insights testing map. I’m afraid this won’t be happening anytime soon – but I’m pretty confident that we will get the term “governmental crisis” up there in a heartbeat.

A lesson learned from James Bach

About “Secrets of a Buccaneer-Scholar” (James Bach)

I just finished James Bach’s “Secrets of a buccaneer-scholar” and it hit home in a weird way. I’m not an unschooler or a high school dropout, but I could still relate to a lot of things in his book. It was a tremendous read, giving me instant flashbacks to the days of yore.

As a young kid, I constantly skimmed through encyclopedia volumes that were lying around the house. I wasn’t “studying” from them, I was just fascinated by what I thought was all the knowledge of the universe compiled into 14 volumes. I let my mind wander while looking at the pictures, jumping randomly from subject to subject. When something looked fascinating enough to stay with it for a while, I dove in and read through the whole entry. I didn’t understand all of it, but I didn’t really mind. Most of the time it was just superficial browsing anyway – I blamed it on my short attention span. But as I was doing it more frequently, it became more systematic. Once in a while, I came across things that I previously ignored, but all of a sudden did seem interesting enough to investigate. Things I had previously read helped me to understand new things as well. I learned that I remembered lots of information without trying to. It just sticked because it was so damn interesting. I did the same thing with all the world maps and globes I could get my hands on. They really got my imagination running. The result is that I’m still bursting with trivia that spill out on the most inconvenient moments. It’s great in the occasional quiz, though.

I always thought that was a bit awkward. Not many kids I knew read encyclopedias and atlases in their spare time. It’s not that I didn’t enjoy school, but this kind of exploratory learning felt more natural to me. There was hardly any effort involved. It was pretty chaotic, but it was a learning style that fit me like a wet suit. 

As an adult, I am facing the same problems: I like to learn and educate myself, but in an almost impractical and inefficient way. I see interesting ideas and sources of knowledge everywhere, and this overwhelms me – so many things to learn, so little time! I purchase far more books than I can read (thanks for that, Paypal & Amazon). I start reading books but do not necessarily finish them. My reading isn’t very linear. I tend to get distracted often and feel the need to switch to something else. I procrastinate more than I would like. At this very moment, I’m trying to read nine books at the same time.

I used to feel bad about all this inefficiency. Until I finished James Bach’s book, a couple of hours ago.

It put things in perspective. It all makes a bit more sense to me now. Apparently it *is* okay and natural to let your mind wander. Allow yourself to be distracted. James calls it the “Follow your Energy”-heuristic: go with the flow of what engages your curiosity. Stick with what is fun and fits the natural rhythms of your mind. But in order to be more in control of your learning, combine it with the “Long Leash”-heuristic. Let your mind drift off, but in a controlled manner – keep it on a long leash. Remind yourself that you are on a mission and gently pull on the leash to regain focus again. 

These are just a couple of examples, but there’s more where that came from. In a way, a lot of the principles or heuristics described in the book reminded me of the young kid trying to work his chaotic way through that wealth of interesting information out there.

James Bach describes his pattern of learning with the “SACKED SCOWS” acronym:

  • Scouting Obsessively (…I discover the sources and tools I will need)
  • Authentic Problems (… engage my mind)
  • Cognitive Savvy (…means working with the rhythms of my mind) 
  • Knowledge attracts Knowledge (…the more I know, the easier I learn) 
  • Experimentation (…makes learning vivid and direct)
  • Disposable Time (…lets me try new things)
  • Stories (…are how I make sens of things)
  • Contrasting Ideas (…leads to better ideas)
  • Other Minds (…exercise my thinking and applaud my exploits)
  • Words and Pictures (…make a home for my thoughts)
  • Systems Thinking (…helps me tame complexity)

According to James Bach, a Buccaneer-Scholar is

“anyone whose love of learning is not muzzled or shackled by any institution or authority; whose mind is driven to wander and find its own place in the world”. 

So, am I a Buccaneer-Scholar? Maybe, I wouldn’t know. I wasn’t a rebel kid at war with the educational system – I actually enjoyed most of my time at school. I am not radically unschooling my kids, as James is doing. I wasn’t a whizz-kid either. I don’t think that’s the point. But I do love to learn new stuff, and preferably in ways that do not really make sense. At least, they didn’t until today.

Thank you, James.

Testing analogitis (a phantom menace)

A story about the phantom of Heilbronn and testing

Blame this post on my wandering mind. I’m suffering from a severe case of analogitis. I’m starting to see testing analogies everywhere.

On  April 25, 2007, a 22-year-old female police officer was fatally shot in Heilbronn, Germany. The analysis of the DNA that was found at the crime scene revealed some astonishing information. The DNA belonged to a woman and started popping up in several seemingly unrelated cases, some of them dating as far as fifteen years back. Traces were found:

  • on a cup after the killing of a 62-year-old woman in Idar-Oberstein, Germany
  • on a kitchen drawer after the killing of a 61-year-old man in Freiburg, Germany
  • on a syringe containing heroin near Gerolstein, Germany
  • on the leftovers of a cookie in a trailer that was forcefully opened in Budenheim, Germany
  • on a toy pistol after the robbery of Vietnamese gemstone traders in Arbois, France
  • on a projectile after a fight between two brothers in Worms, Germany
  • on a stone after a burglary in Saarbrücken, Germany
  • after a burglary at an optometrist’s store in Gallneukirchen, Austria
  • after 20 burglaries and thefts of cars and motorbikes Germany and Austria
  • on a car used to transport the bodies of three Georgians killed in Heppenheim, Germany
  • after a burglary in a disused public swimming pool in Niederstetten, Germany
  • after four cases of home invasion in Quierschied, Tholey and Riol, Germany
  • after an apartment break-in in Oberstenfeld-Gronau, Germany
  • after the robbery of a woman in a club house in Saarhölzbach, Germany
  • in the car of an auxiliary nurse who was found dead near Weinsberg, Germany

The so-called “phantom of Heilbronn” was born. An unknown woman was scattering her DNA all over the place, committing murders, breaking into houses, eating cookies, drinking beer, toting toy guns, she was even shooting up heroin. Profilers could tell that she was quite a busy lady, but she had no identity – the police had absolutely no clue. No Mentalist or CSI Heilbronn coming to the rescue – things were looking bleak.

But in March 2009, the case took a new turn. Investigators discovered the very same DNA sequence on the burned body of a male asylum-seeker in France – an anomaly, since the sequence was of a female. They eventually found out that the phantom serial killer did not actually exist and that the laboratory results were due to contamination of the cotton buds used for DNA probing. They discovered that the cotton swabs were already contaminated before shipping, and that they all came from the same factory. That factory, in turn, employed several Eastern European women who fit the type the DNA was assumed to match. The cotton swabs were not intended for analytical, but only medical use. They were sterile, but not certified for human DNA collection.

At this point you are probably wondering what all this has to do with testing. Bear with me a little.

Reading the Phantom of Heilbronn story reminded me of a phenomenon I briefly described in my 2007 paper “Software testing, profession of paradoxes?“. When we investigate something, the outcome of our investigations is sometimes influenced by the observation itself. The very act of testing influences its outcome. This axiom is also often referred to as the ‘observer effect’.

The idea is that since any form of observation is also an interaction, the act of testing itself can also affect that which is being tested. For example:

  • When log files are used in testing to record progress or events, the application under test may slow down drastically
  • The act of viewing log files while a piece of software is running can cause an I/O error, which may cause it to stop
  • Observing the performance of a CPU by running both the observed and observing programs on the same machine will lead to inaccurate results because the observer program itself affects the CPU performance
  • Observing (debugging) a running program by modifying its source code (e.g., adding extra output or generating log files) or by running it in a debugger may cause certain bugs to diminish or change their behavior, creating extra difficulty for the person trying to isolate the bug (also known as a ‘Heisenbug’)

Paradoxically, software testing is not always considered as the best way toward better quality. Just like in the Phantom of Heilbronn case, the advanced state of the technology might work against us, rather than with us. In 1990, Boris Beizer described the “complexity barrier principle” (1990): software complexity (and therefore that of bugs) grows to the limit of our ability to manage that complexity. 

Sometimes, testing is not the best option. Sometimes, testing and fixing problems does not necessarily improve the quality and reliability of the software. Oh sweet paradox, how can I embrace thee? Let me count the ways…

Pinpointing & iphone mindfulness

About pinpointing a bug on the iphone and mindfulness.

Two months ago my trusted smartphone started failing on me on an intermittent basis. In mid-conversation, people stopped hearing me, resulting in lots of confused hellos on the other end and eventually a whole lot of lost connectons too.

At first I was thinking along the lines of a hardware defect. My phone did end up on the ground a couple of times, and I thought that caused my microphone or antenna to be a bit dodgy. I decided to roam the internet in search of an explanation. That resource never failed me so far and I thought that with a little patience and well-chosen search terms I would be able to find some Slovakian or Belarusian forum-guy experiencing exactly the same problem. Well, none of that. I did encounter a lot of nationalities, and some of them I can’t even pronounce, let alone spell correctly. I also met a couple of Mac-savvy gurus with too much time on their hands, but no one recognized my problem or was able to help me.

I was puzzled. I had recently upgraded from version 2.2 to 3.0 – did the upgrade go awry? The problems started appearing around that time. Some more googling ensued. I got lost on strange webpages with flashing banners indicating I was visitor nr. 100,000. Another banner told me I had just won the green card lottery for a US visa – without even entering.  Miracles do exist. I got heavily distracted by ugly first-generation websites and decided to stop using the internet as my oracle.

I started doubting my googling and pinpointing skills, I even started questioning my phoning skills. How hard could it be to find the cause of a problem that is so easy to reproduce? I just needed to call someone or be called and within 5 minutes, people would stop hearing me. One hundred percent reproducible.

I was stuck here, so I decided not to think about it for a while to get a fresh angle on the problem. A couple of days later I noticed by chance that the problem didn’t occur when calling hands-free in the car over bluetooth. Wait, did the problem just solve itself, “automagically”? I called from my car again. No problem. I switched off the bluetooth setting and called manually. The problem re-occurred. Bingo!

Apparently it had something to with my phone-handling. As far as I knew I didn’t change the way I used my phone, but something was definitely different. I decided to be very conscious while calling, aware of every action I normally perform instinctively. Mindfulness for the iphone, but unfortunately without reaching the path to liberation and enlightenment. It must have looked rather strange to bystanders, but it eventually paid off. By using the phone in a kind of slow-motion way, I noticed that something was wrong with the light detection mechanism. The iphone is designed so that when you put the phone to your ear, the screen goes black to conserve power and to make it insensitive to touching. In this case it was the other way around: when I put the phone to my ears during a call, it went black but not much later turned back to an active, touch-sensitive state – something you normally don’t notice while being on the phone. Then I wondered… which options are active while making a call? And which one of these options would cause the problem of people not hearing me anymore, while I could still hear them?

I felt a little bit silly after realizing that I had been hitting the mute button with my cheek for two months without noticing.

This iphone incident taught me a valuable lesson about testing too. All too often, we do things instinctively, without really thinking. Or we think we are thinking, but our minds are actually on autopilot, and we’re just going through the motions. Becoming very conscious about what you are doing will improve our noticing skills. Noticing is a core testing skill that helps us reveal information about our environment, our actions, ourselves and the product we are testing. When we become more mindful, aware of what we are doing – focus on the current moment – we might become better testers, too.

All this learning thanks to a faulty iphone, you just gotta love Apple!