INTRODUCTION
Organisations across different industries have become interested in Workday and the benefits of a more centralised employee data management system. A particular module that has gained interest as of late is Workday Human Capital Management (HCM). As Workday HCM involves a large amount of data to manage, most companies rely on the flexibility of the components available to tailor fit each of their unique requirements. Testing Workday for the first time bids curiosity on how things work just as with any other application/system, but it also presents insights on how different it is in testing applications in general.
This article focuses on testing the Human Capital Management suite of Workday. We aim to provide an overview on:
- the core functionalities to test
- how testing can be managed in general
- the challenges encountered and
- interesting learnings from the actual testing done.
While there are differences in some degree between Workday in different organisations, the following are common requirements and scenarios within the HCM area.
Testing Core HCM Functionalities
On its own, rendering employee data in Workday - Human Capital Management requires validating swathes of data. When viewing the profile of an employee in Workday (i.e., personal data, job profile, organisation, compensation details, and so on), information is consolidated and considered when designing the test.
During System Integration Testing, variation on the test data set for employee type, organisation, job type can be added as variation to the datasets. All possible data groups would need to be tested to make sure that the various data types are recognised between different systems. This is especially true when the source of data is fed from a different system integrated with Workday.
When adding a new employee to the organisation, for example, where a set of data is created and sent through integration, their data could be validated in the employee profile page. How this set of data is displayed and how much information is shared would depend on the business requirements and which specific roles have access to view certain amounts of employee data.
Since Workday has a set of flexible and interactive UI elements that can be customised, validation is easy between screens and pages. It is important to explore the application and check the different sections and tabs available to confirm which screens and pages are relevant to a specific scenario, as it is possible that the same data will be available in multiple areas of the application.
The same considerations can be applied when testing a scenario where an employee needs to be removed in the system for Termination and Resignation, which should be the absence and/or that proper tagging of the employee record as Resigned/Terminated.
Testing Dashboards and Reports
This same set of data is used to generate reports. The same goes to the Dashboards. Testing the Dashboard would mostly show how the sections and tabs would look like, availability of report links and specific set of data and notifications designed for the user role in the organisation. Below is a sample view of a Dashboard
from Workday site.
In testing Reports, aside from the structure, type, completeness of the information and other general validation points for reports, one should also consider what triggers the changes in the content, how and when these changes are expected to be available in the report. Depending on the requirements, these changes should be reflected accurately when the report is generated again.
Testing Configured Workflow
Workday works with a set of business process frameworks to perform core transactions such as Onboarding, Reorganisation, and Job Change. The different transactions work based on conditional logic, which in the case of HCM, depends on the role who is initiating the transaction. Along the process, certain stages will require other roles for the whole process to be completed. Testing this area involves the combination of different data types and security access as Workflows are sometimes restricted to a certain group in the organisation.
One common scenario is testing the changes to the profile of an existing employee in Workday, for example a promotion or a transfer of an employee to a new position. This change in the employee’s profile would involve approval from different persons in a different role. Therefore, the test would need to cover the in between approval for the whole process to complete and would require switching between different users when doing the test. Testing would also need to cover the verification where the set of mandatory tasks are triggered within a specific Workflow. Depending on the user role, one Workflow skips certain tasks which are otherwise needed for a different user with different security group who initiated the business process.
Example of one business process where it is possible to have different set of Workflow depending on who initiated the transaction.
Example of one business process where it is possible to have different set of Workflow depending on who initiated the transaction
Testing Tasks within a Workflow
Related to the configured workflow testing, part of the automated business process are multiple individual tasks that needs to be completed in a logical manner. Testing involves the verification that the logical stages of the process - routing to the correct users of each tasks/stage, documents are generated (when required) and sometimes notifications should be validated as per the design and requirements. Testing these scenarios are tricky and long as this would need to cover the variation on the user roles and security groups that have access to the same specific Workflow are granted only to those applicable.
Testing Security Access to Workflow, Dashboards, Reports
As mentioned above, business processes are restricted to be used by a specific role or groups only. Negative testing should be given the same weight when doing testing around this requirement to make sure that controls are in place in using critical business process/transactions. When an unauthorised user attempts to initiate a business process, testing should see evidence of restriction like an error message or totally not display at all depending on the defined requirements. The same for Dashboards and Reports. Another aspect to include in testing is the different level of access for different users to Reports and shared Dashboards when applicable.
Challenges and Insights when Testing Workday - HCM
The lengthy validation steps in testing one business process were one of the challenges while doing the testing. Coupled with the incorporation of the access restrictions to the condition based on roles, complicates even further the test design process. One business process could include five individual tasks on average with multiple validation points each.
It was also a challenge to consolidate multiple employee type, roles, organisation and incorporate it in the test case creation to cover the scope effectively without ending up with unnecessary exhaustive set of test cases. Moreover, the actual testing could involve going through different users for one business process to complete and that alone would mean that during testing, a tester would need three or more users to complete one scenario.
Another challenge that can be expected is the creation of test data. Creating an employee would need a set of at least ten or more data points and would have to go through multiple steps and screens to complete one.
There are, however, functionalities in Workday which could help make testing a streamlined process.
- One is the EIB (Enterprise Interface Builder) framework used to upload data into Workday in bulk. Workday provides spreadsheet import templates that offer immediate business value by helping you upload data into Workday. You can generate templates directly in Workday. Each spreadsheet template is based on a template model that defines the column information for upload. To simplify data entry and streamline the upload process, you can edit the template model to fit your needs. For example, you can override column values, provide your own labels, and cell comments, reorder worksheets, and hide unwanted items to customise the template for a specific purpose. Inbound EIB is an Excel front-end to WWS. While it makes it easier for non-technical users to load bulk data into Workday. This functionality could answer the challenges on creating test data, eliminating the need to go through all the screens in Workday.
- Another functionality is the use of ‘Proxy’. Majority of the scenarios as mentioned in the previous sections would require different user roles to fulfill and complete the business process flow. This function not only minimises the need to set up additional test users for each tester, but it also makes it possible to efficiently change between users during testing. It therefore provides continuity on the flow of testing without requiring to login or logout of the application which would be a good candidate for test automation.
- Global search, though common, is very handy in terms of finding the business process or transaction to perform. You can enter just a part of the transaction name and Workday will display relevant results. With these functionalities it would somehow trim down some of the testing processes which has multiple tasks and stages.
These functionalities allow you to fully automate tedious manual tests. This in turn can save time in completing long test scripts which could also be run repeatedly as defects are uncovered across the different test phase in software development. Carefully designed test cases can be reused for Regression testing, Smoke testing, and End-to-End test cases. If both the test data creation and actual testing are automated, you will be able to quickly report bugs on instances when a new version of the application is introduced.
Partnering with a test provider who is adept in analysing and designing test sets which are accurately scoped and efficient to support the amount of test to cover is crucial. Said test provider could also help create an easy to maintain test suite to easily keep up with any changing requirements.
CONCLUSION
In summary, testing Workday involves a lot of processes and a lot of different data types. It can be very overwhelming especially when testing Workday for the first time. But it is important to always note and understand the core Workflow and functionalities combined with an understanding of the business perspective and work through the different data types which drives the variation on the tasks triggered in a business process.
Workday as an application offers a comprehensive suite of products designed to streamline HR, finance, and planning processes within organisations. Its user-friendly interface, robust analytics capabilities, and seamless integration features empower businesses to make data-driven decisions and enhance operational efficiency. As organisations continue to adapt to changing market demands, leveraging Workday's innovative solutions can drive strategic growth and improve employee engagement. These characteristics can also be used as leverage in doing testing for Workday.
To learn more on how to be strategic in doing testing, feel free to reach out on our contact page.
To learn more about our Workday services, visit our Workday page.