Stop building automation from scratch.

Before work begins, we document the agreed workflow, deliverables, and the criteria you will use to accept them. We demonstrate the completed automation and review it with you. If our automation does not meet the requirements originally agreed upon, we correct it as part of the implementation at no additional charge. The implementation fee becomes payable when you accept the agreed work. If we don’t deliver the agreed results, you don’t pay that fee. Scope, dependencies, and payment terms are documented in the engagement agreement.

In a healthcare claims application, the use case “Enter a claim” may depend on a supporting workflow such as “Add and verify a provider.” This gives claim testing a repeatable starting point.

The automation creates a new provider in the agreed test environment using controlled test data, completes the required fields, checks the agreed validation rules, and saves the record. The workflow ends when the new provider’s identifier and saved details are verified and the provider can be selected for a claim. Each run creates its own test provider, avoiding reliance on a record left behind by another test or user.

Patient setup, coverage setup, and claim submission are additional workflows, included only if agreed in the proposal. Your QA manager selects the coverage needed; together, we define the prerequisites, validations, test data, named screens, and any cleanup or reset steps. The actual screen count and fixed fee are confirmed during the application walkthrough.

A broad use case such as “Enter a claim” may contain many workflows and scenarios. The package covers one agreed workflow within that use case, with a defined start, finish, and up to five named screens. During the application walkthrough, we agree on the screen inventory, including how relevant tabs, dialogs, and wizard steps are counted. A larger workflow requires a separate quote or a smaller phase with its own useful, independently acceptable outcome.

If a screen is added, removed, replaced, or becomes conditional on an earlier step, we review how that change affects the automation. This includes changes that take the workflow beyond the five named screens in the proposal.

We explain any impact on the work, price, and delivery schedule and agree on revisions with you before proceeding with the affected work. A change does not automatically mean an additional charge; that depends on the work required.

Start with a selected workflow and a QA contact who understands the application. Before implementation, we agree on the acceptance criteria and confirm these technical prerequisites with your IT team:

• Forge Agent: An approved computer with a compatible Forge Agent installed and registered to the project, or permission to install and configure it. The Agent must be available during the agreed work and test runs.
• Required software: We deliver automation using either Java/Selenium or TypeScript/Playwright, as agreed for your project. Both options require Node.js version 22 installed and used by the Agent, npm 10, Git, and the required browser dependencies. Java/Selenium engagements also require JDK 21 or newer and Maven 3.8 or newer.
• TEST automation database: A dedicated, nonproduction PostgreSQL or SQL Server database, connection details, and permissions to initialize the project’s tables and read and write automation data. This is separate from your application’s own database; any direct access to that database is agreed only if needed.
• Test application and accounts: Access to a working TEST environment, test accounts with the required roles, and permission to create and manage the agreed test data.
• Repository and workspace: Access to the automation Git repository and agreed branch, including publishing permissions, plus writable folders on the Agent computer.
• Network access: Approved connectivity from the Agent to Forge, the test application, automation database, Git repository, and required package and browser downloads, including any VPN or firewall configuration.

We verify readiness with your QA and IT teams and document who provides and configures each item. The delivery schedule depends on these agreed prerequisites remaining available; any setup work or impact from access delays is discussed with you.

You don’t need a Forge subscription to get started with our consulting services. If your team later chooses to build, manage, and expand its own automation, Forge is available through an optional subscription. You keep the delivered automation code whether or not you subscribe.

The generated automation code is delivered to a repository you control and stays with your team. You can run the tests repeatedly through your own CI/CD pipeline—for example, with each build, before a release, or on a scheduled regression run—using the required software, test data, and environment access.

Our handover includes guidance for running and maintaining the delivered automation. Any setup or integration work needed for your pipeline is agreed as part of the engagement scope.

As your application changes, the automation may need updates. Your team can maintain and extend the delivered code, or engage us for additional coverage or ongoing maintenance. Further consulting work is scoped and agreed separately.

Yes, we can discuss Forge access for your team. The first conversation establishes which mix of software, implementation, and support suits your needs.