– Post escrito por María Morales (@MaMoralesMC) y Noemí Navarro (@nnsanchez92).
Hace algo más de un año os contábamos en qué consistía la técnica BDD y se ha hablado bastante por el blog de las diferencias entre TDD, ATDD y BDD.
Sin embargo hasta el momento no os hemos contado en ningún post sobre Keyword Driven Development o KDD, ni de Keyword Driven Testing o KDT, y lo hemos escuchado en alguna ocasión, por eso os lo queremos transmitir a vosotros también.
¿Qué es eso de KDD?
Keyword Driven Development o KDD es un proceso de desarrollo software, que se impulsa por la palabra clave, la cual se almacena en una base de datos y en la automatización se la hace referencia.
¿Qué es eso de KDT?
Casi siempre que se habla de KDT va enlazado de “Data Driven Testing” que consiste en utilizar datos pero que están separados de las pruebas automatizadas, y esos datos son utilizados en el script de la prueba.
Keyword Driven Testing o KDT es un framework de automatización de pruebas, donde se utiliza un formato de tabla para definir palabras claves o palabras de acción para cada función que nos gustaría utilizar.
La ISO/IEC/IEEE 29119-5 define KDT como una forma de describir los casos de prueba mediante el uso de un conjunto predefinido de palabras clave. Estas palabras clave son nombres que están asociados con un conjunto de acciones que se requieren para realizar un paso específico en un caso de prueba. Mediante el uso de palabras clave para describir las medidas de prueba en lugar de lenguaje natural, los casos de prueba pueden ser más fáciles de entender, mantener y automatizar.
Una palabra clave puede ser definida como un conjunto de acciones a llevar a cabo, también se define como una única palabra que representa una funcionalidad. Las palabras clave se organizan en tablas que representan una prueba, de esta forma como ya decíamos podemos separar el diseño de los casos de prueba de la implementación de la prueba.
Otra característica muy importante es que las palabras clave son de un lenguaje de uso común, decir, que lo pueden entender personas tanto técnicas como no técnicas (quizás te recuerde a Gherkin, te dejamos un post).
Este método separa el proceso de creación de la prueba en dos etapas distintas: una etapa de diseño y desarrollo y una fase de ejecución. Por lo tanto, no solo se centra en automatización de pruebas sino que se centra en la prueba integral desde su diseño hasta su ejecución.
KDT se puede dividir en dos capas:
- Capa de Infraestructura (KDT Engine), donde encontramos una una combinación de funciones definidas por el usuario, que se utiliza como un «motor» que recibe las palabras clave y lleva a cabo las operaciones de las operaciones de la aplicación que se está probando.
- Capa de lógica (KDT Test Case). A nivel más técnico en esta capa aparecen los “profesionales” que construyen y ejecutan scripts de prueba mediante el uso de una palabra clave.
KDT se puede utilizar para alcanzar una serie de objetivos:
- Mejorar la comunicación entre los testers
- Evitar incoherencias en los documentos de prueba
- Servir como la infraestructura para la automatización de pruebas basado en pruebas de búsqueda.
Pros y Contras de KDT
A continuación os vamos a mencionar algunas ventajas e inconvenientes de utilizar este framework.
Pros
- Cuando usamos KDT mejoramos la mantenibilidad ya que el formato es fácil de revisar.
- Podemos reutilizar el código.
- Todas las operaciones se presentan en la forma de una hoja de cálculo en Excel o en cualquier otro formato similar.
- Todos los objetos de interfaz de usuario se almacenan en archivos externos.
- Todos los casos de prueba, y los conjuntos de pruebas también se describen en archivos externos (normalmente se utiliza Excel como te comentamos en al principio de esta sección), lo que le permite manejar su arranque con facilidad.
- KDT ofrece máxima flexibilidad, se puede fácilmente añadir, borrar, editar casos de prueba y de pruebas existentes, y esta tarea no requiere tener una calificación adicional, sólo se necesita la capacidad de trabajar con KDT. Es decir, las nuevas operaciones pueden ser fácilmente añadidas al sistema, o los existentes se pueden modificar fácilmente, esto hace que sea fácil de extender el framework en sí.
- Si es necesario cambiar a una herramienta de automatización diferente, un mínimo de código debe ser modificado. Los casos de prueba se mantendrá en la misma forma.
Contras
- Al principio puede requerir más tiempo de elaboración que las pruebas manuales, por tanto, retrasa el tiempo que tarda en estar en el mercado el producto sobre la que estemos trabajando.
- Inicialmente se tiene la curva de aprendizaje moderadamente alta.
- Los requisitos para la calificación de los especialistas, que cubren el sistema con autotests, reducen significativamente. Las habilidades necesarias para trabajar con MS Excel serán suficientes. Es por eso que para muchos departamentos de prueba esta solución puede llegar a ser una panacea.
- La inversión inicial en el desarrollo de las palabras clave y sus funcionalidades relacionadas podrían tomar más tiempo.
- Podría actuar como una restricción a los tester técnicamente con discapacidad.
Terminando…
Seguiremos indagando sobre estas metodologías y a ver si nos cuadra llevarlas a cabo, para contaros nuestra experiencia como nos gusta hacer siempre.
Para seguir con el tema, os dejamos un enlace de LinkedIn donde podéis encontrar desde presentaciones sobre KDT hasta miembros especializados en la materia.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024