SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 4 of 4
  1. #1
    Junior Member
    Join Date
    Dec 2004
    Posts
    3
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Organizing test plans

    I am looking at reorganizing a group of test plans. I am curious what anyone might think of my methodology and whether there might be a better way to organize the test plans. Currently I am thinking about organizing by UI. I know I could also organize by function but this is for black box testing. I also don't know if there are any other ways to organize the tests.

    I am organizing the test plans by
    Program -
    Scope (major UI section) -
    Functional Unit (Individual windows) -
    Functional Sub Unit (Tabs within windows)

    -Brian

  2. #2
    Moderator
    Join Date
    Mar 2004
    Location
    West Coast of the East Coast!
    Posts
    7,756
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Organizing test plans

    A good place to start is with a functional decomposition. Breakdown the functions by size and importance then use that as a template to create a unified test plan. If you run out of time you will only have the lower priority functions not tested. The priority should be based on the importance to your company ($$), the past failure rate of each function, and what functions were worked on last.
    Personal Comment

    Success is the ability to go from one failure to another with no loss of enthusiasm.
    ~ Winston Churchill ~


    ...Rich Wagner

  3. #3
    Junior Member
    Join Date
    Dec 2004
    Posts
    3
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Organizing test plans

    I appreciate your feedback. I think that I can see what you are saying and I think that if I was working with a larger project like Word where a single tester wouldn't be able to create or execute a comprehensive series of tests in a reasonable amount of time I would have to separate it into functional blocks. Do you think that starting with functional decomposition is always the right choice even with a smaller program? I think that to create the program properly you should clearly define functions and group them in a clean, efficient way that is easy to use for the user. Perhaps part of the problem with using functional grouping in my case is that there are similar functional components that are implemented with a different UI in separate parts of the program. This means that I couldn't write one test for that functionality. I have to write tests for both locations. And since many of the objects link to each other I have had a hard time deciding if it is going to cause duplicate tests trying to group tests by function.

    My other concern with breaking down the test cases by function is that running a test on a function that is in three different places in the UI verses testing all the items in a window means more jumping around instead of a systematic progression through the product.

    -Brian

  4. #4
    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: Organizing test plans

    Brian, the breakdown you propose, in the first post seems reasonable, though I too would look at some risk/prioritisation element as proposed by Rich_W for the execution of these. However not having much of the context it is hard to provide a definitive approach.
    I am also not sure you have supplied a methodology for us to review and critique, just a checklist of criteria used for the classification; I am not sure if this is a tree view hierarchy or not from the original post.

    Originally posted by Brian Todd:
    I appreciate your feedback. I think that I can see what you are saying and I think that if I was working with a larger project like Word where a single tester wouldn't be able to create or execute a comprehensive series of tests in a reasonable amount of time I would have to separate it into functional blocks.
    <font size="2" face="Verdana, Arial, Helvetica">I am not sure why you believe this is applicable only to larger programmes or where there are multiple resources. I would agree this prioritis(z)ation approach to testing leads to the tendency, in a number of organisations, to create a coverage model of acceptance via omission (i.e. we covered the most important items, ship and forget), which is sub optimal though that is not the intent. Lack of time and lack of ability to cover can still occur on perceivable small programmes and this is where the application of other black box techniques come in useful (boundary value analysis, equivalence partitioning, orthogonal arrays and all pairs) to find an “optimised” number and range of test cases to the business need and drivers (cost, (quality)risk, delivery).
    Arranging by functions works if you are looking purely at the functional elements (it works to an extent to if you are looking at non functional as these are often measured by the execution of functions – but that is a whole separate discussion).


    Originally posted by Brian Todd:
    Do you think that starting with functional decomposition is always the right choice even with a smaller program?
    <font size="2" face="Verdana, Arial, Helvetica">No not always, sometimes I will create another model to help me decide my starting point, it might be a profile of usage or it might be a navigation model and involve no functional execution, it will depend on what I am trying to model and why and what characteristics of “quality” I am testing to sample within the product.
    The following site has some excellent articles on model (graph theory) based approaches to creating tests and tools (both free and low cost) http://www.compendiumdev.co.uk/default.php
    For additional (and large numbers of articles) on model based approaches http://www.geocities.com/model_based_testing/ which will possibly not help a jot in this instance – but I like to promote model based approaches.
    Also I tend on small projects to use exploratory testing techniques in sessions. There are some excellent articles on this form of approach on www.satisfice.com www.workroom-productions.com and www.amland.no the websites of James Bach, James Lyndsay and Stale Amland respectively all of whom advocate exploratory approaches. There is also a tool I am in the process of evaluating for managing exploratory testing in an effective manner and to improve the reporting called Test explorer which can be found on the following site - www.sirius-sqa.com


    Originally posted by Brian Todd:
    I think that to create the program properly you should clearly define functions and group them in a clean, efficient way that is easy to use for the user.
    <font size="2" face="Verdana, Arial, Helvetica">It is a point of view – and valid in contexts where the grouping for the user is the driver though this may not always be the best way to optimise or code the system where it may be better to organise the functions by class models or object/function/procedural type.

    Originally posted by Brian Todd:
    Perhaps part of the problem with using functional grouping in my case is that there are similar functional components that are implemented with a different UI in separate parts of the program. This means that I couldn't write one test for that functionality. I have to write tests for both locations. And since many of the objects link to each other I have had a hard time deciding if it is going to cause duplicate tests trying to group tests by function.
    <font size="2" face="Verdana, Arial, Helvetica">I am not sure why you see this as a barrier, the functions may not act the same way on the same page depending on the inputs, coding/ calling method, and the trigger events within each given temporal state. There is often one to many and many to one relationships’ with test cases, also frequently there is often one test case that covers partially many different functions and requirements but satisfies none fully depending what question you are trying to ask with that test case.

    Originally posted by Brian Todd:

    My other concern with breaking down the test cases by function is that running a test on a function that is in three different places in the UI verses testing all the items in a window means more jumping around instead of a systematic progression through the product.
    -Brian
    <font size="2" face="Verdana, Arial, Helvetica">I am not sure that, jumping around, is an issue. If the system is designed for systematic usage with designated flows, then may be this will not answer the questions, you seek answers for, but it might provide questions to ask for answers you have not yet realised you need. Look to the non systemic approach as a way of providing negative tests and then there is validity in it, this is auditable in an exploratory manner, as with out a map you cannot demonstrate the exploration unless you return with a map and preferably some evidencing.


    I think I may have wandered off topic here, but yes, the approach may well be reasonable depending on context.
    [img]images/icons/wink.gif[/img]
    ------
    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/
    ---

 

 

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 12:25 PM.

Copyright BetaSoft Inc.