QA E7- Análisis, planificación y ejecución de pruebas I

Vista previa del material en texto

Módulo 3 / Encuentro 7/20
Análisis,
planificación y
ejecución de
pruebas I
OBJETIVOS DEL MÓDULO 3
¿Qué habilidades desarrollarás?
● Aprendizaje cooperativo entre pares
● Atención al detalle para el análisis de requerimientos
¿Qué herramientas técnicas aprenderás?
● Matriz de casos de prueba
● Diseño de plan de pruebas
● Métricas y reportes
● Manejo de defectos
*No es necesario solicitar permiso de edición del documento, si
deseas puedes crear una copia �Archivo > Crear una copia]*
Introducción
¡Te damos la bienvenida a tu séptimo encuentro de trabajo!
Damos inicio a un nuevo módulo en el que profundizaremos en la ejecución de
las pruebas. El encuentro anterior estuvo cargado de mucha práctica…
¡Felicitaciones a todos por el esfuerzo!
Bien llegó la hora de iniciar la sesión. ¡A conocerse!…. ya lo saben, nombre,
lugar de procedencia y… aquí tienen una pregunta para facilitar la socialización
¿Cómo fue que decidieron elegir esta carrera? ¿Qué los convocó?
MATERIAL DE LECTURA
Estrategia y análisis
¿Recuerdan que mencionamos los enfoques “estáticos y dinámicos”? Pues
bien, retomaremos este tema y profundizaremos en tres grupos de actividades
asociadas:
● Análisis
● Planificación de pruebas
● Ejecución de pruebas
Análisis de requerimientos o insumos
Ya mencionamos en reiteradas ocasiones que la base para diseñar las pruebas
es el insumo que tengamos a disposición. Este, puede llegarnos en formato
requerimientos, especificaciones, casos de uso, historias de usuario, diagramas
de flujo o inclusive una combinación de estos elementos o ninguno.
El tipo y calidad del insumo que tengamos dependerá del nivel de organización
y recursos de nuestro equipo de trabajo.
En este punto, podemos poner en práctica lo visto en “proceso de revisión y
técnicas” ya que el análisis de requerimientos consiste básicamente en revisar
el insumo que tenemos para luego diseñar nuestro plan de pruebas y reportar
cualquier defecto encontrado en la documentación.
2
Estos son los pasos para realizar un análisis detallado:
1. Revisar el insumo a disposición.
2. Determinar si se entiende la necesidad se quiere cubrir y cómo se la
quiere cubrir a partir del insumo.
3. Tratamos de pensar por fuera del documento. ¿Falta algo? ¿Algo nos
genera duda? En este punto conviene revisar alguna funcionalidad,
producto o información ya existente que nos ayude a analizar
críticamente el documento en busca de errores u omisiones.
¿NECESITAS UN EJEMPLO?
Si el documento que revisamos describe cambios para una funcionalidad ya
existente, podemos revisar en paralelo esa funcionalidad para verificar que los
cambios descritos se apliquen.
4. Registramos las preguntas que nos hicimos para consultar a quien
corresponda.
Una vez que entendimos la necesidad que se desea cubrir, los objetivos, el
scope (o alcance del proyecto) que finalizamos el análisis de la documentación,
hicimos todas las preguntas y obtuvimos respuestas, podemos comenzar con
el proceso de diseño de las pruebas que llevaremos a cabo.
TIP😉 ¡Siempre se debe tener en cuenta los atributos de la calidad!
¿Recuerdas que los estudiamos en el módulo 1? Nos referimos a las ISOS
9126 y 2500. Al revisarlos seguramente surgirán inquietudes para resolver.
¿NECESITAS UN EJEMPLO?
Podríamos necesitar información sobre:
● Si el producto debe cumplir con algún estándar de accesibilidad o de
seguridad.
● Si debe tener requisitos mínimos de performance y eficiencia.
● Qué sucede con la interoperabilidad, si el sistema debe poder
comunicarse con otro.
3
● Qué sucede con la portabilidad (en qué sistemas operativos y/o en qué
exploradores debería funcionar)
Las respuestas a esas preguntas nos darían la pauta sobre la necesidad de
incluir pruebas para evaluar esos aspectos o si debemos incluir el uso de
alguna herramienta que nos permita evaluarlos. Incluso nos indica si debemos
solicitar ayuda de algún otro equipo.
A continuación les ofrecemos preguntas disparadoras sobre algunos temas
para abordar la etapa de análisis. No es un cuestionario obligatorio, pero
puede ayudarnos a ejercitar la mirada crítica a la hora de leer y comprender la
documentación.
Sugerimos que en este punto puedes poner en práctica técnicas de “diseño de
caso de prueba” tales como las tablas de decisión para identificar fácilmente si
en la documentación falta describir alguna condición o resultado esperado.
1 Respecto de los “Roles y permisos”
¿Cualquier usuario podría usar el sistema y todas sus funcionalidades? ¿Hay
algún tipo de usuario que pueda / no pueda completar algún tipo de acción
específica?
2 Respecto de las “Condiciones”
¿Se debe cumplir alguna condición para llevar a cabo esta acción?
Por ejemplo: Para ingresar al sistema por primera vez, ¿debo tener un usuario
creado? ¿Quién puede crear ese usuario? ¿Yo mismo? ¿Alguien con el rol de
administrador?
¿O quizás no? ¿El sistema crea un usuario para mí automáticamente la primera
vez que ingreso?
¿El sistema no requiere la existencia de un usuario para interactuar con él?
4
3 Respecto de los “Inputs válidos/inválidos”
¿Existen para esta funcionalidad grupos de acciones o inputs válidos e
inválidos?
En aquellos formularios en los que se puede ingresar datos, ¿los campos son
son para texto libre? ¿o tipos de campos en los cuales se espera que ingrese
cierto tipo de información? Ej, sólo números, sólo números con formato
telefónico de estados unidos, solo números con formato de documento de
identidad, sólo emails.
Secreto de la industria 1�
Aún en los campos de texto libre seguramente no se pueda
ingresar cualquier tipo de texto libre. Por cuestiones de
seguridad, el ingreso de scripts o código ejecutable no esté
permitido.
4 Respecto de “Outputs o comportamientos esperados”
¿Tengo en claro cuál es el comportamiento esperado para cada funcionalidad y
combinación de inputs?
¡¡¡Pro tip alert!!!😨 No den por sentado que la documentación o insumo
recibido está libre de errores.
Diseño de plan de pruebas
Con el análisis del insumo reflexionamos y delineamos escenarios.
Esos escenarios de prueba son descripciones de alto nivel de aquello que
tenemos que probar.
5
¡Disclaimer! El diseño del plan de prueba entra dentro de la planificación.
Pero en la planificación de las pruebas podrían entrar más actividades >
las actividades necesarias para completar un plan de pruebas más
elaborado con toda o alguna de la información sobre estimación, plazos,
estrategia, análisis de riesgo. etc.
De alguna forma, podemos decir que la planificación incluye al diseño del
plan. La planificación de la prueba implica actividades que definen los
objetivos de la prueba y el enfoque para cumplir los objetivos de prueba
dentro de las limitaciones impuestas por el contexto. Los planes de prueba
pueden revisarse en función de los comentarios de las actividades de
monitorización y control.
Cada escenario se complejiza a partir de la descripción en detalle hasta lograr
lo que se denomina como “Casos de prueba".
Al analizar los requerimientos se podría delinear los siguientes escenarios:
● Probar inicio de sesión válido.
● Probar intento de inicio de sesión con email no registrado.
● Probar intento de inicio de sesión con contraseña incorrecta.
Estas descripciones generales son escenarios de prueba que me permiten
tomar nota y recordar funcionalidades que deseo probar. De cada escenario de
prueba es probable que surjan una cantidad de casos de prueba.
Cada caso de prueba debe ser preciso, apuntar a una finalidad particular y
ser lo suficientemente claro para que otra persona lo pueda ejecutar aún sin
conocer el sistema.
6
Un plan de pruebas puede incluir simplemente una matriz de casos de pruebas
-es decir, las pruebas ordenadas- o un documento más complejo y elaborado
que incluya otro tipo de información tal como:
● Descripción
● ID del plan
● Organización
● Autoridad de
aprobación
● Historial de cambios
● Introducción
● Alcance
● Referencias
● Glosario
● Contexto de pruebas
● Análisis de riesgos
● Estrategia de pruebas
● Actividadesde testing
y estimaciones
● Equipo
● Agenda de trabajo
Matriz de casos de prueba
Como ya mencionamos, es útil organizar los casos de prueba dentro de una
matriz. Pero, ¿qué es una matriz? Es una tabla compuesta por filas y columnas.
Las filas presentan un caso de prueba y las columnas la información que debe
ser completada por cada caso.
¿NECESITAS UN EJEMPLO?
7
Secreto de la industria 1�
No todos los grupos de trabajo usan matrices de casos de
prueba, o bien porque no llevan un orden o bien porque utilizan
algún sistema de creación de casos de prueba que genera la
misma trazabilidad que generaría la matriz.
Hay diversas herramientas en el mercado que permiten organizar los casos de
pruebas en matices. Algunas son pagas, otras gratuitas. Las hay gratuitas
hasta cierto cantidad de usuarios
¿NECESITAS UN EJEMPLO?
Está es una visualización de la herramienta Zephyr en su versión Scale:
Zephyr ofrece tres versiones que son gratuitas hasta cierto número de usuarios
y se integra fácilmente a jira, una herramienta de gestión de desarrollo,
ampliamente usada en el mundo del desarrollo de software.
8
En la vista de arriba, los casos de prueba están agrupados por módulo del
sistema bajo prueba.
El identificador de trazabilidad se genera de manera automática para cada
prueba y las etiquetas de estado pueden ser creadas con texto libre por el
administrador de la herramienta.
En el ejemplo de arriba la etiqueta “TBC BY PO/FA” significa to “be confirmed by
product owner or functional analyst” y se utiliza para marcar los casos de
prueba que fueron creados pero que tiene algún detalle a confirmar por el
analista del producto.
¿NECESITAS UN EJEMPLO?
En la imagen de abajo se ve el detalle de un caso de prueba en particular.
Aunque la información está ordenada de un modo distinto al que vimos en la
matriz de trazabilidad clásica (formato de tabla) la información que se captura
es más o menos la misma:
9
10
El uso de herramientas para la gestión de las pruebas puede agregar un
componente de trazabilidad algo más potente que una planilla de cálculos, ya
que el plan de pruebas de un componente o funcionalidad específico puede
quedar directamente asociada a la historia de desarrollo creada en la
herramienta.
¿NECESITAS UN EJEMPLO?
Aquí se muestra un ejemplo de cómo es posible visualizar un grupo de pruebas
para un componente específico en una historia de usuario dentro de Jira:
11
¡MANOS A LA OBRA!
Es hora consolidar, repasar y revisar los conceptos vistos hasta el momento.
¿Recuerdas a qué llamamos “caso de prueba”?
Retomemos la definición:
Un test case o caso de prueba es una serie de precondiciones (en caso de
ser necesarias) valores (o datos de entrada) acciones (o pasos a ejecutar) y
descripción de un resultado esperado que se utiliza para probar que una
condición o funcionalidad específica se comporte de la manera deseado.
A continuación indicamos los pasos necesarios para generar pruebas para una
condición específica:
● Identificar la condición o funcionalidad que se va a probar.
● Diseñar el o los casos de prueba que van a verificar esa condición o
funcionalidad.
● Diseñar el procedimiento de ejecución de las pruebas.
¿NECESITAS UN EJEMPLO?
Con todo lo dicho, esto sería un flujo de trabajo:
Anteriormente sugerimos algunos ejemplos de matriz de casos de prueba y
vimos que la información a completar puede variar dependiendo de la
organización del equipo, su orden y el nivel de trazabilidad que requieran.
Es fundamental que cada caso de prueba contenga:
● Título descriptivo del caso de prueba
● Funcionalidad específica a cubrir y contexto
● Datos de entrada
● Resultado esperado
12
TIP😉
Podría pasar que en momentos de tiempos ajustados quizás no llegaras a
escribir el “paso a paso” detallado para cada caso de prueba.
De ser así, ten en mente incluir al menos la información fundamental con
una descripción clara y concreta. Para que cualquier persona que no
conozca el sistema que se va a probar entienda cómo ejecutar el caso de
prueba.
Ejercicio #1
Del siguiente listado de casos de pruebas, identifica aquellas que
están descritas correctamente.
Probar inicio de sesión
Iniciar sesión en Gmail.com/login con $usuario (rol administrador) y
$contraseña válidos. Se llega a bandeja de entrada con mensaje:
“Bienvenido $usuario”
Contraseña incorrecta
Intentar iniciar sesión desde Firefox con un usuario no registrado. Se
muestra mensaje: usuario inexistente
Probar exportar reporte
Exportar reporte Excel desde Brave browser en Administración > ventas
con usuario con permiso “export:reporte Ventas”
Intentar ingresar con un usuario registrado y un password válido luego
de tres intentos de ingreso fallidos. La cuenta se bloquea y el usuario no
puede ingresar. Se muestra el mensaje: usuario bloqueado
¡Comparte las respuestas con tu equipo! Puedes ver la solución aquí.
MATERIAL DE LECTURA
Casos de prueba positivos y casos de prueba negativos
Los casos de prueba positivos conocidos también como “el camino feliz” son
aquellos pasos que verifican el correcto funcionamiento del uso principal y
esperado de una funcionalidad.
13
https://docs.google.com/document/d/1t2UOiKcCyLJs54Xo7b9OC7Rl9W6s71eD6rfEEfB5nj4/edit?usp=sharing
¿NECESITAS UN EJEMPLO?
Para la funcionalidad de login o ingreso a un sistema, el camino feliz sería que
se ingrese en el campo “usuario” un nombre de usuario válido para ese sistema
y la contraseña correcta relacionada al mismo.
Todos los posibles errores de log in en un sistema, no forman parte del camino
feliz si no de caminos alternativos agrupados en lo que llamamos “casos
negativos”.
Casos positivos = camino feliz
Casos negativos = caminos alternativos
En el ejercicio anterior habrás notado que hay una palabra clave que se utiliza
para los casos de prueba negativos, esta es: INTENTAR
Generalmente usamos esta palabra para los casos de prueba negativos ya que
da cuenta de que la acción descrita no debería poder realizarse.
Secreto de la industria 2�
Las palabras claves pueden ser útiles para la rápida lectura e
interpretación de los casos de prueba que se diseñan.
Ejercicio #2
A continuación, encontrarás dos definiciones funcionales con base
en diferentes metodologías: casos de uso e historias de usuario.
Para cada grupo debes:
● Listar los casos de prueba que propondrías. NO olvides incluir casos de
prueba positivos y negativos.
● Ordenar los casos de prueba por prioridades, de la más alta a la más baja.
Agregarles la clasificación de prioridad: Alta, media o baja.
14
Extra: Si quieres, puedes usar una matriz de casos de prueba, ya sea en
formato tabla / Excel o usando una herramienta gratuita como Zephyr (en Jira)
Pueden utilizar la siguiente plantilla y revisar la solución aquí.
Tiempo estimado: resolver este ejercicio te podría llevar entre una hora y una
hora y media del encuentro en vivo.
Caso de uso: El usuario con rol Administrador accede al perfil del usuario y visualiza las
opciones, deshabilitar usuario, desbloquear cuenta, restablecer contraseña, editar usuario.
*El administrador puede editar: nombre de usuario, email de usuario, rol de usuario.
*El administrador puede clickear en la opción deshabilitar usuario para bloquear el acceso
del usuario seleccionado al sistema. Si cliquea en deshabilitar usuario, la cuenta de usuario
se bloquea y el texto cambia a “habilitar usuario” . Si cliquea en “habilitar usuario” el usuario
recobra el acceso al sistema
*El administrador puede cliquear en desbloquear cuenta para desbloquear una cuenta que se
encuentra bloqueada porque el usuario ingresó un contraseña incorrecto más de 5 veces.
*El administrador puede cliquear la opción restablecer contraseña que envía un email a la
casilla de correo seleccionada en el campo email de usuario.
Si la cuenta del usuario no se encuentra bloqueada, la opción desbloquear cuenta se
encuentra deshabilitada.
Si la cuenta del usuario se encuentra deshabilitada, las opciones: restablecer contraseña y
desbloquear cuenta se encuentran deshabilitadas.El panel de usuario solo se encuentra visible en los registros de personas de tipo usuario del
sistema. Las personas que no son usuarios del sistema no tienen panel de usuario.
Permisos necesarios para el rol administrador: ver panel de usuario, resetear password de
usuarios, editar usuarios, deshabilitar/habilitar usuarios, desbloquear cuenta de usuarios.
User story o historia de usuario: Como usuario del sistema quiero poder restablecer mi
contraseña de acceso para mantener mi cuenta segura.
Criterios de aceptación:
El email de restablecimiento de contraseña se envía a la dirección de correo electrónico
completada en el campo user email del perfil del usuario siempre que el usuario no esté
bloqueado ni deshabilitado.
¿Estamos llegando al final del encuentro y aun así te has quedado
con ganas de seguir aprendiendo más?
Accede a los siguientes documentos para profundizar en el
concepto de “Historia de usuario” o “User Story”.
15
https://docs.google.com/document/d/1OJjPhUR65Qw5etHbnFhWodjmXukp-dcUKKxZrooyPdw/edit?usp=sharing
https://docs.google.com/document/d/15sLL-2vcZZ2vAWcHAayC26cgFDMG3xrUKZ08wYiJGLY/edit?usp=sharing
● What’s in a Story?
● ¿Qué hay en una historia?
¡Hora de cerrar!
¡Han dado lo mejor! Felicitaciones ¿Tienen dudas? No olviden nuestra
comunidad de prácticas, la encuentran en Discord, siempre dispuesta a la
cooperación.
¡Llegó el momento de los pulsos. ¿Te gustaría recibir? Demuéstrales a tus
compañeros qué estás presente para promover su aprendizaje y el tuyo
también.
16
https://dannorth.net/whats-in-a-story/
http://adrianmoya.com/2012/08/que-hay-en-una-historia/#sthash.xWJibi6q.dpbs