Documentos de Académico
Documentos de Profesional
Documentos de Cultura
QA E8 - Plan de Prueba 2 - 2
QA E8 - Plan de Prueba 2 - 2
Plan de
prueba 2/2
● Procesos de Prueba
● Análisis de Requerimientos
● Matriz de Trazabilidad de Requerimientos
● Historias de usuario
● Documentación de pruebas
● Introducción a formularios HTML
Conceptos clave en el encuentro de hoy
● Estrategias de prueba
● Criterios de prueba
● Planificación de los entornos de pruebas
● Planes de prueba
● Requisitos necesarios para un buen diseño
● Tipos de pruebas
Por otro lado, así como lo fue en el encuentro anterior, tienes un Check de
Conocimiento para completar una vez que hayas completado la guía de trabajo
de hoy. Te ayudará a consolidar todos los aprendizaje que vienes adquiriendo.
2
MATERIAL DE LECTURA
1
Arquitectura en software hace referencia a la estructura y la relación entre las diferentes
partes de un software y sus propiedades visibles externas. En suma, una arquitectura de
Software está compuesta por más arquitecturas de datos que se articulan entre sí. ¿Quieres
leer más?
3
En esta fase de STLC (Software Testing Life Cycle o Ciclo de vida del testeo
del software), los tester trabajan tanto dentro de sus propios equipos como de
forma interdisciplinaria para contextualizar cómo probarán el software. El
análisis de requisitos a menudo incluye sesiones de intercambio de ideas,
identificación de puntos ciegos o áreas poco claras en los requisitos y
priorización de ciertas evaluaciones.
La segunda fase de STLC es importante, ya que guía gran parte del trabajo a
seguir. La planificación de pruebas toma los conocimientos encontrados
durante los requisitos o el análisis del producto y los convierte en una
estrategia de control de calidad documentada.
2
Unit testing: se llama testing y es testing pero lo llevan a cabo los desarrolladores de
software.
4
La creación de un plan de pruebas implica los siguientes pasos:
Imagen 8.1: Pasos en la creación del plan de pruebas. Fuente: elaboración propia.
1. Análisis de producto
El foco de un tester es aprender lo más posible sobre el producto que se está
probando, el cliente y los usuarios finales de productos similares. Idealmente,
esta fase debería centrarse en responder a las siguientes preguntas:
● ¿Quién usará 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?
Para lograr estas respuestas, recomendamos hacer lo siguiente:
● Entrevistar a clientes, diseñadores y desarrolladores.
● Revisar la documentación del producto y del proyecto.
● Realizar un recorrido del producto.
5
Imagen 8.2: Etapas del análisis de producto. Fuente: elaboración propia.
3
¿Qué es middleware?
6
Imagen 8.3: Estrategia de la prueba. Fuente: elaboración propia.
7
identificar un tipo específico de errores del producto. Sin embargo, todos los
tipos de pruebas tienen como objetivo lograr un objetivo común: "Detección
temprana de todos los defectos antes de entregar el producto al cliente".
Pro tip: existen estándares de calidad en procesos4 regulados por las normas
ISO. Para el testing de software estas normas se llaman ISO/IEC/IEEE 29119 e
indican el orden y la seguridad necesarios para llevar a cabo pruebas
robustas. No es algo que debas manejar ni saber en este momento de tu
formación, pero consideramos que es lenguaje que debes saber en caso de
querer profundizar algunos conocimientos.
4
Hacemos hincapié en que son estándares de calidad de procesos porque suelen confundirse
con estándares de calidad en los productos. Para darte un ejemplo concreto: puedes estar
fabricando lápices. Si tus lápices son los mejores del mercado, tienes un producto de excelente
calidad. La calidad en los procesos habla de cómo fabricas ese producto. Dicho de otra
manera, puedes tener procesos de una calidad excepcional y sin embargo tus lápices no son
los mejores del mercado. ¿Te ha pasado estar en una organización que implemente alguna de
las normas ISO?
8
2.3. Documentar riesgos y problemas
RIESGOS MITIGACIÓN
9
Aún cuando no estén definidas las personas del equipo que llevarán a cabo las
pruebas, el manager decidirá qué perfil de especialidad debe llevarlas a cabo.
10
Imagen 8.4: Requerimientos para el testeo. Fuente: elaboración propia.
3. Definición de objetivos
Los criterios de prueba se refieren a los estándares o reglas que rigen todas las
actividades en un proyecto de prueba. Los dos principales criterios de prueba
son:
5
¿Recuerdas? Graphic User Interface o muchas veces UI (pronunciada en inglés como “iuai”)
11
● Criterios de salida: define los puntos de referencia que significan la
finalización exitosa 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 etapa de desarrollo. Por ejemplo, el 80 % de
todos los casos de prueba deben marcarse como exitosos antes de que
una función o parte del software en particular pueda considerarse
adecuada para uso público.
Esta fase crea un desglose detallado de todos los recursos necesarios para la
finalización del 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 prueba decide la medida de los recursos (número de
testers y equipos) que requiere el proyecto. Esto también ayuda a los gerentes
de pruebas a formular un cronograma y una estimación correctamente
calculados para el proyecto.
12
3 Desarrollador/Progra Implementar los casos de prueba, el programa de
mador que testea prueba, el conjunto de pruebas, etc.
13
comportamiento del software en condiciones reales de usuario. Ya sea que se
trate de pruebas manuales o pruebas de automatización, nada supera a los
dispositivos reales, instalados con navegadores reales y los sistemas
operativos no son negociables como entornos de prueba. No comprometa los
resultados de sus pruebas con emuladores o simuladores.
Para finalizar esta tarea, se necesita una fuerte cooperación entre el equipo de
prueba y el equipo de desarrollo.
14
● Riesgos asociados al proyecto que ha sido evaluado en una etapa
anterior.
¿NECESITAS UN EJEMPLO?
15
8. Establecer entregables de prueba
Los entregables de prueba se refieren a una lista de documentos, herramientas
y otros equipos que deben crearse, proporcionarse y mantenerse para
respaldar las actividades de prueba en un proyecto.
Se requiere un conjunto diferente de entregables antes, durante y después de
la prueba.
- Entregables requeridos antes de la prueba. Documentación sobre:
o Plan de prueba
o Diseño de prueba
- Entregables requeridos durante la prueba. Documentación sobre:
o Guiones de prueba
o Simuladores o emuladores (en etapas iniciales)
o Datos de prueba
o Registros de errores y ejecuciones
- Entregables requeridos después de la prueba. Documentación sobre:
o Resultados de la prueba
o Informes de defectos
o Notas de lanzamiento
Un plan de pruebas en software es la columna vertebral sobre la que se
construye todo el proyecto. Sin un plan lo suficientemente amplio y bien
elaborado, los controles de calidad se confundirán con objetivos y plazos
vagos e indefinidos. Esto dificulta innecesariamente las pruebas rápidas y
precisas, y retrasa los ciclos de lanzamiento.
16
¡MANOS A LA OBRA!
Luego, podrás evaluar la discusión de estos puntos con tu equipo del día. ¡Te
sorprenderá que haya más de un punto de vista!
Cada uno podrá exponer las razones por las que eligió cada opción.
17
b) Incorrecto, ya que el doc. de estrategia de prueba lo tiene que
realizar un programador.
18
d) Debería desestimar cualquier tipo de reclamo hacia su trabajo, ya que
su grado y experiencia se lo permiten.
c) Incorrecto, ya que su tarea nada tiene que ver con los procesos
anteriores.
19
MATERIAL DE LECTURA
Análisis y diseño
Factores que determinan los niveles de detalles de las condiciones de prueba:
Las siguientes son las diversas fuentes para recopilar información de prueba:
20
o Detalles válidos y no válidos.
6
FDS - Functional Design Specifications (o “specs”)
21
traer cuando se complete la especificación de diseño funcional. La
especificación de diseño específico identifica lo que debe usarse en el ciclo de
vida de la ingeniería de software industrial.
¡MANOS A LA OBRA!
Tendrás que poner en práctica todas las habilidades que llevas entrenando, ya
que deberás:
- Organizar la información
- Armar un flujo de uso (en UML si deseas, pero puede ser a modo de
boceto)
- Distinguir las tareas a testear. Cada flujo debe ser probado por separado
22
- Revisar que los requerimientos estén bien definidos7
- Responde a las preguntas de cada caso
Desafío 7.2.1.
Caso: Si tomas el tren antes de las 9:30 am o en la tarde, luego de las 16:00 (4
pm) y hasta las 19:30 (7:30 pm), debes pagar el precio total ya que te
encuentras viajando en hora pico. Tienes un ticket “ahorro” que está disponible
para los viajes entre las 9:30 am y las 4:00 pm y luego de las 7:30 pm.
Desafío 7.2.2.
Caso: Si tienes una tarjeta de pasajero senior (60+ años), tienes un 35% de
descuento en cualquier ticket que compres. Si viajas con un niño menor a 16
años, tienes un descuento del 50% en cualquier ticket si tienes una tarjeta de
“Familia viajera”. Si no la tienes, recibes un 10% de descuento en el ticket para
7
Un requisito bien desarrollado debe tener estas características:
● Atómico
● Identificado de forma única
● Completo
● Coherente y sin ambigüedades
● Trazable
● Priorizado
● Comprobable
23
menores de 16 años. Solo puedes poseer un tipo de tarjeta de viajero
frecuente.
Desafío 7.2.3.
24
MATERIAL DE LECTURA
Tipos de prueba
Los tipos de prueba vistos a continuación son una clasificación sencilla,
adaptada al nivel del curso.
Las técnicas de prueba de caja blanca analizan las estructuras internas, las
estructuras de datos utilizadas, el diseño interno, la estructura del código y el
funcionamiento del software en lugar de solo la funcionalidad como en las
pruebas de caja negra. También se denomina prueba de caja de vidrio o prueba
de caja transparente o prueba estructural.
8
¿Recuerdas? WBT (white box testing) y BBT (black box testing) por sus siglas en inglés.
25
3. Planificación adecuada de las pruebas: diseñar casos de prueba para
cubrir todo el código. Ejecute enjuague-repetir hasta que se alcance el
software sin errores. Comunique los resultados.
Ventajas:
o Fácil de automatizar.
Desventajas:
o PRUEBA FUNCIONAL:
26
Son aquellas que se llevan a cabo para comprobar las especificaciones críticas
para el negocio, la funcionalidad y la usabilidad. Este tipo de pruebas
garantizan que las características y funcionalidades del software se comporten
según lo esperado sin ningún problema. Valida principalmente toda la
aplicación con respecto a las especificaciones mencionadas en el documento
Software Requirement Specification (SRS). Los tipos de pruebas funcionales
incluyen pruebas unitarias, pruebas de interfaz, pruebas de regresión, entre
otras.
o PRUEBAS NO FUNCIONALES:
o PRUEBA DE REGRESIÓN:
Esta prueba se realiza para asegurarse de que los nuevos cambios de código
no tengan efectos secundarios en las funcionalidades existentes. Garantiza
que el código antiguo siga funcionando una vez que se hayan realizado los
últimos cambios en el código.
27
Imagen 8.6: Pruebas de caja blanca y caja negra. Fuente: elaboración propia.
Los dominios de datos y los límites Esto solo se puede hacer mediante
internos se pueden probar mejor. un método de prueba y error.
Niveles de prueba
28
Imagen 8.7: Niveles de prueba. Fuente: elaboración propia.
29
¡MANOS A LA OBRA!
Ejercicio
Consigna:
Te hemos dejado un ejemplo completo en el que hemos descrito los objetivos,
alcance, equipo, estrategia, criterios, ambientes, entregables, incidentes,
riesgos y tareas que se mencionan tomando como caso de prueba a un mouse.
Sabemos que estás aprendiendo y este ejemplo te guiará y servirá de apoyo.
Desafío:
En esta actividad te proponemos que elijas un ejemplo diferente al mouse y
puedas describir todos los elementos mencionados.
Para resolver el ejercicio, utiliza esta plantilla para practicar de forma individual
y consolidar el proceso de armado de pruebas. Tienes espacios en blanco en
las tablas para ir complementando con tus respuestas. Aquí debajo tienes la
resolución de la actividad utilizando el mouse como ejemplo.
Alcance
Se verificará la funcionalidad del mouse así como también su compatibilidad
con otros hardwares y su portabilidad en diferentes plataformas. También
estará dentro del alcance de las pruebas verificar su ergometría y los tiempos
de respuesta.
Quedarán fuera del alcance de las pruebas las comprobaciones de seguridad.
30
Equipo
El equipo de pruebas estará conformado por un tester junior full time y un
tester semi-senior part time. Ambos testers estarán prestando servicios desde
Argentina. Debido a que se estará trabajando con hardware, será necesario
asistir a la oficina cada vez que se lance una nueva versión.
Estrategia
El equipo de desarrollo implementará pruebas unitarias de los drivers
asociados al mouse como parte de su pipeline.
El equipo de testing realizará pruebas funcionales y no funcionales de forma
manual. Cada vez que una nueva versión llegue a testing se hará una prueba
de regresión sobre aquellos escenarios que se consideren de prioridad alta.
Dentro de las pruebas no funcionales se ejecutarán pruebas de performance,
portabilidad, compatibilidad y usabilidad.
Al finalizar cada sprint9 se realizarán pruebas de aceptación de usuario. Al
mismo tiempo, se aprovecharán esas reuniones para hacer pruebas de
usabilidad.
Criterios
Las pruebas del equipo de testing comenzarán cuando hayan pasado
satisfactoriamente las pruebas unitarias.
El criterio de finalización de las pruebas será cuando se hayan ejecutado todas
las pruebas planificadas o, si el tiempo apremia, al menos se hayan ejecutado
los casos de prueba de prioridad alta y media.
El criterio para pasar a producción será que no haya errores bloqueantes o
críticos sin resolver.
Ambientes
● 1 notebook mac
● 1 notebook lenovo con windows 10
● 1 notebook samsung con ubuntu 22.04 LTS
● Superficies de madera, plástico y vidrio.
9
En metodologías ágiles, se denomina sprint al tiempo designado para realizar un ciclo de
entrega de tareas asignadas. Por ejemplo, tu equipo puede trabajar con sprints de 7 días y eso
significa que cada 7 días se revisan las tareas entregadas, pendientes y bloqueadas de cada
miembro del equipo. Además se planifican los siguientes 7 días de trabajo, estimando el tiempo
para resolver cada tarea.
31
Entregables
● Plan de pruebas
● Lista de escenarios de pruebas ejecutadas
● Informe de estado al finalizar cada sprint
● Reporte de defectos
Gestión de incidentes
Se utilizará el siguiente workflow para la gestión de defectos:
10
Es un rol que se enfoca en entregar el mejor producto posible. Se centra en las necesidades
de los usuarios finales, para que todos entiendan qué se intenta lograr con el producto y por
qué.
32
Riesgos
Riesgo Probabilidad Impacto Mitigación Contingencia
Tareas
33