QA E5 - Casos de Estudio
QA E5 - Casos de Estudio
QA E5 - Casos de Estudio
Casos de
estudio
2
MATERIAL DE LECTURA
En la siguiente imagen vemos una simple matriz de análisis que nos puede
servir de ayuda para saber qué hacer al descubrir un defecto.
1
Error es lo que comete el desarrollador al escribir el código, defecto es lo que vemos de
manifiesto en el software.
3
Imagen 5.1: Matriz de priorización de defectos, basada en la matriz de toma de decisiones de
Eisenhower. Fuente: producción propia.
¡MANOS A LA OBRA!
Ejercicio #1
Vamos a poner en práctica la matriz de priorización y le vamos a
sumar un componente: identificar el tipo de error que vemos.
4
ID Defecto o bug Gravedad Valor para el negocio / Prioridad
Defecto encontrado -Alta Impacto en los -P1: urgente
-Media usuarios -P2:rápido
-Baja) -P3: puede
esperar
5
MATERIAL DE LECTURA
3. Verificación y validación
El proceso de verificar y validar es el proceso por el cual se investiga si un
sistema de software satisface las especificaciones, requerimientos y
estándares indicados y si cumple el propósito deseado.
Estos dos términos son utilizados indistintamente por muchas personas. Dado
que los especialistas en testing se encargan fundamentalmente de la
verificación, debemos hacer foco en comprender el término y distinguirlo de la
validación.
Verificación
2
En el encuentro #1, vimos cómo se inicia un proyecto de software. En la primera etapa
“Estrategia” el equipo de desarrollo recopila todo lo que debe ejecutar el software y redacta un
documento guía que acompaña todos los estadíos de desarrollo. A ese documento se lo
conoce como “Requerimientos.”
3
Seth Godin es un autor, emprendedor y consultor de Marketing y ventas estadounidense.
Entre sus logros se encuentran ser el autor del blog más antiguo de internet:
https://seths.blog/. Desde su inicio, Seth no ha dejado de publicar una entrada por día. Si vas a
procrastinar con tu tiempo, hazlo leyendo sobre Seth Godin.
6
- Asegúrate de haber comprendido lo que se debe hacer
- Haz las preguntas en este momento o luego ya deberás cumplir con lo
establecido en ese documento inicial
Dado que el proceso de verificación suele ser complejo debido al tamaño del
proyecto o la complejidad del mismo, se utilizan varios métodos de verificación.
Algunos de ellos son: inspección del código, revisiones de código, revisiones
técnicas, entre otros. Los equipos de testing (QA) también pueden usar
modelos matemáticos y cálculos para predecir el comportamiento del código y
verificar su lógica (etapa de análisis de requerimientos).
¿NECESITAS UN EJEMPLO?
4
¿Te acuerdas del caso que vimos en el Encuentro #1 en el que un cliente ficticio hacía un
pedido? El primer paso luego de ese pedido era que el equipo de desarrollo se preocupara por
tener todos los requerimientos lo más exactos posibles, para no diseñar ni cotizar nada que no
sea relevante.
5
Layout es la distribución gráfica de los elementos en una pantalla, por ejemplo. En una
habitación, el layout es cómo están distribuidos los muebles y qué sensación generan de una u
otra manera.
7
Paso 3: La verificación del código tiene por objetivo evaluar el código para ver
si está (a) completo, (b) correcto y (c) si es consistente (al ser testeado,
responde en forma previsible). En esta etapa el equipo de QA chequea si el
código fuente, las interfaces de usuario y el modelo de la base de datos de la
aplicación cumplen con las especificaciones de diseño.
Conclusiones:
La verificación es un proceso continuo, interno que se debe realizar en todas
las etapas del desarrollo de software. La verificación es el testing estático.
Validación
8
Para que ya vayas teniendo un idea, en el proceso de validación, estas son las
actividades más relevantes:
El extraño caso del UAT (User Acceptance Test). El UAT es el último test del
proceso de verificación (y está a cargo de usuarios reales, beta testers o
usuarios designados por el cliente), o puede ser considerado como parte de la
Validación ya que es parte del proceso de validación del producto. Hoy en día
la línea que divide Verificación de Validación es muy difusa ya que los procesos
se han vuelto más dinámicos, respondiendo a cambios mucho más ágiles
propios del desarrollo de software ágil.7
6
Podemos hacer muchos esfuerzos para que tengas esta información en español, pero la
realidad es que el 90% de las veces vas a escuchar que se llama a estos tests por su
denominación original en inglés.
7
¿Quieres leer más sobre este tema? AVISO: está en inglés y es altamente técnico.
9
Verificación Validación
El objetivo de la verificación es la
El objetivo de la validación es el
aplicación y la arquitectura y
producto en sí.
requerimientos de software.
8
Ya profundizarás sobre estos temas en encuentros futuros.
10
¿NECESITAS UN EJEMPLO?
¡Por supuesto que sí! La teoría es útil pero solamente cuando sabemos en
dónde utilizarla y para qué.
Automóvil: poner en uso los comandos de las ventanas y los asientos para
verificar que funcionen correctamente, encender el vehículo para corroborar que el
aire acondicionado produzca aire frío, dar una vuelta con el automóvil para tener una
idea de aceleración y rango de maniobras como fue descrito en los requerimientos.
Software: ingresar todos los campos en las pantallas y seleccionar los botones
que cumplan con lo solicitado, esperando la respuesta específica. Asegurar que los
datos devueltos son del tipo requerido.
Automóvil: acelerar el automóvil de cero a 100 km/h. Verificar que pueda ser
realizado en 5.2 segundos. Acelerar en una curva bajo condiciones de control,
produciendo 0.8 fuerza G, sin que el vehículo pierda tracción.
11
4. Análisis: es la verificación del producto o sistema utilizando modelos, cálculos
y equipos de pruebas especializados. Esta etapa permite que se puedan hacer
predicciones sobre el desempeño o performance típicos del producto o
software basados en resultados confirmados de las pruebas. También se
pueden combinar estos resultados para ofrecer mayor información sobre el
producto para poder estimar los rangos límites de performance.
¡MANOS A LA OBRA!
Ejercicio optativo
Es mucho material para absorber y seguro volverás en el futuro a
leerlo con mayor entendimiento de su importancia.
12
MATERIAL DE LECTURA
Reporte #125
9
UX: user experience o experiencia de usuario se refiere a la navegación intuitiva y sensación
de claridad que tienen los usuarios al interactuar con soluciones de software. A pesar de que la
UX (User Experience) y la UI (User Interface) tienen nombres parecidos son completamente
diferentes. La UI o interfaz de usuario está dirigida hacia el lado más racional de la navegación
y la arquitectura de cómo se presentan los elementos.
13
Cuándo se encontró el defecto: 19.11.2022
Prioridad:
- Muy alta
- Alta
- Media
- Baja
¡MANOS A LA OBRA!
Ejercicio #2
Te presentaremos una serie de imágenes. En el encuentro anterior te
alcanzamos este artículo que creemos que será de gran ayuda para ir
consolidando el lenguaje con el que hablamos de los defectos o bugs.
10
Tickets: en general para dar seguimiento a los bugs se utilizan sistemas como Trello,
Atlassian o ClickUp. Si quieres comenzar a investigar estas herramientas, te invitamos a
hacerlo ya que es una ventaja competitiva para tí conocerlas en profundidad. Más adelante las
estaremos poniendo en práctica con algunos ejercicios.
14
B. ¿Puedes incluir el tipo de error que ves? Si no los recuerdas, son estos
que vimos en el encuentro anterior.
Ejemplo 2: Notificaciones
15
Ejemplo 3: Facebook
16
5. Colección cooperativa de defectos in the wild
Estuvimos viendo muchos ejemplos. Casi todos recuperados de la vida real, de
anécdotas de testers y de nuestras experiencias personales. Es hora de que te
sumes y comiences tu propia colección de errores que han atravesado barreras
de supervisión y testeo para llegar directamente al usuario final.
¡MANOS A LA OBRA!
Ejercicio #3
En nuestro Discord, ve al canal de WANTED - Errores infraganti y comienza a
postear defectos que hayas encontrado en estos días.
17
Ejercitación de casos
Tenemos una serie de ejercicios que te ayudarán a poner en
práctica todos los conceptos aprendidos hasta hoy.
Ejercicio #4
¡Tip! Ten a mano las guías de los encuentros anteriores ya que estarás
usando conceptos que ya hemos visto.
18
de datos e imprime la factura y el ticket de compra a través del mismo postnet.
De esta forma lo desarrollado cumple con todas las especificaciones para
realizar una compra con una tarjeta de crédito.
El sistema, hasta el momento permite tomar los datos del cliente y ofrece los
diseños de pantalones, bermudas, shorts, camisas, polleras, tops y camperas
para que el cliente pueda elegir los productos a confeccionar. El sistema recibe
del scanner los datos de las medidas guardándolos en la ficha del cliente.
Cuando se intenta simular cómo quedaría en la persona con las fotos 360
tomadas por el mismo, el botón de simulación solo muestra las prendas
elegidas del catálogo, pero no con las medidas y el escaneo de la persona.
19
MATERIAL DE LECTURA
Las pruebas son necesarias para reducir el riesgo de detectar errores pero
muchas veces no logran anticipar todos los casos posibles de uso.
Cuanto mejores y más adecuadas sean las pruebas de software, menor será el
riesgo de encontrar errores durante la fase de operación o producción11, y ya
sabemos que no todos los errores son iguales. No es lo mismo un error crítico y
urgente que un error trivial que puede esperar. El problema con los errores en
producción es que están a la vista de todos.
Ya hemos visto errores y defectos. Veamos cuáles son las causas posibles de
los errores y defectos en software
1. Error Humano
Las personas a cargo de un proyecto pueden equivocar alguno de los
puntos a resolver. Desde una fecha de entrega incorrecta (“Era para
hoy?”), hasta enviar a producción una porción de código que no estaba
testeada todavía. Los memes abundan, dando cuenta de cuántas veces
se pierden los detalles en la comunicación incompleta de
requerimientos o en la falta de procesos de verificación.
2. Condiciones Ambientales
Existen causas ambientales que tienen impacto directo sobre la
tecnología. Algunos ejemplos son la radiación, el magnetismo, campos
electromagnéticos, polución, tormentas solares, rayos cósmicos12. Y
luego algunas fallas en el hardware (los componentes duros de la
tecnología) causadas por elementos externos. Algunos ejemplos son:
11
El mundo de la tecnología robó este término de la manufactura. Cuando en una fábrica un
producto pasa de diseño a producción, quiere decir que ya está en el piso, siendo fabricado y
no admite cambios. Imaginemos el cambio estacional de etiqueta de una botella de gaseosa
(ej, por la época navideña). En el momento en el que el nuevo diseño se implementa, la cadena
de producción ya comienza a imprimir miles y miles de etiquetas y a aplicarlas en las botellas.
Imaginemos que la etiqueta sale con un error de ortografía. Las botellas ya se encuentran en
producción, a la vista de los usuarios (¡y los influencers!). En software, un producto en
producción es un producto que ya está “impreso” a la vista de los usuarios. Seguro conoces
este caso real.
12
No es algo de todos los días, pero es real. Mira
20
fallos de discos duros debido a fluctuaciones en el suministro de energía
eléctrica, temblores, terremotos, inundaciones, y otros elementos de la
naturaleza que puedan afectar directamente a la estructura más visible
de una computadora.
4. Errores en el código
Errores al escribir código por parte de un programador que no hayan
sido detectados en la fase de pruebas. No son errores de malos
entendidos (como en el caso de los errores humanos) sino que son
errores de la lógica interna que hacen que el código no pueda ser
ejecutado. Por ejemplo, ingresar una edad “negativa” (-18) puede
generar que una aplicación no funcione13 o que un usuario pueda pedir 1
millón de hamburguesas mediante una app de pedidos a domicilio.
¡MANOS A LA OBRA!
Ejercicio #5
¡Tip antes de empezar! Te recordamos una máxima del testing: “El testing
puede probar la presencia de errores, pero no la ausencia de ellos”.
Antes de avanzar con este ejercicio, ¿quieres acceder a las posibles
soluciones del ejercicio anterior (#4)? Hazlo desde aquí. Sabemos que la
atención al detalle implicó un gran esfuerzo pero queremos que puedas
validar si has podido observar bien al detalle.
13
Este tipo de “inputs” o ingresos se contempla en lo que se llama manejo de excepciones. Es
buena práctica que los desarrolladores tengan en cuenta estos casos al escribir código, pero
siempre hay algún caso en el que estas excepciones no se detectan y quedan en producción.
21
Defecto y situación a analizar Falla Condición Defectos de Errores en
humana Ambiental fabricación el código
22
logística. Le han dado material para
leer, inclusive un video de cómo debe
funcionar y aún así no logra
comprender la lógica de los
requerimientos. Al hacer su entrega
de esta semana nada funcionaba
como pedía el cliente.
¡Hora de cerrar!
23