Curso de Testing QA avanzado

MATERIAL DE LECTURA

Master Test Plan y Release

Test Plan
 Objetivos de la Guia
En esta guía aprenderemos a:
● Conceptos relacionados a la gestión de proyectos
● Plan de pruebas
● Plan maestro de Pruebas
● Plan release o de lanzamiento
● Partes de un plan de pruebas
● Calidad y automatización
● Gestión en la automatización de pruebas

INTRODUCCIÓN

Con este material abordaremos temas relacionados a la creación de Plan de pruebas, los
diferentes tipos de planes, cuando sería necesario crear uno u otro, además
aprenderemos sobre campos que contiene un plan de pruebas y cómo completarlos,
todos estos conceptos con enfoque en la gestión de proyectos con pruebas
automatizadas, aprenderemos también algunos conceptos de calidad asociados a la
automatización de pruebas y veremos la importancia de la gestión de proyecto en el ciclo
de desarrollo de software.
Introducción
Profundizaremos los temas vistos anteriormente los asociaremos a la gestión y control de
calidad en el proceso de desarrollo de software y la automatización.

Actualmente la tecnología nos ha facilitado nuestro día a día, convirtiendo los sistemas informáticos en
nuestros grandes aliados, pero cuando fallan pueden tener consecuencias catastróficas, incluso muerte
y destrucción de gran magnitud.

En nuestra historia han ocurrido una gran cantidad de fallos causados por errores de software,
originando numerosas pérdidas económicas y humanas, como parte introductora al proceso de gestión
en pruebas de desarrollo de software, te compartimos algunas de las más impactantes:

1. Mariner 1.
En el año 1962, la Nasa se disponía a realizar el lanzamiento al espacio de la misión Mariner 1, con el
fin de navegar la órbita de Venus. Un error de programación representó la diferencia entre el éxito y una
catástrofe total.

La Mariner 1 fue creada para recabar datos sobre la temperatura y atmósfera de Venus, pero no logró
salir de la atmósfera de la tierra. La catástrofe se originó a solo 5 minutos del despegue debido a la
mala transcripción de un código, el fracaso del Mariner 1 produjo la pérdida de 18,5 millones de dólares
a la Nasa, ¿Que produjo la falla? Falta de un guión “-“ en el código.

2. Therac-25.
En 1982 fue fabricada una máquina diseñada para la administración de radioterapia a pacientes con
cáncer llamada la Therac-25, era controlada exclusivamente por un computador sin tener sistemas de
protección mecánicos para evitar irradiar a pacientes con dosis muy altas.

Entre 1985 y 1987 la máquina tuvo un error de software, el cual ocasionó la sobredosis de radiación a 6
pacientes, 100 veces más elevadas a las que exigía su tratamiento ocasionando la muerte de al menos
3 de ellos.

3. Caída de la red AT&T.

El 15 de enero de 1990, gran parte de la red AT&T dejó de funcionar por 9 horas, debido a que un
conmutador de 114 centros conmutados sufriera un problema mecánico que desactivo el centro, esta
gran caída fue causada por una línea de código errónea en una compleja actualización de software
empleada para acelerar las llamadas, ocasionando una reacción que tiró abajo toda la red afectando 75
millones de llamadas telefónicas.

4. Patriot la falla mortal.

El 25 de febrero de 1991, un sistema de defensa de misiles Patriot de EE.UU. en Arabia Saudita, no
detectó un ataque a un cuartel del ejército. Un informe del gobierno determinó que un problema de
software provocó un cálculo de rastreo inexacto que empeoraba cuanto más tiempo funcionaba el
sistema. El día del incidente, el sistema llevaba más de 100 horas funcionando y la inexactitud era lo
suficientemente grave como para hacer que el sistema buscará en el lugar equivocado el misil entrante.
El ataque mató a 28 soldados americanos.
5. Fallo de Pentium.
A finales de 1994 el muy promocionado chip de Intel, Pentium, produjo errores en la división de
números en coma flotante. Aunque el error solo afectó a pocos usuarios, se transformó en una
pesadilla, con 5 millones de chips en circulación.

Este error fue causado por el divisor en la unidad de coma flotante, el cual contaba con una tabla de
división errónea, al que le faltaban 5 entradas cobre 1000 causando este este fallo.

6. Ariane 5.
El 4 de junio de 1996 el cohete espacial no tripulado Ariane 5 fue destruido a solo unos segundos de
su despegue en su vuelo inaugural, destruyendo consigo 4 satélites destinados a estudiar la
interacción del campo magnético de la tierra con los vientos solares.

