Project Meetings
The End-to-End (E2E) Testing Kickoff is a project-wide session that introduces the objectives, scope, and approach for Workday E2E testing, including key processes (e.g., hire–to–pay, procure–to–pay, recruit–to–onboard) and integrations.
Attendees:
All project team members
E2E testers
Meeting Purpose:
To confirm that end-to-end business processes, data, and integrations work together in Workday the way the organization intends to operate at go‑live, not just in isolated steps.
Timing:
Test Stage
Change Management Value-Add
Why This Matters for Change Management:
CM participation is key to planning end-user involvement, aligning communications, and preparing readiness materials for testers and end-users.
E2E testing allows you to experience the actual "Day-in-the-Life" experience for end-users.
It’s where you validate if the self-service scenarios you’ve been promising are actually intuitive or if they’re going to require heavy-duty training.
Questions to Ask Yourself
Expand each section below:
-
Watch the Employee Self-Service (ESS) and Manager Self-Service (MSS) scenarios closely.
Do they feel "natural," or are there too many clicks?
-
Where does one user’s job end and another’s begin? (e.g., After a Manager clicks "Submit," does the Recruiter know exactly what to do next?).
-
Are users being spammed with too many Workday notifications, or are they missing critical tasks? (This is a huge factor in Day 1 user sentiment).
-
Are there "real world" situations missing from the scripts? (e.g., "What happens if a manager is on leave while an employee tries to submit time off?").
Preparing for the Meeting
End-to-End Testing formally launches the Test phase where full, cross-functional “day in the life” business processes are tested in the configured Workday tenant.
Watch (5:39)
This video shows you why the end-to-end testing cycle is actually your most underrated change management superpower.
Self-Service ‘DITL’ Test Scenarios
These end-to-end test scenarios are designed as realistic “day-in-the-life” workflows that mirror how managers, employees, and back-office teams will actually use the new system. They’re ideal for testers, who want to validate business processes, spot human friction points, and harvest insights to refine training, communications, and support materials before go-live.
Key Points
1. Validate and Refine Your Change Impact Assessment
E2E testing is one of the best opportunities to pressure-test your change impact analysis. As you watch workflows play out end-to-end, ask yourself whether the impacts you've documented for specific roles still hold true. New impacts often surface during testing — a manager approval step that wasn't anticipated, a role that touches more transactions than originally scoped — and catching these before go-live keeps your readiness plan accurate and credible.
Observe end‑to‑end workflows (e.g., hire‑to‑pay, performance‑to‑comp) and document where roles, handoffs, and decision rights differ from today’s process.
Use issues uncovered in testing (gaps, workarounds, added steps) to refine the change impact assessment, risk log, and targeted interventions for specific stakeholder groups.
Capture which policies or process steps are new or enforced differently in Workday, then feed that into your impact assessment and stakeholder analysis by role, location, or population.
2. Shape training content and practice scenarios
Treat each test script as a potential training scenario, especially “day-in-the-life” chains like hire–onboard–time entry–payroll.
Mark which E2E scripts should become hands-on exercises for end-user training, and where you need simplified, role-based variants.
Identify complex or error-prone steps and flag them for job aids, quick-reference guides, or short demos that mirror the tested workflow.
Capture specific moments where the system behaves differently than users expect — terminology mismatches, unfamiliar approval flows, or multi-step processes that feel counterintuitive.
3. Capture voice of the user to refine communications
Listen for spontaneous feedback (“this is easier,” “this is confusing”) and turn it into concrete messages about benefits, trade‑offs, and behavior changes.
Turn frequently asked questions and misconceptions raised in testing into FAQs, talking points for managers, and targeted communications by role or region.
Capture common questions and misconceptions as input to FAQs, manager talking points, and targeted communications by audience.
4. Advocate design and process tweaks that reduce adoption risk
Use patterns from E2E defects and confusion (e.g., unclear labels, complex approvals, security/role issues) to recommend small configuration or process changes that make adoption easier.
When you see repeated confusion, log it as both a usability risk and a change risk, bringing concrete examples to design and governance forums.
Suggest quick wins like clearer field labels, streamlined approval paths, or improved in-system help where they materially reduce learning curve and support future adoption.
5. Build Relationships with Process Owners and SMEs
Testing sessions put functional leads, SMEs, and business process owners in the same room. Use this time to strengthen those relationships.
A quick debrief conversation after a session — "What surprised you most today?" — can surface concerns that wouldn't come up in a formal status meeting.
These stakeholders are also your future training champions and communication validators, so the trust you build here pays dividends through hypercare.