When looking at Testing and more specific Test coverage in the Lifecycle [ALM] you can conclude that much effort is done to test as good as possible, but nobody can tell you what Test coverage is achieved in the successive stages of the ALM.

Work must be done in the thinking and communication concerning the quality levels that should be reached! It is proved to be very difficult to choose the thoroughness of testing and it is proved to be even more difficult to explain the executed Test coverage to the colleagues of the next test levels.

With the appearance of the chapter 14 "Test Design Techniques" in TMap® Next , there is now some light on the horizon. In the "old TMap®" the Test coverage was expressed in terms of dynamic and static quality characteristics, coupled with test techniques, which nobody understood. Even the full-time testers had trouble understanding it through and through.

With the introduction of TMap® Next the test coverage is, more friendly and intuitively, expressed in terms like paths, decision points, CRUD (coverage of the basic operations), checklists, and so on...
Now we can explain the chosen Test coverage practically in plain English!

I can give an example how we introduced this type of Test coverage expression in ALM in a project I've done within Sogeti. In the project we planned a serial of 5 successive test levels: Unit Tests (UT), Component Integration Tests (CIT), Technical End-to-end Test (EET), Functional Acceptance Test (FAT) and User Acceptance Test (UAT). Instead of designing the tests on an individual bases we created one overall "tuned" test strategy.



Picture: Clemens Reijen; from his article:
Testing in the Lifecycle [ALM]... a focus on automation

This overall test strategy was designed in three layers:

• First; for all the test levels we determined the Basic Quality level, which can be seen as the absolute lowest level of Test coverage (labeled: Bronze). Formal escalation is needed to escape from this Basic Quality requirement. And of course the depth of testing is expressed in terms of chapter 14 of TMap® Next.
• Second ; based on the BDTM-approach (see chapter 3.1 in TMap® Next) risk classes are determined for each combination of characteristic and object part. Characteristic= what must be investigated; Object part= what must be tested. The Test coverage above the Basic Quality level is, for all test levels, determined in a so called Master Test Plan. In my experience it is easy to communicate with stakeholders when the higher Test coverage levels are labeled as Silver and Gold and even Platinum. And again the labels silver, gold and platinum are expressed in chapter 14 terms.
  
  
• Third; we introduced the Learning Cycle. Every time a blocking or costly defect occurred we analyzed the defect and if necessary we modified the Test coverage definition of the test level where the defect should be found.
  Another example of working with the bronze, silver, gold and platinum labels can be found in chapter 7 "Development Tests" of TMap® Next.

ALM (Application Lifecycle Management) regards the process of delivering software as a continuously repeating cycle of inter-related steps: definition, design, development, testing, deployment and management. Each of these steps needs to be carefully monitored and controlled [Wikipedia].
For more definitions see the article about ALM Definitions in the blog of Clemens Reijnen.

TMap® (Test Management approach) is a registered trademark of Sogeti Nederland BV

I'm living in 2 Worlds.

In one world I'm working with Developers, trying to let them build software at a quality level the application user wants.
In the other world, at the other side of a "Wall", I am coaching Generalist Testers to do their job as good and efficient as possible.
Yes, my two worlds are separated by a fictitious Wall.
The Challenge: Developers and Generalist Testers, each at one side of the wall, don't make efforts to understand or help each other.

....don't make efforts to understand or help each other
D-world perceptions
In the D-world, the world of the Developers, we think Generalist Testers are pencil-pushing, nit-picky quality geeks. Mostly they are beside the point and are easily replaced. They seems to like making much noise about little defects, as if we made those errors deliberately....

T-world perceptions
In the T-world we don't hate the Developers for their perceptions. We are disappointed about the poor quality of the software.
Bad assumptions on the part of Developers are more to blame for the problems than are software weaknesses.
We never(or seldom) get software what will work right the first time. No, in the T-world we think that developers forget for whom they are building software, it looks like they are building for themselves......On the other hand we, Generalist Testers, realize that the Developers seldom get the time to do it right, but always get the time to do it over....But why are some errors made over and over and over again?


The Walls between Developers and Testers do exist for many years now. And probably there are good reasons to go on like this..... but in my opinion there are more reasons for tearing down those Walls.
With the growing complexity of our IT-world....The most important one:
DEVELOPERS AND TESTERS NEED EACH OTHER TO DELIVER THE PROPER QUALITY!!

I like living in 2 Worlds, but I love it when Developers and Testers collaborate.
I've taken the Challenge!!!

Next entry: Pragmatic View on Proper Quality