Esta catástrofe fue provocada debido a que surgió un problema cuando el sistema de guiado intentó
convertir la velocidad lateral de la nave de 64 a 16 bits, siendo este un número demasiado elevado,
produciendo un error de desbordamiento, deteniendo el sistema, provocando su autodestrucción en
tan solo 37 segundos después del despegue.

7. Efecto Y2K.
Este error milenial se basó en la programación de las fechas en los sistemas informáticos.

Para el siglo XX los programadores trataban de optimizar el espacio del que se disponía para guardar
información, utilizando como truco guardar fechas como dd/mm/aa en lugar de dd/mm/aaaa.

Para el cambio del siglo XX al siglo XXI se desconfiaba en esta forma de programación, debido a que
esta podría provocar un caos mundial cuando la fecha realizara el cambio de 31/12/1999 al
01/01/2000, porque para el software existente sería 01/01/00, es decir, del año 1900 atrasando 100 a
todos los artefactos tecnológicos produciendo en ellos errores fatales.

8. Apagón en el noreste de EE.UU.

El 14 de agosto del 2003 al noreste y medio oeste de los EE.UU se generó un apagón debido a un
error de software en el sistema de alarma de la sala de control de FirstEnergy, haciendo que los
operadores no reaccionaran ante la sobrecarga del sistema eléctrico luego que varias líneas de
transmisión cayeran sobre árboles. Este apagón causó la muerte de 90 personas en Nueva York,
accidentes y complicaciones de enfermedades.

9. Se colapsa el aeropuerto de los Ángeles.

En el año 2007 tan solo una tarjeta de red deficiente fue la causante de arruinar computadoras de
inmigración en el Aeropuerto Internacional de los Ángeles, provocando que unas 17 mil personas no
pudieran volar a sus destinos durante 9 horas.

La tarjeta destruyó la red de área local, después de que comenzó a enviar datos a la red, causando
el colapso de toda la red responsable de la revisión secundaria de los pasajeros, esto ocurrió durante
el mes de más actividad del aeropuerto y en uno de los días más concurridos de la semana.
10. El error de Knight Capital.
Knight Capital es una empresa dedicada a la compra y venta de acciones de la bolsa de Wall Street,
la compañía acudió a una aplicación para realizar transacciones de manera automática programando
una cantidad de compras y ventas sé que debían realizar en una cantidad durante unos días.

En el 2012, el sistema tuvo un fallo de software y en vez de ejecutar las operaciones rigiéndose por
una línea de tiempo planificada, terminó por realizar las transacciones una tras otra, causando una
pérdida de casi 500 millones de dólares, en tan solo 45 minutos de mal funcionamiento la compañía
estuvo a punto de perderlo todo.

Estos errores que mencionamos solo han sido algunos entre tantos que han ocurrido en la historia
del software, si bien podemos observar la falta de una metodología para realizar pruebas o la
inexistencia de ellas, provocaron las consecuencias vistas.

Los sistemas son desarrollados por personas y por esta sola razón en cualquier fase se puede
cometer un error que puede generar un defecto en el software, si éste no es detectado y se llega a
ejecutar la aplicación tendremos grandes riesgos. Realizar pruebas de software es la manera de
prevenir o sencillamente corregir posibles desviaciones de un software antes que provoque este tipo
de afectaciones, es allí donde las empresas de testing, tenemos la responsabilidad de brindar
soluciones tecnológicas donde se ejecuten procesos y procedimientos de calidad alineadas al ciclo
de desarrollo de software, para lograr mejorar el funcionamiento y obtener un producto final de
acuerdo a las necesidades del usuario.

Es por eso que antes de que los usuarios tengan acceso a cualquier software o función nueva,
debemos ponerlo a prueba a fondo: probar e intentar romperlo. Debemos asegurarnos de que todo lo
que hagan los usuarios, responda según lo diseñado. En resumen, necesitamos un plan de prueba o
también conocido como test plan.

Antes de profundizar en la creación de un test plan definiremos el proceso de control de calidad, ya

que el plan de pruebas se encuentra incluido dentro del mismo.

Etapas del procesos de control de calidad

La garantía de calidad es un proceso sistemático que asegura la excelencia de los productos y
servicios. Un sólido equipo de control de calidad examina los requisitos para diseñar, desarrollar y
fabricar productos fiables, aumentando la confianza de los clientes, la credibilidad de la empresa y la
capacidad de prosperar en un entorno competitivo.

