SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Page 1 of 2 12 LastLast
Results 1 to 10 of 16
  1. #1
    Junior Member
    Join Date
    May 2006
    Posts
    8
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Risk based testing

    we are currently doing a reporting project. Which was already tested and accepted by customer. afterr the acceptance a refactoring of the code took place in order to do some other project for that customer.

    now the project is full of issues. how do we apply risk based testing for this project where we have limited number of testers.

    its a big project, so executing all test cases are also really time consuming.

    any idea?

  2. #2
    Moderator Joe Strazzere's Avatar
    Join Date
    May 2000
    Location
    USA
    Posts
    13,170
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: Risk based testing

    Every project has a limited number of testers.

    Brainstorm.
    Identify the possible risks.
    Prioritize the risks.
    Assign relatively more testing to the riskiest areas.
    Joe Strazzere
    Visit my website: AllThingsQuality.com to learn more about quality, testing, and QA!

  3. #3
    Member
    Join Date
    Aug 2007
    Location
    RTP, NC
    Posts
    36
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Risk based testing

    What Joe said!

    But before you can do any of those actions you have to KNOW what is about to happen and that requires communication with your dev and PM group. They have to trust that you will provide them good input and actually apply risk principles to your efforts.

    This means you look at the impact of a potential defect and the probability one will be inserted. Lots of material out there on this so I won't repeat it here.

    Then you actually have to go after the high impact defects and not let your team mess with low impact defects. Why write a low impact defect that won't get fixed anyways, and if it does it will probably generate new defects in the process.

    Anyways, sounds like you have a recovery mission now. Good luck and stay focused on resolving the issues that got you here in the first place.

    Brody

  4. #4
    Senior Member
    Join Date
    Jan 2007
    Location
    Castle Grayskull
    Posts
    388
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Risk based testing

    check out my post on the following thread http://www.sqaforums.com/showflat.ph...e=0#Post416672

    I'd consider this very high-level but it does cover many of the basics. A few other things

    1. Once you finish your risk assessment look at QA to R&D ratio. We actually vary our ratio depending on risk for each component

    2. Make sure you re-analyze risk throughout the project...you may want to have formal assessments at certain points in the project. On a weekly/monthly basis though informal discussions should be taking place between QA and R&D. Here's a question I sometimes ask R&D "Hi...let's pretend you move to the QA dept for the next week....with your knowledge of the code + what's changed in the last week what areas would you focus on in terms of testing?"

    3. Monitor the results of testing throughout the project and the absolute minute you determine a component if of appropriate quality for the upcoming milestone, re-adjust the risk to low and focus on the components which are not of appropriate quality

    4. Look outside the team to augment testing. For instance, in a Beta program you'll want to mention to your customers what areas you'd like them to focus on. Assign QA engineers to all/key customers and during con-calls/in-person visits to the customer site and ensure you get customer feedback on the high-risk components. This can be quite useful i.e. validate the project team's feelings about quality and ensure customer opinion and project team opinion are similar. If things look good, drop the component to mid/low risk.

    5. Remember to also talk with R&D and understand what measures they are taking to deliver quality builds to QA. For high-risk components maybe R&D has more stringent criteria in order to check-in code/deliver the build to QA
    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.

  5. #5
    Senior Member
    Join Date
    Apr 2003
    Location
    Wisconsin, USA
    Posts
    5,338
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Risk based testing

    [ QUOTE ]
    Why write a low impact defect that won't get fixed anyways, and if it does it will probably generate new defects in the process.

    [/ QUOTE ]

    The answer is quite simple, Brody. Accountability. If you don't document ALL your defects, the only ones that people will know about are the ones that you did document. If you only document high risk defects, then your risk analysis is already done, isn't it?

    You can't ignore writing a defect report simply because it is low risk. When you fix all the high risk items, do you ship the product as "defect free" because all the documented defects are closed? Or do you document that there are still a number of low-risk defects present?

    I know what the answer is from a legal and liability standpoint.

  6. #6
    Junior Member
    Join Date
    Oct 2007
    Location
    Rochester, NY
    Posts
    2
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Risk based testing

    I couldn't agree more. Document all found defects even if you get flak for writing them. One of things I found is that there is sometimes a blame game which occurs when a defect is found. The best thing to do is document ALL defects no matter how trivial or the amount of flak you might get for them. That way no one can blame you for defects within the system which development decided not to fix. And you'll lessen the use of the "Well, why didn't QA find this defect?" question development sometimes uses to deflect responsibility for bad code.
    - This launch would go better if it weren't for the darn Human Element.

  7. #7
    Member
    Join Date
    Aug 2007
    Location
    RTP, NC
    Posts
    36
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Risk based testing

    [ QUOTE ]

    You can't ignore writing a defect report simply because it is low risk. When you fix all the high risk items, do you ship the product as "defect free" because all the documented defects are closed? Or do you document that there are still a number of low-risk defects present?


    [/ QUOTE ]

    Sorry for the confusion: I am not advocating not documenting or looking for low risk defects.

    I am saying that going after low impact defects generates more risk then it resolves. And, I am saying that given limited QA resources, going after low impact defects that you know won't be fixed and frankly shouldn’t be fixed while pulling resources away from going after high impact defects raises the project risk.

    We all have release criteria and I am reasonably certain that ‘defect free’ is not in the specs. In the orgs I have worked in they either completely ignored the low level defects or set the number of them allowed at release so high that they might as well been ignored.

    By low impact defects I meant defects that are of low severity AND would be a low priority. Misspellings wouldn’t fall into this category as they would have a lowest severity but because they make you look bad would/should receive a higher priority. But, the wrong color being used in a dialog box, different placement of a button then the spec, the icon looks bad, minor usability issues, or general cosmetic errors should be handled in a UI walkthrough and not as ‘trackers’. Find the significant defects that will cause harm to your customers or make the software non functional and plan your testing around finding those defects. If you happen to be ahead of the game or have unlimited resources and have accomplished all the testing needed in the high risk areas then by all means go after the low impact defects.


    In example:
    A recent project I managed remotely generated a lot of severity 5/priority 5 defects (or 4/4s) the developers had about a 30% fix failure rate and generated about 1 bug per defect fixed. Usually the generated bug was a lower PS value then the fixed bug so in general things were getting better. But, they did have a propensity to fix all defects, and being human they often chose the easy ones first – the PS 5/5. So, guess what the odds were that when they generated a defect off of a PS 5/5 fix that it was also a PS 5/5 -- not often. The generated defects from fixing a low impact defect were most often higher PS values – making the quality worse, distracting resources from release significant defects, and chewing up limited QA resources in the process.

    J Brody Brodock

  8. #8
    Member
    Join Date
    Jun 2007
    Location
    NoVA, USA
    Posts
    32
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Risk based testing

    [ QUOTE ]

    We all have release criteria and I am reasonably certain that ‘defect free’ is not in the specs.


    [/ QUOTE ]

    Sadly, I wish that were the case on the latest project to cross my desk ... I read through the SOW and it mandates that the software we're going to develop must be "free of any defects, errors or omissions." Unbelievable.

  9. #9
    Moderator JakeBrake's Avatar
    Join Date
    Dec 2000
    Location
    St. Louis - Year 2025
    Posts
    15,609
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Risk based testing

    ... so this means a Risk Mitigation plan the size of a dictionary?

  10. #10
    Senior Member
    Join Date
    Jan 2005
    Location
    UK
    Posts
    876
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Risk based testing

    [ QUOTE ]
    [ QUOTE ]

    We all have release criteria and I am reasonably certain that ‘defect free’ is not in the specs.


    [/ QUOTE ]

    Sadly, I wish that were the case on the latest project to cross my desk ... I read through the SOW and it mandates that the software we're going to develop must be "free of any defects, errors or omissions." Unbelievable.

    [/ QUOTE ]

    not that unbelievable
    At my last company the CEO wanted the programmers to be producing bug-free software as quickly as possible and honestly could not understand why they couldn't. He wanted to fire them all....

 

 
Page 1 of 2 12 LastLast

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 8.33%
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 11:51 AM.

Copyright BetaSoft Inc.