Weekend Testing hits Europe – EWT01

The first European Weekend Testing session (January 16, 2010)


Last saturday, weekend testing hit European ground. The Weekend testing phenomenon has been the talk of testingtown for a couple of months now. They originally started out as the Bangalore Weekend Testers and are gradually taking their brilliant mix of cybergathering / testing / learning / mentoring / communication / pairing to a higher level. I  became intrigued when I first heard about them through a column by Fiona Charles and some namedropping at Eurostar shortly after. I liked the idea of personal and professional development, while serving the open-source community as well. My first thoughts were “what a shame we don’t have this over here” and “wouldn’t European testers like this too?”.

They do, apparently.

Markus Gärtner and Anna Baik – whom I met online in the Software Testing Club, set up the first European chapter and planned the first session with the help of Ajay Balamurugadas, a weekend testing veteran from Bangalore. On saturday january 16, some great  testers – and me –  gathered online for a unique experience. Among the participants: Markus, Anna and Ajay of course, Phil Kirkham, Jeroen De Cock, Anne-Marie CharrettThomas Ponnet, Maik Nogens and Jassi.

After some initial babylonic confusion in a skype group call, we decided to settle for a group chat. There was a round of introductions first, during which everyone stated his name, experience and what he/she wanted to take away from this session. After that, Ajay (aka the great facilitator) revealed the mission and the target to us, whilst stating enigmatically “that there were traps”. Right then I knew that this wasn’t going to be just another round of testing. The target turned out to be a piece of open-source image-editing software by the name of Splashup. From that moment on, there was a lot of questioning going on – one of the most important testing skills. People explored, asked questions, gave feedback. Some started off on the wrong foot, but quickly recovered and learned from that. We made a lot of assumptions as well, and not always good ones. In the beginning I was a bit distracted by all the chat messages flying around while testing, but once I developed that second pair of eyes, it worked out just fine. The first hour flew by and everyone sent in their bug reports on time (yes, there *was* a deadline). Peer pressure, in a good way.

Next up was an interesting group discussion. Everyone shared their impressions, approaches, things they learned and the traps they fell into. Ajay did a great job in moderating this, and made sure all testers were involved. Here are a couple of things I took away from this first session:  

  • When confronted with testing within a really short timespan, it is good to quickly decide on your personal mission and focus, and stick to that. Try to stay focused on the areas you chose and don’t go wandering off, unless of course you accidentally open pandora’s box and bugs are thrown at you. I sticked to the file opening and saving functions – and there’s plenty to report about that. 
  • I think the way we start testing largely depends on our domain knowledge as well. When confronted with a completely new product, you probably start exploring in an attempt to primordially learn about the application first. Knowing the domain makes you less of an explorer – and more of a bug hunter, which may be dangerous – make sure you don’t block out the learning. I had worked with Splashup before, which gave me a (misplaced?) sense of ‘expertise’, so I dove in and went on an immediate bughunt.
  • Always question the mission you get. Question your assumptions about the mission. The main goal might not always be a mere bughunt.
  • There are some great exploratory testing tools out there. I used Session Tester, which allowed me to quickly generate an html-report at the end. It is great for notetaking too. I really like the ‘Prime Me’-function in there – great to get new testing ideas when you’re stuck. I didn’t have to use it this time – ideas galore.
  • When working with image editing programs, I immediately tend to go in that ‘comparable product’-mode and start comparing it with Photoshop. While that may be ok to have some idea of the expected behaviour of filters and effects, it might not be ideal for an open source application. It makes you expect too much. Free tools often cater for other needs – their users have different expectations.
  • Afterwards we all agreed that it was strange that we didn’t pair up while testing, or that we didn’t do a short ‘who will do what’-briefing before we started.  Divide and conquer, we didn’t. I think that was mainly due to the fact that it was all pretty new to us. This will be easier once we get to know eachother better. Another lesson learned in software testing.

