Rob Kuijt's Testing Blog
Finding bugs AEAP (As Early As Possibly) 
Saturday, June 7, 2008, 07:56 PM - ALM, Quality, Testing, TMap®
Posted by Rob Kuijt
Analyzing and fixing a bug is, without doubt, a loss of time. And the later the bug is found, the greater are the losses. Finding bugs AEAP (As Early As Possibly) becomes more and more important, especially in the complex systems we make nowadays. So, let's join the knowledge of the Developer, the Tester and the Designer and tackle this challenge!


Of course we can train the individual team members to test their own work....but, I know from my own experience, you can be blind for your own short comings.

In the Application Life Cycle we should stimulate Developers, Testers and Designers to work together in the challenge to Find Bugs AEAP (As Early As Possibly). Join their knowledge and they will accomplish better systems in less time!
For instance, let's look into the creating of Unit Test cases. The Unit Test mechanism is great, but if you don't know anything about test coverage it's almost impossible to get the advantages you want.
Let me give an example how the Developer, the Testers and the Designers can work together....

Case
Let’s say a Developer must create a component that contains the following decisions:
if C1 and (C2 or not C3)
then
        if C5 or C4
        then
                "Result_1"
        else
                “Result_2"
        end if
else
        if C3 and C4
        then
                "Result_2"
        else
                "Result_3"
        end if
end if


We want to create Unit Test cases which will Find the Bugs AEAP....That's why we must choose for the best test coverage: Modified Condition/Decision Coverage (MC/DC)


Modified Condition/Decision Coverage
Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken on all possible outcomes at least once, and each condition has been shown to affect that decision outcome independently. A condition is shown to affect a decision’s outcome independently by varying just that decision while holding fixed all other possible conditions. (wikipedia.org)


It is not easy to create the test cases for the test coverage MC/DC, especially if you want a minimum amount of test cases. Here the Tester comes into the play. With the help of TMap® test specification techniques, he/she creates the (logical) test cases. In this case the Tester delivers the Developer the following 7 (logical) MC/DC test cases.



Depending on the risks, and with the help of Equivalence classes and Boundary value analysis, the physical test cases are derived.
Now, the Developer can start building the test cases into his/her component.

So, by joining their knowledge, the Developer and Tester did create, for this phase in the life cycle, the best test coverage to Find Bugs AEAP . The effect of collaboration can even be greater if the Unit Test cases, before implementing in the code, are reviewed by the Designer.

Reviewing the test cases gives the Designer insight in the assumptions and interpretations of the Developer and Tester.

Finding Bugs during this review is the ultimate AEAP!!!

Creating these test cases manually is, even for experienced testers, pretty difficult. Within Sogeti we use a tool (I made) for this work. (The generation of the test cases of this example took me 5 minutes).



add comment ( 239 views )   |  0 trackbacks   |  permalink   |   ( 3 / 2194 )

<<First <Back | 1 | 2 | 3 | 4 | 5 | Next> Last>>