SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 6 of 6
  1. #1
    Senior Member
    Join Date
    Jan 2002
    Posts
    221
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    How to include back office process in automted testing?

    Hi all,
    I have a question that might have been asked many times. I am still putting it up as I was not able to get answer to it through already posted postings.
    OK I have application that has front end which is web based. And then there is back office that is developed in MUMPS that runs on VAX/VMS OS. Now obviously I cannot develop automated testing script for back office process, as with mercury tools it is either not possible to give a try or needs too much of complicated way out. Well whatever. (If anyone has any idea please do put that in). As far as front end, the one which I am working on. I have a process say PROC-A which has 2 steps
    - Enter input thru WEB interface
    - Run some back office processes that processes the inputs and then passes data to WEB.

    If the back office process is not executed the user cannot see the effect of the input data immediately. Now in order to develop the automated test script, I was thinking of developing 2 scripts for PROC-A.
    - Pre_PROC-A – this script will automate those test cases that verifies the data input process on WEB interface
    - Post_PROC-A – this script will automate the verification of data once after the back office process has been executed.

    Prior to running the 2nd script the back office process needs to be executed manually.

    Can anyone please suggest any other ways or methods?
    Thanks in advance



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

  2. #2
    Member
    Join Date
    Oct 2002
    Location
    McKinney, TX, USA
    Posts
    37
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: How to include back office process in automted testing?

    Hi,

    IMHO the key is to have access to all of the system inputs and outputs within a test script. I have been down the road of attempting to synchronize independent scripts and the result was a minefield followed by a dead end . So, there are two potential ways you could implement this, both of which require some tool development:
    1) Use a commerically available tool such as Winrunner to control the Web front end. Using the API, develop a "test head" that can talk to the back office system. It might be as simple as a telnet scripting test head that
    can invoke the backend
    2) Create test heads for both the HTTP interface and back office system.

    The advantage of 1) VS 2) is that 1) allows end to end testing. The advantage of 2) VS 1) is that tests will generally run faster and more reliably.

    Hope this helps. The system I work on has many types of interfaces as well so I share your challenge.

    The advantage

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

    Bill Thomson
    Test Architect (Demolition Man)
    Testability = 1/complexity
    Bill Thomson
    Test Architect
    Testability = 1/complexity

  3. #3
    Senior Member
    Join Date
    Jan 2002
    Posts
    221
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: How to include back office process in automted testing?

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

    IMHO the key is to have access to all of the system inputs and outputs within a test script. I have been down the road of attempting to synchronize independent scripts and the result was a minefield followed by a dead end . So, there are two potential ways you could implement this, both of which require some tool development:
    1) Use a commerically available tool such as Winrunner to control the Web front end. Using the API, develop a "test head" that can talk to the back office system. It might be as simple as a telnet scripting test head that
    can invoke the backend
    2) Create test heads for both the HTTP interface and back office system.

    The advantage of 1) VS 2) is that 1) allows end to end testing. The advantage of 2) VS 1) is that tests will generally run faster and more reliably.

    Hope this helps. The system I work on has many types of interfaces as well so I share your challenge.

    The advantage

    <HR></BLOCKQUOTE>

    Well first thanks for your response. Glad to know that someone is there that shares the same challenge.
    OK I am already using WINRUNNER. And I am new at it so when you say use PAI for developing “test head”…can you please explain that a little more. I do use a terminal emulator “Smart Term” for getting onto back office screens.

    I am Sorry if I say that I am lost with rest of the post
    “2) Create test heads for both the HTTP interface and back office system.
    The advantage of 1) VS 2) is that 1) allows end to end testing. The advantage of 2) VS 1) is that tests will generally run faster and more reliably.”
    Looking forward to your reply post. Thanks



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

  4. #4
    Senior Member
    Join Date
    Jul 2002
    Location
    Palm Bay, FL USA
    Posts
    2,346
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: How to include back office process in automted testing?

    I don't mean to take you guys off topic - but I have never heard the term "test head" before. Same as a "test harness"??

    A test harness is an artificial interface to test stuff (often using an automated tool, but not necessarilly) that you couldn't see otherwise. These are commonly used to bypass incompleted parts of the system under test.

    In this case, maybe a blank web page with a button that says "launch back office process" with a little java code behind it to do just that.

    If that isn't what a test head is, then maybe this is another idea for you.



    ------------------
    Scott Barber
    NOBLE(STAR
    Sr. Performance Engineer
    sbarber@noblestar.com
    http://www.noblestar.com
    http://www.perftestplus.com
    Scott Barber
    Chief Technologist, PerfTestPlus
    Executive Director, Association for Software Testing
    Co-Author, Performance Testing Guidance for Web Applications
    sbarber@perftestplus.com

    If you can see it in your mind...
    you will find it in your life.

  5. #5
    Moderator
    Join Date
    Aug 2000
    Location
    Vancouver, BC, Canada
    Posts
    1,189
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: How to include back office process in automted testing?

    I prefer using the "driver" and "stub" terminology.
    In this case having a driver that can be triggered from your test tool could do the trick.

    ------------------
    Roland
    Roland Stens

  6. #6
    Member
    Join Date
    Oct 2002
    Location
    McKinney, TX, USA
    Posts
    37
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: How to include back office process in automted testing?

    Sorry if I confused folks with the "test head " term. We refer to drivers and harnesses as test heads internally so my corporate inbreeding just became apparent.

    To answer your question, if you are using a terminal emulator you are on the right track. Depending on the complexity of the interface to the back office system it might be worth creating a set of functions or macros as a layer on top of "Smart Term". For example, if it takes a series of 10 commands to invoke an action on the back office system (log in for example) you could create a macro or function for that action. This simplifies both test case creation and maintenance.
    If the series commands to invoke the action changes you just need to change the function/macro instead of changing all your test cases. IMHO, test case maintenance is the biggest long term cost of a set of automated test cases so plan your test cases and tools around this.

    Regarding the HTTP test head, what I am suggesting is creating a driver/harness that emulates the Web interface as opposed to using Winrunner or a similar tool to poke the Web interface itself. We actually use both approaches. Why?
    1) We need the capability of running a lot of test cases in parallel on a single machine. With a test head (er harness) this can be done easily. Winrunner test cases need to be run serially on a machine unless you get into some really tricky and kludgy scripting.
    2) Since test cases implemented with a tool that pokes the GUI directly are generally more fragile than test cases that use a driver/harness, we need to keep the numbers of these types of test cases to the bare minimum. Basically we have a thin layer of test cases implemented with Winrunner that verify GUI of the system. The bulk of the test cases access the system via a test driver. We ended up with about two dozen different drivers. And we use Winrunner for front end client and back office OA&M. Makes life entertaining.


    Again, I can not overstate the importance of considering test case maintenance when coming up with a automation plan and tool set.


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

    Bill Thomson
    Test Architect (Demolition Man)
    Testability = 1/complexity
    Bill Thomson
    Test Architect
    Testability = 1/complexity

 

 

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 05:44 AM.

Copyright BetaSoft Inc.