Seperate scripts for SIT & UAT
I have a requirement where automation scripts need to be deployed from SIT to UAT environments whenever there is a change in the application. The client wants us to maintain the script in the SIT environment and then move them in to UAT where it is executed.
We are using QTP 11 & ALM currently for our automation. Please provide your suggestion on how to achieve this.
Last edited by akumars0; 10-01-2013 at 07:17 AM.
What is SIT? Software Integration Test? Just a guess.
You should be able to just parameterise the opening of the browser, once the browsers open as long as the code is the same in both environment in theory you "should" be able to use the same script.
In the past I have used an External environment variable to hold the key to the environment I want to run on (DEV, SIT & UAT) and with a bit of code like this I can run on any of the 3 environments by changing the Environment variable:
Select Case Environment("ENV")
URL = "www.sit.com"
URL = "www.uat.com"
URL = "www.dev.com"
.... Add Stop Run code here and output message ....
Set IE = CreateObject("InternetExplorer.Application")
Set IE.Visible = True
Personally, I like checking in my tests in the same project folder as the SUT itself. It allows the tests to be branched off each time you create a release branch or push the code to a different branch.
If you can't do that, I think the next best thing would be to use a git flow model (or parallel this strategy if you don't use git)
A successful Git branching model » nvie.com
Keep one branch that mirros the development stage, and during releases, push the code to Master and tag it with the release number.
This will allow you to check out code that can run at the different version tags in case you need to run older tests, and still be able to perform development against the latest dev version of the SUT.
I have been using the CASE statement as well to choose the URL.
Sometimes the code is expected to work differently for different environments. Then I have to put conditions in the script as well.
I usually put in a comment with constant text so that when the requirements change, I can quickly do a control + f and update the script.
' Branch by environment
IF URL = "UAT" Then
Do something else
Last edited by bklabel1; 10-01-2013 at 08:43 AM.
Reason: forgot end if on code
I think branching for configuration settings in code is a very bad idea. Whether it's if/else, case statements. They all put hard coded settings into your execution code.
What I like to do instead is have a global configuration singleton object that reads a config file. Usually this config file is the same config file as the server deploy so I can just share the same config settings as the system itself. What ever the method, the idea here is I can feed it a different config file that has all the settings in one place. I can create multiple config files for different systems. My devs can create a local copy of a config file for their personal dev instances.
Problem with if/else, and case statements for configurations, is you won't be able to seamlessly support automatic branching. It'll make it harder for devs to be able for devs to run tests on their personal instances and make changes to the config on the fly. If the devs can't run tests, than you're catching the bugs late. That means the dev would have to check their code in first, in order for the general build to pick up the changes, deploy, and have your tests run. At this point, you have bad code in the repo that other devs can check out causes issues to cascade. Automated tests, I think it best run as early as possible.
Your idea sounds good.
So you use a VBScript class to create an object that holds the configuration information. Is that the global configuration singleton object?
Then you request that information at each place where you need it.
Would it be similar to loading a set of Global variables or using Environment Variables to hold the information throughout the script.
What happens when the code has to perform something slightly different. For example in environment A we click on a different button than B. Where do I put the action differences?
I do not wish to hi-jack your topic. Please let me know if I am still "on topic".
I believe Mark suggestion is best, Similar way i had used in many situations.
SIT - System Integration Testing
I was answering the question as it was stated, that approach worked at the client site I used it as they were not an agile site, it was a big-bang release. In an agile environment I would go for something similar to what David has outlined.
Tags for this Thread