In our previous article, we introduced the five types of testing that every Kronos customer should know. Each of these Kronos testing types plays a vital role in an effective quality assurance program for your workforce management (WFM) initiative.
In this article, we’ll offer some high-level guidance and best practices on regression testing.
What is Regression Testing?
Regression testing ensures that a recent fix or change to a software product hasn’t affected previously working functionality. Traditionally, regression testing was an infrequent occurrence for WFM tools. For example, QA teams would conduct regression testing every few years when the business upgraded Workforce Central or when there was a significant policy, progress, or legislative change. With Workforce Central, the customer usually had control of the upgrade timeline so they could execute regression testing when it was convenient for the business.
Customers of today’s multi-tenant enterprise solutions require a more streamlined and faster approach that ensures they can move quickly without adding risk to their business. Workforce Dimensions systems are always up-to-date and secure, offering customers the best possible experience.
However, those updates happen in real-time, and that timeline is no longer fully under the control of Workforce Dimensions customers. That means you may need to do regression testing during an inconvenient time for your business (e.g., during a seasonal change freeze period) or at a challenging time for those responsible for maintaining these tools.
How to Approach Kronos Regression Testing
The Kronos Workforce Dimensions customer is responsible for verifying that any new software changes – whether they are new features, system updates, or even bug fixes made by the vendor – do not disrupt their unique system configurations or employee workflows.
During ‘business as usual’ operations, the business owner or systems administrator is responsible for regression testing. But regression testing might be handled by a project team if there’s an active initiative underway.
It’s imperative that regression testing occurs before every production change, including:
- New system releases
- Any changes to customer business processes or policies.
- When a new module or functionality is implemented.
- Before rollouts to new employee populations, locations, business units, or geographies.
We know that system upgrades happen in perpetuity. It’s a recurring event requiring a long-term efficient solution to lessen risk.
Pro Tip/Recommendation: Regression testing should be cost-effective, easy to perform, and part of your overall software governance and maintenance. Regression testing instills confidence and reduces the risk that the solution will negatively impact the organization. That’s why regression testing should always be part of your change control process.
You should perform regression testing in a non-production environment but with current production configurations in place.
As a cloud-based, multi-tenant SaaS application, Kronos Workforce Dimensions introduces the need for frequent regression testing, based on the release schedule. Click here to visit the Kronos Community to find out everything you need to know on Release Readiness for Workforce Dimensions.
Staying agile is the new business imperative. That makes regression testing more critical as the pace of change accelerates. Today, your customers want shorter and more frequent release cycles so they can respond more quickly to competitive and market influences.
In practical terms, this means doing more testing, more often, and within a limited window of time. This can put pressure on your QA team and heighten risk.
To put this into perspective, it takes roughly 167 hours to execute a regression test bed of just 1,000 tests manually. That’s more than four weeks of testing for a single resource. The problem is that the usual daily demands on the person’s time don’t stop; they must find a way to squeeze this effort on top of their existing busy workload. Plus, it takes more effort to enlist and train additional resources, especially when there is a narrow testing timeframe.
Thankfully, test automation from companies like TestAssure can remove this manual effort, reduce costs, and shrink timelines. With automation, you could complete those 1,000 tests in less than an hour. Tests are so easy to maintain and run in the TestAssure automated environment that many of our customers average testbeds of more than 5,000 cases.
The result is that customers catch defects before they hit production, which results in fewer incident tickets, reduced costs, and less frustration for everyone involved.
Getting Started with Kronos Regression Testing
The first step toward your regression testing timeline is to visit the Kronos Community to determine upcoming release schedules. After you instigate the regression tests, like other testing processes, always investigate any failures that occur. The next step is to raise any defects to the vendor or systems integration (SI) partner and then retest the case. As changes occur, maintain the test cases as appropriate. Your deliverables during this process include the regression test cases and a regression status report.
Best Practices for Kronos Regression Testing
It’s essential to update and maintain the regression test best with each system change. Unfortunately, we often see that the regression testbeds are abandoned or lost.
It’s also crucial to understand the coverage provided by the regression testbed to ensure it touches all of the modules and system functionality. Your team should continue to modify the regression testbed as part of your change control process and grow it over time as you introduce new features.
With the right approach, companies can leverage their regression testbeds as essential resources for documentation. Their testbeds are rigorously maintained and written in plain English to promote shared understanding. And they are an indispensable reference for company policies, workflows, and processes for business users. As a result, tests written in Behavior Driven Design (BDD) are gaining in popularity.
As we outlined in 5 Types of Testing that Every Kronos Customer is Responsible For,regression testing validates that a recent upgrade, update, or new feature will not adversely impact existing features or user populations.
Validating every release or update to production is critical to ensuring that any changes don’t adversely impact your employees and customers.
Manual regression testing is time-consuming and requires the full attention of your QA team and SMEs. But testing automation from TestAssure can cut the time and costs of manual testing to help reduce these burdens.
We can help if you’re implementing a new Kronos workforce management system, upgrading to a new version, or releasing business-driven changes.
TestAssure is committed to providing Kronos customers with test strategy, planning, and automation to help you minimize the impact of your system changes, reduce your risks, and help you move faster with confidence.
Contact us today for a test drive.