A passing build is not a passing user journey
Workday source validation tells you whether Workday accepts the component definitions it checked. A successful build tells you that App Hub compiled a captured package. Neither one proves that a deployed page loads for the intended role, follows the right navigation, saves the right record or explains a failure clearly.
Treat each layer as separate evidence: source validation, build and deployment, browser behavior, tenant-data readback, role and security behavior, orchestration steps, and application logs. A complete test says which of those it covered and which it did not.
Choose preview, mock data or a deployed tenant deliberately
App Preview is fast for page logic and layout. With mock responses, it can exercise different endpoint shapes without touching a tenant. Connected preview can call real tenant and external endpoints, which means it can also change real data. Workday documents behavior differences in preview, including security, timezone and component limitations.
Use a deployed Development, Implementation or Sandbox app when the question depends on real navigation, identity, proxy behavior, security, tenant configuration or saved records. State the environment in the test record; never let a convenient preview stand in for the deployed flow you were asked to prove.
Start from a named target and a known baseline
- Confirm the tenant, served app version, signed-in identity and proxy identity.
- Choose a record whose starting state is known and safe to change.
- Record every value the test will enter and the result it should create.
- Confirm which related records must remain unchanged.
- Define cleanup or say that controlled test data will remain.
This separates a real product failure from an old deployed version, the wrong role, existing data or an unfinished earlier test. It also makes the result reproducible without exposing a customer's records in screenshots or notes.
Test the whole flow, including the quiet failures
Follow the job the person actually performs: open the task, load the data, enter values, trigger validation, confirm or cancel, save, navigate onward, reopen the result and run the report or downstream step that consumes it. Include at least one invalid or interrupted path, not only the happy path.
Some of the most important defects sit between visible moments. A save can succeed while the return route opens an error page. A button can exist but remain hidden until another control changes. A report can eventually load while offering no feedback that its action started. Check the state after the click instead of judging the click alone.
Read the result back independently
A success message is not the record. Reopen the saved object, query the created data or use the Workday report that owns the result. Compare every material value with the test inputs, confirm ownership and status, and verify that unrelated records did not change.
If the page failed after sending the request, readback decides whether the operation failed, succeeded once or reached a partial state. Do not repeat a write merely because the browser did not navigate where expected.
Check the intended roles, then use logs for the cause
Test as each role that sees a different page, action or population. Confirm both positive access and the important denial cases. Keep proxy identity explicit and end the proxy when the check is finished so the next test does not inherit it accidentally.
Application logs can identify page-script errors, endpoint failures and orchestration messages. Correlate them with the exact action, time, page and version. A quiet log does not prove the journey worked; it means only that the available log search did not explain the observed behavior.
Finish with an evidence ledger, not a verdict word
Record the target, identity, version, starting state, actions, browser observations, readback, logs and cleanup. Separate Passed, Failed and Not tested. When one defect is repaired, repeat the smallest test that reproduces it, then inspect related paths only after the mechanism is confirmed.
kiweely follows this loop in a browser you can watch: Workday validates the source, the agent uses the deployed app, reads the resulting state and reports what remains untested. For errors before the browser opens, continue with Workday Extend validation errors or Workday Orchestrate errors.