How to Launch a Successful Kronos Test Plan

Editor's note: This is Pt. II of how to set up a successful Kronos Testing Phase. Read Part I, here.

In last week's blog we discussed the three testing methods best to test your new Kronos software upgrade before taking it enterprisewide. Whether you choose Agile, Waterfall, or a Custom testing plan, your actual Testing Process needs to include key elements to ensure a smooth go-live event.Testing a new Kronos product, upgrade, or service pack — be it Workforce Central (WFC), Workforce Ready (WFR), or Workforce Dimensions — is a critical step in the go-live process. Kronos describes this step best as a formal plan that outlines “. . .the strategy, resources, processes, tasks, and schedules involved in making sure that your workforce management system meets your established business requirements and acceptance criteria.”

Take shortcuts in your Testing Plan and you can easily compromise the success of your rollout, user adoption, and your project’s ROI. Hopefully, you added Change Management as part of your initial Kronos implementation plan/budge to address potential employee resistance to adopting the new technology after you go-live.

Note: Every testing plan will vary depending on what version of WFC or module of WFR you are upgrading from, what changed in your processes, and what extra modules your version may have such as mobile apps, Attendance, Advanced Scheduler, and HR, among others.

Steps to Success

1. Start early. Begin Test Planning discussions early in your project, so your Kronos implementation test team can reach agreement on what situations would make them pause testing and start over. Define the show-stoppers.

2. Appoint a testing team. Identifying power or super users from key departments to be part of your testing is the first, most crucial step in testing.

3. Communicate consistently. Provide testing status updates at the appropriate times. This includes updates for your project teams, for the system users, and for leadership.

4. Determine entry and exit criteria. Understanding your criteria (goals of testing) will help you define the scope, depth, and duration needed for training. This will vary with every upgrade and every team. Your testing datasheet — be it a high-end tracking software or excel — should help you track different issues, so you have an aerial view of potential system issues that need to be fixed. 

Testing data should include:

• What action to take when a tester finds an issue

• How to input the problem (how much detail to add, where to log the issue)

• How to prioritize the issues logged

• Who is responsible for gathering, analyzing, prioritizing each problem item

• What department or person is responsible for fixing each type of issue

• A schedule for testing meetings/milestones before your go-live

Access the relevant data. Your Testing Plan should identify the necessary data for each test case, the data source, and the person responsible for making the data available in your testing environment. Relevant data will vary depending on the work environment.

Document everything. A Testing Plan is the framework of your entire testing process. Record the details, review the plan with your rollout team, and archive it to reference for future WFM upgrades. 

Be positive and thorough. Testers may experience frustration but encourage everyone to remember that pausing to test and even re-test is doing the right thing and will allow the team to deliver a quality product to the rest of the company.

Test Plan Outline

• Testing Overview
  What Kronos products are we testing, and what are the outcomes attached to the project?

• Testing Objectives
  What are the goals for testing effort? 

• Testing Scope
  What are the items that are in scope/out of scope for testing? What types of testing will be performed? 

• Schedule
  What testing activities, resources, and days are available for testing? How will this affect the current workload, holidays, go-live?

• Testing Environment
  What environments will be using for testing (browsers, Java/Flash, software versions, etc.?

• Data Requirements
  What data is required, who is responsible for supplying it?

• Roles and Responsibilities in Testing
  Sample chart should outline Test Plan roles such as project sponsor, project manager, gatekeeper, test lead, and testers. 

• Testing Activities and Tools
  How will testers receive assignments (daily or weekly), where will testing take place, what will the input document be, and how will results be logged (pass, fail, etc.)? 

• Testing Reporting and Metrics
  How will progress be reported to the overall project team? What does success look like, and what are our daily, weekly goals? 

• Reporting and Tracking Fixes
  How will issues be recorded (screenshots, written steps, etc.)

• Acceptance, Entry, and Exit Criteria

  • Have we recorded all acceptance, entry, and exit criteria (tasks)?

  • Have all high priority issues have been identified and resolved?

  • Have all application design functions been thoroughly tested?

  • Have all development items been tested and validated by the development team?

• Risks and Contingency Plan
  Have we identified all project risks and a plan for managing them?

This outline gives you a potential approach that helps you envision the scope of what's required in the testing phase. Every Testing Plan will differ depending on your unique work environment and requirements. Your end goal of Testing is to identify any issues that may affect the quality of your end-user experience. A plan will uncover and resolve critical issues such as labor data processing reporting and configuration flaws that could derail your project’s go-live date and, its long-term success. 

~ ~ ~