Forthcoming presentation on Release Readiness

The fundamental reason we are paid to manage tests is to answer a simple question: 'can we make the release'? Get this wrong and you could face some unanticipated career changes. Get it right and no-one will thank you (except the users).

The question can be broken down into two others:
1. Have we covered all the features/requirements/risks (fill in your probleme du jour)?
2. Have we found all the bugs?
3. Is the system stable (this last was added following the presentation as I realised the situation needed clarification).

This presentation breaks these questions down a bit further and provides (some) answers the author has used for the last 5 years (and which still work when others use them).

Handout of Release Readiness

I am excited to know more about this concept. Can somebody share the soft copy of the Release Readiness discussion ?

Release readiness

Vijay,
There is a book called "Manage Software Testing". Goes into the subject in some detail. It's on Amazon. Author is ... er hang on, it'll come to me in a moment.

Thanks a lot Peter for the

Thanks a lot Peter for the response. It would be great if you could kindly provide me with the details of the book.

Release Readiness - Scope Driven

I suggest that your first question, 'have we covered all...’ is the key, if we don’t cover the scope of the Release, we will not find any of the bugs, missing configuration, missed modifications or whatever. Demonstrating we have found them ‘all’ is just not possible.

Coverage to my mind depends on scope, and just what you mean by a ‘Release’. For us a Release tends to be a bit of a portfolio, a mixture of in house enhancements, vendor packs of modifications and fixes and, often, some architecture or technical changes.

Enhancements, we have a good idea what the requirements were (some cross over with Stevan’s session perhaps), know what the design was and what features were added, right down to the individual objects added or modified. Relatively easy to manage System, Regression and User Acceptance.

Vendor packs, we have an all too vague description, no design documentation and impossible to follow lists of modified objects and code. I find we are left with repeated, risk based, regressions testing. By which I mean the things that trip us up often, the things the business (and the tester) deem important and the functional areas listed in the notes are tested first. More chance of not finding all the bugs.

Architecture changes, the risk of not finding all the bugs is somewhat dependent on what has changed, basing the early regression test on the changes has helped, and often leads to some snowballing when you find something and then have to work out how widespread. Next risk based regression as above. Again a good chance of missing a bug.

I look forward to hearing your comments at the end of April.

Which April

Scope is whatever the release manager says it is.

Release readiness

If you haven' got specs write them as you test. It'll stop you testing the same thing three times over. By the time you've written enough of the spec to have tested the product end-to-end you'll have found so many bugs, the management will start to twitch.

If management says "there isn't time" work out what happens if you don't find all the bugs - who will find them, how they can make their sorrows felt and what it will cost the organisation. Put this down on a bit of paper and tell your boss you need to discuss it. Urgently.

Don't waste your time trying to be a 'nice guy', a 'team player', or a 'safe pair of hands'. Wear black, an eyepatch and keep a photo of Eva Braun on your desk with the caption "Ihre Liebe Mutti"* scrawled in felt tip on the bottom right hand. Never smile at the management.

You are not employed to be a victim.