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--  "Will the testing be done by Friday?" If the question relates to some prior discussion about scenarios we've agreed to run through before Friday then I'll do my best to base my answer on experience gathered so far . How sim...

A while ago my team was asked for estimates on a customer project that had become both urgent and important. Unfortunately, but not unusually, there was a reasonable amount of uncertainty around the customer need and two possible approaches were being proposed.  It fell to me to organise the team's response. First off, should we refuse to estimate? Woody Zuill talks compellingly about #NoEstimates approaches. In Control, or the Fear of Losing It I summarised his perspective as: 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, ... Ron Jeffries has a typically nuanced take on the idea in The #NoEstimates Movement : How to apply #NoEstimates isn’t entirely clear. ...

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

As Test Manager I fit my team's work into multiple overlapping project schedules which are not under my control. The schedules have, as you might expect, multiple constraints that operate simultaneously, such as: end dates or other milestones dependencies on other parts of the schedule or other schedules level of effort we are able or prepared to commit to different tasks in absolute terms (e.g. contractually) or in relative terms (e.g. based on perceived risk) methodology; different teams in Linguamatics operate different development methodologies, and we work with non-development teams too desired quality level (whatever that means in any given case) Scheduling in this environment is a challenge even without the wildcard that is the unknowns; the stuff you find out as you go and the contexts that change under your feet. To do my best to provide the service my (most often internal) clients want - which generally includes some kind of estimate, even if there is little ...