I've got a new way of testing things that there isn't significant documentation for. By looking at it you may think you've got it figured out but you can never be sure because there's nothing written down. It's an old technique. It's effective too or it wouldn't be around or as useful as it is. It's called "Procrastination". Here's how you use it:
When the feature is implemented in the application you go in and try to figure out what it does. You make sure nothing explodes and that all the pulls, pushes, bells and whistles you can figure out do work. If you find any you obviously report them. Then, you wait. You wait until someone has been using it for a while. If you're in luck, like I was on this one, they roll out the new feature in semi-production and the customer looks at it if not actually uses it. They'd let you know if it doesn't work for them wouldn't they? I sure hope so because that's all I've got to go on.
If there haven't been any complaints then you can assume it works as expected. That means you get to close the ticket.
So, consider it tested.
Why would I do that? Because this, the text below, is the entirety of the documentation of a new functionality that significantly changes the business process and hooks into about a third of the application code which took the developer something like three weeks to implement.
Need a station manager page to better handles the relationship between a group of kiosk to a clinic/team. The idea is to allow a clinic to have several kiosk in one location and a patient can go to any kiosk in that location and check in and restrict a patient from checking into a place where they don't have an appointment. The old system allows a patient to check in to an appointment anywhere there is a kiosk.
Well, there was this update to the ticket:
added three new methods that for the station manager page. Plus unit test for Mark