As some scientist already pointed out (and actually proved too), time is relative. The planned two hours quickly became three. I have the impression that everyone was thrilled about this fresh kind of collaboration. Interacting with passionate fellow testers, talking to them, learning from them – it all made for a great experience. Sure, it is probably not always easy to attend the sessions, you actually have to plan for it – make sure the kids are entertained elsewhere. But the reward is significant.

People might argue “weekends, isn’t that supposed to be quality time away from work?” – I admit that this thought crossed my mind too. I now realise that this *is* quality time, and far away from work as well. Quality learning time. And fun fun fun – did I mention it’s lots of fun, too?

Happy two thousand and System.NullreferenceException!

A comment on the Y2.01K bugs detected at Symantec and the DSVG bank group.

First of all, happy 2010 everyone!

And a happy new year for the German banks as well, althought it must have been a not-so-happy-one for the DSVG bank group. Yesterday, they issued a statement  that some 20 million debit cards issued by the banks belonging to the group were affected by a “millennium bug”-like problem. Apparently the problem stemmed from a chip on the cards which, due to a programming fault, wouldn’t correctly process the number 2010. The group said cash machines were adjusted hours after the problem emerged to ensure that customers can withdraw money, but there may still be problems using some debit-card terminals. Those should be fixed by Monday, it said.

Monday? Like in Monday, January 11th? Like in “almost a week from now”? In full winter sales period, with the number of payment transactions generally hitting historical highs (who’s paying in cash, nowadays?), that seems kind of disastrous to me.  

The same problem hit Symantec as well. The Symantec Endpoint Protection Manager (SEPM) server handled all dates greater than December 31, 2009 11:59pm as “out of date”.

Back in 1999, computer experts widely believed that hardware and software systems would fail as the clocks rolled over to the year 2000 because computers and other devices, which used only two digits to represent the year, would mistake the year 2000 for the year 1900. In the end, however, the so-called “millennium bug” caused few problems, because a lot of companies had anticipated the turn of the millennium with all possible resources. The computer software business was booming at the time. There were lots of new jobs. Granted, most of them were repetitive and rote programming and testing jobs, but jobs nontheless. Freshly graduated students were sent off to bootcamps to become ruthless programmers. I still dream about riding dinosaurs while yelling Cobol commands at them – but I digress. There also was a high demand for testers. A wide range of different people were transformed into software testers. Finally, companies were acknowledging the need for testing. Great! But apparently, not all testing (and programming, for that matter) was up to standard.

Now I don’t know the exact processing happening at Symantec or in the DSVG bank terminals, but this indeed looks like a sibling of that good old millennium bug. Maybe this was the result of a cheap and dirty Y2K bug fix where programmers put in a simple if <10 = 20xx otherwise the date is 19xx. In that case, this unwanted emergent behaviour doesn’t seem too hard to detect. Or does it? My 2 cent’s worth: this is what you get when performing scripted testing based on poorly thought-out boundary value analysis (aka domain testing) without exploring the software to know more about the risks. Or maybe they did explore, but they were only focused on that one known boundary called 2000. In both cases, testers failed to acknowledge other boundaries in the software that maybe simple talks with the developers would have detected anyhow. Michael Bolton talked about this in his Eurostar tutorial this year: the actual boundaries in a system may not be the ones we are told about – that’s why we need to explore. He also wrote this interesting article (pdf) on domain testing in Better Software magazine.

Eurostar 2009 – a week to remember

A write-up of the Eurostar 2009-conference in Stockholm

I absolutely *love* Stockholm in wintertime. Pepparkakor, glögg, gravad lax… and Eurostar too. People keep telling me that I would probably love it even more in summertime, but I’ll always associate those dark days with Eurostar. I presented my first Eurostar track there in 2007 – nothing but good memories – and I was selected this year as well. The Eurostar line-up is always pretty impressive, so it can be both intimidating and exciting to be a part of that. It’s just a matter of keeping the intimidation level below the excitement level, I guess. As a boyscout, good old Baden Powell always told me to “be prepared”. Now sometimes I wouldn’t recognize a life lesson if it punched me in the face, but here’s one that I did remember. So I found myself writing a paper and assembling a presentation during those hot holiday nights in Southwestern France. You just gotta love those early deadlines!

