ATF Migration Problems - Used Update Sets and XML Export

[Dakker]

Hi,

I am having problems with migrating ATF Steps, Tests, and Suites from Dev to Test. Both environments are clones of our production environment upgraded to London. The process I tried:

1. Created the ATF test in Dev

2. Tested them in Dev

3. Created a Update Sets and tried importing into Test - none of them worked perfectly (some were missing steps)

a. Created an Update Set for each Suite

- in each test, I went into the list of Steps and added them all to the Update Set

- added the Test and the Suite to the Update Set

b. Created an Update Set for each Test

- for each Test, I went into the list of Steps and added them all to the Update Set 

c. Created an Update Set for all Suites, Tests and Steps

- in each suite, I went into Test list and added them all to the Update Set,

- then I went into the list of Steps and added them all to the Update Set

- added the Test and the Suite to the Update Set

- also tried this in the reverse order.

Finally, I exported the following 3 tables in the following order:

sys_atf_test_suite.list
sys_atf_test.list
sys_atf_step.list

then imported then in the appropriate table in Test. 

Created an Update Set of the custom Configuration Steps and imported that into Test

This was the closest to working correctly. There were some bad references and some tests didn't work. 

So after hours of trying, I decided to fix them in Test and do with that.

Now I would like to keep these tests forever and not have to repeat the work. I was told by a HI Tech to migrate the tests to Production and that way when we Clone they will be there. Sounds like a good thing to do. BUT:

How do I make sure they work? Can I run them in Production, when no one else is using SNow to make sure?

Comment and suggestions?

[Brian Bouchard]

Best practice is to NOT run ATF tests in production because it will create data and noise that will go out to users, etc.. For instance, any notifications that may be generated will be generated and be sent to the appropriate people, but when the tests are complete, the records they refer to will likely be gone.

There is a level in trust in here, I think.  When you are promoting things through the environments if the tests work in all other environments, you have to assume they will work in Production.  If you're really concerned about it after a production implementation you can clone production down to your Dev environment and run the tests there, which should essentially be the same thing as running them in PROD, but without the updates to real production data and notifications going out to end users, etc...

[Nia McCash]

I had the same issue when trying to capture my ATF work in an update set - I lost some of the step configurations when I moved it to a different instance.  This is the solution that ServiceNow HI support staff shared with me: 

... we observed that dictionary entries of “type” Glide Var are missing a serializer attribute.

/sys_dictionary_list.do?sysparm_query=internal_type%3Dglide_var%5EnameSTARTSWITHsys_atf 

On out of the box these dictionary entries have attribute serializer defined with value com.glide.vars.VariableValueXMLSerializer.

To correct this, you can do the following:

1. Open each record to edit the dictionary records included in the list mentioned above
2. Switch to advanced view from related links
3. Add to the existing attributes (in the attributes textarea) : serializer=com.glide.vars.VariableValueXMLSerializer

[Dakker]

Nia,

I read this post and confirmed that is the cause in our environments. Still there is a problem with migrating them.

[Nia McCash]

Do you mean that you've done the above steps and still test step configurations are missing from your update set?  Please note that the 'fix' described by support doesn't correct any existing update sets you've already created.

You may need to start again to properly capture all the configurations in your tests or add those missing configurations again to your test steps and then merge your update sets.