Workday testing — How it differs from traditional ERP projects
Workday is different, so it stands to reason that testing is different 3 as well.
The Workday deployment approach has a phase called “Test”. Clients are responsible for testing, with input from their deployment partner on the testing strategy.
In the legacy ERP (Enterprise Resource Planning) world, you install your version of your application on your own web servers. You after that are accountable for patching code repairs as well as keeping the application updated. The first thing you require to do is test each and every single page for pests and also concerns.
The awesome fact about Workday is that it is a unified system and all customers get on the exact same version and also the same code. Workday has a huge army of quality control testers that are frequently examining the application to guarantee that there are no bugs.
Along with Workday’s QA (quality control) teams, you have the whole ecosystem of clients using or implementing the same version of the code at any point. So if someone does find a bug, it gets logged quite promptly.
In Workday, you can flip your testing approach on its head.
Your testing method must be written during the strategy phase of the project and testing manuscripts should be put together as early as possible. Take advantage of the configure & prototype stage to complete your initial wave of testing and document your testing manuscripts, to ensure that you have proof of every one of your testing.
You should take a look at automated testing tools where your budget allows. Automating testing implies that you can regression test that much quicker during your implementation, and in Production when the Workday updates come down the pike.
Your testing approach should be security-focused. 80% of your post-production issues are typically security related. “I can’t see this”, “I need to do this task” etc. Define your target operating model and maintain it as lean as possible, within the constraints of duty-based access control policies, SOX, data security, etc. The more security roles you define, the more maintenance in your future.
You need to align all your testing to the various Role-Based and User-Based security groups that will certainly be utilized in your target operating version. Obtain all your job streams to pull together their checklists of security Roles and User-Based Security Groups.
Ensure that you have a cross-practical workstream conference to line up security roles and user-based security teams for your target operating models.
As an example of using the configure & prototype model to test, when you are doing co-configuration sessions and you develop a new Job Profile, effectively you have examined that you can produce Job Profiles. Take it a step better and visit various roles, to ensure that only the authorized customers, e.g. those assigned as the Work & Placement Manager, can include a Task Profile. Currently, you don’t require to trouble retesting Work Account production throughout your examination phase.
Want to Boost Your Skills? Visit Our Website To Learn From Our Industry Experts
Your emphasis should be on:
- Navigation & search — are landing pages configure properly; do the organization graphs look all right?;
- Security — that can see what data; is each role seeing the correct workouts, dashboards, and tasks; can they execute their business procedure transactions; can they run their reports/integrations?
- Data — is the data loaded appropriately; does the converted data behave properly in reports once you begin transacting; is data missing out on?
- Business Process Flows — does the process flow practically; are steps entering properly; do problem rules & guidelines-based meanings work all right; hold-up steps, integration steps, report steps, and to-dos — are they all firing properly?
- Integrations — who can run them; do the file layouts match the specification documents; is connectivity developed;
- Reports — are your customized reports developed; do they pull back the proper data; do the ideal security roles have accessibility to them; do we have way too many Workday granted reports noticeable & should we hide some?
Be clear regarding your stage entry & exit requirements prior to your entering & exit each Workday stage.
Ideally, by the final thought of the configure & prototype phase:
- System Designed & configured up to 80% at least: all major design decisions are signed off and the Workday Partners have configured your design. You have run through the process flows across all work streams and with each other as a project team. Feel free to engage end-users to validate your project team assumptions.
- Data Validated: you want to have your data recognition completed in your Workday tenant. Before you begin doing anything in a Workday tenant have all workstream leads sign off that the data has been moved correctly, consisting of configuration and transactional information. Take care of all data problems, before testing.
- Security configured: check your security roles and User-Based Security, Groups. Ensure that Roles are assigned to the right hierarchies and who can complete business procedure transactions, see data and run reports- before beginning end-to-end testing.
- Setup Tasks completed: your configuration and maintenance testing are finished.
- Integrations built & unit examined: Most of your essential integrations should be built and unit tested and be ready for an end to end testing. Without integrations, it is not end-to-end testing, it merely ends to …
You can then concentrate your testing phase on confirming your target operating model, completing your end-to-end testing manuscripts, and testing how data is flowing incoming and out of Workday by means of Integration systems. Once finish to finish is finished, you are onto parallel runs (where payroll remains in play) training end-users, customer approval testing, and also planning for the cut-over to Manufacturing.
End-to-end testing should consist of all work streams working through test scripts that imitate the target operating version. Walkthrough of a new hire does Payroll get alerted and can they finish their tasks? Does onboarding fire correctly and can the pre-employee complete their pre-employment paperwork and so on
You want to avoid major design decision modifications or scope improvements in your test phase and focus on ensuring that the system is benefiting your target operating model and feeding downstream systems accurately.
Do not rush to build the testing Workday tenant. The testing Workday tenant should be as close to your Production system as possible and the build must be dealt with as a rehearsal for the Pre-Production occupant build.
When you know your data and security are excellent, your process flows show your target operating model and your integrations are working appropriately, you can be certain of a successful go-live.
Bottomline
Our Workday testing article is a great area to get going when it comes to learning more about the power of Workday testing. Also, if you want to learn more, we are here to help you.
At ZaranTech we offer self-paced online training on Workday-related topics. To learn more about our courses, feel free to visit our website.
Get any Workday video course — https://zarantech.teachable.com/courses/category/workday
Join Workday Learner Community on Linkedin — https://www.linkedin.com/showcase/workday-learner-community
In the end, as always, thanks for reading, and stay sound and safe!
These are the related articles that you can check
