Hiccupps

So my wife caught me giggling to myself in the kitchen. Why? I'd just seen a really corny pun on peace and peas . It wasn't the "classic" above  but it was the same kind of thing. In fact, it wasn't the joke itself that had caused me to crack my face at all, but the thoughts spurred from the desire to make a better one from the same phonetic premise. The first thing I come up with is: Give Pisa chance This slight variation on the well-known punchline is a plausible sentence but to make it work as a joke I need a context that can produce it. I'm working backwards from a result to look for some setup in which it is coherent: Did you know that casinos are illegal in some parts of Italy? Apparently a bunch of gamblers held a candlelit protest overnight.  They were singing "All we are saying is give Pisa chance." This is also a testing pattern. When you're looking at responses from a system, a useful approach to finding potential issue...

Screen  is a godsend for those of us who work at the command line on Linux servers. It provides a way to persist session state across connections to the server and to run multiple terminals in parallel from within in one application. If you've ever suffered from dropped connections to the server killing your session and all of your running applications, or ever wanted to kick off long-running test code at work before you leave, peek at it when you get home and then pick it up again in the morning as if you'd never been away, or run multiple  PuTTY  sessions on the same server and got lost in a whirlwind of windows, screen is for you. I use it pretty much every day. Useful links: http://www.rackaid.com/resources/linux-screen-tutorial-and-how-to http://linux.die.net/man/1/screen http://www.computerhope.com/unix/screen.htm   Image: Wikipedia

So I had a character picker to test across three releases, call them A, B and C. Between A and B new characters had been added and there was a requirement that a certain range of the Latin-1 character set  must be fully-populated by these additions. Between B and C there should be no differences. Putting functional testing of the component aside, I wondered how I could efficiently compare two versions of a graphical interface component (a) for the characters on their labels and (b) for the codes of the characters represented by them. And then do it again for another pair of versions. On a hunch, I tried selecting all of the characters in the component from release A and copy-pasting them into Excel. A little inspection convinced me that the characters had been copied reliably. So I did the same for release B. And then I simply used Excel to compare cell values for corresponding cells for the two releases. Something as naive as this does the trick, showing y where they...

At last night's Cambridge Tester Meetup , Karo  talked about heuristics  (slides here ). After a brief introduction to the topic, she walked us through a couple of testing mnemonics: FCC CUTS VIDS   FEW HICCUPPS   We then split into two groups for an exercise. While the other group applied FCC CUTS VIDS to testing Karo's kitchen - in fact, a schematic and floor plan of it  - the group I was in took FEW HICCUPPS and a beer glass used at the 42nd Cambridge Beer Festival . There's plenty of pictures of the glass at #cbf42  but to give a quick description: it's a pint glass with a loosely-themed Hitchiker's Guide to the Galaxy/Beer Festival mashup logo (because it's the 42 nd festival, we assume) on one side and a Campaign for Real Ale  (Camra) logo along with the festival name and dates on the other. It has calibrations for different amounts of beer, apparently in accordance with some kind of volume marking regulations which have a CE log...

From plitter to drabbletail: the words we love  is list of lexical lostlings, of forgotten or underused words such as clarty , slipe , eschew and splunder that have special appeal to a selection of leading authors. In his piece, Robert MacFarlane offers the term apophenia , attributed to Klaus Conrad , and defined as: the unmotivated perception of connections between entities or data ... abnormal meaningfulness. MacFarlane counters apophenic tendencies by approaching his work in a way he describes using another uncommon locution, humbel , from James Stout Angus , the Shetland poet: to reduce protruberant parts ... as the beard of corn is knocked off by ... thrashing with a flail. I've long thought that it's a useful heuristic for testers to be humble ( 1 , 2 )  and to that I can now add that we should also be humbel. Image:  https://flic.kr/p/8qYFUo

Sometimes, perhaps when you're under time pressure and on a mission and in a part of the product you're not familiar with, you bump into issue after issue after issue trying to get to the thing you just have to get tested right now . Maybe you looked at the doc, but really you only skimmed it because your boss was on your back, a pain in the neck, giving you a headache and tapping his wrist. Maybe you noticed there was a warning in the log file, but it looked a bit internal and you dismissed it because some output was produced and the product manager is standing in the doorway editing her MS Project plan and tutting heavily. Maybe you hopefully copied the conventions of other commands in the config file, or just plain guessed at the syntax for the bits you added, because the end of the sprint is tomorrow and the Scrum Master's definition of done is all about the done and less about the definition . Maybe you asked somebody else, an expert, who had just the knowl...

Here's a couple of personal, experience-based, posts by developers that I came across recently and really like: On Code Review by Glen D Sanford Lessons Learned in Software Development  by Henrik Warne While Warne is up front about the fact that he's talking heuristics, Sanford doesn't explicitly say but is thinking that way too ("should probably always be"). In both cases the suggestions they make include general team-working advice for those working in software. Image:  https://flic.kr/p/59RmYJ

I've had a good run of reading in the first three months this year and I thought I'd try to summarise it  by picking out one or two thoughts on each book. Becoming a Technical Leader , Gerald M. Weinberg  I'm not a vain or pretentious kind of chap, but I did enjoy discovering that leadership is all about moi . That is Motivation, Organisation and Ideas.  A good technical leader will look to supply these things in the right measures at the right times for their teams; a great technical leader will look at themselves to see which of these is their weakest and find ways to work at improving it. What Did You Say? The Art of Giving and Receiving Feedback , Charles N. Seashore, Edith W. Seashore, Gerald M. Weinberg Before I started regular 1-1s with my test team last year, I cast around for ideas and found a series of Manager Tools podcasts which, despite being much longer than it needed to be, I liked a great deal. A few months in, I was looking for ways grow...

I was flattered to be asked to contribute articles to The Testing Planet and the uTest blog recently. Here's what I gave them: Not Sure About Uncertainty : thoughts on known/unknowns, quantifiable and unquantifiable risks, testing models incorporating them and their relationship to risk-based testing. Make Like a Tester : thoughts for testers starting a new job, with butter, elephants, Stephen Hawking and a sponge. Image:  https://flic.kr/p/9k7Wk1

As a tester, comparison, and confidence in your ability to compare, are key parts of your toolkit. So, like me, you might find this video humbling. It talks about metamers (where different things look the same) and anti-metamers (the same things look different) and shows how easy it is to mislead our visual systems even while explaining how the images were created and why the optical illusion works. Video: https://www.youtube.com/watch?v=tQ9oUfyEc1k