Hiccupps

If you aren't using automation to get you to a place where you can efficiently apply intelligence you're almost certainly wasting time and effort. Michael Bolton put it this way on Twitter last week :  I like ... using automation as a taxi to drop me off at the site of the real work. When we moved offices a couple of months ago Marketing updated the contact details in their collateral and then requested that we review the changed PDFs. Simple approaches to this task would include reading all of the documents from top to bottom, skimming them looking for addresses to check or using a PDF reader's search functionality in each document to look for likely mistakes.  All of these would have been slow, prone to error and without a good way to make efficiencies. What we actually did was automate, using command line tools to do the heavy lifting. First, we transformed the PDF files into a text format in which they could easily be searched as a set:  $ f...

So the Dev Manager  finally started his own blog . Obviously, I was more than happy to pour feedback on it but more than disappointed that there's no public bug tracker, so I had to content myself with exaggerated outrage and inflated prioritisations via email. Which just isn't the same. But, joking aside, we should offer up a toast to him for writing positively about Weinberg's Perfect Software in one of his first posts even if he misinterpreted my face when I passed him the book as hopeful. In fact it was merely reflecting my ennui, despair, frustration, coffee intake and thoughts of an impending holiday . Weinberg wants to know  about how his writing has affected people's lives and I'm anxiously awaiting developments here too. Image:  http://flic.kr/p/9V2bKU

Maybe I'm just an oversensitive, subtle and thoughtful kind of guy, or attuned to ambiguity, or unempathic, or unimaginative, or a git, or plain old-fashioned thick, but being precise and clear with language is a skill that I value highly and strive to achieve . With questions, I find that I'm unlikely to assume the context if it's not already present or given. So, for example, I probably would not have a simple answer to " should the product do X?" Are we discussing a version of the product in the field or the product in development? Is it my personal opinion you're after? My user-head opinion? If so what kind of user? Perhaps it's what the spec says or said once upon a time? Maybe X is a reasonable result under certain circumstances but not others? Are you implicitly telling me that the software does do X and you're not sure whether it's right? Or that you think it might be intended to do X, and it doesn't? Or asking whether we need X in...

As the wartime slogan had it, careless talk costs much time in reimplementation and testing and ultimately late delivery of software that contains less than you wanted at a quality level of just-about-bearable and which will be followed immediately by a patch release, no two, no three patch, no four patch releases. It's incumbent on everyone in a development project to share knowledge efficiently by getting key points across economically. If you're not comprehensive, coherent, correct and concise, you risk other people missing your point because they never heard about it, couldn't follow it, didn't believe in it or lost interest in it, and that leads inexorably to extra costs. In that spirit, the meat  in this post is that you should endeavour be as open as possible, full in description and slight in length. When these are in conflict, strive to remove the need for fullness. If you must be full, then structure your content accordingly. Software teams are often...

I think a lot about the user experience when I'm testing . Not only for conformance with the UX guide we refer to but also in less tangible, subjective, respects such as how the software will  feel  to different kinds of users. The UX guide can't help here. Although it has value and the potential to save time - for example, by reducing the number of discussions about capitalisation policy for dialog title bars  to merely single figures per release - at close to 900 pages it is not a shining example of usability itself and it doesn't try to answer the question  who's a user?  In particular, it has only a handful of mentions of new users outside of the section on first-timers which itself is largely about setting up the product rather than using it. Inexperienced users will at various points form a significant enough proportion of your userbase that they merit special attention and when that happens, you'll need to think about lack of experience with ...

If extracting feature motivations, requirements and priorities from stakeholders is an art, presenting the analysis requires artfulness. The MoSCoW method suggests using English words M ust, S hould, C ould and W on't as an alternative to purely numeric priorities to make it more transparent that not everything listed will be delivered. But reversing the MoSCoW rules can help to obtain  the implicit prioritisations. You'll frequently hear "we must have a solution to X" or "Y should be improved in this release" or "we'd like to get Z into the payload if we could ". Key verbs like this  can be mapped to prioritisations, e.g. P1 (must), P2 (should), P3 (could). We use these clues to bootstrap priority discussions and, perhaps surprisingly, I often apply it to my own bug reports to get an idea of my intuition on an issue. You ought to beware that there will not b e a 1:1 mapping between key word and priority, and negation does not help. Fo...

One of the reasons that software testing is challenging, both intellectually and practically, is that the information about the state of the system under test is partial. It's part of the testing role to formulate a model (or, more usually, a cloud of overlapping, incomplete and contradictory models) that represent our best view of the system at any given time and we've developed a collection of monochrome boxes  that reflect the idea that access to source code can help make sense of it. But even that doesn't equate to an understanding of the model that the software has when it operates. For example: The tester may not follow the source code (completely). External libraries may implement a substantial part of the functionality but appear minimally in the source. Interactions with other layers, such as the operating system for file operations, will form part of the model without being part of the codebase. If the source code is compiled, it may be optimised in ways th...

As the tickets pour in and your will to live seeps out you need something to cling on to, something to keep you afloat, a software development life raft, if you will (with patches, natch). Unfortunately, this is not it. Instead, this is a bunch of those drug, chug, smug and shrug report definitions you've seen all over the place that the Dev manager and me have come up with in triage meetings over the years. We tried using them as buoyancy aids but, frankly, it takes more than Archimedes to lift this mood. debug report : A note from the developer to his future self as insurance: "Well, I did submit a report about that issue back when I committed the code". Yes, instead of fixing it. doodlebug report : Everyone knows it's coming and hopes it doesn't land on them. Doug report : The premise is fair, all the points made are apparently plausible, each step in the logic seems reasonable and internally the report appears to be consistent but you know the c...

So long ago it feels like another geological age - the Pre-Childrian, anyone? - I used to be in bands and I even made a few records. I don't have any formal schooling in music, and I didn't make much effort to learn by myself. Playing guitar was a creative endeavour and I took the view that I could do it however I wanted and when it didn't sound too good I just turned up the distortion because that always sounded good. When I started using trackers  to compose on the computer I unlearned what little I'd found out about music and the skill required to make it. Now I could focus on the selection as much as production; which samples to employ, how to arrange them, ways to process them to generate something new. The machine gave me space to improvise (read: bash the keyboard randomly) and then pick the bits that sounded good afterwards without ever having to be able to play them again. I embraced this freedom and began to collaborate with other people  using the same...

The focus/defocus distinction is important in Rapid Software Testing . It encourages the tester to consciously employ both logical reasoning and lateral thinking and to switch between them particularly at those times when one or the other is not productive. But while reasoning can often be ground out, it's hard to make intuitive leaps just because you want to, to simply hop out of the rut when you find you're bogged down, to free your mind from its box, especially when you haven't realised it's in a box yet, let alone that it's shaped like a straightjacket. So it's gladdening to find that we'll soon be able to pop on an electro hat and all our problems will be solved , literally.  I foresee a future where the brainly-enhanced QA staff trample all over the latest build seconds after it's delivered, booting it back to the Dev team for reworking and gleefully following it with an eruption of bug reports like Mount Etna on Ash Wednesday, all the while...