November 29

After an uneventful flight from Brussels to Arlanda, set foot on Swedish soil. Met up with fellow Belgian Mieke Gevers, a member of this year’s program committee and in charge of the track chairs as well. I helped her carry some excess bagagge that turned out to contain presents for the trackchairs – you can’t go wrong with Belgian chocolates and “jenever“. We took the Arlanda express (easy and quick) to Stockholm C and a cab to the Rica Talk hotel.

November 30 – Tutorial day

On monday I attended a full-day tutorial by Michael Bolton called “Exploratory Testing Masterclass” (slides available here). Two years ago I attended his tutorial on Rapid Software Testing, which I found very valuable. Michael Bolton is an engaging speaker and teacher who invites you to think, rather than just sit and absorb theoretical matter. There were lots of exercises, including one on factoring (identifying dimensions of interest in a product). We were asked to identify all dimensions of a wineglass that may be relevant to testing it, using the “San Francisco Depot” – heuristic (Structure, Functions, Data, Platform, Operations, Time) – not new to me but always worth repeating. A lot of mnemonic wizardry to be found here. What about that handy mnemonic for oracles – HICCUPPS/F (History, Image, Comparable product, Claims, User expectation, Product, Purpose, Statutes, Familiar problems) – never again say that you don’t know why something should be considered a bug. Care to take a ride on that test reporting heuristic called MCOASTER? Well I’ll see your CRUSSPIC STMPL, and raise it with a FCC CUTS VIDS (Mike Kelly’s application touring heuristic). Mnemomania!

Of course, there were plenty of other impressions that kept lingering for a while.

  • A quote by Jerry Weinberg: “A tester is someone who knows things can be different” – true.
  • “If it ain’t exploratory, it’s avoidatory” – made me laugh. 
  • “A good tester doesn’t just ask “Pass or Fail?”. A good tester asks “Is there a problem here?”.
  • CHECks are CHange detECtors, testing is exploring.
  • A complete debunking of some boundary value analysis truisms: it is generally accepted that the behaviour at boundaries is more likely to show erratic behaviour, but how do we know these boundaries? The actual boundaries in a system may not be the ones we are told about. That’s why we must explore.
  • Testing is “storytelling” – I liked that take on testing:

“You must tell a story about the product, about how it failed, and how it might fail – in ways that matter to your various clients. But you must also also tell a story about testing, how you configured, operated and observed it – about what you haven’t tested, yet… or won’t test, at all – and about why what you did was good enough.”

The end of the session was foreseen at 5 PM. The discussions kept going on until 5.45 PM. I think that says it all. Later that evening, an international amalgam of testers set out to explore the possibilities of finding food in Gamla Stan. Eventually we found an Indian restaurant using that good old I.NEWTON heuristic (Indian, Nearby, Edible, Welcoming, Tasty, Open, Not-too-expensive). The end of a great day. Had some nice conversations with Rikard Edgren, Tone Molyneux, Ray Arell and  John Watkins (my trackchair) as well.

December 1

The second day started with a tutorial as well, be it a half-day one: Managing Exploratory Testing by Jonathan Kohl. Of course there were a lot of similarities with the first tutorial, but this was more of a hands-on session, where we could put Michael Bolton’s concepts from the day before into practise. There was some theory about coverage models – SF Depot anyone? We ended up describing a whole bunch of characteristics of a table that we had never associated with an ordinary table before. Practical and fun. Certainly an eye-opener.

At that point I was still trying to get a hold of the person I was supposed to trackchair on wednesday. Originally I would be trackchairing my colleague Wim De Mey’s track about regression testing in a migration project, but Wim had to cancel his presentation at the very last moment because of unfortunate familial circumstances. A replacement was found in the person of Mika Katara, from Finland – but no sign of him, yet. Oh well, time for a quick lunch, a tour of the expo and the actual kick-off of the conference.  Dorothy Graham opened the 17th Eurostar conference in style. She introduced the program committee (Tone and Mieke made sure Isabel Evans was also represented by carrying an air-filled balloon with a face drawn on it – I’m not sure if Isabel would be too happy with the analogy 🙂 ) and set the scene for the first keynote speaker.

