The T.E.S.T.I.N.G. Framework: Your Roadmap to Workday Student Readiness

Implementing Workday Student is a major investment—and one that deserves an equally rigorous approach to testing. Why? Because smart, strategic testing doesn’t just prevent costly issues down the line—it trains your team, accelerates campus adoption, and ensures your system works the way your institution needs it to. In other words, T.E.S.T.I.N.G. matters. But where do you begin? Start here—with a framework designed to help you get the most out of your Workday Student deployment:

Touchstone, Ensemble, Scope, Tenant, Instance, Nitty gritty, and Going forward.

Touchstone – Why are you testing?

Testing is the only way to ensure your configurations, integrations, reports, and security are working as intended. It’s embedded in Workday’s deployment methodology and plays a critical role throughout every phase of implementation. But testing doesn’t end at go-live—it’s an ongoing necessity.

Whether administrators are making changes or Workday is releasing fixes, consistent testing is essential. And twice a year, Workday delivers major feature releases that require every organization to test thoroughly. Without it, new features could disrupt operations in your production tenant. Staying proactive with testing helps you avoid surprises and maintain stability across your environment.

Ensemble – Who is involved?

Tear down the silos because Workday Student is a cross-functional system that requires input from and collaboration between every office on campus to implement and use successfully.

Let’s look at a common example: It’s the middle of the academic period and a student needs to take a leave of absence. This one enrollment status change requires institutions to assemble representation from student affairs, academic affairs, records, billing, financial aid, residential life, dining, security, and institutional reporting (to name a few) to determine the policies, configure the system, and test to ensure it works as desired (and can be reported correctly). Just getting the meetings scheduled is a challenge let alone developing and executing a testing plan.

As you can see, even a single student status change can ripple across nearly every department. That’s why testing in Workday Student isn’t just a technical task—it’s a highly collaborative effort that requires coordination, planning, and campus-wide participation.

To make testing successful (and sustainable), here are some proven tips and strategies that will help your institution test smarter and work better—together:

• Hire a testing coordinator during implementation and keep that role permanently.
  • Coordinating testing is a body of work that should not be tacked onto an existing job. It’s a whole job unto itself.
  • The right person for the job is someone already familiar with your culture and campus so they know who to invite and where to host the gatherings.
• Get everyone in the same (virtual) room and test together.
  • “Everyone” means representation from every team involved in the testing scenarios.
  • Scheduling tips:
    • Make every testing meeting hybrid (in-person and virtual options) to allow for maximum attendance.
    • Schedule testing meetings month in advance and pre-plan an actionable agenda.
    • Keep testing meetings on the books after implementation ends, because testing doesn’t.
  • Use proxy to test from every perspective—it’s your best friend in Workday.
    • No, proxy isn’t allowed in production, but you should never test in production anyway.
    • Familiarize yourself with your institution’s proxy policy—there may be some roles such as those with elevated security with proxy limitations.
    • Proxying tips:
      • You can keep using “Start Proxy,” you don’t have to “Stop Proxy” in between.
      • Already on the person’s profile? Use the related actions button > security profile > start proxy to jump right into acting as that person.

Scope – What are you testing?

Every testing meeting should have an agenda. That may be an unpopular opinion, but everyone participating in a testing session needs to know exactly why they’re there, what’s expected of them, and what the goal is. If attendees know the answers to the following questions before the session, or can at least reference it while everyone is getting settled in, they can spend the meeting time actually testing.

• What are the actual scenarios, example students and situations, and personas?
  • Tip: this drives who should be in attendance.
• Who is “driving” during the meeting, sharing their screen, and executing the steps?
• Who has the instructions? Who is responsible for documenting the process?
• Who is taking notes? Who is logging bugs?
• What does success look like at the end of the testing session?

Tenant – Where are you testing?

Never test in production. In fact, never do anything for the first time in production. Instead, use a testing tenant (a specific instance/environment of your Workday Student configuration and data). But which one?

Picking the right tenant to test in is especially crucial during implementation because you’ll have multiple different tenants with similar names and varying stages of configuration in each of them. So make sure everyone in the testing session knows which tenant to log into (and that everyone has the proper security and login credentials in place).

After go-live, your go-to testing tenants are Sandbox (aptly named for the place where you can play) and Sandbox Preview (where you play with the new stuff Workday is releasing or longer-term projects).

• Anything you do in Sandbox will be wiped out almost every weekend when Workday “refreshes” the environment, such as copying your production tenant over to Sandbox.
  • Tip: don’t lose your work. Take lots of screenshots and notes and prepare to re-configure Sandbox on Monday mornings to resume testing.
