Proyecto: Sitio Web Quality Stream
Estrategia de Prueba Automatizadas
Historia de revisiones
Tabla de Contenidos
[Link]ón
2. Alcance
3. Roles y Responsabilidades
5. Ambiente y Herramientas de Pruebas
5.1 Herramientas de Pruebas
5.2 Arquitectura del framework de automatización
5.3 Ambiente de Pruebas
6. Criterios de Entrada y Salida
6.1 Criterios de Entrada
6.2 Criterios de Salida
7. Planificación de ejecución de las pruebas
7.1 Planificación de las Pruebas de Regresión
8. Reporte de Pruebas
[Link]ón
En esta Estrategia para la realización de pruebas automatizadas se describe el alcance de las
pruebas, el ambiente de pruebas, los recursos necesarios, las herramientas a utilizar, los
riesgos, planes de contingencia y el calendario de ejecución de las pruebas del proyecto
Quality_Stream.
2. Alcance
Se realizarán pruebas de caja negra (automatizadas) a las funcionalidades seleccionadas
durante la planificación de cada sprint.
Las funcionalidades a ser automatizadas serán seleccionadas utilizando los criterios de la Lista
de Chequeo “Qué casos de pruebas automatizar”. Ver Video ( Introducción a la Automatización
de Pruebas de Software [Link]
3. Roles y Responsabilidades
Roles Responsabilidades
Manager de QA Planificación y monitoreo de las pruebas
automatizadas
Reporte de Defectos
Reporte de progreso de las pruebas
Ingeniero QA de Automatización/ Diseño e implementación de las pruebas.
Analista QA Ejecución de las pruebas automatizadas.
Reporte de resultados de las pruebas.
Product Owner/Stakeholders Toma de decisiones
4. Riesgos y Planes de Contingencia
No Riesgos Probabilidad Impacto Severidad Plan de Contingencia
de (1-5) (Prob*Impa
Ocurrencia cto)
(1-5)
1 Funcionalidades no 2 5 10 Re planificar las
terminadas en el tiempo funcionalidades para ser
automatizadas (sección
estimado no pueden
7)
formar parte de las
funcionalidades
planificadas para ser
automatizadas en el
sprint actual
2 Solicitud de cambios en 3 3 9 Estimar el tiempo del
aquellas funcionalidades cambio y volver a
priorizar la lista de
que ya tienen casos de
funcionalidades a ser
pruebas automatizados. automatizadas en el
Esto ocasiona re trabajo sprint.
debido a que se deben
actualizar estos scripts.
5. Ambiente y Herramientas de Pruebas
5.1 Herramientas de Pruebas
Herramienta Función
Selenium WebDriver API para automatizar sistemas Web
JUnit testing framework Ejecución y Reporte de las pruebas
Maven Creación de la estructura de proyectos y uso
e importación de librerías
Chromedriver Crea una instancia del navegador
Chrome
Geckodriver Crea una instancia del navegador Mozilla
Firefox
5.2 Arquitectura del framework de automatización
Utilizaremos el patrón Page Object Model (Ver Video: Page Object Model con Selenium
WebDriver | Paso a paso [Link] para “mapear” las páginas del sistema
a clases “Page” que permitan aislar las acciones de las diferentes páginas y a la vez agrupar
todos los webElements de una página y las acciones que se pueden llevar a cabo, en una
misma clase.
La clase “Base” permite aislar todo el framework de la versión del API de Selenium WD que
estemos utilizando. De esta forma si hay algún cambio en los comandos del API no tenemos
que cambiar todas las clases sino solo la clase “Base”.
El Page Object Model también nos ayuda a concentrar los localizadores en estas clases
“Page”, de forma que cuando el sistema cambia y es necesario actualizar el código de los css
selectors, xpath o lo que hayamos utilizado para localizar los webElements, solo tenemos que
cambiarlo una sola vez en la clase “Page” y los “Tests”, que son el último nivel, no necesitan
ningún cambio (a menos que haya cambiado la lógica de funcionamiento y dentro de los
cambios se hayan eliminado o agregado funcionalidades al sistema).
5.3 Ambiente de Pruebas
Navegadores Chrome, Mozilla Firefox
Sistemas Operativos Windows
6. Criterios de Entrada y Salida
6.1 Criterios de Entrada
Las funcionalidades deben estar desplegadas en el ambiente de QA y haber sido probadas
manualmente.
El framework de pruebas está instalado y listo para la ejecución
El ambiente de QA está disponible.
Los defectos críticos encontrados durante las pruebas manuales han sido resueltos y cerrados.
6.2 Criterios de Salida
Ejecución de todos los casos de pruebas automatizados
Se ha logrado la suficiente cobertura de los requerimientos y funcionalidades bajo pruebas
Ningún defecto de severidad alta se encuentra abierto.
7. Planificación de ejecución de las pruebas
Lista de funcionalidades a ser automatizadas por Sprint
Sprint número Funcionalidades Comentarios
1 Insertar comentario en un Post
Las pruebas de automatización normalmente comenzarán en la segunda semana del Sprint (de
2 semanas).
Es necesario que las funcionalidades a automatizar se desarrollen, implementen y prueben
manualmente para que tengan un nivel determinado de estabilidad cuando comienzan las
tareas de automatización.
7.1 Planificación de las Pruebas de Regresión
Las suites de regresión se ejecutarán al final de cada Sprint (antes de la Revisión del Sprint), al
realizarse un cambio o por solicitud de los Clientes, Product Owner y Project Manager.
8. Reporte de Pruebas
El Reporte automático de pruebas se obtendrá a través de JUnit. Este Reporte informará sobre
los resultados de la ejecución de cada caso de prueba. Incluirá las pruebas que pasaron y las
que fallaron, los errores encontrados, la tasa de éxito y el tiempo transcurrido.
