Hiccupps

It's nothing personal I'm sure but at this week's Cambridge Agile Exchange Ben Mancini told me that I'm a failure. Ouch! Failure, he says, is "the state or condition of not meeting a desirable or intended objective ... may be viewed as the opposite of success" and his hypothesis is that failure provides more learning than success but that we talk more about success than failure. In his talk, Ben showed examples of people who have succeeded despite repeated failure, talked about the negative effects of failure, ways to reframe perceived failure, and the benefits of pushing through failure's cloud to its silver lining. Along the way he shared some of his own failures and invited us to share personal faux pas with our neighbours in the audience then look for the learnings in them. One of the reasons I attend meetups is to be provoked into thought so, in no particular order ... In my time I've certainly done things that I'd have preferred ...

A friend lent me two books on metrics. One was so thumpingly wrong I could not finish it. One was so joyfully right I had to read it end-to-end, despite the author's recommendation not to. Dave Nicolette will be pleased to know that his book, Software Development Metrics , was the second of the two. Why so right? Because immediately I felt like I was in the hands of a pragmatist, a practitioner, and a personable guide. By page 8 he's chattily differentiated measures and metrics, identified a bunch of dimensions for projects, and then categorised metrics too. Along the way, he drops this piece of wisdom (p. 5): The sort of development process you're using will influence your choice of metrics. Some metrics depend on the work being done in a certain way. A common problem is that people believe they're using a given process, when in fact they're working according to a conflicting set of assumptions. If you apply metrics that depend on the process being done cor...

The seventh State of Testing survey is now open and continues its mission to "identify the existing characteristics, practices, and challenges facing the testing community today in hopes to shed light and provoke a fruitful discussion towards improvement." Results of previous rounds of the survey are available at the same link. Kudos to PractiTest and Tea Time With Testers for reliably keeping on keeping on with this. Image:  https://flic.kr/p/4aVL6n

What feels like a zillion years ago I wrote a few pieces for the Ministry of Testing' s Testing Planet newspaper. Understandably, they've since mostly been replaced with much better stuff on the Dojo but MoT have kindly given me permission to re-run them here. --00--  Let's not kid ourselves; we know that software always ships with bugs in it and that we’re likely to be asked about the release-worthiness of the current build at some point in the release cycle. Putting aside the question of whether or not testers should be making go/no-go release decisions, we have to be able to give a coherent, credible and useful response to that kind of request. Such a response will be part of your testing or product story at a level appropriate to the person who asked. You might talk about whatever metrics you’re required to produce, or produce for your own benefit (and the value you perceive them to have) and perhaps performance requirements such as execution speed for impor...

What feels like a zillion years ago I wrote a few pieces for the Ministry of Testing' s Testing Planet newspaper. Understandably, they've since mostly been replaced with much better stuff on the Dojo but MoT have kindly given me permission to re-run them here. --00--  You've got skills, but still you know you want more skills. Skills for testing, naturally, for the tools you use, for choosing which tools to use, for the domain you work in, the kind of product you work on, the environment your product is deployed in, for working with your colleagues, for reporting to your boss, for managing your boss, for selecting a testing magazine to read, for searching for information about all of the above. You want to hone your skills, to develop, consolidate and extend them. You want to learn new skills that will help you do what you do more effectively, efficiently, efficaciously, or just effing better. You want to find ways to learn new skills more easily, and you kn...

What feels like a zillion years ago I wrote a few pieces for the Ministry of Testing' s Testing Planet newspaper. Understandably, they've since mostly been replaced with much better stuff on the Dojo but MoT have kindly given me permission to re-run them here. --00-- It was Irving Berlin who famously said that there was no business like it but, for me, there’s no business without it. Irving’s version scans better, I’ll give him that, but mine captures an essential aspect of pretty much all successful projects with multiple participants: demonstration. On a project, at some point or points, you’re going to clue your collaborators in on what you’re doing, or what you’ve done or what you reckon you will do. And also what you aren’t, didn’t or won’t.  If not you risk confusion about important stuff like responsibilities, scope, delivery, budget and whose turn it is to make the tea. Your team mates are a great source of test ideas and, whether they’re on the project or...

Peers Exchanging Ideas : The AST Peer Conference Guide The Association for Software Testing is an organisation dedicated to advancing the craft of software testing and one of the ways we do that is by promoting and sponsoring peer conferences. When we say peer conference we don’t have a particular format in mind. Adrian Segar describes a peer conference as a conference that is small, attendee-driven, inclusive, structured, safe, supportive, interactive, community-building, and provides opportunities for personal and group reflection and action. We like that kind of framing as it provides room for many local variants, although we’d add that disseminating the results of the conference could be an important outcome too. If we had to boil down our own perspective, it would be something like this: peers exchanging ideas. To help the conferences that we sponsor, we decided to write a checklist based on the experiences of the AST Board members and other organisers that we'...

In Juggling and Bicycles , an episode of the Akimbo podcast , Seth Godin talks about learning. In particular, he makes a point about training wheels and learning to ride a bike. If the goal is to ride a bike then, while training wheels do permit anyone to pedal themselves around, superficially feeling like they are riding a bike, they don't actually teach a fundamental skill: balance. Sure, training wheels immediately give a sense of accomplishment and perhaps a confidence boost, but they don't teach balance. Worse, they actively inhibit learning that skill because they compensate for any lack of balance that the rider has without penalty or encouragement to improve at balancing. This is not to say that no-one using training wheels can ever learn to ride a bike. Godin's point is that there are ways to learn to balance and with balance riding comes easier. He points to balance bikes as one approach. In my role I support people in work they have not done before....