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
    Mar 2002
    Location
    Bangalore, India
    Posts
    22
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Architectural issues in testing


    I have read this article titled "A Pragmatic Strategy for NOT Testing in the Dark" by "Johanna Rothman and Brian Lawrence". they say that a tester needs to examine the products architecture which will help in the testing activity.
    My question here is "How much does a black box tester need to get involved in the architectural issues of the product?". What kind of testing could be done with the architectural design? An example would be a great help for me.

    ------------------

  2. #2
    SQA Knight
    Join Date
    Aug 2000
    Location
    Elanora Heights, NSW, Australia
    Posts
    3,271
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Architectural issues in testing

    sanalmenon

    I am not sure what is in the article you read, but a tester's job is to test a solution, not an architecture.

    However, when doing certain types of testing you will need to consider the archtecture of the product. For example load testing will be impacted by the chosen architecture.

    ------------------
    Robert Tehve
    rtehve@bigpond.com
    Robert Tehve
    rtehve@bigpond.com

  3. #3
    Junior Member
    Join Date
    Jan 2002
    Location
    chennai,TamilNadu,India
    Posts
    29
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Architectural issues in testing

    Hi Robert ,

    Probably you should have gone through the article available in the following URl : http://www.jrothman.com/Papers/Pragmaticstrategies.html , before sharring ur views on the good question raised by sanal.
    To test the rigidity of an architecture you can evaluate it with what are commonly known as design patterns . It is beleived that any good object oriented architecture will abide to a design pattern .The following link could be useful for u: http://hem.passagen.se/gumby/cs/patterns.html
    The following link provides just a very brief message of what it is all about . http://hillside.net/patterns/DPBook/Foreword.html.

    I always beleive that whether a QA or TestEngineer , knowing the underlying design and architecture is always an added advantage (at times is also very essential).

    From my experience I feel that architectural and design flaws are quite evident if you view the implementation from a user's point of view. Just for example , in a 3 tier architecture a request must always be from a client to server and hence if you are going to come across a method called` processRequest in the client side you must be able to identify this as an architectural Issue .


    ------------------

  4. #4
    SQA Knight
    Join Date
    Aug 2000
    Location
    Elanora Heights, NSW, Australia
    Posts
    3,271
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Architectural issues in testing

    Rajesh D

    The original post was about blackbox testers. Software Architechs and Analysts are the correct people for analysing a design, not testers, especially blackbox ones.

    However a good tester will find design flaws as these will impact the software products ability to deliver the solution.

    Leaving it up to testers to analyse a design is a very dangerous approach.

    ------------------
    Robert Tehve
    rtehve@bigpond.com

    [This message has been edited by rtehve (edited 04-28-2002).]
    Robert Tehve
    rtehve@bigpond.com

  5. #5
    Junior Member
    Join Date
    Jan 2002
    Location
    chennai,TamilNadu,India
    Posts
    29
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Architectural issues in testing

    hai robert ,
    apart from black box testers , there was also a reference to an article which emphasized on something which started the thread.
    i'm not sure in how many concerns there are system analysts and system engineer placed specifically to validate the architecture . if there are such analysts what u say looks fine , but the question has a lot of relevance to normal test engineers in ordinary concerns.
    knowing the basic architecture makes u aware of the weak points in the architecture which needs to be checked with mush more stress applied and also throws light on all the parameters and attributes likely to affect the system.


    ------------------

  6. #6
    Junior Member
    Join Date
    Mar 2002
    Location
    Bangalore, India
    Posts
    22
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Architectural issues in testing

    Thank you Rajesh / Robert for the inputs. The articles have given me good inputs. The point that architectural issues are generally taken care of by the specialists, make good sense.
    Do you also think that a black box tester can categorize a defect as Architecture / Design defect in the bug report? If yes, what strategy do we normally adopt to find whether a defect is pertaining to the design / Architectural flaws?
    And Robert, your point that "A testers job is to test a solution" sounds interesting. I would definitely be very much interested to discuss more about it.
    ------------------


    [This message has been edited by sanalmenon (edited 04-29-2002).]

  7. #7
    SQA Knight
    Join Date
    Aug 2000
    Location
    Elanora Heights, NSW, Australia
    Posts
    3,271
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Architectural issues in testing

    Rajesh D

    Analysing designs / architecture should be a normal part of your SDLC (design review phase) and as I said before this should be done by the experts.

    Yes, as I have said also, testers should be aware of architectral issues, but as a BLACKBOX tester you should be focused on testing the solution against the customers requirements.

    Blaming architectural issues on a tester would be complete BS as they generally have little or no input into such issues.

    Rememeber...... YOU BUILD Quality....not test quality into a product.

    ------------------
    Robert Tehve
    rtehve@bigpond.com
    Robert Tehve
    rtehve@bigpond.com

  8. #8
    Points for Confirmed Friends
    Guest

    Re: Architectural issues in testing

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by rtehve:
    Rajesh D

    Analysing designs / architecture should be a normal part of your SDLC (design review phase) and as I said before this should be done by the experts.

    snip

    Rememeber...... YOU BUILD Quality....not test quality into a product.

    <HR></BLOCKQUOTE>

    A tester with those skills is an asset to any project he works on. I for one am working towards an MCP, MCSD and learning UML. I do not intend to become a system architect, but I believe having the same skill set will enable me to be a much more effective tester.

    Your last sentence I agree with it. It marginalises the role of the black box tester in any organisation committed to building quality into the product.

    If that job is done effectively there really isn't going to be much for your blackbox tester to do because validation against the customer requirements is part of the quality build.

    Secondly whither the blackbox tester who is asked to produce test cases from a UML (or equivalent ) model.

    ------------------
    GUI automation is GUI automation. It is not testing.

  9. #9
    SQA Knight
    Join Date
    Aug 2000
    Location
    Elanora Heights, NSW, Australia
    Posts
    3,271
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Architectural issues in testing

    wooks

    That is very admiral or you, but still does not alleviate the need for the experts to look at the architecture.

    ------------------
    Robert Tehve
    rtehve@bigpond.com
    Robert Tehve
    rtehve@bigpond.com

  10. #10
    Senior Member
    Join Date
    Jun 2001
    Location
    United Kingdom
    Posts
    819
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: Architectural issues in testing

    Robert,
    I am not sure if you are saying that testers are no use and should not be involved in a review of architecture or design? I wouldn’t disagree that architecture and design experts should/must review as part of the SDLC but why would you want to exclude testers? There are two good reasons for including testers in the review:
    - an experienced tester can find faults. Architects and designers can miss the “what if” questions that a tester will often ask, e.g. “What if all 100 users all log in at 09:00 when they get into work, will the system grind to a halt?” or “What if the database synchronisation fails for one of the three servers, how can that be rectified?”
    - knowledge of the design helps to design tests. System limits are the obvious area that helps testers with boundary conditions. A tester will start, almost subconsciously, designing tests in their mind as part of the review and this will also help find design faults – early

    Making the distinction that “black box” testers don’t need to know (and if I am reading you incorrectly, I apologise!) is limiting what a tester can do to find defects.

    As an aside, I don’t believe there are such animals as “black box” testers. There are are testers (which is most of us) who use black box techniques, but I wouldn’t want to label them as “black box” testers.


    ------------------

 

 
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.71%
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 08:24 PM.

Copyright BetaSoft Inc.