Lee Copeland started this very first talk of the conference about nine of the most important innovations in software testing: the context-driven school, test-first development, really good books, open source tools, session-based test management, testing workshops, freedom of the press, virtualization and “testing in the cloud”. Strange that he sees the context-driven school as an innovation – as far as I know it was founded in 1999; the first book that explicitly named it was already published in 2001. I agree with the freedom of the press thing. Testing blogs are appearing everywhere (guilty, your honour), twitter is on the rise. Lee is apparently not a fan of twitter. Neither was I – I always thought of it as encouraging the spreading of triviality, but I’m actually starting to come back from that. I noticed that a lot of people within the testing community are using it to share their ideas, give advice or call for help. And it gives a great deal of extra coverage to an event like this (see twitter.com/esconfs), so maybe I’ll give it a try. Later. 

The rest of the afternoon consisted of a series of  short 20-minute tracks, which is mostly just enough to launch some provoking ideas, but not really ideal for a lot of content. Johan Jonasson talked about how he managed to save a project with the introduction of a structured exploratory testing approach. This track would have benefited from a 45 minute timeslot – there was no time to go into detail, which I found a pity. Next up was Julian Harty, who explained the concept of “trinity testing”: short session of around 90 minutes per feature, where the feature owner, the developer and the test engineer work interactively through the software to share knowledge and ideas. Pretty interesting, since I also found out later that “the trinity test” was also the name of the very first nuclear test ever conducted, marking the very start of the nuclear age. Julian is probably aware of this – I didn’t hear him mentioning it, though.
Geoff Thompson then talked about reporting – “If only we could make them listen!”. Well actually, it’s more the communicator’s job to make sure he gets heard. It was a great talk – he was able to slip in the Challenger disaster and the Heathrow terminal 5 debacle as examples of how important messages were apparently not deemed important enough, with horrendous results. Knowing your recipients is key, and knowing what information they want as well. Noteworthy: a lot of people are color-blind. If you absolutely want to make sure that everyone understands your reports, shouldn’t you avoid the reds and greens?
Besides being a sapient testing evangelist, Michael Bolton is also a human quote machine. He did this cross between stand-up routine and  political televangelism called “Burning Issues of the Day” (available here). A lot of wisecracks and eye-openers, the funniest moment at Eurostar for me. He was even able to win a bet by slipping in a quote about agilists and sex:

“The agilistas did not discover pairing or test-first programming. They’re like teenagers who’ve just discovered sex. It IS great, but calm down”.

The last speaker of the day was the same as the first one. Jonathan Kohl talked about how our urge to be “Agile” can distract us from our mission to deliver software that our customers value, while supporting our team. Agile can distract from skill development too. The term “Agile” has become big business, and lost a great deal of it’s significance. So let’s stop worrying about whether what we do is “agile” or not, and go back to calling it “software development”. As far as I’m concerned, he hit the nail on head. I wouldn’t have minded him talking about this a little longer.

The day ended with drinks in the expo and my attempt at playing a memory game at one of the stands. I kept failing epically. While I was trying to get asleep I found the ideal excuse: my head was already full of things to remember – no room for these trivial button sequences.

December 2

Right before the first keynote of the day I finally met Mika, whom I was supposed to be trackchairing in the afternoon. He was invited as a backup speaker on friday to speak on wednesday, was able to make it, but had to leave immediately after his talk. A true case of hit-and-run guerilla presenting at Eurostar! Naomi Karten then delivered an interesting keynote about “changing how you manage and communicate change”. Her talk was built around the Satir change model. There’s an initial status quo, then a foreign change-inducing element causing a ‘POW’, then chaos, after that an adjustment and in the end a new status quo. When people are confronted with change, they are experiencing a loss of control, and they often react to that in an emotional way. Important: listen, be empathic, regularly communicate the status of the change, even when there is nothing to report. She also used a quote that I well certainly use myself when feeling cornered:  

