Why ATF Should Not Be Built in Production?

[AP2K]

ATF test cases are not recommended to be built in Production and the best practice approach is to have it build and execute in the Non-Production instances. Production should only receive already-validated code through proper change management.

The golden rule is "ATF is a quality gate before Production, not something to run in Production"

Recommended Flow of ATF Testing:

Development - Build and write ATF Test cases

Test / QA - Execute and validate ATF test cases

UAT - Final validation before Go-Live

Below are some known challenges/risks encountered if ATF tests have to be considered in Production.

 

1. Data Integrity Risks

ATF tests create, modify, and delete real records during execution. Running tests in Production can corrupt live business data, affect real transactions, and cause unintended changes that are difficult to reverse.

2. System Performance Impact

Test execution consumes significant system resources (CPU, memory, database connections). Running ATF in Production can degrade performance for real users and cause slowdowns or timeouts in critical business processes.

3. Unintended Business Process Triggers

ATF tests often interact with workflows, business rules, notifications, and integrations. In Production, this could trigger real emails to customers, fire live integrations with third-party systems, or kick off actual approval workflows.

4. Security and Compliance Concerns

Test scripts may require elevated permissions or access to sensitive data. Exposing test accounts or test data in Production creates security vulnerabilities and can violate compliance requirements (GDPR, HIPAA, SOX, etc.).

5. Best Practice: Environment Segregation

ServiceNow's recommended environment strategy is to use dedicated instances for testing — typically Dev → Test/QA → UAT → Production. ATF is designed for non-production environments to validate changes before they reach Production.

6. Test Data Pollution

ATF generates test records, dummy users, and sample data. This pollutes the Production database with irrelevant records, skews reporting/analytics, and creates clutter that is hard to clean up.

7. Risk of Irreversible Actions

Some test steps may perform destructive operations (deleting records, deactivating users, changing configurations). In Production, there is no easy way to roll back these changes.