Strengths and Weaknesses are up in the air!

Jeremy Berriault provided an example from this presentation at QAI Quest 2017 for us to count test case points.  Jeremy, QA Corner,  indicated baseline data was required to effectively run the three test cases in his example

The logon, transaction

, reports and expected output blocks represent verification points.  The arrows from one test case to another represent interfaces and steps are. . .steps.  The results of the count is as follows:

Test Case Number of
Steps
Interfaces Verification
Points
Baseline
Test Data
Complexity

test case 1

4 0

4

required medium
test case 2

4

0

4

required medium
test case 3 3 2 3 required

medium

Deriving the complexity leverages the following chart:

The test cases generate three medium test cases or 12 unadjusted use case points (3 x 4 = 12).  This represents the output of steps 1 – 4 of the basic test case point counting process.  Step 5 requires the evaluation of the 16 adjustment factors.  For example, a set of test cases that required multi-language support would require more effort for a set of test cases that requires only one language support.

Strengths:

  1. Rules Based:  Rules increase consistency and enable cross-team or project comparison.
  2. Identifies Complexity:  Test cases that are complex based on the rules are targets for simplification.  Complex test cases are harder to execute (whether automated or manually) and evaluate.
  3. Generates thought and conversation: The process of sizing forces practitioners to think about and talk what they are testing.
  4. Testing Specific:  Test case points relate only to the activities performed by testers.

Weakness:

  1. Not Available Early: Counting test case points requires a level of detail that is often on available early in Agile efforts.
  2. Testing Specific: Test case points can only be used to predict testing activities, in cross functional teams just sizing one part of the lifecycle is not as useful.
  3. May Not Be PredictIve:  There is no published industry data that proves test case points are predictive of the testing effort.  Many test case point estimation approaches are driven by weak correlations.
  4. Only Testable Requirements: Not all requirements are “testable” however non-testable or non-functional requirements still require effort to evaluate.
  5. The Relative Adjustment Factors:  Some of the adjustments require interpretation rather than explicit criteria based evaluation.  Subjectivity will likely creep into the process.  

Test case points are a useful sizing technique.  Test case point users needs to answer two questions: whether the value of the information generated outweighs the effort needed to generate the number, and when the information to count test case points is useful.  We will return to question two next week.

Advertisements