This post is a continuation of my first post about a lean MTP. Last week I had my second two days in filling in the test strategy and finalising my MTP. But first the response I got of my project leader about the first concept I send him. He most of all missed the DSDM principle in there. When I read the document last week I realised he was right. I didn’t look enough at the DSDM products I had to produce instead of the normal test products. I realised I had it all in the document, but not in DSDM terms (I did have iterations stated in the testplan, but I don’t which yet).

Test products that are different from ‘normal’ are:

• Business and Technical Testing Strategy part of the mastertestplan;
• Test cases, scripts and charters are for the business process are part of the Business Testing Suite;
• Test cases, scripts and charters are for the technical flow are part of the Technical Testing Suite, and
• Test manager is a Technical Coordinator QA (not a product, but sits better here).

When I adjusted this in the document I had some interview sessions with users, functional service management, an analyst, the project leader ICT and Content and application management. I had to hold separate interviews because of the time challenge and not coinciding agendas of these persons. I asked everybody to think negative about where they think the application could fail (where they saw risks). On each answer I asked them what could go wrong (the risk of failure) and how bad this was. And what parts of the application of process should be tested and why (stating test goals).

The users, f and project leader Content were most interested in the process within and the performance of the application. They were also interested that the application shows the correct content in the application. The performance part was weird, because it wasn’t stated in the requirements. IT (project leader) and analyst had the greatest risks with the type of viewer that was to be integrated with the software. One viewer created higher risks for the program because nobody could work with it yet (it was new technology to them). Application Management didn’t have that many risks. Their main priority was to have a normal development cycle on the different environments (Development, Test, Acceptance and Production).

As of now I haven’t had much time to integrate the vision of the development team. Their team leader’s agenda hasn’t allowed us to talk, let alone summarise the risks.

After these interviews I tried to sort them out into a product risks analyses (PRA). I did:

• At first I stated the test goals (including priority and quality characteristics for the test goals) and I matched them with everybody.

• Then I sorted the results into the different processes and object parts of the product (they were stated in the documentation).

• After this I matched the test goals with the different processes and their characteristics;

• Next was the match between object parts and characteristics;

• Per characteristic I assessed the damage for the processes;

• Per characteristic I assessed the risk of failure for the object parts;

• At last I integrated these last two to pick the risk classes.

Normally I have a workshop to do this PRA and we all take these steps in the workshop as a group. It’s easier this way to get a consensus, but due lack of time I had to improvise this option. After I processed the PRA I mailed it to everybody involved with a manual on how to read it. Some reacted on it and I needed to re-asses some values.

With this I could create my test strategy! And finalise my ‘lean mastertestplan’!

1. Ed H Says:
   February 23rd, 2010 at 16:51

   Question: In the last schema you combined object parts with processes to determine the risk class. It looks like a step is missing, namely which process uses which object part. Or did I miss something?

   Ed

2. Ewald Says:
   February 24th, 2010 at 09:22

   Ed,

   You’re correct. That step is taken with “Then I sorted the results into the different processes and object parts of the product (they were stated in the documentation).” There I combine the process and object parts.

   Thanks.

   -Ewald