Hiccupps

This month's  Lean Coffee  was hosted by  DisplayLink . Here's some brief, aggregated comments and questions  on topics covered by the group I was in. How to spread knowledge between testers in different teams, and how often should people rotate between teams? How to know what is the right length of time for someone to spend in a team? When is someone ready to move on? How do you trade off e.g. good team spirit against overspecialisation? When should you push someone out of their comfort zone, show them how much they don't know? Fortnightly test team meetings playing videos of conference talks. Secondment to other teams. Lean Coffee for the test team. Daily team standup, pairing, weekly presentations, ad hoc sharing sessions after standup. Is there a desire to share? Yes. Well, they all want to know more about what the others do. People don't want to be doing the same thing all the time. Could you rotate the work in the team rather than rotate people

Good Products Bad Products by James L. Adams seeks, according to its cover, to describe "essential elements to achieving superior quality." Sounds good! As I said in my first (and failed) attempt to blog about this book, I'm interested in quality. But in the introduction (p. 2) Adams is cautious about what he means by it: Quality is a slippery, complex, and sometimes abstract concept ... Philosophers have spent a great deal of time dealing with the concept of quality. This is not a book on semantics or philosophy, so for our purposes we will simply assume that quality means "good." But, of course, that leaves us with "good for whom?" "good for what?" "good when?" "good where?" and if you really like to pick nits, "what do you mean by good?" I won't go there, either. My bias is towards being interested in the semantics and so I'd have liked not to have seen a concept apparently so fundamental to t

I recently became interested in turning bad ideas into good ones after listening to Reflection as a Service . At around that time I was flicking through the references in Weinberg on Writing - I forget what for - when I spotted a note about Conceptual Blockbusting by James L. Adams: A classic work on problem solving that identifies some of the major blocks - intellectual, emotional, social, and cultural - that interfere with ideation and design. I went looking for that book and found Adams' web site and a blog post where he was talking about another of his books, Good Products Bad Products : For many (60?) years I have been interested in what makes some products of industry "good", and others "bad". I have been involved in designing them, making them, selling them, buying them, and using them.  I guess I wanted to say some things about product quality that I think do not receive as much attention as they should by people who make them and buy them I h

Last month's Cambridge Tester meetup was puzzling. And one of the puzzles was an empty wordsearch that I'd made for my youngest daughter's "Crafternoon" fundraiser. At Crafternoon, Emma set up eight different activities at our house and invited some of her school friends to come and do them, with the entrance fee being a donation to charity. The idea of the wordsearch activity is simple: take the blank wordsearch grid and make a puzzle from it using the list of words provided. Then give it to someone as a present. If you fancy a go, download it here:  Animal Alphabet Wordsearch (PDF) (You're free to use it for your own workshops, meetups, team exercises or whatever. We hope you have fun and, if you do, please let us know about it and consider donating to an animal charity. Emma supports Wood Green .) After Crafternoon, I offered the puzzle to Karo for the Cambridge Tester meetup and she wrote about in Testing Puzzles: Questions, Assumptions, St

Months ago, Rich Rogers asked on Twitter for volunteers to review the book that he's writing, and I put my hand up. This week a draft arrived, and I put my hands up. After the shock of having to follow through on my offer had worn off, I pondered how to go about the task. I've reviewed loads of books , but always with the luxury of pulling out just the things that interest me. I can't recall giving detailed feedback on something book-length before and I wanted to do a thorough job. I liked the idea of an approach that combined reaction and reflection . Reaction is an "inline" activity. I can read the book and provide my  System 1  responses as I go. Because they are instinctive I don't need to interrupt my flow significantly to capture them. My reactions can then be data for my reflection, where my System 2 processes try to make sense of the whole. That seemed reasonable. But I'm a tester so I framed it as a mission: Explore the manuscript us

So you’re thinking you might like to move into software testing? Perhaps you’re already in software and fancy a change. Perhaps you’re working in another industry and fancy a change. Perhaps you’re fresh out of college and just fancy finding a job … that you can later change. No doubt you’ve spent some time Google-wrangling and found those numerous lists of things that software testers need to be able to do, or skills that great software testers always display, or attributes that employers think that testers must have. Things like this: You shouldn’t be a tester if you don’t have attention to detail You shouldn’t be a tester if you don’t have great communication skills You shouldn’t be a tester if you’re not patient You shouldn’t be a tester if you’re not willing to learn You shouldn’t be a tester if you don’t have prioritization skills You shouldn’t be a tester if you don’t have a technical background You shouldn’t be a tester if you can’t code You shouldn’t be a tes