Hiccupps

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn ,   Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "What’s the right ratio of developers to testers?" You're an intelligent person with a sense of humour, so I hope you won't mind when I start my answer with what's the ri...

Zenzi Ali has been running a book club on the Association for Software Testing Slack and over the last few weeks we've read Agile Testing Condensed by Janet Gregory and Lisa Crispin. Each chapter was taken as a jumping off point for one or two discussion points and I really enjoyed the opportunity to think about the questions Zenzi posed and sometimes pop a question or two back into the conversation as well. This post reproduces the questions and my answers, lightly edited for formatting. --00-- Ten principles of agile testing are given in the book. Do you think there is a foundational principle that the others must be built upon? In your experience, do you find that some of these principles are less or more important than others?  The text says they are for a team wanting to deliver the highest-quality product they can. If we can regard a motivation as a foundational principle, perhaps that could be it: each of the ten pr...

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn ,   Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "For your annual review, I’ll need to see evidence of what you produced this year." From the way you phrase that question I suspect you're after some kind of output of my wor...

Brian Marick  recently launched a new podcast, Oddly Influenced . I said this about it on Twitter: Boundary Objects, the first episode of @marick's podcast, is thought-provoking and densely-packed with some lovely turns of phrase. I played it twice in a row. Very roughly, boundary objects are things or concepts that help different interest groups to collaborate by being ambiguous enough to be meaningful and motivational to all parties. Wikipedia  elaborates, somewhat formally:  [boundary objects are] both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites ... The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds. The podcast talks about boundary objects in general and then applies the idea to software development specifically, casting ...

  The testers at work had a lean coffee session this week. One of the questions was  "I like testing best because ..." I said that I find the combination of technical, intellectual, and social challenges endlessly enjoyable, fascinating, and stimulating. That's easy to say, and it sounds good too, but today I wondered whether my work actually reflects it. So I made a list of some of the things I did in the last working week: investigating a production problem and pairing to file an incident report finding problems in the incident reporting process feeding back in various ways to various people about the reporting process facilitating a cross-team retrospective on the Kubernetes issue that affected my team's service participating in several lengthy calibration workshops as my team merges with another trying to walk a line between presenting my perspective on things I find important and over-contributing providing feedback and advice on the process identifying a...

In yesterday's post, Optimising start of your exploratory testing , Maaret Pyhäjärvi lists anti-patterns she's observed in testers that can lead to shallow outcomes of testing. She ends with this call: Go find (some of) what the others have missed! That strikes a chord. In Toujours Testing I recalled how my young daughter, in her self-appointed role as a Thing Searcher, had asked me how she could find things that no-one else finds. I replied Look where no-one else looks. Which made her happy, but also made me happy because that instinctive response externalised something that had previously been internal.  The phrase has stuck, too, and I recall it when I'm working. It doesn't mean targeting the obscure, although it can mean that.  It also doesn't mean not looking at areas that have previously been covered, although again it can mean that. More, for me, it is about seeking levels of granularity, or perspectives, or methods of engagement, or personas, or data, or im...

  We asked one hundred customers how they'd like teams to approach work on their projects. It's long been my intuition that the families on Family Fortunes will almost always choose to play, overtaken by the adrenalin buzz of starting something, unhindered by any consideration of the context or subject matter.  The view is supported (thank you, Internet!) by Nicholas Boy's informal analysis Pass or Play: A Data Driven Approach to Family Feud . Out of the one hundred face offs I watched, can you guess how many times the teams passed? Nope, less. No, seriously, less. Twice. The analogy is weak I know, and I doubt it's as high as 98% at work, but I've seen so much started with so little consideration of anything other than some potential positive wished-for outcome.  Every time, I imagine the line of Sunday Best grandparents, trying-to-be trendy nephews, and that weird extrovert brother-in-law, all waving their hands in the air and shouting ... "PLAY!" Imag...

A month or two ago, after seeing how I was taking notes and sharing information, a colleague pointed me at Tiego Forte's blog on Building a Second Brain : [BASB is] a methodology for saving and systematically reminding us of the ideas, inspirations, insights, and connections we’ve gained through our experience. It expands our memory and our intellect... That definitely sounded like my kind of thing so I ordered the upcoming book, waited for it to arrive, and then read it in a couple of sittings. Very crudely, I'd summarise it something like this: notes are atomic items, each one a single idea, and are not just textual notes should capture what your gut tells you could be valuable notes should capture what you think you need right now notes should preserve important context for restarting work notes on a topic are bundled in a folder for a Project, Area, or Resource and moved into Archive when they're done. ( PARA ) ...

Last week I hosted a webinar, Steel Yourselves , at the Association for Software Testing .  I'd been thinking about the format for a while and waiting for an opportunity to try it out with speakers that I knew would be able to do it justice. There's an interesting debating tactic in which the idea is ...  ... to help one's opponent to construct the strongest form of their argument. This may involve removing flawed assumptions that could be easily refuted, for example, so that one produces the best argument for the 'core' of one's opponent's position. I thought it would be interesting to have speakers take a testing concept they are opposed to and construct a case for it, present it, defend it during a Q&A, then talk about what they learned and how they felt. I thought it would be challenging for the speaker — a chance to find something out about their views — and inspiring for the audience — a chance to see someone p...

  If only we knew ... When our testing is essentially the same eyes looking through the same lens at the same thing in the same context in same way over and again then we are limiting the extent to which we can learn about our product. If we aspire to know more, then we should use different eyes and different lenses and look in different ways at different aspects of the system under test in different scenarios. Easy to say, of course. But how to do ? Engage with what's happening elsewhere in our teams, in other teams, in our companies, in our domains, in the tech our companies use, in the testing community and industry, and in other areas relevant to our contexts. If only we new ...  We will find people, tooling, approaches, or knowledge that could help us do a better job. We will make opportunities to try those new things and invest in the ones that look promising.  We will find that what we knew wasn't as much as we thought. Image: https://flic.kr/p/2mz3krH