I'm in a project to improve an application. We have done three testing cycles and now we go on with the migration of data from the old application (production) to the new application(QA). When have done the migration we want to do a new testing cycle, but focus on the migration data.
I learn a little with some articles in the net and I now I need ensure that users who are migrated are able to log on, to access resources based on group membership and ensure that users are able to access the resources that are migrated.
Because I'm a big fan of reusing information, here's a little something I posted earlier this week with a few minor tweaks (I really ought to blog about this somewhere):
Two umbrella issues to consider:
1. Has the data been converted/migrated correctly? This will address validating the conversion itself. Think about things like counts and states. If you have 10 records on the legacy system, you should have 10 on the new...that is, unless there are rules that exclude a subset of the data for whatever reason. Similarly, if you have 5 active and 5 inactive records on the legacy system, do you have the same counts broken down by state on the new?
2. Is the data usable? Think CRUD.
C - Can you create records in the new system? So, from above, can you add new users post-migration that are similar to ones that existed pre-migration?
R - Can you read/access records in the new system?
U - Can you update records in the new system? For your migrated users, can you change their passwords or other information pertinent to the data that you track?
D - Can you 'delete' records in the new system? (From an application standpoint, you might 'delete' a record...but what you're really doing is changing its state. To me, this would fall under 'U'. Rather, is there a means/need to DELETE data? If so, you'll want to explore that as well.)
It all boils down to understanding the lifecycle of your data.
I would only like to add something from my own painful experience:
Don't forget about the interfaces to other systems (specially the APIs) and make sure that if you have other systems accessing your data either directly or via other layers or systems, they are still working in the same CRUD way that Jason described above.