Take an example of deleting email(s) from an Inbox, sent by a particular sender.
[This is just an example. It can be done in many other ways also, like you can combine some steps into one step or you can altogether change the steps according to your requirement.]
Above example will need lot of different input data (e.g. for username & login) and verification data files (e.g. count of emails in Trash etc) for various screens.
For an error a "FALSE" condition is returned to the calling script. The calling script in turn returns “FALSE” to its calling script until the control is returned back to driver script. The Driver can continue with the next Test Case or exit depending on how you have handled it.
Advantages:
It provides division between data and scripts which in turn provides better maintainability and reduces redundancy and repetitions in creating automated test scripts.
It delivers script reusability as individual scripts each identifying a business function can be combined into a higher level script(s) in order to create composite and large scripts.
It makes available single maintenance point for each functionality or screen. If functionality changes, we only need to update a particular "Business Function" script.
Limitations:
Team must have a programming background or expertise in any scripting language.
Multiple data-files may be required for each Test Case. Changes in Test Cases necessitate updates to propagate to several sets of input/verification files for each Test Case.
Also See:
What is Test Automation Framework
5 Generations of Test Automation
Keyword Driven Framework
Choose Your Test Automation Framework