QA testing in DEV instance in servicenow

RajeshwariHP
Tera Contributor

Hi All,

 

Is there any documentation to understand why we need to perform the testing in DEV instance whenever developer completes their development work. Is there any best practice that servicenow is preferring to perform testing in lower instances.

 

Please let me know

Thank you.

Rajeshwari

1 ACCEPTED SOLUTION

Dr Atul G- LNG
Tera Patron
Tera Patron

Hi @RajeshwariHP 

It is a best practice to never perform testing in the Development environment, as it is considered unstable and meant solely for development activities.

Testing should always be done in either the Test or UAT (User Acceptance Testing) instance to ensure stability and reliability.

*************************************************************************************************************
If my response proves useful, please indicate its helpfulness by selecting " Accept as Solution" and " Helpful." This action benefits both the community and me.

Regards
Dr. Atul G. - Learn N Grow Together
ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
Topmate: https://topmate.io/atul_grover_lng [ Connect for 1-1 Session]

****************************************************************************************************************

View solution in original post

7 REPLIES 7

Hi @RajeshwariHP ,
Please accept my answer as solution. 

GlideFather
Tera Patron

Hi @RajeshwariHP,

 

there is no general response to this. It will be always customer-specific.

 

I have been on projects where there were 4 environments: DEV - TEST - QA - PROD, as well as projectes with DEV and PROD only... but the most standard is DEV - TEST - PROD, that is the 90 % of my projects.

 

You should always tend to have the relation 1:1:1 Dev:Test:Prod. Of course when you develop new stuff, you start in DEV so if you make changes that are not going to be deployed further it shall be reverted back or cloned from PROD to maintain this 1:1 situation.

This is applicable also from the other side, if you make any change directly in PROD, it shall be deployed to the non-PROD instances.

Example: in a user criteria (giving access to catalog items and knowledge articles) we have there a list of 15 companies. So, in the beginning it was 15 companies in DEV, 15 in TEST and 15 in PROD. 

But then a colleague add two Companies to PROD only. So it was 15-15-17, everything was working ok. Until a new requirement to add one more Company to this user criteria was required. ANd because in DEV there were 15 (not 17) and one was added, so it changed from 15 to 16, the same in test 15 to 16, and then to PROD where there were 17 and it has been replaced by these 16.

 

Result: in PROD two Companies were removed due to that and issues with access ocurred.

Because the 15 were there all the time in all environments, the 2 added to PROD were not reflected in DEV and not TEST, so adding a different one was 15+1 and not 15+2+1 as it would be correct.

 

Not sure if this make sense to you, please ask if you want any further details on the topic

———
/* If my response wasn’t a total disaster ↙️ drop a Kudos or Accept as Solution ↘️ Cheers! */


There are comments not to test in DEV, what do I do when developing is to verify in DEV to see if it does what I want, then moving to TEST and I test it myself before I ask for testing by somebody else.

 

It is always better to validate that everything was deployed correctly before reaching out to others.

 

Also, some things cannot be tested in TEST or at all. For example integrations are usually not configured for DEV, only sometimes to UAT, but often just to PROD without a chance to TEST it. Only Postman or SOAP UI
simulation of integrations sending the REST/XML messages by yourself but not from the other system.

———
/* If my response wasn’t a total disaster ↙️ drop a Kudos or Accept as Solution ↘️ Cheers! */