Hiccupps

Eric Proegler was in town last week and I asked him if he'd be up for re-running his recent TestBash talk, Continuous Performance Testing, at our office. Good news! he was, and he told us the story of how a lumbering testing dinosaur who watched the agile asteroid crashing into his world could become a nimble testing ninja, slotting valuable and targeted performance tests confidently into modern continuous integration. Bad news! I continued my adventures in sketchnoting and they're not the greatest.

"Do you have generic strategies for the prioritisation of tasks?" When  Iuliana Silvăşan  asked the question I realised that I probably did, but I'd never tried to enumerate them. So we went to a  whiteboard for 20 minutes, and we talked and sketched, and then afterwards I wrote brief notes, and then we reviewed them, and now here they are... We think these factors are reasonably generally applicable to prioritisation of tasks: Risk Value Cost Importance Urgency Time Goals Commitments Yes, they are generic and, yes, they will overlap. That's life. The last three perhaps merit a little additional explanation. Time is a compound factor and covers things like resource availability, dependency planning, and scheduling problems which could be split out if that helps you. Goals cover things like experience you want to get, skills you want to practice, or people you want to work with. This might not be a primary factor, but could help you to choose betwe...

George Dinwiddie recently delivered a webinar, Distilling the Essence , on the topic of crafting good examples of acceptance criteria. From the blurb: When creating our scenarios, we want to fully describe the desired functionality, but not over-describe it ... Which details should we leave visible, and which should we hide? ... [We will see how we can] distil our scenarios down to their essence and remove distracting incidental details. I loved it and, naturally, wondered whether I could distil the essence of it . Here goes: Not just examples, but essential examples. An essential example promotes shared understanding, testability, clarity of intent. Remove incidental details; they obscure the important. Highlight essential details; they have the most communicative value. Essential details don't change with user interface, workflow, implementation technology. To help: name scenarios, abstract specifics, note explicit rules, conditions, and boundaries. Bottom-up is O...

I laughed out loud when I saw this sign on the merch stand of the  The Johnny Cash Roadshow  gig in Bury St Edmunds yesterday. At face value, it's straightforward, right? You can only pay with good, old-fashioned, money. But the Roadshow are a tribute act and so also play Cash only . Except they don't, they covered  Wildwood Flower  (June Carter) and Flowers on the Wall  (Statler Brothers). But those artists have strong connections to Johnny Cash so, yeah, still Cash only. Except the band also played an original song by Clive John, from the band. But it was a song he was asked to write, "in the style of Johnny Cash," so just about Cash only. Except that several of Clive's CDs, also containing original material, are available on the merch stand. But he's Johnny Cash in the band so perhaps still tenuously Cash only? Except nothing on the table is actually by Johnny Cash. [Repeat to fade.] I strongly believe that there's value, as a ...

As a hiring manager it'll often be days between engagements with a candidate. I am not renowned for my memory but, even if I was, it'd be hard to remember all relevant details of all relevant candidates during a recruitment drive. Over the years I've developed a way of taking notes which I find helps me to cheaply review and keep track of what I think of a candidate and why, and which gives me the data I need at each stage. When we open recruitment for a new position I'll start a new directory and each applicant will get a text file in it as I read their CV. I use very simple markup to record my thoughts into the file and to put notes for myself to pick up when I come back. I have a handful of key requirements: I want my notes on each candidate to be in one place (for ease of consumption). I want my notes across candidates to be consistent (for ease of comparison and navigation). I want my notes to be put down in real time (for efficiency). Let's have ...

Recently,  Sime  has been curating a reading list on complex systems for the Test team book club at Linguamatics . The last couple of papers we looked at were  Keeping It Too Simple  by Paul J. Feltovich, Robert R. Hoffman, David Woods, and Axel Roesler and  How Complex Systems Fail  by Richard Cook. Last week he suggested we stay with Cook but watch one of his talks, Resilience In Complex Adaptive Systems . The core concept from it is that systems operate in a space constrained by three boundaries: economic, effort, and performance. Crossing a boundary causes some kind of failure, and there are pressures to keep the system away from them. Typically for economic and effort boundaries, it's management pressure with an eye on the bottom line. For the performance boundary, it's common to have some kind of safety margin in place to provide a buffer against failure. Pressure to keep the system's operating point on the right side of the margin comes ...

In Episode 10 of The Guilty Tester podcast Dave Duke took questions from the Twitterverse . The first one was this: Think of a piece of work you’ve done recently, what did you actually do to test it and looking back, what surprised you? In his answer, Dave told a story about a recent series of bugs, his involvement in sharing knowledge about them, and how that prompted an unexpected fix. It's a nice story, but a different reading of the original question interests me too: how do we  test our own work? As he was asking for more questions, I suggested it to him, and he tweeted back : That's an interesting question. Back at you though. Do you test your own work differently to how you test others? Do you practice what you preach? Is it realistic to expect people to test their own work the same as they test others? Is there an advantage though. Juicy! I didn't want to spend loads of time trying to craft an answer into a sequence of 240-character soundbites but I lik...

Coaching, training, mentoring, teaching and all the rest then, eh? What are the differences? When do they matter? I'm interested in that stuff, because I find theory useful to inform my practice . But as a practitioner I want to prioritise congruence with the situation over being constrained by a label. How can theory inform my practice? A book like The Coach's Casebook provides a set of scenarios, talks about possible coaching approaches to them, and reflects on a fictionalised coach's attempts to work through them. This provides me with knowledge of tools and areas of potential application. I can call on these when someone comes to me with a problem. (Which they do, often.) What I generally won't be doing at that point is trying to open a meta-discussion in which we negotiate whether we should try coaching or mentoring right now. At best this can be clunky and a distraction for  the person I'm trying to help. At worst it blocks the conversation and maybe...

This is a joint post with Claire Banks about a mentoring experiment we conducted for six months last year. We describe how it started, how we organised it, how it went, why we stopped, and how we feel about it now. Starting Claire : I’ve been testing for more years than I care to remember. I am one of many that ‘fell into testing’ around the time of the hyped Y2K bug . I have held a variety of roles from being a test team member through to manager at numerous different companies and industries over the last 19 years. Given this wealth of experience, why on earth would I want someone I can talk things through with and seek advice from? Surely I should know it all? Well, no. I don’t know it all and never will. Plus I have a confidence issue. At CEWT #4 I presented on why I would never be a test manager again. I reflected back on my career and was struck by the realisation that I’d had: 16 years in testing 12 different companies 25 test managers 3 great test manage...

The testers at Linguamatics decided to explore the adoption of a set of team values and this short series of posts describes how we got to them through  extended and open discussion. If you find the posts read like one of those "what I did in the holidays" essays you used to be forced to write at school then I'll have achieved my aim. I don't have a recipe to be followed here, only the story of what we did, in the order we did it, with a little commentary and hindsight. Introduction Why? Teasing Them Out Living With Them Reflection --00-- We took our own sweet time to  arrive at a set of team values . That's okay with me. It felt like a good pace for us given all of the variables: the ongoing work, the people, the novelty, and the uncertainty of the outcome. We took small steps, with space for review, with clarity on the next stage, and with consensus. We've now been living with our values for a few months and I thought it might be interest...