How to write a TC to verify the 'To Be' screen UI/function is same as 'As Is'
How would you write test cases to test if the ‘To Be ’ modernised screens are the same as the Legacy ‘As Is’ mainframe screens . ( Both UI & functionality)
Should the UI test case specify a mapping for each and every field in the ‘To Be’ and ‘As Is’ screen ?
1. You will need to define what you mean by "the same as" in your screens' context.
2. If your new application is nothing more than a simple transformation of "this field" is now represented as "that field", then yes - specify a mapping for each and every field.
3. Most likely, it will be nowhere near this simple. Few folks just design a simple one-to-one mapping. Almost certainly screens will be redesigned, workflows will be modified, systems will be enhanced. In that case, you'll need to actually put some thought into your tests.
Last edited by Joe Strazzere; 04-16-2013 at 03:20 AM.
1. 'same as' means the new screens will have the same fields as the old ones (@99% of them) . The screens are going to have drop down boxes , selection lists and buttons as opposed to the mainframe function keys f3 and f1.
2. Im thinking ill require a 1:1 mapping of the fields and function keys. This sorts the Ui
How do I handle the functional side ? As that can be quite a task if we want to test each and every button and the workflows ..