Results 1 to 7 of 7
  1. #1

    Branching Test Scripts

    Hi guys,

    I'm looking some advice about branching test scripts.

    Currently I have several QTP test scripts which I run against a development branch of our software. I have been asked to take a branch of my tests every time a release branch is taken of our software.

    I'm not sure if this is a good idea as I will have to spend more time maintaining the scripts. I would prefer to only have one version of scripts to run against the release branch. This would mean no automated test would be run against the development branch, and fault would not be found until a release branch was taken.

    Has anyone any experience of having different version of scripts? Would it end up a maintenance headache?

    I look forward for any comments.


  2. #2

    Re: Branching Test Scripts

    Would it end up a maintenance headache?
    <font size="2" face="Verdana, Arial, Helvetica">I've tried it, and - IMHO - unless you have sufficient resources - yes.

  3. #3

    Re: Branching Test Scripts

    Maybe you could have the script "identify" the version under test and change behavior/feature set accordingly?

    In a way, it makes sense to branch the tests along with the code, but if both old and new are going to be kept active - you betcha, it's going to be a headache.

  4. #4

    Re: Branching Test Scripts

    I have been modifying my scripts to handle different versions of the app. But these have been small changes and only 2 versions. When we create another development branch of the app, there will be 3 versions, then 4, 5, 6 etc.

    Then it will become a headache.

  5. #5
    Join Date
    Mar 2004
    West Coast of the East Coast!

    Re: Branching Test Scripts

    Utilizing the Key Word methodology included in QTP, would ease some of the maintenance time by having only a few places to change. Other than that, I am not very helpful.
    Personal Comment

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

    ...Rich Wagner

  6. #6

    Re: Branching Test Scripts

    Originally posted by graemeal:
    Has anyone any experience of having different version of scripts? Would it end up a maintenance headache?
    <font size="2" face="Verdana, Arial, Helvetica">I have been doing this for the last year or so, and while there is a certain maintenance overhead, I think it is much smaller than keeping different versions of largely identical scripts.

    The way that I work is to keep the release version numbers as variables in my script, and then branch in the script based on the version number. When a new release then breaks an existing script, I surround the existing script with an if clause that limits its execution to a release number range, and make a new copy of that part of the script suitable for the new release. For my application this has the following advantages;

    1) Resources required to maintain test scripts appear to remain proportional to resources required to change the AUT.

    2) It is possible to retest older versions of the app by changing the version numbers in the script.

    The downside to all this is that the test scripts keep on growing. When I get the chance, I intende to put all of the code dealing with obsolete version support into a library of version specific scripts, primarily to make the primary script more readable.

    Another alternative that you might consider is to put your test scripts into a version control repository such as VCS or SourceSafe. Basically, the version control system would handle all of the above, letting you avoid version based branching. I imagine that this is what your dev people are using, so it might be worth asking them how they handle versioning and do likewise.



  7. #7
    Senior Member
    Join Date
    Sep 2000
    Twin Cities, MN, USA

    Re: Branching Test Scripts

    I dealt with 4 versions of an ERP system at my last job. A common framework handled them all and additional products. Since development supported the 4 versions, I had to also. The system got big but not out of control, IMO. Approx. 250,000 lines of code in the system, but when you work with it all day it's like a book you know well. I developed scripts to test the functionality of an automated testing function across all versions. So if I changed the button click code, I could see pretty quickly if I had introduced a bug.

    This framework supported external Excel files in a keyword-driven format. This is where it got ugly. If one of the promises of keyword-driven automation is to have a document and automated test in one, and a link changes to a button, the document should change, right? Not in my situation - I had to code to look for a link in version x and a button in version y. This was a fight I lost, because my position was that the document for version x was inaccurate when applied to version y. My management insisted that the "real problem" was that my automation wasn't dealing with the change the way "it should".I went into this fight knowing that I would introduce a maintenance issue, but handing one of these Excel files to a developer for a bug path would have been a joke. Answering questions from development would have taken longer over time than just keeping a couple versions of the same document.



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
BetaSoft Inc.
All times are GMT -8. The time now is 03:57 PM.

Copyright BetaSoft Inc.