‘When all bets are off’ -- an expression meaning a situation in which one factor alone can change or cancel out everything. *
A few months ago my family adopted Duke, a 10-pound canine combination of fur and attitude. Duke has diabetes and requires an insulin shot twice a day. To validate he is on the best insulin dosage, we scheduled him at the vet for blood sugar testing. Duke was to eat breakfast and have his morning shot at home, then hang out at Dr. Heather’s office for 8 hours without eating, while undergoing the blood sugar tests, at specific times.
Unfortunately, Dr. Heather found during the first test that his blood sugar count was very low. So low that she needed to deviate from the test plan and feed him immediately. Later that morning another test was run, and Duke’s reading showed improvement.
But by this time Dr. Heather had determined that ‘all bets were off’ for him to successfully complete testing as originally planned. We would have to reschedule and run the test series again, on another day…
Determining ‘all bets are off’ Testing situations:
Part of good Kronos implementation or upgrade test planning requires that you establish the factors or scenarios you could encounter that are significant enough, and that would cancel out the probability of success for your test run.
What pieces of your parallel testing process are at risk for this? It could depend on how many parallels you have planned for the project. Ex: Parallel #1 is scheduled, where the team is performing unit, integration and system testing. The employee demographic interface is run with non-current data.
-
What is the intent of testing the EE demographic interface in Parallel #1? Is it to validate only the mechanics of the interface?
-
Or are you testing both the mechanics and the correctness of all the data being passed in the interface?
Now compare to Parallel #3, your final validation before going live. Where everything needs to be golden. The configuration must work as planned, and the data has to be current.
Perhaps you are leading a project with a phased rollout in a single instance? Site A just went live, with site B onboarding next week, and other sites to follow. The team is developing their regression test plan to validate that adding B’s code doesn’t break A’s code, confirming that A and B can co-exist together. As this is your first time adding another site, you are also developing and testing your process for onboarding a new site as well.
Do you have constraints that limit what times and/or days of the week where you can schedule an outage to perform the onboarding and testing for site B? Ex: Your Kronos system shutdown can only be for 8 hours during Wednesday, during daytime hours, so it doesn’t disrupt operations for both sites. Knowing this limit, you schedule to onboard site B and regression test next Wednesday starting at 8am. You’ve designed your test plan to have the team measure results at noon, which is 4 hours into the testing window. You review what’s been completed, what’s left to get done, and evaluate: can we get the balance of testing done in the remaining 4 hours?
Advice and Best Practices:
-
Begin test planning and discussions early enough prior to testing startup, so your Kronos implementation test team can reach agreement on what situations would make them pause testing and start over. Define the show-stoppers.
-
When the ‘all bets are off’ call is made by the team, honor the reality of the situation. Testers may experience frustration, but help everyone to remember that pausing and restarting is doing the right thing in order for them to deliver a quality project.
-
Per your project communication plan, provide testing status updates at the appropriate times: updates for your project teams, for the system users, and for leadership.
-
Then clear the decks, and schedule the re-start of testing.
How do you plan for ‘all bets are off’ situations in your Kronos testing? Good luck testing!
* - Definition from the Urban Dictionary
Comments