This is not exactly E10 specific but my question is due to E10 testing before going live with a new implementation.
Does anyone have any tips or suggestions for testing your system end-to-end as if months had passed, without actually testing for months? Any other general testing tips along these lines?
Our business is heavily project-based and the projects typically take many months to complete. I’m not real sure how to test in a way that simulates the passage of time. Some records can be back dated, but I’m thinking some cannot, at least not without manual manipulation after the fact. Labor / data collection via MES, for example.
Seems like it will be difficult to aggregate and report on data in a realistic way, that would represent what we see in production.
Back in the Y2K days (holy that was 20 years ago!) there were packages that allowed you to change the system date for only the system under test. These still exist if you Google for Time-based Testing or something similar.
My 1st question off the bat for Microsoft Environments is how the software maintains the authentication as Microsoft processes require system clocks to be within 10min or 15mins (can’t remember exact value) otherwise authentication fails. On the URL you posted they answer that question specifically but question is has anyone used this software as sales/marketing information should always be taken with a pinch of salt?
I think the whole environment runs in the time capsule so both would have the new times. This technology is…gotta say it…time-tested. Y2K produced a lot of good tools and we’ll be needing them again in 2038.
So you’ll still need to have a test database OS and an application OS with a test domain controller, restored from a production backup, in an isolated environment if you’re using any services with AD authentication. Still useful to know though especially as some staff here have posed the same question re: timephasing and testing.
Unless the state of the art has changed, that’s my understanding - especially if you’re testing authentication. Of course, if you’re just testing Epicor functionality then basic auth should be much easier.
Wouldn’t a complete testing environment require have domain controllers, App and DB servers, and client machines all in an isolated sandbox?
I added the domain controller, as it usually manages setting the time on other servers and client machines.
I’d only ever advance time forward, never back. In other words, if today is July 1, 2020, and I need to test with a 4 month span, start with the DC’s date/time as the current date/time. Enter data , advance the date/time, rinse and repeat.
If you missed something that was supposed to happen in month 2, and you’ve advanced to month 3, take a hard look to see if back dating the entries would provide the same result. Else you need to start from scratch again. Never set the DC’s date/time backwards (except when starting from scratch)
Thanks for the input. Setting up an entire isolated environment with a dedicated DC, etc is definitely more than I want to do, but that is probably the best solution.
that was 20 years ago!) there were packages that allowed you to change the system date for only the system under test.