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.
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.
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.
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.
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.
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.
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.
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.
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.
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 synthetic or anonymized test data wherever possible.
Avoid dependencies on production data.
Clean up test data after execution to prevent clutter and conflicts.
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.
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.