End-to-End Testing in Workday: Business Processes, Integrations and Extend Apps

An end-to-end test of a Workday change follows one transaction from the moment a person starts it to the last thing it produces, which might be a worker record, an output file at a trading partner, or a saved record in an Extend app. You run it as each role that touches the transaction, and you check the result at the end, not only the screen you finished on.

The method below uses only features Workday documents publicly: proxy sessions, the business process Full Process Record, integration events, the Process Monitor, and a Sandbox Preview tenant for release checks.

What counts as an end-to-end test in Workday?

A test counts when it crosses every boundary the real change crosses. For a typical change that means five links, and a test that skips one has not tested the chain:

1. The business process runs from initiation to completion with the real routing.
2. Each approval step is done by the role that does it in production.
3. Any integration the process launches runs, and its output is checked.
4. Any inbound load that feeds Workday is run and read back.
5. Anything built on top, such as an Extend app, shows and saves the result.

A unit test of one calculated field or one XSLT does not do this. Those are worth having, and the AUnit guide covers the Studio side, but they sit underneath an end-to-end test rather than replacing it.

How do I test a business process from start to finish?

Start with data you control, then walk the process one actor at a time. The test data guide covers building the cases. Then:

1. Initiate as the person who initiates in production, not as an administrator. If an administrator can start it but the real initiator cannot, the test passed for the wrong reason.
2. After each step, open the event's Full Process Record and confirm the step moved on and the awaiting person is who you expected.
3. Sign in as each approver through proxy and complete their step. The multi-persona proxy testing guide lays out this handoff sequence.
4. Include at least one path that should branch: a condition that sends the event to an extra approver, and one that does not.
5. Include a path that goes wrong on purpose, such as a send back, a deny or a cancel, and check the data afterward.

When a step stops where it should not, the Awaiting Action guide and the reassign and advance guide cover diagnosis and the fix. If the event never reached the step at all, see the condition rule guide.

How do I test the integration a business process launches?

A business process can launch an integration through an Integration step. Workday says that step always launches an Integration Process Event business process for the chosen integration system, so you are testing two connected processes. The step is configured with the integration system, a Run As User, and optional date range rules for the data selected.

To test it:

• Complete the parent process so it reaches the Integration step.
• Find the run in the Process Monitor, or through the integration events for the integration system. When an integration launches, Workday creates an integration event with its own ID, and that is what tracks the run. The request name you configured on the step is what the Process Monitor displays.
• Open the Output Files tab on the run to get the file the integration produced, and check the content, not only the status.
• Compare the output with an expected file for the same input.

Check failure on purpose too. Workday states that when an Integration step fails, the entire parent business process is terminated unless you configure redirect on the step. With redirect, Workday can either route the failure to a configured user or advance the process automatically. Cause a failure in the test tenant, for example by pointing at an unreachable endpoint, and confirm the behavior you configured is the behavior you get.

The Integration Process Event also has a documented shape you can test against. By default it is Initiation, then a Service step that fires the integration. An outbound integration with approval puts an approval before the fire step and a document delivery step after it. For inbound, a document retrieval step comes before the fire step.

How do I test an inbound integration?

Load a small file and read the data back from where the business would see it. A status of Completed on the run is not the same as every row landing, so check the processed count and then open several of the loaded records. The EIB load errors guide shows how to read the run and its failures, and the test data guide shows how to build the spreadsheet.

Test the file you will actually receive in production, from the real source, if you can. A hand-made spreadsheet exercises your spreadsheet, not your partner's file.

How do I test security for each persona?

Test it in the same pass, role by role, not as a separate exercise later. For each persona in the chain, sign in through proxy and record two things: what they can see and do at their step, and what they must not be able to do. The second half is the one skipped most often.

For a Workday Extend app the same idea applies. Workday's documentation for WCP Development tenants says a proxy access policy specifies the non-Production environments it applies to, the security groups whose members have proxy access, and optionally groups that cannot have it. Create the policy before you need it, then open the deployed app as each persona.

How do I test an Extend app end to end?

Test the deployed app, not only the preview. Workday documents App Preview as a way to test page logic, and notes differences from a deployed app in areas such as security and time zones, so a preview pass does not prove the role behavior. The sequence in the Extend testing guide is validate, deploy to a Development tenant, run the flow per role in a browser, then read the saved records back through a report or query rather than trusting a success message.

Where an Extend app depends on a business process, the two tests meet. The process must complete before the app's next step becomes valid, so run them in one pass.

How do I re-test after a Workday release?

Run the same scripts again in a Sandbox Preview tenant. Per Workday's tenant datasheet, Sandbox Preview receives new feature updates ahead of Production and is refreshed twice a year, so it is the place to see what the next release does to your processes and integrations before it reaches Production. That only works if the end-to-end cases are written down and repeatable. The release preparation checklist gives a week-by-week plan for it.

Keep each script with its expected results: the process route, the approver at each step, the integration output file and the record you read back.

kiweely runs this kind of check against your tenant for Extend apps. It deploys the app, exercises it in a browser, and reads the saved record back from Workday, and it reports what it saw rather than that the build passed.