Hofstadter’s Law: It always take longer than you expect, even when you take into account Hofstadter’s Law”

By then it was time to pay a visit to the Test Lab that was set up by James Lyndsay and Bart Knaack. It was a Eurostar first, and I am actually wondering now why it took so long to have some actual “testing” going on at a testing conference. The software they were running was Open EMR, an open source patient management and appointment book system. What made it even more interesting for me is that I have been testing and working with a similar (not open source, though) system for a long time, so I more or less know what to expect (or what actual users of the software would expect). I paired up with Rikard for a while and found a whole bunch of issues by merely touring the application – we noted them for later reference. It is always nice to pair with fellow testers to see what they focus on, and what their reasoning is. The state of the software under test was something else. It showed some pretty alarming behaviour, and it was far from intuitive or user-friendly.

By then it was time for Eurostar veteran Erik Boelen, speaking at Eurostar for the fifth time already. I’ve known Erik for some time now, and his talks are always entertaining and relaxing in a way. “The power of risk” was his view on how to use a risk-based test strategy that “makes people talk”, like Läkerol. His main message was (apart from the implicit one that testing can be fun *and* will rule the world) that they defined all the risks and used them as entry paths for exploratory testing. For the highest and medium risks they documented their test cases, and for low risks they just reported the results.

After lunch I introduced Mika Katanen (from the university of Tampere in Finland) and his talk about Automatic GUI test generation for smartphone applications. I am totally new to model-based testing and I was impressed with the brief demo he showed. His track went well, and there were a lot of people approaching him for a chat at the end. I do hope that he was able to catch his plane on time. Parallel with this track, Shrini Kulkarni held his talk about software metrics which I was unable to attend. People said it was good – I hope I will be able to see him speak some place else in the future.

Remembering the memory game disaster from the day before, I decided to unfocus for a while – my mind was getting stuck again. I teamed up with some CTG colleagues plus a wildcard named Tom and enrolled ourselves for the quiz that was supposed to take place in the evening. We aptly named ourselves “The Handsome Oracles”, but it wasn’t meant to be. The quiz was canceled later on, so we weren’t able to put the money where our mouth was. We also worked out some testing limericks for the limerick competition – we didn’t win. I thought they were good, but that’s probably just another example of parents not recognizing the ugliness of their own babies. There’s a good joke and an interesting analogy about that hereGitte Ottosen ended the day with a talk about combining agile and maturity models which was chosen best presentation last year in The Hague. I had the impression she was a little nervous – which is completely understandable. I was telling to myself that delivering a keynote for a full auditorium like that sure looked like a daunting task – until I suddenly realised that I would be standing in that same room tomorrow. My unfocused mind started wandering off.

While the temperatures were taking a dive, the Handsome Oracles went into town for dinner. I returned a bit earlier than the rest to rehearse my talk and to get a good night’s sleep while the (by then just plain) Oracles went barhopping. Haha! Life’s good, but not fair at all. 

December 3

The last day of the conference, and people started looking weary. Ray Arell gave us a good wake-up call with his keynote on moving to an agile environment, based on his experiences at Intel. Ray’s a great speaker (and a fun guy too – I might add). He described his hits and misses; the ‘misses’ are often the most interesting parts of experience reports. Lot’s of good advice and some nice puns (Wagile, FRagile, Scrumfalls).

I stayed in the agile track in the big auditorium where John Watkins presented some material from his book on agile testing, aptly named “Agile Testing”. John had gathered case study material from twenty agile projects and proposed agile methods for small, medium, large, off-site, and even off-shore projects. Intriguing, but upon hearing the idea of “agile best practises”, my context-driven genes started to play up.