Antes de poner en marcha un proceso de control de calidad, es importante comprender los pasos
que lo componen, hay muchas formas de implementar un sistema de garantía de calidad, podríamos
definir los siguientes pasos entre los esenciales:

1. Analizar requerimientos: Es más costoso arreglar un error detectado durante las pruebas,
que prevenirlo en la fase de diseño de requerimientos, los profesionales del control de calidad
deben participar en el análisis y definición de los requerimientos del software, funcionales
como no funcionales de esa manera asegurar que los QAs reciban requerimientos
coherentes, exhaustivos y trazables.
2. Planificar las pruebas: Se utiliza como base la información obtenida durante la fase de análisis de
requerimientos para planificar las pruebas necesarias.

El plan de pruebas debe incluir la estrategia de pruebas, el alcance, el presupuesto y plazos

establecidos del proyecto, los tipos y niveles de pruebas necesarios, métodos y herramientas para el
seguimiento de errores, recursos y responsabilidad de cada uno de los miembros del equipo.

3. Diseñar las pruebas: Los testers deben crear casos de prueba y listas de comprobación que
cubran los requerimientos del software.

Se recomienda comenzar con pruebas exploratorias para familiarizarse con el software y así sumar
casos de pruebas adicionales a los escritos en base a requerimientos.

Nota: Si se ha definido una estrategia de automatización en el ámbito de la prueba, esta es la etapa

para crear escenarios de control de calidad de la prueba de automatización.

4. Ejecución de pruebas y notificación de defectos: Se realizan las pruebas, comenzando con las
pruebas estáticas analizando la documentación de requerimientos, despues los niveles más bajos
donde se aplican las pruebas unitarias o de componentes y de esa manera ir reportando defectos
desde que se comienza a desarrollar el software y a medida que va evolucionando ir probando en los
diferentes niveles, reportar defectos e informe de las pruebas.

5. Re-test y regression test: Una vez reportados y corregidos los errores, se vuelve a probar la
funcionalidad afectada para asegurarse de que realmente se haya corregido, además se realizan
pruebas de regresión con la finalidad de verificar que las correcciones no afectaron las funciones
existentes.
6. Refactoring test: Después de que los desarrolladores emitan una notificación de actualización del
software donde deberán detallarse las características implementadas, errores corregidos y
limitaciones, se debe identificar las funcionalidades afectadas por los cambios y diseñar pruebas que
cubran el alcance de las modificaciones.

También será necesario realizar pruebas de humo para asegurarse de que cada funcionalidad sea
estable.

7. Aplicar mejoras continuas. La garantía de calidad es sinónimo de mejora continua. Los resultados
o la información obtenida de la encuesta de una organización o de otras herramientas de
retroalimentación del cliente deben utilizarse ahora para realizar los cambios necesarios en el proceso
de garantía de calidad.

Esto puede implicar un mayor desarrollo del liderazgo, la formación en el servicio al cliente, una mayor
dotación de personal, correcciones en el proceso de producción, cambios en el producto o servicio que
fabrica o presta, etc.

8. Medir resultados. Aunque puede haber muchas razones para implantar un proceso de garantía de
calidad, uno de sus principales objetivos es garantizar que la organización satisfaga las necesidades
de sus clientes. Cuando una organización no lo consigue, es difícil obtener un retorno positivo de la
inversión y la existencia de la organización queda en entredicho.

Desde el primer momento, hay que asegurarse de que haya objetivos cuantificables y de que todos los
implicados sepan lo que hay que conseguir. Si no se alcanzan los objetivos, hay que asegurarse de
que todos tengan claro qué medidas correctoras son necesarias para garantizar la seguridad y la
satisfacción del cliente.
9. Implementar DevOps. DevOps aplica prácticas ágiles para los equipos de QA y Ops,
simplificando la construcción, validación, despliegue y desarrollo del software. Elimina los
conflictos entre los equipos de desarrollo y de control de calidad, y tiene otras ventajas:

● Proporciona un mayor control sobre el entorno de producción para los desarrolladores.

● Mejora la frecuencia de despliegue.
● Reduce la tasa de fallos de las nuevas versiones de software.
● Mejora el tiempo medio de recuperación.
● Aumenta la velocidad y la calidad del software liberado.
● Consigue un tiempo de comercialización más rápido.

