User Tag List

Results 1 to 2 of 2
  1. #1
    Junior Member
    Join Date
    Feb 2008
    Post Thanks / Like
    0 Post(s)
    0 Thread(s)

    Defect complexity normalization


    How do we measure ourselves that we performed better than the previous release in terms of defects? If the number of defects found in the current release are less than the previous one, do we say we have improved? I feel it is not a good measure as the complexity of the features implemented in the previous release might have been more than the current release.

    Can someone suggest me how do I normalize the complexity here? How do I use the normalized day to see where I'm with respect to the previous release?


  2. #2
    Senior Member
    Join Date
    Jan 2007
    Castle Grayskull
    Post Thanks / Like
    0 Post(s)
    0 Thread(s)

    Re: Defect complexity normalization

    You're correct but I'd look at it from a few different perspectives....

    1. Customers really aren't that concerned with complexity. They want the logon dialog to work just as well as a complex, configurable business rules engine for an app. This can make it VERY HARD on a dev and testing team though but the level of effort must be scaled appropriately in order to ensure quality across the app as well as a team lead/manager/director putting the right people in the right positions.

    2. How can one compare components and enhancements across app versions? Check out this post....it's at least something worth considering. One of our attributes is "level of experience/competency" of those on a component team


    It's by no means a precise science but in my opinion it's something that can be more accurate than allowing random people using random quality definition and random/unknown data points to make such a proclamation that a component is better or worse in terms of quality than in previous releases.

    At the end of the day though one would ideally like to have an app that is given to the QA team and there are simply no defects to be found that must be fixed prior to release.

    One of the things you could look at is the trend of components becoming low priority. At what point do people stop testing and are transitioned to other projects or other areas of the app? I've often found there seems to be "security" in continuing to test a component after it's already production quality. I would not let such a thought-process to be widely-accepted.....get people off testing components that already meet expectations or are very close to meeting and get them to high risk components....this will allow one to start gather some metric information.

    The amount of testing to be performed should really not be a function of how complex something is to test but rather how much a customer workflow relies on particular functionality. Likewise, one should really not make the assumption that something complex to implement is inherently more buggy than something that is trivial. If someone asked me to integrate a function between 0 and 2 I think (ok, I know) I'd have some problems with it. However, someone has worked in the Math field for quite some time could answer it correctly with no problem. Again it comes down to how "complex" is defined and the level of proficiency and correctness one can perform their assigned duties.

    I have always mentioned to my teams the goal of QA is to perform the LEAST amount of testing while still ensuring an appropriate assessment of quality has been performed. And this is why I mention above to track when high risk components become medium risk and then become low-risk throughout a project because we (QA) must, at least in my opinion, not be bothered with how "tough" it is to implement a feature.
    Reserve a few months every so often and preview retirement throughout your career. You won't regret that a 35 year career was reduced to 34 years to take vacations measured in months in order to remember what a stress and care-free life is all about.

    Books and hard work will get you anywhere you want to go.



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.0.9 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Questions / Answers Form provided by vBAnswers (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominatevBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 11:07 AM.

Copyright BetaSoft Inc.