When testing applications that are still being implemented, it’s possible that you have a function or screen that’s already for testing but some dependencies are not yet available. As a tester, you have to weigh whether the function is really not testable or if there’s a way to work-around current limitations. More often, the case is the latter.
To be able to simulate the cases realistically, you have to analyze and find out what would be the conditions needed to be fulfilled. Otherwise, you might end up simulating an invalid case that shouldn’t happen IRL, and worse trigger bugs that normally wouldn’t occur and wouldn’t really have to be handled.
For instance, in the application we’re working on, there are scenarios wherein we have cases where user is logged out but we have no log out function yet, or we have to have cases wherein the user doesn’t have a profile yet but we have no delete function yet to re-initiate the user to having no profile.
We found that in the Profiles List, there are records appearing more than once. There’s just 1 record in the PROFILES table, but what differs is that they have more than 1 value for their Availability Status (should be just 1 per profile).
Our hunch is this is what happened:
- The migration tool pulled the initial set of data from the existing system. Say, profile KC has availability status GREEN.
- The availability status got updated in the existing or new system under test. Say, profile KC now has RED availability status in the existing, and YELLOW in the new system.
- The migration tool is re-executed. This resulted to profile KC having 2 availability statues RED and YELLOW in the new system.
The catch is the 3rd step isn’t part of the intended use cases of the migration tool. It was intended to run onto a clean environment. So the case wherein profiles are appearing multiple times was caused by an invalid scenario or invalid data. As to whether the migration tool’s use case has to be extended to support multiple reruns, that’s a different story.