SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 3 of 3
  1. #1
    Junior Member
    Join Date
    Mar 2006
    Location
    UK, Kings Langley
    Posts
    2
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Functional tests with no requirements docs

    The company I work for had many years where developers developed and used customers as testers. It them woke up and decided we should be testing our own software.
    New functionality goes through a process of approval and then test cases are created in parallel with the development work from the requirement specs. My question is what approach(s) could be taken to identify the functionality already coded that should be tested. My end goal is to generate a functionality test suite which is subdivided into groups. When new features are implemented we can look at the groups they fall into and pick appropriate tests.
    We have looked at two approaches so far.
    1. running all our regression tests through a code coverage tool to identify "methods" called and try and group the methods and then link them to functionality mentioned in the user guide

    2.Take the User Guide and try and identify functions or areas to test then look for or create tests.

    I suppose a question would also be why bother with the old stuff providing the regression testing of customer jobs is in place?

    This is my first posting so if I have not posted correctly then my apologies.

  2. #2
    Senior Member
    Join Date
    Jan 2003
    Posts
    1,898
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Functional tests with no requirements docs

    Either method will work and has some positives and negatives.

    On your first method, this will not verify all the methods that should be there are actually there.

    On the second method, normally what is documented for a user is not every way to perform a given function and often error paths are not documented at all.

    That said, and knowing code coverage tools have some limitations, I'd try the first method, primarily because when writing regression tests for existing software with no specs, one normally has to "assume" that what is in production is "right".

    Going back and writing tests for existing software is a tough job, but it is normally done because changes or additions to that software may yield errors in something that previously worked. If time and money is an issue (and isn't it always?), you might want to take a quick historical look at what seems to get updated most often and prioritize what you script. You can also opt not to script with the same level of detail for existing software - like skipping boundary test cases, for example.

    - Linda

  3. #3
    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: Functional tests with no requirements docs

    First off let me extend a hearty Welcome Stranger! Your post is very good. There is a bit more context you could have included like type of software you are testing, Web, Server Client, or stand-alone. Not that the type is crucial, but the approach will usually vary by type.

    Linda is dead-on. If you have access to a good code coverage tool, and the developers do not mind recompiling their applications with all the hooks in it, go for it. The only real draw-back is coverage tools, good coverage tools are quite expensive.

    From what you have said, most of the tests may have to be updated or rewritten anyway so the second recommendation, again as Linda said, is to scrap the old and write the new tests. I have just brought on 4 consultants for that express purpose. We have a Legacy app. which has never been through regression in 6 years of usage. Needles to say, it's fairly crippled by now. So, even though there are over a thousand tests for it, there is NEVER time to run them. We have only 2 days to validate the enhancements and fixes and then it's delivered. That really hurts me and several others, but that's business. You may know what's right but be unable to implement it.
    So we are scraping all the tests and starting over. But rest assured, as Linda points out, everything costs money, resources, and time.
    Personal Comment

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


    ...Rich Wagner

 

 

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 05:50 PM.

Copyright BetaSoft Inc.