Plan de pruebas
Un plan de prueba es una de las partes más importantes de cualquier proceso de desarrollo de
software, este debe describir cómo se asegurará de que nuestro producto o función haga lo que
se supone que debe hacer y no se rompa cuando los usuarios más lo necesiten.
Pero, ¿qué deberíamos incluir en el plan de prueba? ¿Qué tan profundo debe llegar realmente
para asegurarnos de que el producto se mantenga y sus usuarios obtengan lo que esperan?
Este debe ser un documento detallado que describa la estrategia de prueba, los objetivos, los
recursos necesarios, el cronograma y los criterios de éxito para probar una nueva característica o
pieza de software específica.

El objetivo principal, por supuesto, es descubrir defectos, errores y cualquier otra brecha que
pueda hacer que el software no actúe como se esperaba o que brinde una mala experiencia a sus
usuarios.

¿Qué debería incluirse en la plantilla del plan de prueba?

Cada producto y función tendrá sus propios criterios, estrategias y necesidades de prueba
específicos, además, el objetivo de la prueba cambiará la forma en que lo aborda.

Por ejemplo, las pruebas de aceptación del usuario (UAT) son completamente diferentes de las
pruebas de estrés y carga, y su plan deberá adaptarse a su objetivo final.

¿Cuáles son sus objetivos?

Un plan de prueba garantiza que el software:

● Responde según lo esperado a todo tipo de entradas.

● Se puede instalar y ejecutar en todos los entornos previstos.
● Logra los resultados esperados por las partes interesadas y el equipo de QA.

¿Cómo redactar un buen plan de pruebas?

Recordemos los seis pasos para escribir un buen plan de pruebas:

● Análisis de productos/software.
● Desarrollar la estrategia de pruebas.
● Definir los objetivos de las pruebas.
● Planificación de recursos.
● Calendario y estimación.
● Determinar los resultados de las pruebas.
Tipos de Plan de pruebas
Existen diferentes tipos de planes de pruebas, entre los que podemos destacar plan de pruebas
maestro y de liberación o lanzamiento. Entendamos sus diferencias.

Un plan de pruebas tiene como objetivo definir cómo se llevarán a cabo las pruebas, así como,
determinar qué supuestos se tendrán en cuenta para establecer un estándar de calidad del producto
a analizar.

Un plan maestro de pruebas se utiliza en un escenario más amplio, que implica al producto en su
conjunto.

Un plan de pruebas de lanzamiento, se refiere a la definición de cómo se probará el lanzamiento de

una versión específica del producto.

El Plan Maestro de Pruebas

● Contiene todas y cada una de las pruebas que se ejecutarán durante el desarrollo general de
la aplicación.

● Contiene las áreas de riesgo de la aplicación.

● Incluye los escenarios de prueba que se ejecutarán en todas las fases de prueba a lo largo del
ciclo de vida de desarrollo de la aplicación.
● El resultado será un documento de publicación del plan de pruebas que contenga los casos de
prueba correspondientes a los escenarios de prueba planteados.
El Plan de Pruebas de lanzamiento / despliegue
● Incluye todas y cada una de las pruebas que se ejecutarán durante el lanzamiento /
despliegue de la aplicación, además describe el alcance, el enfoque, los recursos y el
calendario de ejecución de las pruebas pero siempre con foco en el lanzamiento de la
aplicación bajo prueba.

● Tendremos un Plan de Pruebas de Lanzamiento cada vez que una nueva versión de nuestra
aplicación sea lanzada.

Sólo en el caso de los grandes proyectos, necesitamos un Plan Maestro de Pruebas que requiera la
ejecución de todas las fases de pruebas. Sin embargo, la preparación de un plan Test Release
básico por ambiente es suficiente para los proyectos pequeños.

Los Planes Maestros de Pruebas/Release se utilizan como guías para el equipo de pruebas,
centralizando toda la documentación necesaria para el aseguramiento de la calidad del producto a
probar.

El plan de pruebas, redactado normalmente por el QA Lead o por un analista de calidad, es un

documento base para la toma de decisiones relacionadas con el proceso de calidad del software y
también sirve de orientación para los nuevos miembros del equipo de pruebas.

CONCLUSIÓN

Conocer la diferencia entre los tipos de planes de prueba es extremadamente importante para el
proceso de garantía de calidad del software.

Al no saber diferenciarlas, es muy probable que el área de pruebas no tenga una dirección adecuada
al momento de realizar sus actividades, no garantizando, por lo tanto, la certeza de que el producto a
probar tendrá la confiabilidad mínima necesaria para cumplir con sus objetivos de negocio.
¿Qué podría incluir en mi plan de prueba?

