SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 5 of 5
  1. #1
    Junior Member
    Join Date
    May 2005
    Location
    Argentina
    Posts
    1
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Testing rules, is necessary to test everything?

    Hi,
    I am working for a software factory, and now we are defining the testing process. We are looking for a method to cut the amount of testing on the fixes that are not so serious. We want to set rules to define whether is necessary to send the fix to the test group, or if the developer test is good enough.
    Anybody has done this?
    Any help will be appreciated.

  2. #2
    Senior Member
    Join Date
    Sep 2004
    Location
    London, UK
    Posts
    1,798
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Testing rules, is necessary to test everything?

    elfer_Ar, sounds like a form of risk based testing to me, there are a number of approaches some more formal then others. It really is contextual and will depend on the drivers behind this and the acceptable level of risk to the "facotry", it also in part will depend on the dimension identified as important and how well these reflect the final goal.
    simple ideas for the items that may be acceptable not to be retested, depending on the context could cover such items as:

    Less then 1 hour of development and analysis time required to fix and unit tests executed sucessfully.
    Less then 1.5 hours of development and analysis time required to fix and component not reused in other functions. Change underwent inspection and was unit tested through positive and exception paths.
    These can be built up and quantified to give reasons and explain in a quantified manner why test will not revisit these fixes. Most shops however do to some level revisit fixes, it is just the depth and level of test coverage that is altered.
    I suspect it would not be acceptable, say, in an FDA regulated shop to not retest the fixes in any way shape or form however.
    ------
    Regards,
    Neill McCarthy
    Agile Testers of the World UNIT!

    For more contextual Musings visit http://www.testingreflections.com/ and now at http://www.sqablogs.com/neillmccarthy/
    ---

  3. #3
    Senior Member
    Join Date
    Oct 2002
    Location
    New Zealand
    Posts
    749
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Testing rules, is necessary to test everything?

    elfer_Ar,

    several factors to consider:

    1. Does your shop do peer reviews, code inspections etc on the fix work?
    2. Are the fixes applied by the original deveper(s) or someone new to the code?
    3. Do you have impact analysis, in particular looking at regression issues (e.g. alterations to common libraries).
    If the answer to any or all of these in "No", what you are suggesting is extremely risky!!
    I've known cases where the "simple" changing of a field length in a form has (due to a newbie programmer) led to a major loss of functionality.
    And that was supposedly Unit Tested!

    Often the driver behind such "reduce what we test" approaches comes from the current testing being an overkill. For example, always running a full regression set of tests.

    If that is the case, something to consider as an alternative is to have a drive towards focused testing - as Neil stated "risked based" testing. This can be equally cost reducing whilst far less risky.

  4. #4
    Moderator
    Join Date
    Sep 2001
    Location
    Yankee Land
    Posts
    4,055
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Testing rules, is necessary to test everything?

    When I was doing a 7/24 web site, that often had small fixes in functionality to specific areas, we needed to cut down test and release time. When we had a fix to a single page entity we didn't need to run every Regression Test, but we needed to run some. Basically we looked at the fix as it was being done by Development, determined how long it would take them to fix and what they would fix. Using that information we could assign a QA Engineer to shepherd the fix through (QA also functioned as Release) in a quick way through test and release with minimal risk.

    Without knowing your business and your processes as long as you have QA and Dev talking very closely you can manage the process and get the quick turn around.

    - M
    - M

    Nothing learns better than experience.

    "So as I struggle with this issue I am confronted with the reality that noting is perfect."
    - Unknown

    Now wasting blog space at QAForums Blogs - The Lookout

  5. #5
    Senior Member
    Join Date
    Jan 2005
    Location
    Aurora, Ont., Canada
    Posts
    1,174
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Testing rules, is necessary to test everything?

    elfer_Ar, if you want to cut down on testing you need to implement maintenance windows and bundle the changes so that you can perform validation on a whole series of fixes at once. If you simply do a spot checking of probable impact areas you will increase the risk that errors slip through the net (you are making the holes too big, in effect) and if the likelihood of catching bugs is lower then you have to ask yourself why you'd test at all. That is a bit facetious, of course, but your spot checking simply seems ineffective except for "emergency fixes" where you need to get code implemented in a hurry (and follow-up with a more thorough testing effort afterwards).
    Frits Bos, PMP
    frits_bos@hotmail.com

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 9.09%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin 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 03:49 PM.

Copyright BetaSoft Inc.