Hiccupps

Gut instinct. If you're a working tester you probably use it, oooh, roughly, I'd say, well, on average, y'know, in a manner of speaking, perhaps, erm, just about all the time . Feel, or the intuition bred of experience, is rolled into everything you do. In every decision you make, it's playing a part. Every time you speculatively poke the system this way or that, or don't poke it, or poke it twice quickly, or with a series of sticks with lengths in powers of two, or with a null stick, or a log, a twig, a stake or a  bâton , every one of those, and pretty much everything else, in some way, involves your gut. Which is why you'd better feed it. And what does it like to eat?  Data . Data: gather some, test some, generate some, analyse some, learn some.Yum, yum. Image:  http://flic.kr/p/4Lxvsg .  With thanks to  The Social Tester . 

The Dev Manager has a phrase that he uses from time to time when he wants to take some shaky code, perhaps lashed together for speed or an acute need, or prototyped as a script, or created as a demo, and bring it into the product. Let's make an honest woman out of that, he'll say. The novelty of the unexpected anthropomorphism with a side of sexism soon wears off, although some of those kinds of projects can feel a lot like organising a wedding - expense, stress, unrealistic expectations, Mothers-in-law. (Go on, tell me you've never had a Ma-in-law on your project.) What I've taken from it is the idea that I should always consider coding my quick-and-dirty investigative scripts with a view to making them part of a regression suite later. I don't go that way every time. For instance, when I know it's a stricly one-shot deal like processing log files to diagnose an issue, I'll use whatever is fastest. And when I can get what I need inside an existin...

Me and my mate Dave were sitting on the river bank down by the Mill one dinner time, years ago, when we were doing our PhDs at the Computer Lab . We've both ended up in software - he's a developer and I'm in test - but back then there were no chips on our shoulders, no Bugzilla to converse through, no wall to chuck builds over and no barely concealed distaste in each other's presence. No, in those sunny days we were just young bucks flexing our intellects in the finest Cambridge tradition, speculating about the meaning of life, fencing with fine verbal sabres on the origin of the universe, nature versus nurture, the merits of a range of economic models and whether we could tempt a duck over the weir using the crusts off our sandwiches. We spent the best part of an hour, and our cheese and pickle, getting the thing progressively closer to the edge until finally it reached too far forwards after a crumb and slipped onto the lip. Victory!   And then ...

I think I read it in something Oliver Burkeman wrote recently but the idea is all   over the place : counting backwards in threes can help you to fall asleep when you've got stuff on your mind and can't settle down. The idea is that it's a sufficiently complex activity that you have to focus on it rather than all the other things crowding your consciousness and keeping you awake, but it doesn't have a high enough cognitive load to keep you awake itself. So the other night, after one of my daughters had woke me up at 2am to tell me she loved me (thanks, but...) I tried it: 500, 497, 494 ... all going well ... 491, 488  ...  counting down ... 485 ...  a second voice: how can we check we're on track?  ... 482 ...   how about using 470? ... 479 ... 10 by 3 is 30 ... 476 ... and 30 off 500 gives 470 as a simple verification  ... 473 ... Hmm, 473 less three, yes!  ... 470 .... That's a pass. We can check again at another 30 ...

I sometimes consciously split the functionality I'm testing into two parts:   general : behaviour that is the same, or similar, regardless of where it appears, how it is invoked and so on; and  specific : which differs according to function, context, time, data types etc.  I'll tend to do this more on larger projects when  the areas are new to me, or to the product, or if they're complex, or I think the test framework will be complex, or the specific is heavily dependent for its delivery on the general, or perhaps when the specific details are certain to change but the general will be stable.   I'll be looking to implement automation that concentrates first on general functionality and self-consistency and that will serve as a backstop when I move on to the more specific material.  To speed things up, to get wider coverage easily, and to avoid dependencies, I'll try to avoid crafting new test data by looking for data already in the company that can...

Co-location is intrinsic to  some software development  and it can also have social benefits, build an esprit de corps and smooth out the kinds of communication issues that time zones and typing often cause.  But, for me, there's another softer reason why co-location is advantageous - I learn stuff in passing from the natural interactions I have in the course of a working day.  When I go to a colleague's desk to ask about some functionality, and they pull up source files for inspection, I'm looking at the text, but I'm also interested in the editor they're using, the powerful ways it lets them search/replace and the fact that it has a plug-in for fancy diffing that I wasn't aware of and that I can use myself next time. Sitting with a developer as they write code is a welcome insight into the mindset of someone who really knows the nuts, bolts, screws, rivets, nails and other fixings when my skills, relatively speaking, extend to being able to tell a  brad...

The concept of test doubles  is well-established in unit testing with mocking probably the most familiar. The idea is that you fake enough of an API to permit unit tests to run against it. You can control the way that the mock API responds, tailor your test coverage and avoid external executables, dependencies on other code and so on to run your tests. It can be useful to use similar concepts at the component level too. For example: for diagnosis and investigation of misbehaviour in complex systems you can replace components in a workflow. I like this especially when the problem behaviour is hard to reproduce naturally. Part of our core product is  a server that calls out to other software for some tasks and returns data back to a client. Replacing a server-side executable with something that generates a specific output (e.g. returning an error response to the server, or bad data to the client) or behaviour (e.g. taking so long to respond that the server is forced to ti...

I read my daughter a story last night, about an elephant that thinks she's a mouse. It seems reasonable, her big book of knowledge says mice can be grey with big ears and skinny tails. Note to new testers: specifications are seldom sufficient . Think broadly. She moves in with a mouse family but it doesn't go well. Luckily Granny Mouse has the wisdom of age and experience, works out what's gone wrong and takes Nelly to the zoo to be with her own kind. Unfortunately, one of the mice then reads Nelly' s book and gets the idea he's an elephant. Note to old-hand testers: spread your insight through the team. A few times recently I've found myself talking to less-experienced colleagues and realising that I've segued from the mouse to the elephant, assuming they were following. They weren't, and the discussion got confused. We started off on a small acute, practical problem of right now and I expanded out to the big, theoretical potential solution o...

If you aren't using automation to get you to a place where you can efficiently apply intelligence you're almost certainly wasting time and effort. Michael Bolton put it this way on Twitter last week :  I like ... using automation as a taxi to drop me off at the site of the real work. When we moved offices a couple of months ago Marketing updated the contact details in their collateral and then requested that we review the changed PDFs. Simple approaches to this task would include reading all of the documents from top to bottom, skimming them looking for addresses to check or using a PDF reader's search functionality in each document to look for likely mistakes.  All of these would have been slow, prone to error and without a good way to make efficiencies. What we actually did was automate, using command line tools to do the heavy lifting. First, we transformed the PDF files into a text format in which they could easily be searched as a set:  $ f...

So the Dev Manager  finally started his own blog . Obviously, I was more than happy to pour feedback on it but more than disappointed that there's no public bug tracker, so I had to content myself with exaggerated outrage and inflated prioritisations via email. Which just isn't the same. But, joking aside, we should offer up a toast to him for writing positively about Weinberg's Perfect Software in one of his first posts even if he misinterpreted my face when I passed him the book as hopeful. In fact it was merely reflecting my ennui, despair, frustration, coffee intake and thoughts of an impending holiday . Weinberg wants to know  about how his writing has affected people's lives and I'm anxiously awaiting developments here too. Image:  http://flic.kr/p/9V2bKU