Why Testing is like Book Publishing
https://www.flickr.com/photos/nics_events/2349632625

Why Testing is like Book Publishing

Testing software is a complex and difficult thing. There are so many opportunities for issues to arise - from major functional and architectural issues, right through the spectrum, to very minor niggles that can detract from a quality customer experience.

In many ways, this can be very much like publishing a book; where the author's original manuscript may have to go through many editing and revision iterations before it finally hits the shelves and is available for purchase by the reading public.

When a publisher purchases a manuscript, it passes through a very well-established editing process,  which evolved over many years into its current form. It's a tried and true formula that takes a rough manuscript through various stages and transforms it into a publication quality work at the end.

It's worth considering how closely the publication/editing process follows the flow of software testing, and ultimately, what we in the software industry can learn from its traditional but proven approach.

Firstly then, let's look at each editing stage;

  • Developmental or Substantive Editing; where an editor might assist the author with their overall plot, characterisation, world-building and the goals of the work to make sure the manuscript matches the target market expectations and will be saleable. This is very much like reviewing, input into and verification of overall software design, architecture and business requirements.
  • Content Editing; often this is what people think "editing" is, where the editor goes through the manuscript with a figurative red pen to chop and change things wholesale. Just because things make sense to the author, doesn't mean it will make sense to the reader. Sometimes entire chapters, paragraphs, characters or plot arcs might need significant rework to make the book fit the market demographic and publisher's requirements. They will also look for continuity errors introduced because of the changed flow. In software testing this is similar to testing and review of the technical design. If there are fundamental issues at this stage, then the final deliverable will be far from a quality product.
  • Line Editing; where the editor goes through the revised manuscript, paragraph by paragraph and line by line looking at sentence structure, vocabulary, word usage and character dialogue. Again they will ensure the flow and logical consistency of the work still holds together. The author and editor will add/remove anything that is out of place or requires tightening up to make sure the manuscript, plot, characterisations and overall ebb and flow of the work comes together and builds up as it needs to. This often goes hand-in-hand with…
  • Copy Editing; where the editor will nit-pick the grammar, punctuation, spelling and fact check each and every paragraph, sentence and word in the manuscript. The editor will look for changes in wording tense and narrative perspective shifts, and they will use a style guide to ensure consistency throughout so it reads smoothly. The most obvious parallel with software testing is formal unit testing, white box testing (and development standards).
  • Type Setting; if everything goes to plan, by this stage the manuscript should be ready for insertion and formatting in the publishing software of choice. The mark up, placement, formatting and look and feel of the end product takes shape as all the pieces come together into the "almost final" proof. This is the software equivalent of system integration testing when all the units of the system can be tested together and in order.
  • Proof Reading; the final editing stage of the proof itself. This is where the final format of the book is gone over looking for any errors, spelling mistakes or any omissions that might have been missed in any of the previous iterations. Anything spotted at this stage should be very minor and result in the absolute minimum of changes. Any more than this would require the editor and author revisiting any or all of the previous editing stages. This equates to User Acceptance Testing. If anything is found that requires anything other than a minor change, then this needs to go back through regression testing in previous stages. Nowadays for software testing, this is often where crowd-sourced testing comes in. Unlike software testing though publisher's don't ask a random selection of people to proof read the manuscript. Publishers value language skills, reading and comprehension levels, grammar and spelling knowledge, and they would not rely on sheer weight of numbers of unskilled readers to detect errors in a manuscript. They use skilled, content- and context-savvy editors for this.  
  • Book Review; Although this is not part of the editing process, before a full print run and the book becomes available for general sale, the final proof - or even a small run of books - are provided to select book reviewers for comment and feedback. This is similar to a pilot release or soft launch of a software product to a small, contained audience.

Although these stages aren't an exact match for traditional software testing phases, I think they are close enough to draw a parallel. As every published author will attest, the editing and publishing process can be laborious, sometimes tedious, and even sometimes downright confrontational as editors put the author's labour of love under a microscope and pull it apart at the seams. But, it is necessary, and has proven time and time again, as the author's work progresses from manuscript to delivered book, the end result for the reader is a far higher quality product.

For the publishing process, many years of experience has proven that professional, highly skilled, specialist editors are required to achieve a quality result, and the same holds true for software testing.

As technology progresses and word processors allow authors to spell check, grammar check, type set and much more, we find that software development tools come bundled with syntax checkers, debuggers, test automation features and more.

High-quality, skilled professionals with local context and market knowledge yields a far better and more customer-satisfying result.

The common factor in these two industries is the same though: Whatever the quality of the initial starting point, high-quality, skilled professionals with local context and market knowledge yields a far better and more customer-satisfying result. Anything less is little more than proof reading the original manuscript; the end result might be an improved manuscript, but it is extremely unlikely to be a highly polished, marketable, professional, best-selling book.

要查看或添加评论,请登录

Chris Jones的更多文章

  • Performance is not horsepower alone

    Performance is not horsepower alone

    I’m always banging on about performance being fit-for-purpose rather than just outright speed. At AccessHQ, we’re…

    3 条评论
  • Why do we never learn in IT?

    Why do we never learn in IT?

    I honestly can’t think of any other major industry which consistently over-spends, under-delivers and repeats the same…

  • Think you'd make a good Performance Tester?

    Think you'd make a good Performance Tester?

    “Some men aren't looking for anything logical, like money. They can't be bought, bullied, reasoned, or negotiated with.

  • Performance Is Not Just Speed

    Performance Is Not Just Speed

    A lot of people think performance in IT systems is all about speed. Questions like; “How fast does it go?” and “What’s…

    2 条评论
  • Performance Testing - are you peering into darkness?

    Performance Testing - are you peering into darkness?

    Within big IT projects, often performance tests run with few infrastructure monitors in place, if at all. It's not…

    2 条评论
  • Performance Testing Averages, 90th percentiles or Avg-90%?

    Performance Testing Averages, 90th percentiles or Avg-90%?

    As a performance tester, my role is to ensure my clients clearly understand how their systems perform under load. To…

  • Performance is not just reliability and availability

    Performance is not just reliability and availability

    There's no truer maxims in the world of complex IT systems than Murphy's Law, and its corollary Finagle's Law. These…

  • Performance Testing Cheatsheet - Diagnosing Server Congestion

    Performance Testing Cheatsheet - Diagnosing Server Congestion

    When faced with diagnosing performance issues with windows-based servers (especially when perfmon stats are easily…

    1 条评论
  • Open All Hours. 23? x 7; 357 Days a Year

    Open All Hours. 23? x 7; 357 Days a Year

    In today's online market, to coin a phrase, time is money. So, availability and performance are king, right? Well…

  • Life in the (not-so) Fast Lane - Part II

    Life in the (not-so) Fast Lane - Part II

    Following on from my last post -- Life in the (not-so) Fast Lane -- I spent some time thinking a little more about the…

社区洞察

其他会员也浏览了