I'm going to get on my soap box here for a moment. Bear with me.
When you go live with a huge new system or huge new set of changes like this to a major application such as
MDE, there are different types of testing required. For example:
- Testing the overall load of web users hitting the web app all at once. This can be done in a simulated way...to mimic tens of thousands of users all clicking the same buttons at the same time to try to get to the new park reservation part of MDE.
- Testing various iterations of non-AP users - For example, option #1 might be where all the people in the reservation are staying in ONE resort hotel room and everybody ONLY has regular tickets. No AP people. #2 - regular ticket holders but people in multiple hotel rooms under different reservation #s but their tickets are all linked. #3 - User accidentally clicks the check box for child <age 3, so they should have set up an automated error message telling the user what to do instead. #4 - Everyone has regular tickets and all tickets are the same # of days. #5 - All regular tickets, but variations on # of days on those tickets. #6 - All regular tickets, but they're 14 day tickets and user wants to schedule the park days over a month, not over 14 consecutive days. Etc, etc.
- Testing AP users - #1 - local AP'ers who only want one day at a time. #2 - AP'ers from out of town who only have ONE resort stay scheduled. #3 - AP'ers who have multiple resort stays scheduled. #4 - APers who have a couple of resort stays scheduled in 2020 and want to schedule consecutive days at various times in 2021 through late Sept.
- Testing a combo of reg ticket holders & AP'ers together in 1 set of park reservations.
- Testing a combo of reg ticket holders & AP'ers together when the entire party has 2 or more scheduled/booked on site resort stays between now and 12/31/2020.
- Failure testing - this basically means that you TRY to get the system to fail. This is important so you can validate that the error messages and error screens, etc. that you've coded are actually going to show up and display like you expected them to. Ideally, you'd have documentation in place for your Customer Service team to access so when the horde of angry users calls on Monday morning to complain about how come they have the pink castle still or the Millennium Falcon on their screen, you can tell them what that means and what to do next.
It's unacceptable. For a company as large as this to have this sort of application disaster is an unacceptable nightmare. And they don't have the option of rolling back the changes and going live on a different date. Their only option is to fix it in place and continue moving forward. From a project management perspective, this could be considered a massive failure.