John was also my great trackchair and introduced me as “Filmstar, Rockstar, Tester!” At least, that was his own juicy summary after I mentioned to him that I had worked as a movie distributor before and had also played in a rock band. Granted, I also admitted playing a zombie once – a serious case of method acting. Anyway, his introduction loosened the audience a bit and I was able to present my track “A lucky shot at agile?” without any problems. I wanted to tell a testing story and I think it went well. I felt at ease (those wireless microphones are really great) and there were many questions afterwards. During the rest of the day people I didn’t know came up to me to congratulate me with the presentation, which was nice. I took a long lunch and had a walk around the expo. I went back to the Test Lab to report the bugs that we found earlier. I didn’t succeed in entering them all, which made me feel kind of guilty – I wished that I would have spent more time there. But I had a hard time choosing. It’s a pity that test labbing also meant skipping tracks as well.

The last regular talk of the conference was held by Rikard Edgren, who is also a Eurostar regular. I had seen his presentation on testing creativity (“Where testing creativity grows”) in 2007 and I liked it a lot, since it is also a subject that is dear to me. There’s far too many people that think that testing is not a creative or challenging activity. This time he talked about  “More and better test ideas“. He promoted the use of oneliners as test ideas – a brief statement of something that should be tested. These test ideas can then be used as a basis for test cases, or as a guideline for other types of testing, or even discarded when there irrelevant or when there is simply not enough time. I think Rikard’s subjects will always be a bit polarizing due to their innovative nature – you either like them or you don’t. I am a believer and it was a good way for me to finish the conference.

I missed the first part of the Test Lab result presentation since they changed the timing and I totally forgot about that. But I got the most important statistics. Over two and a half days, more than 50 bugs were found. My first reaction was: “Only 56? Man, there’s hundreds of them hiding in there”, but then I realised that people had been testing in the lab only for short periods, in between tracks, just as I did. I wonder what would have happened if hundreds of testers had a go at it, all at the same time. Bugfest!

After a short panel discussion with John Fodeh (next year’s programme chair), Geoff thompson, Tobias Fors and Nathalie Van Delft it was time for the award ceremony. Naomi Karten received the Best Tutorial Award and the European Testing Excellence Award went to Anne Mette Hass. In the meanwhile I was dozing off in my not-so-comfy chair – these 4 days of conferencing were finally getting to me. A friendly woman on the stage was mentioning someting about a longlist of papers, and a shortlist, and a final selection of three, containing two Dutch and one Belgian paper. Now wait a minute… how many Belgians sent in a paper? 1…2… before I could make the math, my name was announced as winner of the ENEA Best Paper Award. Two talks at Eurostar, two papers, two awards… what are the odds of that? I was absolutely flabbergasted. That’s actually three in a row for my company CTG, since Bert Jagers won the award last year in The Hague. The pressure is on for next year :-).

I spent the rest of the evening in the hotel bar, where all the testers with an early flight on friday morning were flocking. We ended the day singing an eclectic mix of Irish traditionals, Dylan, early Springsteen and – of course! – Abba, accompanied by a non-certified tester, who plays a mean mandolin. I love Stockholm in wintertime. It was a good Eurostar. Yes sirree.

The winner takes it all (a 3-day workshop with Cem Kaner)

A review of the Cem Kaner workshop during the Cem Kaner Week, held in the last week of October 2009 in Nieuwegein, The Netherlands.

Last August I received a mail from a company called Immune-IT that promoted their upcoming “Cem Kaner week“. The concept: during the last week of october Cem Kaner would visit The Netherlands to lead a three day workshop and give a freely accessible presentation as well. Considering the cost of the workshop I settled for the free presentation, which I figured was also quite unique. Nieuwegein in The Netherlands is only a 160 km drive from my home (ok, you’d have to get past Antwerp, Breda and the Utrecht traffic jams, but still: worth the hassle). Later I heard that there was also a possibility to get a free workshop place by entering a contest on their website. Long story short: I participated, won the contest, checked the mail again (still said I won it) and jumped from joy. On October 26, I had a date with testing history.

