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
    Member
    Join Date
    Jan 2007
    Location
    UK
    Posts
    150
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Testing analogies

    The recent thread on someone almost getting fired for not finding a bug made me think about how I what explain testing is. Below is an analogy I often use. Does anyone have anything better?

    Being a tester is a bit like a surveyor. When you buy a house you hire a surveyor to look at the house to determine if it is sound or if there are any problems. Based upon his report the decision to buy or not is still yours not the surveyors. Additionally you may ask the seller to fix some things or leave them.

    You usually have a choice of how detailed the survey will be. This will impact the cost and chance of findng something important. Whichever way you go there is still the chance something will remain undetected.
    The story so far:
    In the beginning the Universe was created.
    This has made a lot of people very angry and been widely regarded as a bad move.

  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: Testing analogies

    It's a good analogy, Squamry!

    In the US, I believe the term is "Home Inspector".
    Joe Strazzere
    Visit my website: AllThingsQuality.com to learn more about quality, testing, and QA!

  3. #3
    Member
    Join Date
    Sep 2006
    Location
    Vadodara, India
    Posts
    65
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Testing analogies

    Hey Sqyamry, how about this one.

    We are also called gatekeepers of the project. So when something goes out of gate unnoticed then shouldn't the gatekeepers be responsible?

    I agree,not to the extent of hanging the gatekeeper for tiny escapes but yes we are responsible !

  4. #4
    Member
    Join Date
    Jan 2007
    Location
    UK
    Posts
    150
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Testing analogies

    We are responsible, but so is everyone on the project. Testers are the final checkers that the product is fit but not the only ones. Analysts, designers and coders all do some form of testing.

    The analogy is still useful though.
    The story so far:
    In the beginning the Universe was created.
    This has made a lot of people very angry and been widely regarded as a bad move.

  5. #5
    Moderator
    Join Date
    May 2001
    Location
    Michigan, USA
    Posts
    1,330
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Testing analogies

    I use the analogy of "Light Cavalry" - Test Group scouts out the area of interest, finds potential problems and reports back with this information to Command (owners/stakeholders/PM whatever it is) for the group. They, Command, then decide on the action to be taken: Probe more deeply; Engage; scout out the borders (find the scope of the potential problem); Mark it (to be addressed by others, development, artillery, whatever) and move on; Leave it alone.

    Light Cav and Testing can't find all the potential problems, but can find significant ones.

    Pete

  6. #6
    Member
    Join Date
    Sep 2006
    Location
    Vadodara, India
    Posts
    65
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Testing analogies

    Hey Walen & Squamry,

    From both above mentioned analogies I am getting an impresstion that, we want to wash our hands from the task once testing cycle is complete. In other words, I did my job and now its your baby kind of the thing.

    Don't you think we (Testing team) own it till it reaches end user/client? and its our failure if client finds defect in delivered product/application after the necessary certification from QA?

    What you say?

  7. #7
    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: Testing analogies

    WhoCares - in my company, the ship/don't ship decision is a business decision, not a QA decision. We don't provide a "certification".

    We are not the gatekeepers, but instead are an adviser to the business side. We provide a series of Status Reports, Bug Reports, along with our professional opinion to help inform the team, but ultimately, the team decides if the system is "good enough", not just us.

    It might be "our failure" if a defect slips through to the client, because we have missed a bug that we should have caught. Or it might be a failure in the Requirements, because they have incorrectly framed the market/client need. Or it might be a failure of Development, because their code was so bad that all the defects couldn't be found in the time allotted. Or it might be a failure of Project Management, because they have not allocated sufficient time for testing. Or it might be a combination of factors (it usually is).

    In all cases, it's a failure of the business, never just one person/group.
    Joe Strazzere
    Visit my website: AllThingsQuality.com to learn more about quality, testing, and QA!

  8. #8
    Moderator
    Join Date
    May 2001
    Location
    Michigan, USA
    Posts
    1,330
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Testing analogies

    Much as Joe said.

    What the test group/QA group does is based on its charter, its mission in that context. If our mission is to track it down, we do. If our mission is to identify it and allow business owners/stakeholders to decide if it should be fixed or not.

    It is in identifying and advocating for bugs to be addressed - some sooner than later. Let's face it, not all bugs are created equally. Some are much bigger deals than others. I'd rather have dev working on those than the flurry of low or minimal severity defects.

    I may work to influence the decision, but the decision is, usually, not mine to make.

  9. #9
    SQA Knight
    Join Date
    May 2006
    Location
    Playa Del Rey, California, United States
    Posts
    2,594
    Post Thanks / Like
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: Testing analogies

    I think that's a good analogy for places where QA acts like a gate keeper. This can work, but often becomes a blame game between departments. I've seen this at my previous company before we went into mixed dev/QA teams and had separate teams. Then again at my current position moving to a new job.

    Personally, I think QA plays a bigger role than just gate keepers and the gate keeper analogy sells the role of QA short. QA accelerates development as it frees up the developer to be more aggressive in their coding/refactoring (imagine having to worry about small details ever time you write a line of code, as oppose to thinking of the big picture items first then just fixing things later), QA acts like a customer advocate pointing out potential isues with design a customer may have (as oppose to checking the program against specs, which may not be as easy to use as the customer would wish).
    David Lai
    SDET / Consultant
    LinkedIn profile

  10. #10
    Moderator
    Join Date
    May 2001
    Location
    Michigan, USA
    Posts
    1,330
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Testing analogies

    [ QUOTE ]
    It might be "our failure" if a defect slips through to the client, because we have missed a bug that we should have caught. Or it might be a failure in the Requirements, because they have incorrectly framed the market/client need. Or it might be a failure of Development, because their code was so bad that all the defects couldn't be found in the time allotted. Or it might be a failure of Project Management, because they have not allocated sufficient time for testing. Or it might be a combination of factors (it usually is).

    [/ QUOTE ]

    Rereading this thread, this paragraph stood ou. I remember 1 time and angry Dev Manager stormed into my cube demanding to know why QA did not find a given bug that was found at a customer site. I asked him why Dev put it there.

    Not fair, but highlights what Joe's point is. We can find bugs all day long, and have no certainty that we can test the specific combination of variables that will expose a defect. Complete testing is simply impossible, no matter what anyone tells you. Bugs will get through.

    Who should be blamed? Everyone. Not just the poor blokes on the tail end of the project plan being pressured to "finish" so the product can ship on time.

 

 
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 10.00%
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 01:35 AM.

Copyright BetaSoft Inc.