• If you need several weeks to test something, consider using Sandbox Preview, but beware that there may be new features at play and that twice a year Workday will refresh that environment with your production data and a slew of new features, fixes, and retired elements.

Instance – When are you testing?

After selecting the tenant, you need to pick your academic period for testing. Workday is a point-in-time system. Everything is as of now which can present particular challenges for higher education since we often need to look backwards and forwards to compare data and to be able to test upcoming processes. Testing coordinators can’t do this part alone, they need the subject matter expert’s advice.

To avoid surprises and make sure your test scenarios are meaningful and accurate, there are several critical considerations when selecting and preparing your academic period for testing. Here’s what to keep in mind:

• Determine the test academic period in advance.
  • You can’t test academic standing without having grades entered. To prevent testing delays and last minute scrambling, identify the dependent processes in advance and ensure the period you select is fully enabled to execute the test.
  • There is likely prep work needed in the academic period (or in the particular records you’re using as samples) and that work needs to be called out as a prerequisite to the testing session or something that needs to happen at the beginning of the meeting.
• Always check your academic period date controls before testing.
  • Maintain academic period data controls = the gatekeeper.
    • Testing instructor ability to assign grades? It won’t work if the “Final Grading Start” date isn’t current or if the “Final Grading End” date is in the past.
    • Tip: keep in mind that academic period date controls are set per Academic Unit and Academic Level, so you might need to check multiple combinations.
• Don’t test with only converted/legacy data.
  • Course section reports, as an example, may render perfectly with converted data but not with new sections you create in Workday. Make sure to test each report (and each process) with both legacy and newly generated data.
  • This is primarily applicable during implementation, but also for the first few years of using the system.

Nitty Gritty – How are you testing?

Your training coordinator pulls it all together, but your subject matter experts are the only ones who know the policies and data well enough to design the test scenarios and identify examples for each one. Yes, you likely have many people on campus with the skills to pull reports from your legacy systems, but only someone like your registrar will be able to identify the edge cases and exceptions. The latter being one thing every institution of higher education has in common: exceptions to the rules.

To build realistic and comprehensive test scenarios, your subject matter experts need to dig into the data—especially the exceptions—and surface real-world examples from your legacy system. These examples form the foundation of effective testing in Workday Student. Here’s how to do it right and set yourself up for long-term success:

• During implementation, use your legacy system to find the examples.
  • You’ll need students from every recruiting region, applicant type, program of study, class standing, academic standing, enrollment status, athletic team;
  • And faculty from every college, department, rank, instructor type, advisor role;
  • And course sections from every academic period, department, combination of instructional formats and course tags and section fees, that fulfill every academic requirement, are taught in every campus location, and represent every bespoke process at your institution.
    • Some of those terms are specific to Workday, such as program of study, so you’ll need to understand the jargon to be able to cross-walk the values back to your legacy data.
    • Keep updating this list after go-live to facilitate rapid testing as fixes and releases come out.
  • Use your documentation while testing. If none exists, write it as you test.
    • Spoiler alert—most implementation partners help with job aids for end-users like students and faculty, but they typically leave the administrative documentation to the client. If you want your registrar’s staff to know how to do their jobs at go-live, then document the steps as you test.
  • Training coordinators should designate a central (and secure) digital location to store testing scenarios, example data, and notes that everyone involved with supporting Workday testing can access and easily navigate.
    • Tip: create templates at the beginning of implementation for the scenarios, examples, and notes that can be used and referenced for years to come.

Going Forward – What happens next?

Congratulations, you did all the prep work and successfully executed your testing plan! Now what?

To keep momentum and accountability high, you need a clear plan for what happens next. Here’s a list of tasks to align on:

• Training coordinators shine in the “what happens next” space because they (should) already have methods in place for scheduling additional internal or external meetings, but they can’t schedule something they don’t know needs to happen.
• Before you ever start testing, decide:
  • how the results will be communicated to those not in the testing meeting;
  • who handles action steps and ensures they are done;
  • who takes the lead on reaching out and scheduling additional conversations;
  • how much detail your project management, advisory committees, and executive sponsors need to know;
  • and how you’re tracking all of this iterative work.
• After deciding, make sure it is clear who does what.

Don’t think you have time to test? Make time for it now or it’ll take more of your time later.

Not sure where to start or want help developing templates or designing testing sessions? Kognitiv’s experienced Workday Student consultants love T.E.S.T.I.N.G. and can help your institution assess your testing-readiness and develop a plan now that will save you time later.

Contact us to learn more.