En términos generales, hay algunas áreas principales que son convenientes incluir y que actuarán
como la base del documento:

Cobertura: ¿Qué se está probando exactamente?

Un plan de pruebas debe ser completo, pero no abrumador, es decir, ser específico sobre lo que
se incluirá y lo que no.

Después de una breve introducción que destaca los objetivos del plan de prueba, el alcance de
alto nivel y el cronograma, se deberá definir lo que se probará o no probará.

● ¿Qué pruebas va a realizar?

● ¿Por qué ha elegido estos (y no otros)?

Métodos: ¿Cómo se van a realizar estas pruebas?

A continuación, se debe explicar tan detalladamente como sea posible: ¿cuál es la estrategia de
prueba?

● ¿Qué reglas seguirán las pruebas?

● ¿Qué métricas se van a recopilar y a qué nivel?
● ¿Cuántas configuraciones o entornos diferentes se van a probar?
● ¿Existen requisitos o procedimientos especiales que se deban probar?

También se necesita saber cuándo la prueba fue exitosa, es decir:

¿Cuáles son los criterios de aprobación/reprobación para cada prueba?

Estos criterios incluyen:

● Criterio de salida: ¿cuándo está bien dejar de probar una función y asumir que la función
tiene éxito en hacer lo que se propuso hacer?
● Criterios de suspensión: ¿cuándo debería pausar una prueba? ¿Existe un umbral de
errores en el que debería dejar de realizar pruebas y empezar a buscar soluciones?
¿Cuáles son los pasos para cerrarlo y documentar lo que se ha hecho hasta ahora?
● Requisitos de reanudación: ¿cómo se sabe cuándo reanudar una prueba en pausa?
¿Cuáles son los pasos para revisar lo que se ha hecho y retomar?

Por otro lado, es una buena idea en este punto enumerar las suposiciones y riesgos.

En otras palabras: ¿qué se supone que va a suceder y cuáles son algunos de los riesgos
durante las pruebas?

Por último, describir las necesidades de recursos y el cronograma del proyecto de prueba.

Es decir: ¿Quién está a cargo de las pruebas y qué recursos necesitan (tanto técnicos como
humanos)? ¿Cuándo se realizarán las pruebas y durante cuánto tiempo?
Responsabilidades: ¿Cuáles son los resultados deseados?
¿Cuáles son los entregables de prueba requeridos?
Esto significa los datos que se desean recopilar, cómo agruparlos en los informes y los problemas
y tareas que se devolverán al equipo de desarrollo.

Para asegurarse de que no se pierda nada, cada entrega de prueba debe asignarse a una persona
específica del equipo en una sección sobre roles y responsabilidades.

Ejemplos de control de calidad en pruebas automatizadas

Pruebas Funcionales:
1. Análisis del producto
Se empieza por aprender más sobre el producto que se está probando, el cliente y los usuarios
finales de productos similares, lo ideal es que esta fase se centre en responder a las siguientes
preguntas:

¿Quién utilizará el producto?

¿Cuál es el objetivo principal de este producto?
¿Cómo funciona el producto?
¿Cuáles son las especificaciones de software y hardware?

En esta fase, se recomienda hacer lo siguiente:

● Entrevistar a clientes, diseñadores y desarrolladores.

● Revisar la documentación del producto y del proyecto.
● Realizar un recorrido por el producto.

2. Diseño de la estrategia de pruebas

El documento de estrategia de pruebas lo elabora el líder de pruebas y define lo siguiente:

● Objetivos del proyecto y cómo alcanzarlos.

● La cantidad de esfuerzo y coste que requiere la prueba.

El documento debe detallar:

● Alcance de la prueba: Contiene los componentes de software (hardware, software) que

se van a probar y también los que no se van a probar.
● Tipo de prueba: Describe los tipos de pruebas que se utilizarán en el proyecto. Esto es
necesario porque cada prueba identifica tipos específicos de errores.
● Riesgos y problemas: Describe todos los posibles riesgos que pueden producirse durante
las pruebas - plazos ajustados, gestión insuficiente, estimaciones presupuestarias
inadecuadas o erróneas - así como el efecto de estos riesgos sobre el producto o la
empresa.
● Logística de las pruebas: menciona los nombres de los testers así como las pruebas que
deben realizar. Esta sección también incluye las herramientas y el calendario establecido
para las pruebas.
3. Definición de objetivos
En esta fase se definen los objetivos y los resultados esperados de la ejecución de la prueba.
Como todas las pruebas tienen como objetivo identificar el mayor número posible de defectos, los
objetos deben incluir:

