Automation 2018 PDF
Automation 2018 PDF
Ingeniero de Automatización de
Pruebas
International Software
Spanish Software Testing
Testing Qualifications
Qualifications Board
Board
Copyright © International Software Testing Qualifications Board (en adelante denominado ISTQB®).
Grupo de Trabajo de Automatización de Pruebas de Nivel Avanzado: Bryan Bakker, Graham Bath,
Armin Born, Mark Fewster, Jani Haukinen, Judy McKay, Andrew Pollner, Raluca Popescu, Ina
Schieferdecker; 2016.
Historial de Revisiones
Índice general
Historial de Revisiones ............................................................................................................................ 3
Índice general .......................................................................................................................................... 4
Agradecimientos ...................................................................................................................................... 7
1.1 Versión Española ................................................................................................................... 7
0. Introducción a este Programa de Estudio ........................................................................................... 8
0.1 Objetivo de este documento ......................................................................................................... 8
0.2 Alcance de este documento .......................................................................................................... 8
0.2.1 Dentro de alcance .................................................................................................................. 8
0.2.2 Fuera de alcance ................................................................................................................... 9
0.3 Probador Certificado de Nivel Avanzado - Ingeniero de Automatización de Pruebas ................. 9
0.3.1 Expectativas........................................................................................................................... 9
0.3.2 Requisitos de Acceso y Renovación ................................................................................... 10
0.3.3 Nivel de conocimiento.......................................................................................................... 10
0.3.4 Examen ................................................................................................................................ 10
0.3.5 Acreditación ......................................................................................................................... 10
0.4 Partes Normativas frente a Partes Informativas ......................................................................... 10
0.5 Nivel de Detalle ........................................................................................................................... 11
0.6 Organización del Programa de Estudio ...................................................................................... 11
0.7 Términos, Definiciones y Acrónimos ........................................................................................... 12
1. Introducción y Objetivos para la Automatización de Pruebas - 30 minutos ...................................... 13
1.1 Objetivo de la Automatización de la Prueba ............................................................................... 14
1.2 Factores de Éxito en la Automatización de Pruebas .................................................................. 16
2. Preparación para la Automatización de la Prueba - 165 minutos ..................................................... 19
2.1 Factores del SSP que Influyen en la Automatización de Pruebas ............................................. 20
2.2 Evaluación y Selección de Herramientas ................................................................................... 21
2.3 Diseño para Capacidad de ser Probado y Automatización ........................................................ 24
3. La Arquitectura de Automatización de Pruebas Genérica - 270 minutos ......................................... 27
3.1 Introducción a la AAPg................................................................................................................ 28
3.1.1 Descripción general de la AAPg .......................................................................................... 29
3.1.2 Capa de Generación de Pruebas ........................................................................................ 32
3.1.3 Capa de Definición de Pruebas ........................................................................................... 32
6.2 Identificar los Pasos Necesarios para Implementar la Automatización dentro de las Pruebas de
Regresión .......................................................................................................................................... 84
6.3 Factores que Hay que Tener en Cuenta al Implementar la Automatización dentro de Pruebas
de Nuevas Prestaciones ................................................................................................................... 87
6.4 Factores que Hay que Tener en Cuenta al Implementar la Automatización de las Pruebas de
Confirmación ..................................................................................................................................... 88
7. Verificación de la SAP - 120 minutos ................................................................................................ 89
7.1 Verificación de los Componentes del Entorno de Pruebas ........................................................ 90
7.2 Verificación del Juego de Pruebas Automatizadas .................................................................... 92
8. Mejora Continua - 150 minutos Referencias ..................................................................................... 95
8.1 Opciones para Mejorar la Automatización de Pruebas .............................................................. 96
8.2 Planificación de la Implementación de la Mejora de la Automatización de Pruebas.................. 99
9. Referencias ..................................................................................................................................... 101
9.1 Estándares ................................................................................................................................ 101
9.2 Documentos ISTQB .................................................................................................................. 102
9.3 Marcas Registradas .................................................................................................................. 102
9.4 Referencias bibliográficas ......................................................................................................... 103
9.5 Referencias Web ....................................................................................................................... 103
10. Aviso a los Proveedores de Formación......................................................................................... 104
10.1 Tiempos de Formación ........................................................................................................... 104
10.2 Ejercicios Prácticos en el Área de Trabajo (Curso) ................................................................ 104
10.3 Normas para Aprendizaje Electrónico .................................................................................... 104
11. Índice terminológico....................................................................................................................... 105
Agradecimientos
Este documento fue elaborado por un equipo principal del Grupo de Trabajo de Nivel Avanzado del
International Software Testing Qualifications Board.
El equipo principal agradece al equipo de revisión y a todos los Comités Nacionales y Regionales por
sus sugerencias y aportaciones.
En el momento en que se completó el programa de estudios de nivel avanzado para este módulo, el
Grupo de Trabajo de Nivel Avanzado - Automatización de Pruebas tenía la siguiente composición:
Bryan Bakker, Graham Bath (Presidente del Grupo de Trabajo de Nivel Avanzado), Armin Beer, Inga
Birthe, Armin Born, Alessandro Collino, Massimo Di Carlo, Mark Fewster, Mieke Gevers, Jani
Haukinen, Skule Johansen, Eli Margolin, Judy McKay (Vicepresidenta del Grupo de Trabajo de Nivel
Avanzado), Kateryna Nesmyelova, Mahantesh (Monty) Pattan, Andrew Pollner (Presidente de
Automatización de Pruebas de Nivel Avanzado), Raluca Popescu, Ioana Prundaru, Riccardo Rosci,
Ina Schieferdecker, Gil Shekel, Chris Van Bael.
El equipo principal autor de este plan de estudios está formado por las siguientes personas: Andrew
Pollner (Presidente), Bryan Bakker, Armin Born, Mark Fewster, Jani Haukinen, Raluca Popescu, Ina
Schieferdecker.
Las siguientes personas participaron en la revisión, comentarios y votación de este programa de
estudio (por orden alfabético): Armin Beer, Tibor Csöndes, Massimo Di Carlo, Chen Geng, Cheryl
George, Kari Kakkonen, Jen Leger, Singh Manku, Ana Paiva, Raluca Popescu, Meile Posthuma,
Darshan Preet, Ioana Prundaru, Stephanie Ulrich, Erik van Veenendaal, Rahul Verma.
Este documento fue publicado formalmente por la Asamblea General del ISTQB el 21 de octubre de
2016.
0.3.1 Expectativas
La cualificación de Nivel Avanzado está dirigida a personas que desean desarrollar los conocimientos
y habilidades adquiridas en el Nivel Básico y desarrollar aún más su experiencia en una o más áreas
específicas. Los módulos ofrecidos en el Especialista de Nivel Avanzado cubren una amplia gama de
temas de la prueba.
Un Ingeniero de Automatización de Pruebas es aquel que tiene un amplio conocimiento de las
pruebas en general, y un profundo conocimiento en el área especial de la automatización de pruebas.
Se define una profunda comprensión como el conocimiento suficiente de la teoría y la práctica de la
automatización de pruebas para poder influir en la dirección que toma una organización y/o proyecto
a la hora de diseñar, desarrollar y mantener soluciones de automatización de pruebas para pruebas
funcionales.
El documento Advanced Level Modules Overview [ISTQB-AL-Modules] describe los resultados de
negocio de este módulo.
0.3.4 Examen
El examen para este Certificado de Nivel Avanzado se basará en este programa de estudio más el
Programa de Nivel Básico [ISTQB-FL]. Las respuestas a las preguntas del examen pueden requerir el
uso de material basado en más de una sección de estos programas.
El formato del examen se describe en el sitio web del ISTQB [ISTQB-Web], sección Nivel Avanzado.
En el sitio web del ISTQB también se puede encontrar información útil para quienes se presenten al
examen.
0.3.5 Acreditación
Un Comité Miembro de ISTQB puede acreditar a los proveedores de capacitación cuyo material del
curso siga este programa.
La sección Nivel Avanzado de la página web del ISTQB [ISTQB-Web] describe las normas
específicas que se aplican a los proveedores de formación para la acreditación de cursos.
1
En la siguiente URL se puede consultar la versión española del glosario: http://www.sstqb.es/recursos/descargas.html
Los productos de prueba son necesarios para las actividades de prueba que incluyan:
Implementar casos de prueba automatizados.
Monitorizar y controlar la ejecución de pruebas automatizadas.
Interpretar, informar y registrar los resultados de pruebas automatizadas.
2
"competencia" es la traducción del término “skill”.
3
“capacidad de ser probado” es la traducción del término “testability”. El término “testability” también se puede traducir como
“testabilidad”.
El mantenimiento del código de automatización de pruebas puede ser complejo. No es extraño tener
tanto código para las pruebas como código para el SSP. Por esta razón es de suma importancia que
el código de prueba sea mantenible. Esto se debe a que se utilizan diferentes herramientas de
prueba, diferentes tipos de verificación y diferentes artefactos de productos de prueba que deben
mantenerse (como datos de entrada de prueba, oráculos de prueba, informes de prueba).
Con estas consideraciones de mantenimiento en mente, además de los puntos importantes que se
deben realizar, hay algunos que no se deben realizar, como se indica a continuación:
No cree código que sea sensible a la interfaz (es decir, que se vería afectado por
cambios en la interfaz gráfica o en partes no esenciales de la Interfaz de Programación
de Aplicaciones (o API por sus siglas en inglés).
No cree una automatización de pruebas que sea sensible a los cambios de datos o
que tenga una alta dependencia de valores de datos particulares (por ejemplo, la
entrada de pruebas depende de otras salidas de pruebas).
No cree un entorno de automatización que sea sensible al contexto (por ejemplo, fecha
y hora del sistema operativo, parámetros de localización del sistema operativo o el
contenido de otra aplicación). En este caso, es mejor usar stubs de prueba según sea
necesario para poder controlar el entorno.
Cuantos más factores de éxito se cumplan, mayor será la probabilidad de éxito del proyecto de
automatización de pruebas. No todos los factores son necesarios, y en la práctica rara vez se
cumplen todos los factores. Antes de iniciar el proyecto de automatización de pruebas, es importante
analizar las posibilidades de éxito del proyecto considerando los factores existentes y los factores que
faltan, teniendo en cuenta los riesgos del enfoque elegido, así como el contexto del proyecto. Una vez
que la AAP está en su sitio, es importante investigar qué artículos faltan o aún necesitan trabajo.
Software de terceros
A menudo, el SSP no sólo consiste en software escrito en la organización de origen, sino que
también puede incluir software proporcionado por terceros. En algunos contextos, este software
de terceros puede necesitar pruebas, y si la automatización de pruebas está justificada, puede
necesitar una solución de automatización de pruebas diferente, como el uso de una Interfaz de
Programación de Aplicaciones (o API por sus siglas en inglés).
Niveles de intrusión
Diferentes enfoques de automatización de pruebas (usando diferentes herramientas) tienen
diferentes niveles de intrusión. Cuanto mayor sea el número de cambios que se deben realizar
de forma específica en el SSP para las pruebas automatizadas, mayor será el nivel de intrusión.
El uso de interfaces software dedicadas requiere un alto nivel de intrusión, mientras que el uso
de elementos de Interfaz de Usuario existentes tiene un nivel de intrusión más bajo. El uso de
elementos de hardware del SSP (como teclados, conmutadores manuales, pantallas táctiles,
interfaces de comunicación) tiene un nivel de intrusión aún mayor.
El problema con los niveles de intrusión más altos es el riesgo de falsas alarmas. La SAP puede
presentar fallos que pueden deberse al nivel de intrusión impuesto por las pruebas, pero es poco
probable que ocurran cuando el sistema de software se utiliza en un entorno real. La prueba con
un alto nivel de intrusión suele ser una solución más sencilla para el enfoque de automatización
de pruebas.
4
“prestación” es la traducción del término “feature”.
Arquitectura claramente definida: La tercera parte importante del diseño para la capacidad de
ser probado es una arquitectura que proporciona interfaces claras y comprensibles que
proporcionan control y visibilidad sobre todos los niveles de prueba.
El IAP evalúa las formas en que se puede probar el SSP, incluyendo las pruebas automatizadas, de
una forma efectiva (probando las áreas correctas y encontrando defectos críticos) y eficiente (sin
hacer demasiado esfuerzo). Siempre que se necesiten interfaces software específicas, éstas deben
ser especificadas por el IAP e implementadas por el desarrollador. Es importante definir la capacidad
de ser probado y, si fuera necesario, interfaces software adicionales al principio del proyecto, para
que el trabajo de desarrollo pueda ser planificado y presupuestado.
5
“control de rejilla” es la traducción del término “grid control”.
6
“estándar de formato” es la traducción del término “formatting standard”.
Para la generación de pruebas automatizadas también se pueden incluir las siguientes capacidades:
Capacidad para modelar el SSP, su entorno y/o el sistema de pruebas.
Capacidad para definir directivas de prueba y para configurar/parametrizar algoritmos de
generación de pruebas.
Capacidad de trazar las pruebas generadas de vuelta hacia el modelo (elementos).
La capa de ejecución de pruebas puede consistir en componentes que proporcionen las siguientes
capacidades:
Preparar y desmantelar7 el SSP para la ejecución de la prueba.
Preparar y desmantelar los juegos de prueba (es decir, el conjunto de casos de prueba,
incluidos los datos de prueba).
Configurar y parametrizar la configuración de la prueba.
Interpretar tanto datos de prueba como casos de prueba y transformarlos en guiones
ejecutables.
Instrumentalizar el sistema de prueba y/o el SSP para el registro (filtrado) de la ejecución
de la prueba y/o para la inyección de defectos.
Analizar las respuestas del SSP durante la ejecución de la prueba para orientar la ejecución
de pruebas posteriores.
Validar las respuestas del SSP (comparación de los resultados esperados y reales) para los
resultados de la ejecución de casos de prueba automatizados.
Controlar la ejecución temporal de las pruebas automatizadas.
7
“desmantelar” es la traducción del término “tear down”.
Estos elementos constituyen el producto de prueba y deben estar en la versión correcta para que
correspondan con la versión del SSP. En algunas situaciones puede ser necesario volver a las
versiones anteriores de la SAP, por ejemplo, en caso de que sea necesario reproducir problemas de
campo con versiones anteriores del SSP. Una buena gestión de la configuración permite esta
capacidad.
A menudo, la elección del paradigma depende de la arquitectura SSP y puede tener implicaciones en
la arquitectura del SSP. La interconexión entre el SSP y la AAP se debe analizar y diseñar
cuidadosamente a fin de seleccionar una arquitectura segura para el futuro entre los dos sistemas.
Entre los ejemplos de entornos de prueba y ejemplos de uso se incluyen los siguientes:
Un ordenador con el SSP y la SAP - útil para probar una aplicación software.
Ordenadores individuales conectados en red para un SSP y una SAP respectivamente - útil
para probar el software del servidor.
Dispositivos de prueba adicionales para estimular y observar las interfaces técnicas de un
SSP - útiles para probar el software, por ejemplo, en un decodificador.
Dispositivos de prueba en red para emular el entorno operativo del SSP - útil para probar el
software de un router de red.
Simuladores para simular el entorno físico del SSP - útiles para probar el software de una
unidad de control embebida.
Facilidad de uso para una determinada implementación de arquitectura del producto de prueba
Además de la funcionalidad de la SAP, su compatibilidad con el SSP, su estabilidad y evolución a
largo plazo, sus requisitos de esfuerzo y las consideraciones sobre el retorno de la inversión (ROI por
sus siglas en inglés), un IAP tiene la responsabilidad específica de abordar los problemas de
usabilidad de una SAP. Esto incluye, pero no se limita a:
Diseño orientado al probador.
Facilidad de uso de la SAP.
Soporte de la SAP para otros roles en el desarrollo de software, aseguramiento de la calidad
y gestión de proyectos.
Organización, navegación y búsqueda eficaces en/con la SAP.
Documentación útil, manuales y texto de ayuda para la SAP.
Informes prácticos de y sobre la SAP.
Diseños iterativos para abordar la realimentación y las percepciones empíricas de la SAP.
Estos enfoques se explican posteriormente en términos de los conceptos básicos y de los pros y
contras.
Enfoque de captura/reproducción
Concepto principal
En los enfoques de captura/reproducción, las herramientas se utilizan para capturar las
interacciones con el SSP mientras se ejecuta la secuencia de acciones definida por un
procedimiento de prueba. Se capturan las entradas; las salidas también se pueden registrar
para realizar comprobaciones posteriores. Durante la repetición de eventos, hay diversas
posibilidades para la comprobación de salidas manuales y automatizadas:
Manual: el probador tiene que vigilar las salidas del SSP para detectar anomalías.
Completo: todas las salidas del sistema registradas durante la captura deben ser
reproducidas por el SSP.
Exacto: todas las salidas del sistema que se registraron durante la captura deben ser
reproducidas por el SSP al nivel de detalle de la grabación.
Puntos de comprobación: sólo se comprueban las salidas del sistema seleccionadas en
determinados puntos para los valores especificados.
Pros
El enfoque de captura/reproducción se puede utilizar para SSP's a nivel de interfaz gráfica de
usuario (GUI por sus siglas en inglés) y/o interfaz de programación de aplicaciones (API por
sus siglas en inglés). Inicialmente, es fácil de configurar y utilizar.
Contras
Los guiones de captura/reproducción son difíciles de mantener y evolucionar porque la
ejecución capturada de SSP depende en gran medida de la versión del SSP de la que se ha
tomado la captura. Por ejemplo, cuando se graba a nivel de la interfaz gráfica de usuario (GUI
por sus siglas en inglés), los cambios en la disposición de la interfaz gráfica de usuario pueden
afectar al guion de prueba, incluso si sólo se trata de un cambio en la posición de un elemento
de la interfaz gráfica de usuario. Por lo tanto, los enfoques de captura/reproducción siguen
siendo vulnerables a los cambios.
La implementación de los casos de prueba (guiones) sólo puede iniciarse cuando el SSP está
disponible.
Guion lineal
Concepto principal
Como con todas las técnicas de guiones, los guiones lineales comienzan con algunos
procedimientos de prueba manuales. Hay que tener en cuenta que estos pueden no ser
documentos escritos - el conocimiento sobre qué pruebas realizar y cómo realizarlas puede ser
"conocido" por uno o más Analistas de Pruebas.
Cada prueba se ejecuta manualmente mientras la herramienta de prueba registra la secuencia
de acciones y, en algunos casos, captura la salida visible del SSP en la pantalla. Esto resulta,
generalmente, en un guion (típicamente de gran tamaño) para cada procedimiento de prueba.
Los guiones grabados se pueden editar para mejorar la legibilidad (por ejemplo, añadiendo
comentarios para explicar lo que está ocurriendo en puntos clave) o añadir comprobaciones
adicionales utilizando el lenguaje de guiones de la herramienta.
Los guiones pueden ser reproducidos por la herramienta, haciendo que la herramienta repita
las mismas acciones tomadas por el probador cuando el guion fue grabado. Aunque esto se
puede utilizar para automatizar las pruebas de interfaz gráfica de usuario (GUI por sus siglas
en inglés), no es una buena técnica para utilizar cuando se va a automatizar un gran número
de pruebas y son necesarias para numerosas versiones del software. Esto se debe al elevado
coste de mantenimiento que suelen ocasionar los cambios en el SSP (cada cambio en el SSP
puede requerir muchos cambios en los guiones grabados).
Pros
Las ventajas de los guiones lineales se centran en el hecho de que se necesita poco o ningún
trabajo de preparación antes de comenzar la automatización. Una vez que haya aprendido a
utilizar la herramienta es simplemente cuestión de grabar una prueba manual y volver a
reproducirla (aunque la parte de grabación de este proceso puede requerir interacción adicional
con la herramienta de prueba para solicitar que se realicen comparaciones de la salida real con
la esperada para verificar que el software está funcionando correctamente). No se requieren
competencias de programación, pero suelen ser útiles.
Contras
Las desventajas de los guiones lineales son numerosas. La cantidad de esfuerzo requerido
para automatizar un procedimiento de prueba determinado dependerá en gran medida del
tamaño (número de pasos o acciones) requerido para realizarlo. Por lo tanto, el procedimiento
de prueba número 1000 que se automatizará requerirá una cantidad de esfuerzo similar a la del
procedimiento de prueba número 100. En otras palabras, no hay mucho margen para reducir el
coste de la construcción de nuevas pruebas automatizadas.
Adicionalmente, si hubiera un segundo guion que realizara una prueba similar aunque con
diferentes valores de entrada, ese guion contendría la misma secuencia de instrucciones que el
primer guion; solo la información incluida con las instrucciones (conocida como argumentos o
parámetros de la instrucción) diferiría. Si hubiera varias pruebas (y por lo tanto guiones) todas
ellas contendrían la misma secuencia de instrucciones, las cuales tendrían que ser mantenidas
siempre que el software cambiara de una manera que afectara a los guiones.
Debido a que los guiones están en un lenguaje de programación, en lugar de un lenguaje
natural, los no programadores pueden encontrarlos difíciles de entender. Algunas herramientas
de prueba utilizan lenguajes propietario (exclusivos de la herramienta), por lo que lleva tiempo
aprender el idioma y dominarlo.
Los guiones grabados sólo contienen afirmaciones generales en los comentarios, si es que
contienen alguna. Los guiones largos, en particular, se documentan mejor con comentarios
para explicar lo que está sucediendo en cada paso de la prueba. Esto facilita el mantenimiento.
Los guiones pronto pueden llegar a ser muy extensos (conteniendo muchas instrucciones)
cuando la prueba comprenda muchos pasos.
Los guiones no son modulares y son difíciles de mantener. Los guiones lineales no siguen los
paradigmas comunes de reutilización y modularidad del software y están estrechamente
acoplados a la herramienta utilizada.
Guion estructurado
Concepto principal
La principal diferencia entre la técnica de guion estructurado y la técnica de guion lineal es la
introducción de una librería de guiones. Esta contiene guiones reutilizables que realizan
secuencias de instrucciones que generalmente se necesitan en diferentes pruebas. Buenos
ejemplos de estos guiones son aquellos que interactúan, por ejemplo, con las operaciones de
las interfaces SSP.
Pros
Los beneficios de este enfoque incluyen una reducción significativa en los cambios de
mantenimiento necesarios y el coste reducido de automatizar nuevas pruebas (porque pueden
utilizar guiones que ya existen en lugar de tener que crearlos todos desde el principio).
Las ventajas de los guiones estructurados se obtienen, en gran medida, a través de la
reutilización de guiones. Se pueden automatizar más pruebas sin tener que crear el volumen
de guiones que requeriría un enfoque de guiones lineales. Esto tiene un impacto directo en los
costes de construcción y mantenimiento. La segunda y subsiguientes pruebas no requerirán
tanto esfuerzo de automatización porque algunos de los guiones creados para implementar la
primera prueba pueden ser reutilizados nuevamente.
Contras
El esfuerzo inicial para crear los guiones compartidos puede ser visto como una desventaja,
pero esta inversión inicial debería ser muy rentable si se aborda adecuadamente. Se requerirán
competencias de programación para crear todos los guiones, ya que una simple grabación no
será suficiente. La librería de guiones debe estar bien gestionada, es decir, los guiones deben
estar documentados y debe ser fácil, para los Analistas de Pruebas Técnicas, encontrar los
guiones necesarios (por lo que una convención de nomenclatura adecuada será de gran ayuda
en este caso).
Esto significa que el guion de prueba principal se puede reutilizar para implementar varias
pruebas (en lugar de una sola prueba). Generalmente, el guion principal de prueba "reutilizable"
se denomina guion de "control". El guion de control contiene la secuencia de instrucciones
necesarias para realizar las pruebas pero lee los datos de entrada de un archivo de datos. Una
prueba de control se puede utilizar para muchas pruebas, pero generalmente es insuficiente
para automatizar un rango amplio de pruebas. Por lo tanto, serán necesarios varios guiones de
control, pero esto es sólo una fracción del número de pruebas que están automatizadas.
Pros
El coste de añadir nuevas pruebas automatizadas puede reducirse significativamente mediante
esta técnica de guion. Esta técnica se utiliza para automatizar muchas variaciones de una
prueba útil, dando pruebas más profundas en un área específica y puede incrementar la
cobertura de la prueba.
Tener las pruebas 'descritas' por los archivos de datos significa que los Analistas de Pruebas
pueden especificar pruebas 'automatizadas' simplemente rellenando uno o más archivos de
datos. Esto da a los Analistas de Pruebas más libertad para especificar pruebas automatizadas
sin depender tanto de los Analistas de Pruebas Técnicas (que pueden ser un recurso escaso).
Contras
La necesidad de gestionar los archivos de datos y asegurarse de que puedan ser leídos por la
SAP es una desventaja, pero se puede abordar de forma adecuada.
También, se pueden pasar por alto casos de prueba negativos importantes. Las pruebas
negativas son una combinación de procedimientos de prueba y datos de prueba. En un
enfoque centrado principalmente en datos de prueba, se pueden omitir " procedimientos de
prueba negativos".
Estas definiciones de prueba son más fáciles de afrontar, ya que se puede determinar la
relación lógica entre las acciones, por ejemplo, "comprobar el estado del pedido" después de
"realizar un pedido" en una prueba de prestaciones o "comprobar el estado del pedido" sin un
"realizar un pedido" previo en una prueba de robustez.
Pros
El uso de una definición de casos de prueba similar a la de un proceso, basada en escenarios,
permite definir los procedimientos de prueba desde una perspectiva de flujo de trabajo. El
objetivo del enfoque basado en procesos es implementar estos flujos de trabajo de alto nivel
utilizando librerías de prueba que representan los pasos de prueba detallados (véase también
el enfoque guiado por palabras clave).
Contras
Los procesos de un SSP pueden no ser fáciles de comprender por un Analista de Pruebas
Técnicas, al igual que la implementación de los guiones orientados al proceso, especialmente
si la herramienta no soporta ninguna lógica de procesos de negocio.
Es preciso también asegurarse de que se implementen los procesos correctos, mediante el uso
de palabras clave correctas. Los procesos de buena calidad serán referenciados por otros
procesos y resultarán en muchas pruebas relevantes, mientras que los procesos de mala
calidad no serán rentables en términos de relevancia, capacidad de detección de errores, etc.
Contras
Se requiere experiencia en modelado para ejecutar un enfoque de pruebas basado en modelos
de manera efectiva. La tarea de modelar abstrayendo las interfaces, los datos y/o el
comportamiento de un SSP puede ser difícil. Además, el modelado y las herramientas de
pruebas basadas en modelos todavía no son una corriente predominante, pero están
madurando. Los enfoques de prueba basados en modelos requieren ajustes en los procesos
de prueba. Por ejemplo, es necesario establecer el papel del diseñador de pruebas. Además,
los modelos utilizados para la generación de pruebas constituyen artefactos importantes para el
aseguramiento de la calidad de un SSP y también deben ser asegurados en términos de
calidad y mantenidos.
En la Figura 2 se presenta el Modelo de Ciclo de Vida de Desarrollo Software básico para la SAP.
Compatibilidad de proceso
Las pruebas de un SSP se deben sincronizar con su desarrollo - y, en el caso de la automatización de
pruebas, se deben sincronizar con el desarrollo de la SAP. Por lo tanto, es conveniente coordinar los
procesos para el desarrollo del SSP, el desarrollo de la SAP y las pruebas. Se puede obtener un gran
beneficio cuando el desarrollo del SSP y la SAP son compatibles en términos de estructura de
procesos, gestión de procesos y soporte de herramientas.
Compatibilidad de equipo
La compatibilidad del equipo es otro aspecto de la compatibilidad entre el desarrollo de la SAP y el
SSP. Si se adopta una mentalidad compatible para abordar y gestionar el desarrollo de la SAP y el
SSP, ambos equipos se beneficiarán de la revisión de los requisitos, diseños y/o artefactos de
desarrollo de cada uno, de la discusión de los problemas y de la búsqueda de soluciones
compatibles. La compatibilidad de los equipos también ayuda en la comunicación e interacción entre
ellos.
Compatibilidad tecnológica
Además, se debe considerar la compatibilidad tecnológica entre la SAP y el SSP. Es beneficioso
diseñar e implementar una interacción sin fisuras entre la SAP y el SSP desde el principio. Incluso si
esto no es posible (por ejemplo, porque no se dispone de soluciones técnicas ni para la SAP ni para
el SSP), puede ser posible una interacción sin fisuras mediante el uso de adaptadores, envolturas u
otras formas de intermediarios.
Compatibilidad de herramientas
Es necesario considerar la compatibilidad entre las herramientas de gestión, desarrollo y
aseguramiento de la calidad de la SAP y el SSP. Por ejemplo, si se utilizan las mismas herramientas
para la gestión de requisitos y/o la gestión de problemas, el intercambio de información y la
coordinación del desarrollo de la SAP y el SSP serán más fáciles.
8
“educción” es la traducción del término “elicitation”.
el SSP o de la SAP, es importante verificar la consistencia entre los dos y comprobar que todos los
requisitos del SSP que deben ser probados por la SAP tienen requisitos de prueba definidos.
La Figura 3 muestra un enfoque en el que los dos procesos del Modelo de Ciclo de Vida de
Desarrollo para el SSP y la SAP se sincronizan, principalmente, en dos fases: (1) El análisis de la
SAP se basa en el diseño del SSP, que a su vez se basa en el análisis del SSP y (2) la prueba del
SSP hace uso de la SAP desplegada.
La Figura 4 muestra un enfoque híbrido con pruebas manuales y automatizadas. Cuando se utilicen
pruebas manuales antes de automatizar las pruebas o cuando se utilicen conjuntamente pruebas
manuales y automáticas, el análisis de la SAP deberá basarse tanto en el diseño del SSP como en
las pruebas manuales. De esta manera, la SAP se sincroniza con ambas. El segundo punto de
sincronización importante para este enfoque es el mismo que antes: la prueba del SSP requiere
pruebas desplegadas, que en el caso de las pruebas manuales podrían ser sólo los procedimientos
de prueba manual que se deben seguir.
Mientras que los aspectos de reutilización ya están resueltos cuando se define la AAP, la SAP puede
ayudar a aumentar la capacidad de reutilización mediante:
Seguir la AAP o revisarla y actualizarla cuando sea necesario.
Documentar los artefactos de la SAP para que sean fáciles de comprender y puedan ser
incorporados en nuevos contextos.
Asegurar la corrección de cualquier artefacto de la SAP para que su uso en nuevos contextos
se apoye en su alta calidad.
Es importante señalar que, si bien el diseño para la reutilización es principalmente una cuestión de la
AAP, el mantenimiento y las mejoras para la reutilización son una preocupación a lo largo de todo el
ciclo de vida de la SAP. Requiere una consideración y un esfuerzo continuos para hacer que se
produzca la reutilización, para medir y demostrar el valor añadido de la reutilización, y para
evangelizar a otros para que reutilicen las SAP's existentes.
Mientras que los primeros cuatro aspectos impactan a la SAP en cualquier nivel de prueba, el último
se aplica principalmente a las pruebas a nivel de componentes y a nivel de integración.
La capacidad de una SAP para probar diferentes configuraciones de productos software se determina
cuando se define la AAP. Sin embargo, la SAP tiene que implementar la capacidad de tratar la
varianza técnica y tiene que permitir la gestión de las prestaciones y componentes de la SAP
necesarios para las diferentes configuraciones de un producto software.
El tratamiento de la variedad de la SAP en relación con la variedad del producto software se puede
abordar de diferentes formas:
Se puede utilizar la gestión de versiones/configuración para la SAP y el SSP para suministrar
las versiones y configuraciones respectivas de la SAP y el SSP que se correspondan
mutuamente.
Se puede utilizar la parametrización de la SAP para ajustar una SAP a una configuración del
SSP.
Es importante señalar que, si bien el diseño de la variabilidad de la SAP es principalmente un asunto
de la AAP, el mantenimiento y las mejoras de la variabilidad son una preocupación a lo largo del ciclo
de vida de la SAP. Se requiere una consideración y esfuerzos continuos para revisar, añadir e incluso
eliminar opciones y formas de variabilidad.
Determinar qué competencias se requieren, cuáles de ellas están disponibles y cuáles faltan.
Planificar el piloto
El proyecto piloto debe ser tratado como un proyecto de desarrollo normal: hacer un plan, reservar
presupuesto y recursos, informar sobre el progreso, definir hitos, etc.. Un punto de atención adicional
es asegurarse de que las personas que trabajan en el despliegue de la SAP (es decir, un defensor9)
pueden invertir suficiente esfuerzo en el despliegue, incluso cuando otros proyectos exigen los
recursos para sus actividades. Es importante tener un compromiso de la dirección, en particular con
respecto a los recursos compartidos. Es probable que estas personas no puedan trabajar a tiempo
completo en el despliegue.
Cuando la SAP no haya sido suministrada por un proveedor, sino que se haya desarrollado
internamente, los desarrolladores correspondientes deberán participar en las actividades de
implementación.
9
“defensor” es la traducción del término “champion”.
Evaluar el piloto
Utilizar a todos los implicados para la evaluación.
4.1.2 Despliegue
Una vez que el piloto ha sido evaluado, la SAP sólo debe ser desplegada al resto del
departamento/organización si el piloto ha sido considerado un éxito. La puesta en marcha debe
llevarse a cabo de forma gradual y bien gestionada. Los factores de éxito para el despliegue incluyen:
Un despliegue incremental: Realice la puesta en marcha al resto de la organización en pasos,
en incrementos. De esta manera, el soporte a los nuevos usuarios llega en "oleadas" más que
en una sola vez. Esto permite que el uso de la SAP aumente en incrementos. Los posibles
cuellos de botella pueden ser identificados y resueltos antes de que se conviertan en
problemas reales. Se pueden añadir licencias cuando sea necesario.
Adaptar y mejorar los procesos para adaptarlos al uso de la SAP: Cuando diferentes usuarios
utilizan la SAP, diferentes procesos entran en contacto con la SAP, y necesitan adaptarse a la
SAP, o la SAP puede necesitar adaptaciones (pequeñas) a los procesos.
Proporcionar formación y orientación/asesoramiento a los nuevos usuarios: Los nuevos
usuarios necesitan formación y orientación en el uso de la nueva SAP. Asegurarse de que esto
esté en su lugar. Se debe proporcionar formación/talleres a los usuarios antes de que utilicen
realmente la SAP.
Definición de directrices de uso: Es posible escribir directrices, listas de comprobación y
preguntas frecuentes para el uso de la SAP. Esto puede evitar extensas preguntas de soporte.
Implementar una forma de recopilar información sobre el uso real: Debería haber una forma
automatizada de recopilar información sobre el uso real de la SAP. Idealmente no sólo el uso
en sí, sino también qué partes de la SAP (ciertas funcionalidades) están siendo utilizadas. De
esta forma, el uso de la SAP se puede monitorizar fácilmente.
Monitorización del uso, beneficios y costes de la SAP: La monitorización del uso de la SAP
durante un cierto período de tiempo indica si la SAP se utiliza realmente. Esta información
también se puede utilizar para volver a calcular el caso de negocio (por ejemplo, cuánto tiempo
se ha ahorrado, cuántos problemas se han evitado).
Proporcionar apoyo a los equipos de prueba y desarrollo de una SAP determinada.
Recopilar las lecciones aprendidas de todos los equipos: Realizar reuniones de
evaluación/retrospectivas con los diferentes equipos que utilizan la SAP. De esta manera, se
pueden identificar las lecciones aprendidas. Los equipos sentirán que sus aportaciones son
necesarias y deseadas para mejorar el uso de la SAP.
Identificación e implementación de mejoras: A partir de la realimentación del equipo y la
monitorización de la SAP, identificar e implementar los pasos para la mejora. Asimismo,
comunicar esto claramente a los implicados.
Hay una serie de estrategias de mitigación de riesgos que pueden emplearse para abordar estas
áreas de riesgo. Éstas se exponen a continuación.
La SAP tiene su propio ciclo de vida de software, tanto si se trata de una solución desarrollada
internamente como si se trata de una solución adquirida. Hay que recordar que la SAP, como
cualquier otro software, necesita estar bajo control de versiones y sus prestaciones documentadas.
De lo contrario, se hace muy difícil desplegar diferentes partes de la misma y hacerlas trabajar juntas,
o trabajar en ciertos entornos.
Además, tiene que haber un procedimiento de despliegue documentado, claro y fácil de seguir. Este
procedimiento depende de la versión; por lo tanto, también debe estar bajo control de versiones.
Antes de comenzar con el primer despliegue de una SAP, es importante asegurarse de que puede
ejecutarse en su propio entorno, de que está aislada de los cambios aleatorios y de que los casos de
prueba se pueden actualizar y gestionar. Tanto la SAP como su infraestructura deben ser objeto de
mantenimiento.
En el caso de un primer despliegue, se necesitan los siguientes pasos básicos:
Definir la infraestructura en la que se ejecutará la SAP.
Crear la infraestructura para la SAP.
Crear un procedimiento para mantener la SAP y su infraestructura.
Crear un procedimiento para mantener el paquete de pruebas que ejecutará la SAP.
Una actualización también conlleva los siguientes riesgos y las correspondientes acciones de
mitigación:
El juego de pruebas necesita cambios para poder ejecutarse en la SAP actualizada: realizar los
cambios necesarios en el juego de pruebas y probarlos antes de desplegarlos en la SAP.
Stubs, controladores e interfaces utilizados en las pruebas deben ser objeto de cambio para
que concuerden con la versión actualizada de la SAP: realizar los cambios necesarios en el
arnés de prueba y probarlo antes de su despliegue en la SAP.
La infraestructura necesita cambiar para adecuarse a la SAP actualizada: hacer una evaluación
de los componentes de la infraestructura que necesitan ser modificados, realizar los cambios y
probarlos con la SAP actualizada.
La SAP actualizada tiene defectos adicionales o problemas de rendimiento: realizar un análisis
de riesgos vs. beneficios. Si los problemas descubiertos hacen imposible actualizar la SAP,
puede ser mejor no proceder con la actualización o esperar a una próxima versión de la SAP.
Si los problemas son poco significativos en comparación con los beneficios, la SAP aún puede
ser actualizada. Se debe crear una nota de entrega con los problemas conocidos para notificar
a los ingenieros de automatización de pruebas y a otros implicados e intentar obtener una
estimación de cuándo se van a solucionar los problemas.
Mantenimiento preventivo: se realizan cambios para que la SAP admita más tipos de pruebas,
pruebe en múltiples interfaces, pruebe múltiples versiones del SSP o soporte la automatización
de pruebas para un nuevo SSP.
Mantenimiento correctivo: se realizan cambios para corregir fallos de la SAP. La mejor manera
de mantener una SAP en operaciones, por lo tanto reduciendo el riesgo en su uso, es a través
de la ejecución de pruebas de mantenimiento regulares.
Mantenimiento perfectivo: la SAP está optimizada y se solucionan los problemas no
funcionales. Pueden abordar el rendimiento de la SAP, su usabilidad, robustez o fiabilidad.
Mantenimiento adaptativo: A medida que se lanzan al mercado nuevos sistemas software
(sistemas operativos, gestores de bases de datos, navegadores web, etc.), puede ser
necesario que la SAP los soporte. Además, puede ser el caso de que la SAP necesite cumplir
con nuevas leyes, regulaciones o requisitos específicos de la industria. En este caso, se
realizan cambios en la SAP para que se adapte en consecuencia. Nota: por lo general, la
conformidad con las leyes y reglamentos crea un mantenimiento obligatorio con normas,
requisitos específicos y, a veces, requisitos de auditoría. Además, a medida que se actualizan
las herramientas de integración y se crean nuevas versiones, los puntos terminales de
integración de herramientas deben mantenerse y conservarse en funcionamiento.
La SAP se debe ejecutar aislada con respecto al entorno de desarrollo, de modo que los
cambios en la SAP no afecten negativamente al entorno de prueba.
La SAP, junto con el entorno, el juego de pruebas y los artefactos de los productos de prueba
deben estar bajo gestión de configuración.
También hay consideraciones para el mantenimiento de los componentes de terceros y otras librerías
como se indica a continuación:
Muy a menudo es el caso de que la SAP utilice componentes de terceros para ejecutar las
pruebas. También puede ocurrir que la SAP dependa de librerías de terceros (por ejemplo, las
librerías de automatización de la interfaz de usuario). Todos los componentes de terceros de la
SAP deben estar documentados y bajo gestión de configuración.
Es necesario tener un plan en caso de que estos componentes externos necesiten ser
modificados o reparados. La persona responsable del mantenimiento de la SAP necesita saber
a quién contactar o dónde remitir un problema.
Debe haber documentación sobre la licencia bajo la cual se utilizan los componentes de
terceros, para que haya información sobre si pueden ser modificados, en qué grado y por
quién.
Para cada uno de los componentes de terceros, es necesario obtener información sobre
actualizaciones y nuevas versiones. Mantener actualizados los componentes y librerías de
terceros es una acción preventiva que compensa la inversión en el largo plazo.
Entre las consideraciones para las normas de nomenclatura y otras convenciones se incluyen:
La idea de los estándares de nomenclatura y otras convenciones tiene una razón simple: el
juego de pruebas y la propia SAP tiene que ser fácil de leer, entender, modificar y mantener.
Esto ahorra tiempo en el proceso de mantenimiento y también minimiza el riesgo de introducir
regresiones o correcciones erróneas que, de otro modo, podrían evitarse fácilmente.
Es más fácil introducir nuevas personas en el proyecto de automatización de pruebas cuando
se utilizan convenciones de nomenclatura estándar.
Los estándares de nomenclatura pueden referirse a variables y archivos, escenarios de prueba,
palabras clave y parámetros de palabras clave. Otras convenciones se refieren a prerrequisitos
y post-acciones para la ejecución de la prueba, el contenido de los datos de prueba, el entorno
de prueba, el estado de ejecución de la prueba y los registros e informes de ejecución.
Todos los estándares y convenciones deben ser acordados y documentados al iniciar un
proyecto de automatización de pruebas.
Es una buena práctica introducir la elaboración de documentación como parte del proceso de
desarrollo. Una tarea no debería considerarse realizada a menos que esté documentada o que
la documentación esté actualizada.
Beneficios de la automatización
Es particularmente importante medir e informar sobre las ventajas de una SAP. Esto se debe a que
los costes (en términos del número de personas involucradas en un período de tiempo determinado)
son fáciles de ver. Las personas que trabajan fuera de las pruebas podrán hacerse una idea del coste
global, pero es posible que no vean los beneficios obtenidos.
Cualquier medición del beneficio dependerá del objetivo de la SAP. Por lo general, esto puede ser un
ahorro de tiempo o esfuerzo, un aumento en la cantidad de pruebas realizadas (amplitud o
profundidad de la cobertura, o frecuencia de ejecución), o alguna otra ventaja como una mayor
repetibilidad, mayor uso de recursos, o menos errores manuales. Las posibles mediciones incluyen:
Número de horas de esfuerzo de prueba manual ahorradas.
Reducción del tiempo para ejecutar pruebas de regresión.
Número de ciclos adicionales de ejecución de pruebas logrados.
Número o porcentaje de pruebas adicionales ejecutadas.
Porcentaje de casos de prueba automatizados con respecto al conjunto completo de casos de
prueba (aunque los casos de prueba automatizados no pueden compararse fácilmente con los
casos de prueba manuales).
Aumento de la cobertura (requisitos, funcionalidad, estructural).
Número de defectos encontrados anteriormente debido a la SAP (cuando se conoce el
beneficio medio de los defectos encontrados anteriormente, éste puede "calcularse" sumando
los costes evitados).
Número de defectos detectados a causa de la SAP que no se habrían detectado mediante
pruebas manuales (por ejemplo, defectos de fiabilidad).
Hay que tener en cuenta que, por lo general, la automatización de las pruebas ahorra esfuerzo
manual de prueba. Este esfuerzo se puede dedicar a otros tipos de pruebas (manuales) (por ejemplo,
pruebas exploratorias). Los defectos detectados por estas pruebas adicionales también pueden verse
como beneficios indirectos de la SAP, ya que la automatización de las pruebas permitió ejecutar estas
pruebas manuales. Sin la SAP estas pruebas no se habrían realizado y, posteriormente, no se
habrían encontrado defectos adicionales.
10
“construcción” es la traducción del término “build”.
Conocer la cobertura del código del SSP proporcionada por los diferentes casos de prueba puede
revelar información útil. Esto también puede medirse a un alto nivel, por ejemplo, la cobertura de
código del conjunto de pruebas de regresión. No existe un porcentaje absoluto que indique una
cobertura adecuada, y el 100% de la cobertura de código es inalcanzable en cualquier otra cosa que
no sea la más simple de las aplicaciones de software. Sin embargo, en general se admite que una
mayor cobertura es mejor, ya que reduce el riesgo general en el despliegue de software. Esta métrica
también puede indicar actividad en el SSP. Por ejemplo, si la cobertura de código disminuye, lo más
probable es que se haya añadido funcionalidad al SSP, pero que no se haya añadido el caso de
prueba correspondiente al juego de pruebas automatizado.
Métricas de tendencia
Con muchas de estas métricas, son las tendencias (es decir, la forma en que las medidas cambian
con el tiempo) las que pueden ser más valiosas de informar que el valor de una medición en un
momento específico. Por ejemplo, saber que el coste medio de mantenimiento por cada prueba
automatizada que requiere mantenimiento es superior al de las dos versiones anteriores del SSP
puede dar lugar a la adopción de medidas para determinar la causa del aumento y tomar medidas
para invertir la tendencia.
El coste de la medición debe ser lo más bajo posible y esto puede lograrse a menudo automatizando
la recogida y la presentación de informes.
Integración con otras herramientas de terceros (hojas de cálculo, XML, documentos, bases de
datos, herramientas de informes, etc.)
Cuando la información de la ejecución de casos de prueba automatizados se utiliza en otras
herramientas (para el seguimiento y la presentación de informes, por ejemplo, la actualización de la
matriz de trazabilidad), es posible proporcionar la información en un formato adecuado para estas
herramientas de terceros. Esto se logra a menudo a través de la funcionalidad de la herramienta de
prueba existente (formatos de exportación de informes) o mediante la creación de informes
personalizados que se generan en un formato coherente con otros programas (".xls" para Excel,
".doc" para Word, ".html" para Web, etc.).
Capturas de pantalla y otras capturas visuales pueden ser guardadas durante la ejecución de la
prueba para su uso posterior durante el análisis del fallo.
Cuando un caso de prueba detecta un fallo, la SAP debe asegurarse de que toda la
información necesaria para analizar el problema está disponible/almacenada, así como
cualquier información relativa a la continuación de la prueba, si procede. La SAP debe
almacenar en un lugar seguro cualquier volcado de memoria y trazas de pila asociados.
También cualquier archivo de registro que pueda sobrescribirse (memorias intermedias cíclicas
se utilizan a menudo para archivo de registro en el SSP) debe copiarse a esta ubicación, donde
estarán disponibles para su análisis posterior.
El uso de colores puede ayudar a distinguir diferentes tipos de información registrada (por
ejemplo, errores en rojo, información de progreso en verde).
Toda la información de los diferentes registros debe poder ser fácilmente consultable. Un problema
identificado en el archivo de registro por la SAP debe identificarse fácilmente en el archivo de registro
del SSP, y viceversa (con o sin herramientas adicionales). La sincronización de varios registros con
una marca de tiempo facilita la correlación de lo que ocurrió cuando se informó un error.
Es necesario saber qué pruebas han fallado y las razones del fallo. Para facilitar el diagnóstico, es
importante conocer el historial de la ejecución de la prueba y quién es el responsable de la misma
(generalmente la persona que la creó o la actualizó por última vez). La persona responsable debe
investigar la causa del fallo, informar de los problemas relacionados con el mismo, hacer un
seguimiento de la resolución del problema y comprobar que la resolución se ha aplicado
correctamente.
Los informes también se utilizan para diagnosticar cualquier fallo de los componentes del MTAP
(véase el Capítulo 7).
Frecuencia de uso
La frecuencia con la que se debe realizar una prueba es una consideración en cuanto a la viabilidad
de automatizar o no. Las pruebas que se ejecutan más regularmente, como parte de un ciclo de
entrega mayor o menor, son mejores candidatos para la automatización, ya que se utilizarán con
frecuencia. Por regla general, cuanto mayor sea el número de entregas de aplicaciones y, por lo
tanto, los ciclos de prueba correspondientes, mayor será el beneficio de automatizar las pruebas.
A medida que las pruebas funcionales se automatizan, pueden utilizarse en versiones posteriores
como parte de las pruebas de regresión. Las pruebas automatizadas utilizadas en las pruebas de
regresión proporcionarán un alto retorno de la inversión (ROI por sus siglas en inglés) y mitigación de
riesgos para la base de código existente.
Si se ejecuta un guion de prueba una vez al año, y el SST cambia dentro del año, puede no ser
factible o eficiente crear una prueba automatizada. El tiempo que podría requerir la adaptación anual
de la prueba para ajustarse al SST podría hacerse mejor de forma manual.
11
“retorno de la inversión” es la traducción del término “return of investment” o “ROI” por sus siglas en inglés.
Roles y responsabilidades
La automatización de pruebas debe ser una actividad en la que todos puedan participar. Sin
embargo, esto no significa que todos deban desempeñar el mismo rol. Diseñar, implementar y
mantener un entorno de pruebas automatizadas es de naturaleza técnica y, como tal, debe estar
reservado a personas con sólidos conocimientos de programación y trayectoria técnica. Los
resultados de un esfuerzo de desarrollo de pruebas automatizadas deben ser un entorno que pueda
ser utilizado por personas tanto técnicas como no técnicas por igual. Con el fin de maximizar el valor
de un entorno de pruebas automatizadas, es necesario contar con personas con conocimientos
especializados en el dominio de pruebas y competencias en esta materia, ya que será necesario
desarrollar guiones de prueba adecuados (incluidos los datos de prueba correspondientes). Éstos se
utilizarán para controlar el entorno automatizado y proporcionar una cobertura de pruebas específica.
Los expertos en el dominio revisan los informes para confirmar la funcionalidad de la aplicación,
mientras que los expertos técnicos se aseguran de que el entorno automatizado funcione correcta y
eficientemente. Estos expertos técnicos también pueden ser desarrolladores con interés en las
pruebas. La experiencia en el desarrollo de software es esencial para diseñar software que sea
mantenible, y esto es de suma importancia en la automatización de pruebas. Los desarrolladores
pueden concentrarse en el marco de trabajo de automatización de pruebas o en las librerías de
prueba. La implementación de los casos de prueba debe permanecer en manos de probadores.
Esfuerzos paralelos
Como parte de las actividades de transición, muchas organizaciones crean un equipo paralelo para
comenzar el proceso de automatización de los guiones de prueba manuales existentes. Los nuevos
guiones automatizados se incorporan al esfuerzo de prueba, reemplazando los guiones manuales.
Sin embargo, antes de hacerlo, a menudo, se recomienda comparar y validar que el guion
automatizado esté realizando la misma prueba y validación que el guion manual que esta
reemplazando.
En muchos casos, se realizará una evaluación de los guiones manuales antes de la conversión a la
automatización. Como resultado de esa evaluación, podría determinarse que es necesario
reestructurar los guiones de prueba manuales existentes para adoptar un enfoque más eficiente y
eficaz en el marco de la automatización.
Informes de automatización
Hay varios informes que pueden ser generados de forma automática por una SAP. Éstos incluyen el
estado de paso/fallo de guiones individuales o pasos dentro de un guion, las estadísticas generales
de ejecución de pruebas y el desempeño general de la SAP. Es igualmente importante tener
visibilidad en la operación correcta de la SAP para que cualquier resultado específico de la aplicación
que sea informado pueda ser considerado exacto y completo (Ver Capítulo 7): Verificación de la
SAP).
Solapamiento funcional
Al automatizar las pruebas de regresión existentes, es una buena práctica identificar cualquier
solapamiento funcional que pudiera haber entre los casos de prueba y, en la medida de lo posible,
reducir ese solapamiento en la prueba automatizada equivalente. Esto proporcionará mayores
eficiencias en el tiempo de ejecución de las pruebas automatizadas, que serán significativas a medida
que se ejecuten más y más casos de pruebas automatizados. A menudo, las pruebas desarrolladas
utilizando la automatización adoptarán una nueva estructura ya que dependen de componentes
reutilizables y repositorios de datos compartidos. No es raro descomponer las pruebas manuales
existentes en varias pruebas automatizadas más pequeñas. Asimismo, la consolidación de varias
pruebas manuales en una prueba automatizada más extensa puede ser la solución adecuada. Las
pruebas manuales necesitan ser evaluadas individualmente, y como grupo, para que se pueda
desarrollar una estrategia de conversión efectiva.
Compartir datos
A menudo, las pruebas comparten datos. Esto puede ocurrir cuando las pruebas utilizan el mismo
registro de datos para ejecutar diferentes funcionalidades del SSP. Un ejemplo de esto podría ser el
caso de prueba "A", que verifica el tiempo de vacaciones disponible de un empleado, mientras que el
caso de prueba "B" podría verificar a qué cursos asistió el empleado como parte de sus objetivos de
desarrollo profesional. Cada caso de prueba utiliza el mismo empleado, pero verifica parámetros
diferentes. En un entorno de pruebas manuales, los datos de los empleados se suelen duplicar
muchas veces a través de cada caso de prueba manual que verifica los datos de los empleados
utilizando este empleado. Sin embargo, en una prueba automatizada, los datos que se comparten se
deben, siempre que sea posible y factible, almacenar y acceder a ellos desde una sola fuente para
evitar la duplicación o la introducción de errores.
Precondiciones de prueba
A menudo no se puede ejecutar una prueba antes de establecer las condiciones iniciales. Estas
condiciones pueden incluir la selección de la base de datos correcta o el conjunto de datos de prueba
desde el cual realizar la prueba, o el establecimiento de valores o parámetros iniciales. Muchos de
estos pasos de inicialización son necesarios para determinar que una precondición de prueba puede
ser automatizada. Esto permite una solución más fiable y sólida cuando estos pasos no se pueden
omitir antes de la ejecución de las pruebas. A medida que las pruebas de regresión se convierten a la
automatización, estas precondiciones deben ser parte del proceso de automatización.
Pruebas ejecutables
Antes de convertir una prueba de regresión manual en una prueba automatizada, es importante
verificar que la prueba manual funciona correctamente. Esto proporciona el punto de partida correcto
para asegurar una conversión exitosa a una prueba de regresión automatizada. Si la prueba manual
no se ejecuta de forma correcta, ya sea porque está mal redactada, utiliza datos no válidos, no está
actualizada o no está sincronizada con el SSP actual, o como resultado de un defecto del SSP,
convertirla a la automatización antes de comprender y/o resolver la causa raíz del fallo creará una
prueba automatizada que no funciona, lo cual es un desperdicio e improductivo.
automatización de pruebas para verificar la nueva funcionalidad. Para obtener más información,
consulte la Sección 2.3, Diseño para Capacidad de ser Probado y Automatización.
12
“preparación es la traducción del término “setup”.
diferente al del mundo real. Por otro lado, es muy fácil y económico realizar pruebas
automatizadas a través de interfaces de programación de aplicación (API por sus siglas en
inglés). La prueba del SSP a través de interfaces de prueba puede ser un enfoque sólido,
siempre y cuando se comprenda el riesgo potencial.
Un alto nivel de intrusión puede presentar fallos durante las pruebas que no se observan en
condiciones reales de uso. Si esto causa fallos en las pruebas automatizadas, la confianza en la
solución de automatización de pruebas puede verse reducida de forma drástica. Los desarrolladores
pueden requerir que los fallos identificados por las pruebas automatizadas se reproduzcan primero
manualmente, si es posible, para ayudar en su análisis.
Verificación de nuevas pruebas que se centran en las nuevas prestaciones del marco de
trabajo
La primera vez que se utiliza una nueva prestación de la SAP en casos de prueba, se debería
verificar y monitorizar de cerca para asegurar que la prestación funciona correctamente.
Los fallos intermitentes necesitan ser analizados. El problema puede estar en el propio caso de
prueba o en el marco de trabajo (o incluso puede ser un problema en el SST). El análisis del archivo
de registro (del caso de prueba, el marco de trabajo y el SST) puede identificar la causa raíz del
problema. También puede ser necesario depurar. Puede ser necesario el soporte del analista de
pruebas, el desarrollador de software y el experto en el dominio para encontrar la causa raíz.
13
“condiciones de carrera” es la traducción del término “race conditions”.
Palabras Clave
mantenimiento
Objetivos de Aprendizaje para Mejora Continua
Opciones para Mejorar la Automatización de Pruebas
NA-IAP-8.1.1 (K4) Analizar los aspectos técnicos de una solución de automatización de pruebas
implementada y ofrecer recomendaciones para mejorarla.
Adaptación de la Automatización de Pruebas al Entorno y a Cambios del SSP
NA-IAP-8.2.1 (K4) Analizar el software de pruebas automatizadas, incluidos los componentes del
entorno de pruebas, las herramientas y las librerías de funcionalidades de soporte,
con el fin de comprender dónde se deben realizar la consolidación y las
actualizaciones de acuerdo con un conjunto determinado de entornos de prueba o
cambios en el SSP.
Guiones
Los enfoques basados en lenguajes de guion varían desde el enfoque estructurado simple de los
enfoques basados en datos hasta los enfoques basados en palabras clave más sofisticados, como se
describe en la Sección 3.2.2. Puede ser conveniente actualizar el actual enfoque de guion de la SAP
para todas las nuevas pruebas automatizadas. El enfoque podrá adaptarse a todas las pruebas
automatizadas existentes o, al menos, a aquellas que supongan un mayor esfuerzo de
mantenimiento.
En lugar de cambiar por completo el enfoque basado en guion, las mejoras de la SAP se pueden
concentrar en la implementación de guiones. Por ejemplo:
Evaluar el solapamiento de casos/pasos/procedimientos de prueba en un esfuerzo por
consolidar las pruebas automatizadas.
Los casos de prueba que contienen secuencias de acciones similares no deberían implementar
estos pasos varias veces. Estos pasos deben convertirse en una función y añadirse a una
librería, para que puedan ser reutilizados. Estas funciones de librería14 pueden ser utilizadas
por diferentes casos de prueba. Esto aumenta la mantenibilidad del producto de prueba.
Cuando los pasos de la prueba no son idénticos sino similares, puede ser necesaria la
parametrización.
Nota: este es un enfoque típico en las pruebas guiadas por palabras clave.
Establecer un proceso de recuperación de errores para la SAP y el SSP.
Cuando se produce un error durante la ejecución de casos de prueba, la SAP debería poder
recuperarse de esta condición de error para poder continuar con el siguiente caso de prueba.
Cuando se produce un error en el SSP, la SAP debe ser capaz de realizar las acciones de
recuperación necesarias en el SSP (por ejemplo, un reinicio del SSP completo).
Evaluar los mecanismos de espera para asegurar de que se está utilizando el mejor tipo. Hay
tres mecanismos de espera habituales:
1. Las esperas incrustadas en el código15 (esperar un cierto número de milisegundos)
pueden ser la causa raíz de muchos problemas de automatización de pruebas.
14
“funciones de librería” es la traducción de “library functions”.
15
“espera incrustada en el código” es la traducción del término “hard-coded wait”.
Ejecución de la Prueba
Cuando un juego de pruebas de regresión automatizadas no se termina en una noche, no debería ser
una sorpresa. Cuando la prueba se prolonga demasiado tiempo, puede ser necesario realizarla de
forma concurrente en diferentes sistemas, pero esto no siempre es posible. Cuando se utilizan
sistemas objetivo16 de alto coste para las pruebas, puede ser una restricción que todas las pruebas se
realicen en un único objetivo. Puede ser necesario dividir el conjunto de pruebas de regresión en
varias partes, cada una de las cuales se ejecutará en un período de tiempo definido (por ejemplo, en
una sola noche). Un análisis más detallado de la cobertura de la prueba automatizada puede revelar
que hay duplicación. Eliminar la duplicación puede reducir el tiempo de ejecución y aumentar la
eficiencia. Un análisis más detallado de la cobertura de la prueba automatizada puede revelar que
hay duplicación. Eliminar la duplicación puede reducir el tiempo de ejecución y aumentar la eficiencia.
16
“sistema objetivo” es la traducción del término “target system”.
Verificación
Antes de crear nuevas funciones de verificación, es conveniente adoptar un conjunto de métodos de
verificación estándar para todas las pruebas automatizadas. Esto evitará que se vuelvan a
implementar las acciones de verificación a través de múltiples pruebas. Cuando los métodos de
verificación no son idénticos sino similares, el uso de la parametrización ayudará a que la función se
pueda utilizar en múltiples tipos de objetos.
Arquitectura
Puede ser necesario cambiar la arquitectura para dar soporte a mejoras de la capacidad de ser
probado del SSP. Estos cambios se pueden realizar en la arquitectura del SSP y/o en la arquitectura
de la automatización. Esto puede proporcionar una mejora importante en la automatización de
pruebas, pero puede requerir cambios significativos e inversiones en el SSP/la SAP. Por ejemplo, si
el SSP va a ser modificado para aportar Interfaces de Programación de Aplicaciones para las
pruebas, entonces la SAP también debería ser refactorizada en consecuencia. Agregar este tipo de
características en una etapa posterior puede ser bastante costoso; es mucho mejor pensar en esto al
comienzo de la automatización (y en las etapas iniciales del desarrollo del SSP - ver Sección 2.3
Diseño para Capacidad de ser Probado y Automatización).
Preprocesamiento y postprocesamiento
Proporcionar tareas de preparación y desarmado estándar. También se conocen como
preprocesamiento (preparación) y postprocesamiento (desarmado). Esto ahorra las tareas que se
implementan repetidamente para cada prueba automatizada, no sólo reduciendo los costes de
mantenimiento, sino también el esfuerzo necesario para implementar nuevas pruebas automatizadas.
Documentación
Esto cubre todas las formas de documentación desde la documentación del guion (qué hacen los
guiones, cómo deben usarse, etc.), la documentación para el usuario de la SAP, y los informes y
registros producidos por la SAP.
Prestaciones de la SAP
Añadir prestaciones y funciones adicionales a la SAP, como informes detallados, registros,
integración con otros sistemas, etc. Añadir nuevas prestaciones sólo cuando se vayan a utilizar. Si se
añaden prestaciones que no se utilizan, sólo aumenta la complejidad y disminuye la fiabilidad y la
mantenibilidad.
17
“actualizar” es la traducción del término “update”.
18
“mejorar” es la traducción del término “upgrade” cuando se encuentra junto a término “update”. En otros casos, “update” y
“upgrade” se pueden traducir como “actualizar”.
9. Referencias
9.1 Estándares
Los estándares para la automatización de pruebas incluyen pero no se limitan a:
La notación Testing and Test Control Notation (TTCN-3) del ETSI (European
Telecommunication Standards Institute) e ITU (International Telecommunication Union) está
compuesta por:
ES 201 873-1: TTCN-3 Core Language
ES 201 873-2: TTCN-3 Tabular Presentation Format (TFT)
ES 201 873-3: TTCN-3 Graphical Presentation Format (GFT)
ES 201 873-4: TTCN-3 Operational Semantics
ES 201 873-5: TTCN-3 Runtime Interface (TRI)
ES 201 873-6: TTCN-3 Control Interface (TCI)
ES 201 873-7: Using ASN.1 with TTCN-3
ES 201 873-8: Using IDL with TTCN-3
ES 201 873-9: Using XML with TTCN-3
ES 201 873-10: TTCN-3 Documentation
ES 202 781: Extensions: Configuration and Deployment Support
ES 202 782: Extensions: TTCN-3 Performance and Real-Time Testing
ES 202 784: Extensions: Advanced Parameterization
ES 202 785: Extensions: Behaviour Types
ES 202 786: Extensions: Support of interfaces with continuous signals
ES 202 789: Extensions: Extended TRI
The Automatic Test Markup Language (ATML) by IEEE (Institute of Electrical and Electronics
Engineers) consisting of
IEEE Std 1671.1: Test Description
IEEE Std 1671.2: Instrument Description
IEEE Std 1671.3: UUT Description
IEEE Std 1671.4: Test Configuration Description
IEEE Std 1671.5: Test Adaptor Description
IEEE Std 1671.6: Test Station Description
IEEE Std 1641: Signal and Test Definition
The UML Testing Profile (UTP) by OMG (Object Management Group) specifying test
specification concepts for
Test Architecture
Test Data
Test Behavior
Test Logging
Test Management
Identificador Referencia
ISTQB-AL-TM ISTQB Certified Tester, Advanced Level Syllabus, Test Manager, Versión
2012, disponible en [ISTQB-Web]
ISTQB-AL-TTA ISTQB Certified Tester, Advanced Level Syllabus, Technical Test Analyst,
Versión 2012, disponible en [ISTQB-Web]
[Baker08] Paul Baker, Zhen Ru Dai, Jens Grabowski and Ina Schieferdecker, “Model-
Driven Testing: Using the UML Testing Profile”, Springer 2008 edition, ISBN-
10: 3540725628, ISBN-13: 978-3540725626
[Dustin99] Efriede Dustin, Jeff Rashka, John Paul, “Automated Software Testing:
introduction, management, and performance”, Addison-Wesley, 1999, ISBN-
10: 0201432870, ISBN-13: 9780201432879
[Fewster&Graham99] Mark Fewster, Dorothy Graham, “Software Test Automation: Effective use of
test execution tools”, ACM Press Books, 1999, ISBN-10: 0201331403, ISBN-
13: 9780201331400
[Mosley02] Daniel J. Mosley, Bruce A. Posey, “Just Enough Software Test Automation”,
Prentice Hall, 2002, ISBN-10: 0130084689, ISBN-13: 9780130084682
[Willcock11] Colin Willcock, Thomas Deiß, Stephan Tobies and Stefan Keil, “An
Introduction to TTCN-3” Wiley, 2nd edition 2011, ISBN-10: 0470663065,
ISBN-13: 978-0470663066
ISTQB-Web Sitio web del International Software Testing Qualifications Board. Refiérase a
este sitio web para el último Glosario y programas de estudio del ISTQB.
www.istqb.org
A cada capítulo del programa de estudios se le asigna un tiempo en minutos. El propósito de esto es
orientar sobre la proporción relativa de tiempo que debe asignarse a cada sección en un curso
acreditado y dar un tiempo mínimo aproximado para la enseñanza de cada sección.
Es posible que los proveedores de formación dediquen más tiempo del indicado y que los candidatos
vuelvan a dedicar más tiempo a la lectura e investigación. El desarrollo de un curso no tiene que
seguir el mismo orden que el programa de estudio. No es necesario realizar el curso en un bloque de
tiempo continuo.
La siguiente tabla proporciona una guía para la enseñanza y los tiempos para realizar ejercicios para
cada capítulo (todos los tiempos se muestran en minutos).
Capítulo Minutos
0. Introducción 0
1. Introducción y Objetivos para la Automatización de 30
2. Preparación para la Automatización de la Prueba 165
3. La Arquitectura de Automatización de Pruebas Genérica 270
4. Riesgos y Contingencias del Despliegue 150
5. Información y Métricas de Automatización de Pruebas 165
6. Transición de Pruebas Manuales a un Entorno 120
7. Verificación de la SAP 120
8. Mejora Continua 150
Total: 1170
El tiempo total de un curso en jornadas, basado en una media de siete horas por día laborable, es: 2
días, 5 horas, 30 minutos.