Product Risk Management

I'm just updating content for a training course, and I know I spend a lot of time conveying the importance of testing etc etc, but to do so in the most succinct and digestible way, to ensure the thought or lesson objective is retained.

I'm currently trying to communicate the importance of risk-based test strategies, and one of the biggest concepts ofr me is that "The main purpose of testing is to mitigate risk, therefore our testing strategy should be focused on risk mitigation, rather than purely requirements conformance".

The basis for this is my perception that the majority of testing is founded upon the idea that the requirements as defined are to be treated as 'gospel' and therefore deviation from the requirements alone is all that is required to ensure successful delivery.

In actual fact, it is the tacit knowledge; the undocumented requirements that are seemingly obvious to end users and seemingly invisible to others, that should be captured and assessed. Such things as performance, useability, security, compatibility, in fact all the other abilities, should be factored in.

So, my question, is if testing is about finding defects against system, is there a more elegant and or accurate way to describe a test strategy as the artefact that documents the focus of testing as identifying the most critical defects which would expose the system to the biggest risks.

Medicare e-health contract in limbo | The Australian

The (U/O) HI story continues.

I don't know what the problems are, but it seems government organisations work to different time-scales than private enterprise, who are all ready to press ahead in this case.

ongoing GMail

Down to 41 pst files left, and I'm starting to enjoy GMail especially with some of the new stuff like priority mail.

Moving slowly into the past

After years of trying to avoid it, I have finally bitten the bullet, faced the music and kept up with the Joneses, by moving to GMail. For a start, it runs far more quickly than MS Outlook, especially when dealing with the amount of email I have kept, but also it means I can access it wherever rather than having to boot up to view.

The only challenge is migrating 61 pst files, yes that's right, 61 dirty fat pst files, from my PC to the interwebs. For each project I work on, I create a new PST file, and move pertinent material from Inbox to the project PST file. This works great as I know everything will be in one place, and at the end of the project, I can close that PST from Outlook and reduce the number of emails in my face.

Now however, it is getting harder and harder to manage all of this so a cloud-based solution makes sense.

Unfortunately, unless you have a Google Docs domain you can only upload slowly via Outlook itself, copying files into the imap mirror folder. There are a few scripts that can assist, but due to the miss and miss rate, it is easier, but rather time consuming to upload project by project.

16 down, 45 to go. . . . .