Keyword-driven testing

Testing basado en palabras clave, del inglés Keyboard-driven testting, también conocido como test basado en tablas (del inglés table-driven testing) o palabras de acción testing (del inglés action word based testing, es una metodología de software testing aplicable a tanto manual y automated testing. Este método separa la documentación de los casos de test -incluyendo los datos a usar- desde la presecripción de la forma en que los test serán ejecutados. Como resultado, separa el proceso de creación de tests en dos diferentes etapas; una etapa de diseño y desarrollo, y una etapa de ejecución.

Resumen

Esta metodlogía usa palabras clave (o palabras de acción) para simbolizar una funcionalidad a ser testeada, como Ingresar Cliente. La palabra clave Ingresar Cliente está definida como un conjunto de acciones que deben ser ejecutadas para ingresar un nuevo cliente a la base de datos. Su documentación en palabras clave podría contener:

el estado inicial del sistema bajo prueba (SUT)
la ventana o menú desde donde iniciar
las teclas o clicks del mouse para posicionarse en el lugar indicado
los nombres de los campos para buscar y qué argumentos ingresar
las acciones a realizar en caso de adicionar diálogos desplegables (como confirmaciones)
los botones a hacer click para enviar (submit)
una verificación (assertion) acerca de los valores que el SUT debería tener después de terminar las operaciones

Las pruebas a través de palabras clave usan una tabla en un formato similar al siguiente. La primera columna A tiene la palabra clave, Enter Cliente (inglés para "Ingresa cliente"), que será la funcionalidad a ser evaluada. Después, las columnas restantes, B-E, contienen los datos necesarios para ejecutar las palabras clave: Name, Address, Postcode and City.

A	B	C	D	E
.	Name	Address	Postcode	City
Enter Client	Jane Smith	6 High Street	SE25 6EP	London

To enter another client, the tester would create another row in the table with Enter Client as the keyword and the new client's data in the following columns. There is no need to relist all the actions included.

Advantages

Keyword-driven testing reduces the sensitivity to maintenance caused by changes in the SUT. 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. Also, due to the very detailed description of the way of executing the keyword (in the keyword documentation) the test can be performed by almost anyone. Thus keyword-driven testing can be used for both manual testing and automated testing.^[1]

Methodology

The keyword-driven testing methodology divides test process execution into several stages:

Test preparation: intake test basis etc.
Test design: analysis of test basis, test case design, test data design.
Manual test execution: manual execution of the test cases using keyword documentation as execution guideline.
Automation of test execution: creation of automated script that perform actions according to the keyword documentation.
Automated test execution.

Definition

A Keyword or Action Word is a defined combination of actions on a test object which describes how test lines must be executed. An action word contains arguments and is defined by a test analyst.

Automation of the test execution

The implementation stage differs depending on the tool or framework. Often, automation engineers implement a framework that provides keywords like “check” and “enter”.^[1] Testers or test designers (who do not need to know how to program) write test cases based on the keywords defined in the planning stage that have been implemented by the engineers. The test is executed using a driver that reads the keywords and executes the corresponding code.

Other methodologies use an all-in-one implementation stage. Instead of separating the tasks of test design and test engineering, the test design is the test automation. Keywords, such as “edit” or “check” are created using tools in which the necessary code has already been written. This removes the necessity for extra engineers in the test process, because the implementation for the keywords is already a part of the tool. Examples include GUIdancer and QTP.

Pros

Plantilla:Section OR

Maintenance is low in the long run:
- Test cases are concise
- Test cases are readable for the stake holders
- Test cases easy to modify
- New test cases can reuse existing keywords more easily
Keyword re-use across multiple test cases
Not dependent on a specific tool or programming language
Division of Labor
- Test case construction needs stronger domain expertise - lesser tool / programming skills
- Keyword implementation requires stronger tool/programming skill - with relatively lower domain skill
Abstraction of Layers

Cons