Hiccupps

I'm enjoying The Vernon Richard Show  a lot recently because the vibe Vern and Richard have created is one where two knowledgeable and experienced mates talk around a topic they are both interested in with curiosity and open minds.  Also, there's less football than there used to be. This week's show is titled When Everything Sounds Like Testing… How Do You Explain What You Really Do?  and sees the pair discussing the meanings of quality assurance, quality engineering, testing and other related terms. There's no firm conclusions, and enough left unsaid that they're carrying the dialogue over into the next episode, but I was still interested to see these two models put forward: In the first, proposed by Vernon, quality engineering consists of preventing bugs (QA) and detecting bugs (testing). In the second, floated by Richard almost in spite of his better judgement, quality assurance is the holistic term. In this ver...

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--   "Testing is just to make sure the requirements are met" Yes, that's a common perspective, but ... But I disagree with it given a commonly-held view of the requirements . Let'...

The other day I got tagged on a Twitter thread started by Wicked Witch of the Test about people with a background in linguistics who’ve ended up in testing. That prompted me to think about the language concepts I've found valuable in my day job, then I started listing them, and then realised how many of them I've mentioned here over the years .   This post is one of an occasional series collecting some of those thoughts.  --00-- In this series so far we've looked at words and syntax. In both cases we've found that natural language is an imprecise medium for communication. We might know the same words and grammar as others ... but they will have their own idea about what they mean ... and even where we agree there is ambguity ... and all of us, the world, and the language are evolving ... all the time. Today we'll add semantics which, in a pleasing twist, is itself ambiguo...

  The other day I got tagged on a Twitter thread started by Wicked Witch of the Test about people with a background in linguistics who’ve ended up in testing. That prompted me to think about the language concepts I've found valuable in my day job, then I started listing them, and then realised how many of them I've mentioned here over the years .   This post is one of an occasional series collecting some of those thoughts.  --00-- In The Complete Plain Words , Ernest Gowers notes, acidly, that: What appears to be a sloppy or meaningless use of words may well be a completely correct use of words to express sloppy or meaningless ideas. It surely sounds trite to say it but our choice of words can make a significant difference to how well our message is understood, and how we are judged. We choose from amongst those words we know, our lexicons . The more my lexicon agrees with yours,...

This week I listened to a Ministry of Testing podcast on exploratory testing .  After the intros, as the panelists  attempted in turn to give their definitions of exploratory testing, I realised that I didn't have one for myself. It's not that I don't know or haven't seen definitions. Here's one I've heard a few times, from back in 2008, in A Tutorial in Exploratory Testing by Cem Kaner:  Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project. It's not that I think The Exploratory Elders like Kaner got it right back in the day and their words should be carved on monumental stones and polished on Sundays, or that I'm not interested any more. I was readi...

I was interviewed on Testers' Island Discs a few months ago. During the conversation, Mark Winteringham asked me about the Association for Software Testing and I said this: The AST is a professional body for software testers. It's a non-profit — we're all volunteers — and its mission is to advance understanding of the science and practice of software testing according to context-driven principles ... which sounds like a real mouthful. The way I like to gloss it, and the way it speaks to me, is that we value both expertise and experience when it comes to testing and generally speaking we favour context-driven testing too. My sense is that, these days, most people would, even if they don't really know the terms, probably be doing some kind of context-driven testing. The proportion of people doing old-school stuff, test cases and so on, is shrinking as far as I can see. I love talking about AST (why not come and join us ?) and I very...

  Maaike Brinkhof tweeted this last week:   Give me your most brutally honest definition of software testing.  As it happens, I have a definition of software testing that works for me , and it is (honestly) my honest answer: Testing is the pursuit of relevant incongruity. But Maaike asked for the most brutally honest definition. How might that change what I'd say? Well, what is brutal honesty? As I interpret the term, it describes a statement of perceived truth given with no regards for the feelings of anyone who might hear it. That gives me a route in: can I find someone with a perspective that might offend us testing snowflakes, someone who is relevant to us, and someone whose view I can characterise with extreme candour? I thought about this for about, um, one second and chose THE BUSINESS. A perspective that might offend? Check. In the main, businesses run for the benefit of the business and, particularly as th...

