Keyword-driven testing methodology. Part 3
With the KDT approach, it should first be confirmed that the test plan consists of actions suitable to KDT. Typically, such tests appear when the program under test provides the user with a common interface operating objects containing different structure or logic.
For example, MS Word guarantees the possibility to work with texts, charts, pictures, etc. using the same interface and set of instruments. Testing of business logic for such generic interfaces is quite complicated for a data-driven approach; KDT eases the process.
When used in situations suitable to its strengths, the KDT approach can help any automated testing company save money on support activities and achieve better ROI in the long term. The graph below shows the variations in cost of development and further support between KDT and some other approaches. In addition to saving money and time, the KDT approach works better if you got more test cases. Also, the majority of effort with KDT is concentrated within the initial stage of the test development process.
A keyword-driven approach significantly cuts down development effort due to several reasons:
- A significant part of the automation process can be performed by people without programming skills.
- Script writers can develop automated tests at a higher level. This allows them to concentrate on the design of automated tests instead of low-level operations.
- GUI changes can be made centrally. In other words, it is enough to change the map with interface elements if you need to add a new button to an existing form. When the keywords are developed, they are not connected with certain interface elements. Thus, keywords can easily be used for similar standard elements.
- Refactoring of non-centralized functionality is realized by “Find/Replace” operations in the test description tables. For example, consider the implementation process of a new form in a Wizard sequence of pages. In the table of metadata, you can find all the tests including the previous screen, and change the data to add the new form. Using standard architecture, you would need to add functions and go through the code to define all the dependent functions and change them afterwards.
Finally, let’s compare KDT to data-driven testing (DDT), the most common testing method used to date, using a concrete example. KDT is, in fact, considered by many to be DDT’s “logical next step”.
a1qa recently compared the costs for development and support of keyword-driven and data-driven testing. While these two methods are similar in that both are a part of the automation process test data preparation, a key differentiator is that KDT test data has a much more important role and is able to fully replace the test scripts. To estimate benefits of KDT in practice, we chose a large, stable scope in terms of business logic and user interface changes. This guaranteed that there would be enough keywords to make measurements and to check test development abilities using keywords; 200 test cases were selected for automation. We performed daily test executions, which was necessary in order to speed up the comparison process.
One of the required factors was to get a situation where test development efforts on the keyword-driven test framework were less in comparison with the actual automation process for an existing solution. We achieved this level when 150+ cases were developed.
As a result of this testing, we found KDT had no restrictions for the usage, and the proof of concept (POC) stage showed positive results. We began measurements after test development, compared them and found similar characteristics for the critical automation process for both solutions. However, based on the experience above, we would suggest using the KDT approach when covering hundreds of test cases in long-term projects with complex business logic, which assumes a high level of keyword re-usage.
