Saturday, October 06, 2007

Do Testers Really Thrive At Night?

A couple of weeks ago I presented at Qbit's TestExpo in Manchester.  Rare indeed is it for me to go there these days.  There was a good turnout, a whole bunch of presenters and me to wrap up the show before the prizes, the bar and the night shift.  What would you expect for an audience of testers? Having spent the day gabbing I was sure they'd have to go back to work right after I was done.

These are the slides from the presentation I gave (If you're reading this in an RSS reader such as Google Reader, you're probably not going to be able to see the slides so click on the blog title to get to the page itself and you'll be able to see them.  Alternatively, if you really don't want to visit the blog, you can access them at this page on slideshare.net.

 

The essence of the show was a proposition that too often in programmes, testing is treated as contingency time.  Because testing can't start until design and build are broadly completed, the only scope that ever gets cut is that of test.  Programmes are generally loath to over-run and, even if they do, it's rarely because more time is needed for testing. So, to get as much in as possible, all the stops come out and long nights and many weekends are worked over and over to try and hit the live date.  Inevitably stuff gets missed.

Every so often over the next few weeks I'll pull one of the slides out and post it here as a picture and talk through the things that I said at Qbit - very roughly at least, I have no script (how did Cameron put it?  "It'll be a bit of a mess but it will be me"?) so whatever I post will doubtless not match what I said and here, of course, I get more room to be lazy and expand my points.

3 comments:

  1. Mark N6:48 pm

    I look forward to the posts

    A good test team will plan for such slippages in delivery and a hard delivery date. It is inevitable. Often however the test team compounds the issue.

    Create an agile test process
    Know the size of the test problem and develop accurate metrics
    Use Automation - maintenance, speed of test development and flexibilty are key architecture considerations

    ReplyDelete
  2. Nice to hear from you Mark - saw Paul X D at the show, pass on my regards. sort of agree with what you say, the devil is in what exactly an "agile" process is - but that's your secret sauce i guess ;)

    ReplyDelete
  3. Nice to be commenting! Hope you are well? No secret sauce or witchcraft.
    Based on the scenario represented in the presentation and for simplicity lets assume the test project has two phases preparation and execution. During preparation the test team have no requirement to be “agile”, however they and the project should plan to be “agile” during execution, since this phase will be squeezed. Examples of what I mean?

    How fast can tests be executed and re-executed as functionality is stabilised and defects resolved. For example can the test team test retest 70% of verified functionality in a day? Can coverage increase 4% a day if you have a 25 day test schedule?

    Defects should be resolved ready to test in hours.

    The test process (and some project processes) should be designed (during test preparation) to support and demonstrate these goals.

    Test execution needs to move forwards quickly, increasing coverage and exposing defects on a daily basis. The metrics should demonstrate coverage improving in a linear fashion and defect trend analysis should show defect creation and resolution tracking together, on a daily basis. These metrics monitor test team and project performance and probable project completion.

    ReplyDelete