This methodology uses keywords (or action words) to symbolize a functionality to be tested, such as Enter Client.
Then the remaining columns, B-E, contain the data needed to execute the keyword: Name, Address, Postcode and City.
If screen layouts change or the system is migrated to another OS hardly any changes have to be made to the test cases: the changes will be made to the keyword documentation, one document for every keyword, no matter how many times the keyword is used in test cases, and it implies a deep process of test design.
[1] Furthermore, this approach is an open and extensible framework that unites all the tools, assets, and data both related to and produced by the testing effort.
Under this single framework, all participants in the testing effort can define and refine the quality goals they are working toward.
And, most importantly, it provides the entire team with one place to go to determine the state of the system at any time.
It tells you where corrections need to be made to stay on course at any given iteration of a development effort.
In the RT system test, it is not sufficient to check whether the SUT produces the correct outputs.
This removes the necessity for extra engineers in the test process, because the implementation for the keywords is already a part of the tool.