● Una lista de todas las características del software (funcionalidad, GUI, normas de
rendimiento) que deben probarse.
●
● El resultado ideal o punto de referencia para cada aspecto del software que necesita ser
probado. Este es el punto de referencia contra el cual se comparará todos los resultados
reales.

4. Establecer los criterios de prueba

Los criterios de prueba se refieren a las normas o reglas que rigen todas las actividades de un
proyecto de prueba. Los dos criterios principales de la prueba son:

● Criterios de suspensión: Establece los puntos de referencia para suspender todas las
pruebas. Por ejemplo, si los miembros del equipo de control de calidad descubren que el
50% de los casos de prueba han fallado, se suspenderán todas las pruebas hasta que los
desarrolladores resuelvan todos los errores identificados hasta el momento.

● Criterios de salida: define los puntos de referencia que significan la finalización con éxito
de una fase de prueba o proyecto. Los criterios de salida son los resultados esperados de
las pruebas y deben cumplirse antes de pasar a la siguiente fase de desarrollo. Por
ejemplo, el 80% de todos los casos de prueba deben ser calificados como exitosos antes
de que una característica particular o pieza de software pueda ser considerada adecuada
para el uso público.

5. Planificación de la asignación de recursos

Esta fase crea un desglose detallado de todos los recursos necesarios para completar el proyecto.
Los recursos incluyen el esfuerzo humano, el equipo y toda la infraestructura necesaria para
realizar pruebas precisas y completas.

Esta parte del plan de pruebas decide la medida de los recursos (número de probadores y
equipos) que requiere el proyecto. También ayuda a los responsables de las pruebas a formular
un calendario y una estimación correctamente calculados para el proyecto.

6. Planificación de la configuración del entorno de pruebas

El entorno de pruebas se refiere a la configuración de software y hardware en la que los QAs
realizan sus pruebas. Lo ideal es que los entornos de prueba sean dispositivos reales para que los
testers puedan controlar el comportamiento del software en condiciones reales de uso. Tanto si se
trata de pruebas manuales como de pruebas automatizadas, nada mejor que los dispositivos
reales, instalados con navegadores y sistemas operativos reales, son innegociables como
entornos de prueba. No comprometas los resultados de tus pruebas con emuladores o
simuladores.

Manual vs. Automatizado

El entorno de pruebas se refiere a la configuración de software y hardware en la que los QAs

realizan sus pruebas. Lo ideal es que estos entornos de prueba sean independientes y solo
utilizado por el equipo de calidad. Además, tecnológicamente, debería ser lo más parecido posible
al entorno productivo.
7. Determinación y estimación del calendario de pruebas
Para la estimación de las pruebas, divida el proyecto en tareas más pequeñas y asigna el tiempo y el
esfuerzo necesarios para cada una. Seguramente, en este paso se utilicen técnicas de estimación de
esfuerzo. A continuación, cree un calendario para completar estas tareas en el tiempo designado con
la cantidad específica de esfuerzo.
Sin embargo, la creación del calendario requiere la participación de varias perspectivas:

Disponibilidad de personal, número de días de trabajo, plazos de los proyectos, disponibilidad diaria
de recursos. riesgos asociados al proyecto que han sido evaluados en una fase anterior.

Procedimientos de prueba en las automatizaciones:

Los entregables de las pruebas se refieren a una lista de documentos, herramientas y otros equipos
que deben crearse, proporcionarse y mantenerse para apoyar las actividades de pruebas en un
proyecto.

Se requiere un conjunto diferente de productos antes, durante y después de la prueba:

Etapa 1: Definir el alcance de la automatización

El alcance de la automatización significa el área de su aplicación bajo Prueba que será automatizada.
Asegúrate de haber recorrido con precisión y conocer el estado de las pruebas de tu equipo, la
cantidad de datos de prueba y también el entorno en donde se realizan las pruebas. A continuación
se ofrecen consejos adicionales para ayudarte a determinar el alcance de las pruebas
automatizadas:

● Viabilidad técnica
● La complejidad de los casos de prueba
● Las características o funciones que son importantes para el negocio
● El grado de reutilización de los componentes del negocio
● La capacidad de utilizar los mismos casos de prueba para las pruebas entre navegadores.

