---
title: Infor Automation Testing – Best Practices
description: Best practices for building and maintaining high-quality tests in the Intelligent Process Tester (IPT) platform for Infor ERP, ensuring reliability, maintainability, and ease of understanding.
---

<https://www.infomind.ai/blog>

# [Infor Automation Testing – Best Practices](https://www.infomind.ai/blog/infor-automation-testing-best-practices)

 Written by [Jerome Josephraj](https://www.infomind.ai/blog/author/jerome-josephraj) | Sep 22, 2025 6:01:28 AM

This guide outlines recommended practices for building and maintaining high-quality tests in the **Intelligent Process Tester (IPT)** platform to test Infor ERP. These practices are designed to ensure that tests are **reliable, maintainable, reusable, and easy to understand**, even for users with limited test knowledge.

### 1. Keep Scenarios Independent

Each test scenario should be able to run on its own, without relying on the outcome of another test.

- Benefits: Reduces flakiness, supports parallel execution, and makes debugging easier.
- Example: Do not assume that a customer created in Scenario A will be available in Scenario B. Each scenario should handle its own data needs.

### 2. Use Hooks for Reusable Processes Only

Hooks should be reserved for processes that are always needed across multiple scenarios.

- Common examples: Login, user session setup, or global data initialization.
- Avoid overusing hooks, as they make the test flow less explicit for new readers.

### 3. Use Modules for Reusable Steps

If steps (not whole processes) are repeated across scenarios, place them in **modules** rather than hooks.

- Example: “Create Sales Order” or “Approve Invoice” can be a module.
- This improves readability and ensures that scenarios remain transparent and easy to maintain.

### 4. Prioritise Element ID Over XPath

When identifying UI elements, use **stable locators** such as IDs or data-attributes.

- IDs are more reliable and faster to locate.
- XPath should be avoided unless no other selector is available, as it is brittle and breaks easily when the UI changes.

### 5. Do Not Hard-Code Environment-Specific Details

Avoid embedding environment-specific values (like URLs, usernames, or database connections) directly in scenarios.

- Use environment configuration files instead.
- Example: Instead of hard-coding `test-user@company.com`, reference it from a config file.

### 6. Always Use Secrets for Passwords

Passwords and sensitive information must never be stored in plain text.

- Store them securely in your secret manager or IPT’s secure storage.
- This prevents accidental leaks in shared repositories.

### 7. Prioritise API Over UI Wherever Possible

Use APIs for data setup, validation, or process testing instead of UI steps.

- APIs are faster, more stable, and reduce test execution time.
- Reserve UI automation for validating the user experience, layout, and end-to-end flows.

### 8. Use UI Only for UX Validation, Not for Variations

UI tests should focus on verifying the **user journey** and **visual behavior**, not on testing multiple variations of the same logic.

- Example: If a purchase order approval process works via API, test only one user flow in the UI. Avoid repeating multiple variations of approval conditions through UI, since that is better covered via API.

### 9. Ensure Clear Naming Conventions

Use consistent and descriptive names for scenarios, modules, and steps.

- Example: Instead of “Scenario1”, use “Customer_Creation_Valid_Data”.
- This helps business users and non-technical stakeholders understand the purpose of each test.
- Use this link as a sample naming standard and either use this or come up with your own naming standard that should be followed throughout the project [https://docs.google.com/document/d/1O3vG38Q59h8UdOmwPfXJuyweWscdlmfrLGzx-p7WiTQ/edit?usp=sharing](https://docs.google.com/document/d/1O3vG38Q59h8UdOmwPfXJuyweWscdlmfrLGzx-p7WiTQ/edit?usp=sharing)

### 10. Maintain Test Data Strategy

Use synthetic or anonymized test data wherever possible.

- Avoid dependencies on production data.
- Clean up test data after execution to prevent clutter and conflicts.

### 11. Keep Scenarios Short and Focused

A test should validate a single business process or user journey.

- Long and complex scenarios are harder to debug.
- Break down larger flows into smaller, modular scenarios.

### 12. Review and Update Regularly

Tests must evolve with business processes.

- Conduct periodic reviews to remove obsolete scenarios.
- Keep modules updated so that changes flow consistently across all dependent scenarios.

[View full post](https://www.infomind.ai/blog/infor-automation-testing-best-practices)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Jerome Josephraj"
  },
  "dateModified" : "2025-09-23T16:58:30.910Z",
  "datePublished" : "2025-09-22T06:01:28Z",
  "headline" : "Infor Automation Testing – Best Practices",
  "image" : {
    "@type" : "ImageObject",
    "height" : 1024,
    "url" : "https://146678177.fs1.hubspotusercontent-eu1.net/hubfs/146678177/AI-Generated%20Media/Images/The%20image%20depicts%20a%20wellorganized%20workspace%20dedicated%20to%20software%20testing%20A%20sleek%20wooden%20desk%20is%20adorned%20with%20a%20modern%20laptop%20open%20to%20a%20detailed%20document%20outlining%20best%20practices%20for%20automation%20testing%20Beside%20the%20laptop%20colorful%20sticky%20notes%20display-1.png",
    "width" : 1024
  },
  "mainEntityOfPage" : "https://www.infomind.ai/blog/infor-automation-testing-best-practices",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60,
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
      "width" : 60
    },
    "name" : "blog"
  }
}
```