Automatización de pruebas
funcionales estimación de esfuerzo
Uno de los errores más comunes en
los equipos de automatización de pruebas es que no se elijen los casos de
prueba adecuados para la automatización. Otro error común es pretender
automatizar todo olvidando que los scripts de automatización deberían ser un
apoyo a las pruebas manuales y no el remplazo de ellas.
Como sea, para hacer una correcta
elección de los casos de prueba a ser automatizados, se debe tener en cuenta
dos factores fundamentales. El primero, es la complejidad que tiene los casos
de prueba a automatizar ya que el esfuerzo inicial es elevado; y el segundo, el
retorno de la inversión (ROI) para el negocio que tenga cada uno de los scripts.
En nuestro caso, vamos a
enfocarnos en la complejidad ya que el ROI es propio de cada empresa. Podemos
encontrar casos de pruebas simples, medios y complejos, esta complejidad la da
el número de pasos (acciones) y verificaciones que tenga cada uno de ellos. Se
puede realizar una tabla con la mostrada en la figura donde definamos la
complejidad de cada uno de los casos de prueba.
Sl. No
|
Complejidad del caso de prueba
|
Numero de acciones
|
Numero de verificaciones
|
Buen candidato (~ No de ejecuciones)
|
1
|
Simple
|
< 5
|
< 5
|
> 15 ejecuciones
|
2
|
Medio
|
> 5 - < 15
|
> 5 - < 10
|
> 8 - 10 ejecuciones
|
3
|
Complejo
|
> 15 - < 25
|
> 10 - < 15
|
> 5 - 8 ejecuciones
|
Como elegir un buen
candidato de automatización
Tenga en cuenta que los scripts
comprenden tanto los pasos de las acciones como los puntos de verificación (o
los resultados esperados). Las acciones suelen ser métodos directos o llamados
a funciones del lenguaje de la herramienta de automatización, sin embargo los
puntos de verificación no son de ese tipo y son más complejos.
¿Por qué se necesita
automatizar las pruebas paulatinamente?
La mayoría de los proyectos de automatización de pruebas que
fallan, se debe principalmente al rápido cambio de las aplicaciones, los casos de
pruebas inadecuados, los frameworks inestables y los issues en los scripts.
El análisis de la causas nos
muestra la necesidad de automatizar las pruebas en fases. La automatización de
pruebas necesita un kick off en los casos de prueba críticos que son buenos
candidatos a automatizar y luego lentamente ir extendiendo a los casos de
pruebas medios. Esto ayuda al cliente a tener costos más bajos de
mantenimiento.
Asimismo, recuerde que el
framework debe actualizarse constantemente a lo largo de un proceso desarrollo
de scripts y por lo tanto se hace más difícil mantener el framework en el caso
que se tengan muchos scripts que se desarrollan en paralelo.
¿Qué tipo de prueba
para ser automatizado?
Siempre es bueno hacer los
scripts de las casos de pruebas funcionales de "integración y / o
sistema", ya que la mayoría de los casos de prueba de nivel de componentes
se hacen con ellos. Esto reduciría su esfuerzo al final y encontrará defectos.
Tenga en cuenta que si usted tiene buen framework, entonces usted puede cambiar
el alcance de la prueba y / o el tipo de prueba con los archivos de
configuración.
Factores que
afectan la estimación de automatización de pruebas.
Los siguientes factores pueden tener diversos efectos en la
estimación o en el cálculo del esfuerzo de la automatización de pruebas.
Si. No
|
Tipo
|
Factor
|
Impacto
|
Observaciones
|
1
|
Framework
|
Disponibilidad
|
Alto
|
Un buen
framework permite que los scripts, la depuración y el mantenimiento sean más fáciles.
También, un framework necesita actualización constante durante el desarrollo
de los scripts.
|
2
|
Aplicación
|
Repetir la
funcionalidad
|
Alto
|
Es más fácil
automatizar en los casos donde la funcionalidad se repite a través de toda la
aplicación (Se recomienda usar keyword driven en estos casos, para no
terminar escribiendo más métodos o funciones para acciones o verificaciones).
Si no, el esfuerzo de construir más librerías o scripts será naturalmente
lineal.
|
3
|
Proyecto
|
Alcance de la
prueba
|
Alto
|
Si la
complejidad de la aplicación así como el alcance de la prueba es muy complejo,
entonces consumirá un gran esfuerzo para automatizar cada caso de prueba.
|
4
|
Herramienta de
automatización
|
Soporte de UAT
|
Medio
|
La herramienta
de automatización de pruebas a ser usada puede no soportar alguna
funcionalidad de la aplicación y puede causar sobre costos. Puede que resulte
más difícil empezar a trabajar con herramientas de código abierto.
|
5
|
Scripter
|
Habilidad
|
Medio
|
La adecuada
habilidad de un automatizador es
fundamental para cualquier proceso de automatización de pruebas. No olvide
añadir el costo de la curva de
aprendizaje al costo total del proyecto.
|
6
|
Aplicación
|
Objetos personalizados
|
Medio
|
El número de
objetos personalizados en el alcance de la automatización cobra importancia
si causa un sobre esfuerzo para el equipo de automatización construir y
mantener las librerías para ellos.
|
7
|
Aplicación
|
Tipo (Web/
Cliente-Servidor / Mainframe)
|
Medio
|
Para cada tipo
de aplicación existen herramientas de automatización con una gran utilidad y
soporte, pero para algunos casos es necesario un gran esfuerzo en la
construcción de librerías.
|
8
|
Aplicación
|
Lenguaje de
desarrollo
|
Bajo
|
No importa la
herramienta seleccionada en la prueba no es compatible con los puntos de
control específicos de verificación.
|
Agrupación pasos para determinar la
complejidad.
Este es un ejercicio importante, ya que podrán calcular el
esfuerzo con base en un análisis de profundidad.
Paso 1:
Se sugiere encontrar el número de acciones y los puntos de
verificación para cada caso de prueba (que están en el alcance de
automatización), entonces dibuje un cuadro para encontrar las acciones
promedio, los puntos de verificación y los límites de control para ellos. Así
que la derivación complejidad se basa en la AUT y no se basa en los estándares genéricos
de la industria.
Ejemplo,
Paso 2:
Basado en la grafica,
Promedio de pasos
contados = 16
Control limite
bajo =
08
Control limite
alto = 25
Entonces la complejidad
puede ser agrupada como:
Simple ≤
7 Pasos
Media ≥
8 Pasos -- ≤ 16 Pasos
Compleja ≥
17 Pasos -- ≤ 25 Pasos
Recomendaciones:
Ningún grupo de pasos del caso de prueba debe ser
demasiado cerrado o demasiado amplio para etiquetar la complejidad.
Tenga en
cuenta que el esfuerzo de desarrollo de pre-escritura para cada secuencia de
comandos de prueba es considerable como las siguientes actividades que consumen
tiempo.
Ejecutar
los casos de prueba manualmente antes de construir los scripts para garantizar
la correcta operación
La
selección o generación de los datos de prueba para los scripts.
La
creación de plantillas de los scripts (como la información del encabezado,
comentarios de los pasos, la identificación de los componentes reutilizables a
ser utilizado desde el repositorio y así sucesivamente.)
Estos
esfuerzos son basados en el número de pasos en el caso de prueba. Tenga en
cuenta que si el caso de prueba varía en función de un menor número de pasos, este
esfuerzo no se desvía mucho, pero en caso que varíe por muchos pasos, este
esfuerzo difiere ampliamente.
- También otro
factor para determinar la complejidad es la repetición de la funcionalidad. Si
el caso de prueba es complejo por pasos pero la funcionalidad es la misma que la de otro caso entonces puede
ser etiquetado como “Medio o Simple”
- Si los pasos
contados del caso están por encima del limite de control (~ 25 en este caso)
estos pasos adicionales necesitan ser considerados como otro caso. Por ejemplo,
el TC – 06 contiene 30 pasos este debe ser llamado como “1 Complejo + 1 simple
(30 – 25)” casos de pruebas.
Si el caso es marcado como “Complejo” en vez de
“Medio”, entiéndase que su esfuerzo sube e impacta el proyecto. Explicado de
otra manera, esto también lo impactará a usted. Esto se puede llamar como “Agrupamiento de
la complejidad”.
Característica soportada
Característica soportada (más detalle al pasar el mouse por encima)
Desconocida
