Recommended
Recommended
More Related Content
Similar to Testing mind presentation - Value of a Blocking Bug
Similar to Testing mind presentation - Value of a Blocking Bug (20)
Recently uploaded
Recently uploaded (20)
Testing mind presentation - Value of a Blocking Bug
- 1. The Value of a Blocking Bug
- 2. Me Scott Shea Software Development in various roles for 20+ years Likes Cats
- 3. What led me here Why do we test? What is a Blocking bug? How do we push emotion and ego out of determining what defects to fix? Is there a logical point of reference rather than empirical
- 4. The formula V = value of the application N = total number of users I = value Impact of a blocking defect V/N = I
- 5. Capital V, Value of the application In absence of a true dollar amount, consider it as Par Value, 100 percent (i.e. it is what it is) In dollar terms it can be defined by expected revenue, share of revenue for the company, or any GAAP methods
- 6. Capital N, the number of users Total Number of Users of the application/system At large numbers the impact of a blocker per user is very small
- 7. I, the value of a blocker Assumption: A user that is 100% blocked from using your site finds zero value in your site at that time The cumulative total of users that are blocked indicate the potential value loss to the application should they choose to not pay at the next renewal period
- 8. Threatened Value Example V = $1,000,000,000 N = 100,000 I = $10,000 If 100 users are blocked from using the application then the threatened value is $1,000,000 V/N = I Threatened Value = I * number of users blocked The portion of the value of the application that can be potentially lost
- 9. WHY?
- 10. Zero is the starting point Examples Critical = I * .8 Major = I * .4 Minor = I * .1 Trivial = I * .01 The value risk of subsequent levels of defects are a percentage of the value of I
- 11. Next Steps Finding out the actual value of V (the value of the application) Working out what the value of the lesser defects are Calculating the threat value of your backlog How do we account for uneven distribution of money paid by users; this assumes all users pay the same amount
- 12. Questions?
Editor's Notes
- From a corporate view the only reason to test is to protect against loss of money; testing is a hedge against the failures Stress that this is a work in progress
- Came to me when I was thinking about the value impact of a defect Logical rather than empirical Assumption: a blocked user finds no value in your application *at that moment*
- Par value is used as the stated or face value of a security. In absence of a stated value, say in the case of a forward sale of a security that has yet to be issued, the risks associated with the security are said to impact Par Value of 100
- In cases where user and purchaser are not the same there is an amplification effect; if you sell software to a company and one of their users is blocked, it is unlikely that that blockage has the same impact as in the case where 50% of the users are blocked. Still, as this is a logical exercise it is best to consider each user equally
- The concept of “pay” can be flexible here. For instance you technically do not pay anything to use Google Docs but the fact of your use of the app is how they make money. If you constantly find Google Docs is down you will find a substitute You can abate, ameliorate, or prevent defection by solving the outage and restoring the value in the eyes of the customer – some doubt may linger shortening the grace for the next outage
- The breakdowns and values are subject to your situation; these are just examples based on the default Jira levels and a wild guess on my part Critical in this case indicates that there is still some value to be had in your application
- I hesitate to use Value At Risk because Phillipe Jorion has kind of cornered that phrase One problem I see is that the combined threat value of the backlog can exceed the total amount of value of the applciation