Etapa 2: Seleccionando una herramienta de prueba

Después de determinar su alcance, es el momento de elegir una herramienta para las pruebas de
automatización. Por supuesto, puedes seleccionarla entre una amplia gama de herramientas de
automatización disponibles en el mercado. Sin embargo, sólo depende de la tecnología sobre la que
se construyen las pruebas de las aplicaciones. Cada tipo de herramienta o marco de trabajo puede
satisfacer diferentes demandas, por lo que tener un conocimiento profundo de los distintos tipos de
herramientas es también un factor destacado para elegir la mejor herramienta.

¿Qué Casos de Prueba son Automatizables?

Etapa 3: Planificación, diseño y desarrollo

En esta fase, crearás una estrategia y un plan de automatización. Este plan puedes incluir los
siguientes elementos:

● La herramienta de prueba de automatización que hayas seleccionado

● El diseño del framework y sus características
● Un cronograma detallado para el scripting y la ejecución de los casos de prueba
● Elementos de automatización dentro y fuera del ámbito de aplicación
● Objetivos y resultados del proceso de pruebas de automatización
Etapa 4: Ejecutar casos de prueba y crear los informes
Una vez que hayas completado todos los pasos anteriores puedes escribir los scripts, ejecutar las
pruebas automáticamente ejecutando el código directamente o llamando a la API o a la interfaz de
usuario de una aplicación. Tras su ejecución, el informe de pruebas ofrece un resumen
consolidado de las pruebas realizadas hasta el momento para el proyecto.

Etapa 5: mantenimiento de los casos de prueba anteriores

No importa lo bien que gestiones tus pruebas de automatización, el mantenimiento de las pruebas
es inevitable si quieres ampliar tu colección de scripts de prueba reutilizables. Después de que las
pruebas automatizadas se hayan programado y ejecutado, es necesario actualizarlas si la
aplicación cambia la próxima vez. Recuerda el principio de testing ‘La paradoja del pesticida’, si
tus pruebas no van adaptándose al sistema bajo prueba, quedarán obsoletas.

Pruebas estáticas y dinámicas

Las pruebas son una combinación de múltiples actividades del ciclo de vida del software
relacionadas con la planificación, el diseño y la evaluación del producto de software, con el
objetivo de encontrar los defectos y determinar si el software cumple o no con los requisitos
especificados.

Es por ello que en este módulo continuaremos desarrollando otros tipos de pruebas: las pruebas
estáticas y las pruebas dinámicas. Estas se complementan entre sí y nos permiten entregar un
software con la mejor calidad posible.

Conceptos básicos de la prueba estática

La prueba estática se basa en la evaluación manual de los productos de trabajo (es decir,
revisiones) o en la evaluación basada en herramientas del código u otros productos de trabajo (es
decir, análisis estático). Este tipo de pruebas no requieren la ejecución del software que se está
probando.

Se utilizan este tipo de pruebas para examinar cualquier producto de trabajo, como por ejemplo:
● Especificaciones, requisitos de negocio, funcionales y de seguridad.
● Épicas, historias de usuarios y criterios de aceptación.
● Especificaciones de arquitectura y diseño.
● Código.
● Productos de prueba: planes, casos, procedimientos y guiones de prueba.
● Manuales de usuario.
● Contratos, planes de proyecto, calendarios y presupuestos.

Ventajas de las pruebas estáticas tempranas

Cuando se aplica al principio del ciclo de vida del desarrollo del software, la prueba estática
permite la detección temprana de defectos. Esto genera una reducción de costos y tiempo de
desarrollo y prueba.

Por el contrario, si el defecto se encuentra luego de las pruebas dinámicas, solucionarlo va a

requerir el cambio de código, realizar una prueba de confirmación y luego incluir el mismo en
pruebas de regresión, además de los cambios de toda la documentación asociada.
Defectos encontrados con pruebas estáticas
Algunos de los defectos encontrados con pruebas estáticas que son más fáciles y económicos de
detectar y corregir son:
● Defectos en los requisitos (inconsistencias, ambigüedades, etc.).
● Defectos de diseño (estructura de base de datos ineficiente, alto acoplamiento, etc.).
● Defectos de codificación (variables con valores no definidos, código inalcanzable o
duplicado, etc.).
● Desviaciones con respecto a estándares (falta de uso de estándares de codificación).
● Especificaciones de interfaz incorrectas (unidades de medida diferente, etc.).
● Vulnerabilidades de seguridad (susceptibilidad a desbordamiento de la memoria
intermedia).
● Diferencias o inexactitudes en la trazabilidad o cobertura de la base de prueba (falta de
pruebas para un criterio de aceptación).
● Defectos de mantenibilidad (mala reutilización de componentes, modularización
inadecuada, etc.).