I have always looked up to Cem Kaner, admired him for being one of the pioneers in the software testing field. He is a professor of computer sciences at Florida Institute of Technology and the (co-)author of truly great books like “Testing Computer Software” (alledgedly the best selling software testing book of all time) and “Lessons learned in Software Testing” (which inspired and influenced me big time). He founded the “context-driven school of software testing” (I’m on their side) and has all these excellent free courses available online for Black Box Software Testing. All this was rushing through my head while cruising through the lowlands. Later on, traffic came to a standstill, and this gave me even more time to get my imagination running… What if I don’t like him? What if he turns out to be a belligerent ghoul (gratuitous “The Smiths“-reference)? Well, none of all that. Cem is a nice person, almost humble in his ways. I like him. A friendly, human encyclopedia of black box software testing.

The size of the workshop was pretty small – only 12 people enrolled, which made it super-interactive. Immune IT had asked Cem to talk specifically about testing in difficult economic times. He did talk about that, briefly, but luckily he covered a whole range of other things as well. Some highlights:

  • Exploratory checklists and a truly hilarious piece of scientific proof that following scripts is a best practise (yes, you heard it right, in some cases there *are* best practises) for brain-damaged rats. In 1977, Cem incidentally stumbled upon proof that normal lab rats use ‘checklists’ to drive their behaviour, while brain-damaged ones resort to following the same script over and over, no matter the context. More on this can be found here.
  • Scripting and learning. Cem debunked some common myths surrounding scripted tests.
    #1. “Test scripts are ideal as ‘training wheels’ for new testers. After several months of following a wide range of scripts, the new tester will have learned by example a lot about the application domain, the program and how to test it”. So they say. But have you ever noticed what happens when you drive to a new place with a GPS that gives you a script like “Turn left at the next lights etc…?”. If you try to go there again, do you actually remember the route? You learn faster when exploring and discovering, rather than by ‘being told’.
    #2. “Test scripts specify all initial entry conditions”. But you cannot capture everything, there are so many variables that it becomes impossible (system state, program state, system config, system resources, other processes) to describe this upfront.
    #3.  “Test scripts specify the expected results”. But – same as above – scripts cannot specify all possible outcomes. There are simply too many variables involved. Our tests cannot address all possibilities.
    #4.  “Test scripts involve a comparison that machines or humans should make”. But what about confirmation bias? Or inattentional blindness? We ignore things based on their meaning, before we ever become aware of them.
  • An extensive part about exploratory testing from the godfather himself, it doesn’t get any better than that. He explained the renewed definition of exploratory testing (which I endorse but find a bit too long – I liked the old one better).  *taking a big breath* here goes:

Exploratory Software Testing:
– is a style of software testing
– that emphasizes the personal freedom and responsibility
– of the individual tester
– to continually optimize the value of her work
– by treating
     * test-related learning,
     * test design,
     * test execution, and
     * test result interpretation
– as mutually supportive activities
– that run in parallel throughout the project

  • An intriguing part on testing an investment modeling tool called VectorVest.
  • “Exploratory Test Automation”. Slides available here. I specifically liked his experiences at a phone manufacturing company called Telenova.  They were able to track down a stack overflow bug in one of their telephone sets that had been undetected even though testing achieved 100% statement and branch coverage in the relevant parts of the code. In the field, this would require a long sequence of calls to a continuously-active phone. They succeeded in isolating it through “Exploratory Test Automation”: they created a simulator that generated long chains of random events, emulating input to the system’s 100 phones. That eventually exposed the bug (and several others as well).
  • Cem is obviously not a great fan of automated tests, but he makes an exception for “Exploratory Test Automation” , “High-volume Test Automation” and “Extended Random Regression Testing”. Traditional test techniques tie us to a small number of tests. Extended random regression and long simulations exposes bugs the traditional techniques probably won’t find.

These three days were a real treat. I was able to talk and discuss with Cem Kaner personally – and learn from him, which was priceless.  I also met some other great people – passionate about testing and always prepared for an healthy argument. At the end Cem signed the copies of “Lessons learned in software testing” that we all got for free, which means I now got two of them. One to use and one to cherish.