Much of  Definition of The Engineering Method  by Billy Vaughn Koen chimes with what I've come to believe about testing.  In part, I think, this is because thinkers who have influenced my thinking were themselves influenced by Koen's thoughts. In part, also, it's because some of my self-learned experience of testing is prefigured in the article. In part, finally, it's because I'm reading it through biased lenses, wanting to find positive analogy to something I care about.  I recognise that this last one is dangerous. As Richard Feynman said in Surely You're Joking, Mr. Feynman!: "I could find a way of making up an analog with any subject ... I don’t consider such analogs meaningful.”  This is a short series of posts which will take an aspect of Definition of The Engineering Method that I found interesting and explore why, taking care not to over-analogise. Getting Myself Koen Sota so Good Meta is Better The Tester as Engineer? --00-- It is ...

The topic at CEWT #7  last weekend was Dirty Testing Secrets. I decided to present something reasonably provocative as a conversation starter. I think it worked. The essay below is a pretty version of the notes I prepared in advance. --00-- Quality Assurance. QA. It's getting less common, but it's still not unusual for people in software to talk about getting something into QA or to asking us to QA their stuff. I've worked hard over the years at our place to spread the word that I don't think of my team in that way. I do an induction for all new employees and explain how testing is a creative and intellectual activity, not a checkbox ticking drudge. Sadly, I still encounter career testers who think that their role is to confirm that requirements are met and no more. But my sense is that that's an open secret rather than a dirty one. This isn't a dirty secret either, although it might be a surprise to some: That's not to say that we ar...

At CEWT #7 today I surprised the participants by asking them for some definitions as they arrived. I used the definitions in my talk, which I've blogged about , but for now here's a simple list. Add your own definitions in the comments if you like. Quality How well someone perceives something works and meets a set of requirements. Value to someone who matters at some time. Quality is value to some person that matters. You'll know it when you see it - when something is good, shiny, runs smoothly. External quality is a positive characteristic of software encompassing robustness, correctness, and lack of bugs. An outcome that satisfies all stakeholders + customers. The extent to which any given attribute of a "thing" meets its intended or desired purpose. A positive attribute of something (as in "a quality of ..") Quality is subjective and hence hard to define as what's quality for some is not for others. Initially I was going to say wh...

  We play tricks on ourselves, Woody Zuill says. We think that we estimate because it gives us control. In reality, we estimate because we fear losing control. The irony, of course, is that we aren't in control : estimates are inaccurate, decisions are still based on them, commitments are also based on them, projects overrun, commitments are broken, costs spiral, ... Spending more time estimating typically doesn't make us better at estimating but it does take time away from doing.  Zuill's experience is that it's possible to build software without any estimates by taking an important piece of functionality, building only the absolutely critical pieces of it, and then putting it in front of someone. The doing, and the review of what's been done, will help to determine what should be done next. Sounds simple? Yes, but it's not easy . It's crucial to find allies and customers who are ready to accept it. Here's my tidied-up sketch...

The Test team book club is reading Guide: Achieving Observability from Honeycomb , a high-level white paper outlining what observability of a system means, why you might want it, and factors relevant to achieving and getting value from it. It's not a particularly technical piece but it's sketched out to sufficient depth that our conversations have compared the content of the guide to the approaches taken in some of our internal projects, the problems they present, and our current solutions to them. While I enjoy that practical stuff a great deal, I also enjoy chewing over the semantics of the terminology and making connections between domains. Here's a couple of first thoughts in that area. The guide distinguishes between monitoring and observability . monitoring: "Monitoring .. will tell you when something you know about but haven't fixed yet happens again" and "... you are unable to answer any questions you didn’t predict in advance. Moni...

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...

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-- Having got to a longlist of seven values that we were struggling to cut down further , we decided to live with them for a while and then see how we felt. I made small cards listing the values and short descriptions and distributed them to the team. I also made the values prominent on our team's pages in the company wiki and wrote about our exper...