Proceso de revisión

Dentro de las pruebas estáticas, una forma de detectar errores es mediante un proceso de
revisión.

Las revisiones consisten en examinar cuidadosamente un producto de trabajo con el principal

objetivo de encontrar y remover errores. Pueden ser realizadas por una o más personas.

Las revisiones pueden ser: formales o Informales

Revisiones formales:
● Tienen roles definidos
● Siguen un proceso establecido
● Deben ser documentadas.

Revisiones Informales:
● No siguen un proceso definido
● No son documentadas formalmente.

El grado de formalidad del proceso de revisión está relacionado con factores como:

● El modelo del ciclo de vida del desarrollo del software.

● La madurez del proceso de desarrollo.
● La complejidad del producto del trabajo que se debe revisar.
● Cualquier requisito legal y/o la necesidad de un rastro de auditoría.
Requisitos
Una de las revisiones que se realizan en las pruebas estáticas es examinar los requisitos del
software. Pero ¿sabemos qué son los requisitos? ¿Qué tipos de requisitos existen?

Un requisito define las funciones, capacidades o atributos intrínsecos de un sistema de software,

es decir, describe cómo debe comportarse un sistema. Para decir que un sistema tiene calidad
deben cumplirse los requisitos funcionales y no funcionales.

Requisitos funcionales
Definen lo que un sistema permite hacer desde el punto de vista del usuario. Estos requisitos
deben estar especificados de manera explícita. Por ejemplo: “El campo de monto acepta
únicamente valores numéricos con dos decimales” (pruebas funcionales y de sistema).

Requisitos no funcionales
Definen condiciones de funcionamiento del sistema en el ambiente operacional. Ejemplos:

Requisito de usabilidad: la usabilidad se define como el esfuerzo que necesita hacer un usuario
para aprender, usar, ingresar datos e interpretar los resultados obtenidos de un software de
aplicación (pruebas de usabilidad).

Requisito de eficiencia: relacionado con el desempeño en cuanto al tiempo de respuesta,

número de operaciones por segundo, entre otras mediciones; así como consumo de recursos de
memoria, procesador y espacio en disco o red (pruebas de rendimiento, pruebas de carga, estrés
y escalabilidad, pruebas de gestión de la memoria, compatibilidad e interoperabilidad).

Requisito de disponibilidad: disposición del sistema para prestar un servicio correctamente

(pruebas de disponibilidad). Requisito de confiabilidad: continuidad del servicio prestado por el
sistema (pruebas de seguridad).

Requisito de integridad: ausencia de alteraciones inadecuadas al sistema (pruebas de

seguridad, pruebas de integridad). Requisito de mantenibilidad: posibilidad de realizar
modificaciones o reparaciones a un proceso sin afectar la continuidad del servicio (pruebas de
mantenimiento y de regresión).
 Material de apoyo sugerido

Con los conocimientos de esta guía podremos comenzar a crear nuestros propios planes de prueba,
incluso dependiendo la magnitud del proyecto podremos saber si crear un plan de prueba maestro o un
plan de pruebas de lanzamiento, sin embargo como material de apoyo sugerimos los siguientes videos.

Como crear un plan de pruebas: https://www.youtube.com/watch?v=0anZpU5W0Z8

Plan de Pruebas para Proyectos Ágiles: https://www.youtube.com/watch?v=VKiR6xBtWIQ

Sugerencias para la siguiente clase

Sugerimos estudiar y practicar con los documentos adicionales de esta guía.

Esta guía tendrá como soporte 3 documentos que servirán de base para aprender a crear un plan
de pruebas.

El primero tendrá el nombre de “Ejemplo de plan de pruebas de un proyecto” este documento es

un plan de prueba completo que servirá para que podamos saber como debería quedar escrito el
plan de pruebas de principio a fin.

Además habrán 2 documentos adicionales con los siguientes nombres “Modelo 1 Plan de
Pruebas con definiciones” y “Modelo 2 Plan de Pruebas con definiciones”, ambos son modelos
con definiciones de cada parte de un plan de prueba que nos servirá como base para crear un plan
de prueba desde cero con solo hacer una copia y colocar los datos de nuestro proyecto encima del
documento.