QA E5- Casos de estudio

Vista previa del material en texto

Módulo 1 / Encuentro 5/17
Casos de
estudio
OBJETIVOS DEL MÓDULO 1
¿Qué habilidades desarrollarás?
● Aprendizaje cooperativo entre pares
● Atención al detalle
● Fundamentos de la lógica de programación
● Manejo y priorización de la información
● Herramientas mínimas de seguridad de la información
¿Qué herramientas técnicas aprenderás?
● Entendimiento del mundo del testing
● Ciclo de desarrollo de software
● Introducción al desarrollo ágil
● Lenguaje unificado de modelado �UML�
● Terminología fundamental
Introducción
¡Te damos la bienvenida a tu quinto encuentro de trabajo!
Check de 1 minuto: Hoy es un encuentro de integración de conceptos. Nos
tomaremos el día de hoy para ejercitar, consolidar y transferir los aprendizajes
a contextos nuevos y desafiantes. Lo más beneficioso para ti es darte cuenta
de cuánto sabes. También, podrás identificar aquellos conceptos que más te
cuestan o que todavía no has asimilado completamente. ¡No te preocupes! A
mayor conciencia de tus áreas de mejora, mayor foco para poder trabajar sobre
ellas.
¡Demos comienzo a la actividad del día de hoy!
1. Presentación del equipo:
¡Listos, preparados, ya! A esta altura conoces bien cómo funciona
este momento. ¿Ya se han presentado con el equipo? ¿Te has
encontrado nuevamente con alguien? ¿Han podido resolver las
actividades que han surgido hasta ahora?
Utilicen unos 10 minutos para compartir estas breves presentaciones y repasar
los conceptos que han aprendido en el encuentro anterior. ¡Seguro recuerdas
más de lo que crees!
2
MATERIAL DE LECTURA
2. Evaluación de criticidad y prioridad
Hemos explorado ampliamente el mundo de los errores �¡y
todavía falta!� pero nos detendremos hoy a entender cómo
clasificar a un error o defecto en el momento en el que lo
encontramos1.
Si el ciclo de producción de software está funcionando correctamente el
equipo de testing �QA� podrá identificar o alertar de errores a tiempo antes de
que salgan a la luz, frente a los clientes o usuarios finales. Como bien sabemos
esto sería una descripción del escenario ideal. Lo habitual es que haya muchas
líneas de código y muchas personas colaborando al mismo tiempo (grandes
empresas con procesos de trabajo muy establecidos) o pocas personas
haciendo muchas tareas superpuestas (contexto de empresas pequeñas o en
estadío de startup). Es en esa superposición de muchas personas o muchas
tareas que a veces vemos cómo los errores salen a la luz (bugs o defectos). O
los descubrimos con muy poco tiempo antes de que sea necesario entregar el
producto y ya no hay margen para cambios.
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.
A. En el cuadro a continuación verás distintas descripciones de un reporte
en el que el equipo de QA detecta varios defectos en una app mobile
(para teléfonos celulares).
B. Clasifica cada uno de los defectos detectados. En la columna de
Criticidad/gravedad clasifícalos en torno a su impacto en la
funcionalidad. Y en prioridad asígnales un valor basándote en cuánto
afectan al valor de la empresa.
Aquí tienes una copia de la tabla para poder trabajar.
4
https://docs.google.com/document/d/1oH_G2MjeZDJp4mgD85O-uH-BmdloriPLF-g1ZAFz34k/edit?usp=sharing
ID
Defecto
Defecto o bug
encontrado
Gravedad
�Alta
�Media
�Baja)
Valor para el negocio /
Impacto en los
usuarios
Prioridad
�P1� urgente
�P2:rápido
�P3� puede
esperar
22�FE12 El logo está mal ubicado en
la esquina en la pantalla de
Inicio.
22�BBD
D22
La función de “buscar
amigos” no está
funcionando. Ej: al presionar
el botón, no responde ni da
aviso de error. 95% de los
usuarios la utilizan.
22�BE06 La función de “Acceder a mi
historial” funciona en forma
intermitente. En el 50% de
los casos hay que refrescar
para que traiga la
información. 10% de los
usuarios la utilizan.
22�FE13 En la pantalla de “Mi perfil”
el logo aparece en blanco y
negro. No es adrede.
C. Si no lo han hecho todavía, es un buen momento para compartir
el ejercicio y cómo lo resolvieron. Estos son casos reales y muchas
veces no hay consenso sobre qué funcionalidad se debe resolver
primero. Lo más importante es poder traer evidencias de impacto.
¿Qué están viendo ustedes como testers que los otros equipos no
han logrado identificar? Cuanto más eficientes sean al explicar por qué
estos defectos son relevantes, más rápido se podrá proceder a
solucionarlos y más valor tendrá cada uno de ustedes en los equipos.
D. BONUS� ¿Se animan a catalogar qué tipo de error es cada uno?
E. BONUS #2� ¿Tienen ejemplos gráficos de defectos parecidos? Vale usar
Google, no es necesario que los hayan encontrado ustedes.
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.
● Verificación: ¿Estamos construyendo el producto correctamente?
● Validación: ¿Estamos construyendo el producto correcto?
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
Es el proceso por el que se determina si el software que está siendo analizado
se está diseñando y desarrollando de acuerdo a requerimientos especificados.2
Los requerimientos o especificaciones actúan como guía en todo el proceso de
desarrollo de software. El código que se escribe para un software está basado
en esa documentación inicial.
Seth Godin3 define a la calidad como “estar a la altura de los requerimientos.”
La potente definición de Godin simplifica al máximo nuestra tarea al iniciar un
proyecto:
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.
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.”
6
https://seths.blog/
- 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
La verificación se realiza para corroborar que el software que está siendo
desarrollado adhiera a estas especificaciones en todos los momentos de su
ciclo de desarrollo. La verificación asegura que la lógica del código esté
alineada con estas especificaciones y que no contenga errores.
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?
Supongamos que debemos testear una aplicación para teléfonos móviles. O
dicho como lo diría un profesional: una app mobile.
Esta verificación tiene tres fases:
1. La verificación de los requerimientos.
2. La verificación del diseño.3. La verificación del código.
Paso 1� es verificar y confirmar que los requerimientos están completos, son
claros y correctos. Antes de que una aplicación vaya a ser desarrollada, el
equipo de QA testea que los requerimientos del negocio o del cliente estén
completos y correctos.4
Paso 2� La verificación del diseño es el proceso por el cual el equipo se
asegura que el software cumple con los requerimientos de diseño y lo hace a
través de mockups o evidencias gráficas. Aquí el equipo de QA testea si los
layouts5, prototipos (mockups), los flujos de navegación, el diseño de la
arquitectura y los modelos lógicos de las bases de datos están a la altura de
los requerimientos funcionales y no-funcionales del cliente.
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.
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.
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.
Lo más importante a recordar de este ejemplo es que la verificación se realiza
en forma interna, dentro de los equipos que van a estar trabajando con el
desarrollo de la aplicación. Es importante hacer este proceso antes de iniciar el
trabajo ya que asegura que no se trabaje en direcciones equivocadas,
gastando recursos escasos. Una vez más, el equipo de testing está para
asegurarse de que se trabaje en forma eficiente, anticipando los problemas y
ahorrando tiempo y dinero.
La realidad: muchas organizaciones y startups tardan mucho en implementar
procesos de verificación. Y suelen hacerlo cuando ya han constatado más de
una vez que se gasta mucho más en “lo hacemos rápido, sin un plan” que “lo
hacemos bien, verificando paso por paso y luego lo construimos.”
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.
Sus principales ventajas son:
1. Actúa como control de calidad en cada etapa del proceso de desarrollo
de software.
2. Permite que el equipo de desarrollo produzca productos que se ajustan a
los requerimientos y a las necesidades del cliente.
3. Ahorra tiempo ya que se detectan los defectos en las etapas tempranas
del desarrollo de software.
4. Reduce o elimina los defectos que pueden surgir en las etapas más
tardías del desarrollo de software.
Validación
La validación es el proceso de chequear que se esté desarrollando el producto
correcto. A diferencia de la verificación que va desde los requerimientos hacia
el código, la validación se hace en dirección opuesta. Va escalando por las
distintas capas de desarrollo y va chequeando que el software desarrollado
sea el producto correcto. Es por ello que este proceso lo lleva adelante, en su
mayor parte, el equipo de desarrollo, y se realiza cuando el producto ya está
listo para ser entregado. La validación es el testing dinámico.
8
Para que ya vayas teniendo un idea, en el proceso de validación, estas son las
actividades más relevantes:
1. Testeo de caja negra (Black box testing � BBT)6 - Testeo de sistema
completo. Responsables: equipo de QA/testing
2. Testeo de caja blanca (White box testing � WBT). Responsables:
desarrolladores
3. Testeo unitario (Unit testing � UT). Responsables: desarrolladores
4. Testeo de integración o integraciones (Integration testing).
Responsables: desarrolladores
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
Si en el campo profesional estos dos procesos se superponen, ¿por qué es
importante que aprendamos estos conceptos?
Volviendo al punto de partida inicial: la verificación sirve para saber si estamos
construyendo el producto correctamente (de acuerdo a lo pedido) y la
validación nos sirve para saber si hemos construido el producto correcto (el
que necesita el mercado o el cliente y que va a generar valor).
7 ¿Quieres leer más sobre este tema? AVISO� está en inglés y es altamente técnico.
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.
9
https://softwareengineering.stackexchange.com/questions/266165/why-all-consider-uat-a-validation-activity-it-contradicts-the-original-idea
Verificación Validación
Incluye chequear documentos,
diseños, código y programas.
Incluye el testeo y validación del
producto real.
En su mayoría, son pruebas estáticas
(static testing).
En su mayoría, son pruebas dinámicas
(dynamic testing).
No incluye la ejecución del código. Incluye la ejecución del código.
Los métodos utilizados son reviews,
repasos, inspecciones de código,
demostración y análisis.
Los métodos utilizados son BBT (black
box testing), WBT �White box testing) y
testeos no funcionales. También incluye:
performance testing, regression testing,
security testing y testing de sistema.8
Revisa que el software cumpla con los
requerimientos. Documenta lo que no
cumple o lo que falta cumplir.
Chequea que el software cumpla con los
requerimientos y las expectativas del
cliente. Documenta el feedback del
cliente.
Permite encontrar defectos en etapas
tempranas del desarrollo.
Permite encontrar defectos que no se
pudieron encontrar durante la
verificación.
El objetivo de la verificación es la
aplicación y la arquitectura y
requerimientos de software.
El objetivo de la validación es el
producto en sí.
El equipo de QA realiza la verificación.
El equipo de desarrollo ejecuta la
validación con ayuda del equipo de
Testing.
Ocurre antes de la validación. Ocurre luego de la verificación.
En su mayoría, consiste en el análisis
de documentación y la realizan
personas.
En general, consiste en la ejecución de
un programa y la realiza una
computadora.
Mucho para leer, todo junto….
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é.
Vamos a dar un paseo por una verificación. Estaremos verificando un automóvil
y una aplicación de software al mismo tiempo.
1. Inspección: se refiere a examinar un producto o sistema sin intervenir en él.
Puede ser la simple manipulación física o tomar medidas, por ejemplo.
Automóvil: inspeccionar visualmente el automóvil para asegurarnos de que
cumpla con los requerimientos especificados: levanta cristales eléctrico, asientos
ajustables, aire acondicionado, sistema de navegación a bordo, kit de remolque, etc.
Software: examinar visualmente el software para constatar que existan las
pantallas solicitadas, chequear que estén los campos necesarios para el ingreso de
datos (nombre de usuario, por ejemplo), verificar que existan todos los botones para
las funcionalidades solicitadas, etc.
2. Demostración: es la manipulación del producto como se espera que sea usado,
para verificar que se comporte como se planificó o de acuerdo a las
expectativas.
Automóvil: poneren 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.
3. Prueba: es la verificación del producto o sistema utilizando una serie de
estímulos, datos o ingresos predeterminados para corroborar que el producto
produzca un resultado específico y predefinido en los requerimientos.
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.
Software: ingresar el tipo y modelo de automóvil, con levanta cristales eléctrico,
dirección asistida, y el resto de las opciones definidas en el plan de pruebas,
seleccionar el botón de “obtener precio ya” y que la aplicación devuelva el valor
preciso de “$43.690”.
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.
Automóvil: completar una serie de aceleraciones a unas revoluciones/m por un
tiempo determinado, mientras se monitorea la vibración del motor y su temperatura,
verificando que se logran los resultados deseados. Utilizar esta información para
predecir el punto de falla del motor. Ej, las rev/m máximas toleradas por un tiempo
estimado.
Software: completar una serie de pruebas en las que un número
predeterminado de usuarios ingresan las características del automóvil que están
intentando cotizar e inician la función “obtener precio” al mismo tiempo. Se mide el
tiempo de respuesta para corroborar que la función devuelve un precio dentro de los
límites de tiempo preestablecidos. Se analiza la relación entre el incremento de
usuarios en el sistema y el tiempo que le toma a la función devolver el precio. Se
documentan los resultados y el tiempo de cada prueba para ver si se degrada la
performance a medida que el sistema recibe mayor carga para detectar cuándo es el
momento en el que el sistema deja de cumplir con las expectativas definidas en los
requerimientos.
¡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.
Les proponemos un ejercicio optativo como equipo. Si vienen bien
con los tiempos de hoy, si estos temas ya los tienen claros o si
prefieren el camino de “probar y luego entender”, este ejercicio es para
ustedes.
En Egg debemos realizar todas estas pruebas, y a medida que nuestra
tecnología va adquiriendo complejidad, estas pruebas se realizan para sostener
nuevas funcionalidades y nuevos desafíos de cantidad de usuarios.
¿Se animan a diseñar un plan de pruebas simple para la tecnología de Egg,
siguiendo los 4 pasos de verificación que vimos en el ejemplo anterior?
12
MATERIAL DE LECTURA
4. Introducción a la documentación de defectos (bugs)
Ya estamos afilando nuestras herramientas de detección de defectos. Ya
sabemos cómo clasificarlos y hasta nos aventuramos a entender un poco del
mundo de la UX9. ¿Cómo podemos iniciarnos en la documentación clara y
efectiva de un defecto?
Si bien vamos a estar explorando varias técnicas y matrices de documentación,
es importante saber que hay una estructura básica que incluye todos los datos
necesarios para que un equipo de desarrolladores sepa a qué error nos
referimos, en qué contexto del software está y qué esperamos de la solución.
Reportar defectos en forma clara también ayuda a que puedan resolverse
rápidamente.
Reporte #125
Defecto: La palabra “Settings” está mal escrita en el menú de Configuración en
la versión en inglés.
Descripción del defecto �¿Cuál es el bug?�� Falta la letra “g” en la palabra
“Settings”
Comportamiento esperado �¿Cómo debería verse?�� Cambiar la palabra
“Settins” por “Settings”
Enlaces relacionados: Ver imágenes a continuación
Más información: Si es necesario aclarar el contexto para replicar el error
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
Dónde se reportó el defecto: incluir link al ticket10
Cómo se encontró el defecto: Durante una prueba de QA
Responsable de encontrar el defecto: Mariela García
Reporte #125� Imágenes de apoyo. A la izquierda vemos la imagen como se ve hoy y a la
derecha cómo debería verse una vez solucionado el error.
¡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.
A. ¿Puedes documentar los defectos que ves en las imágenes a
continuación? Te dejamos una copia del reporte para que puedas usar.
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
https://diariobug.com/error-bug-falla/
https://docs.google.com/document/d/1uu-j02GruDZ-jSQ9dEPOGa2_4jUHmDjpN14ahjWnGiQ/edit?usp=sharing
B. ¿Puedes incluir el tipo de error que ves? Si no los recuerdas, son estos
que vimos en el encuentro anterior.
Ejemplo 1� Trip Advisor
Ejemplo 2� Notificaciones
15
https://docs.google.com/document/d/1KB3o5M_RAaBhwVXoB_vAgjNnUySZZbRX/edit#heading=h.px60paj157uu
Ejemplo 3� Facebook
Ejemplo 4� Selector de idioma
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.
Puedes practicar hacer el reporte en tu mismo posteo y explicar qué tipo de
defecto has encontrado, cómo replicarlo y si el productor de ese software tiene
algún sistema de recolección de errores, como el WER de Windows que vimos
en el encuentro pasado.
¡Entre tod@s los estudiantes de la comunidad podremos lograr una colección
enorme de defectos encontrados in the wild! Y si hoy no tienes ninguno a
mano, no te preocupes, puedes volver cuando quieras y dejar tu aporte.
17
https://discord.com/channels/1042107558485311619/1052702755585794079
Ejercitación de casos
Tenemos una serie de ejercicios que te ayudarán a poner en
práctica todos los conceptos aprendidos hasta hoy.
Puedes hacerlos en forma individual o como equipo. Sabemos que
el esfuerzo es grande.
Ejercicio #4
¡Tip! Ten a mano las guías de los encuentros anteriores ya que estarás
usando conceptos que ya hemos visto.
A continuación, podrás ver algunoscasos de interacción con sistemas
informáticos (software).
A. Identifica todas las funcionalidades y selecciona aquellas que consideres
críticas para ser analizadas y déjalo asentado en un cuadro como este.
Allí verás un ejemplo para ayudarte desde el principio.
B. En equipo, comparen sus análisis y debatan las razones por las que
eligieron esas transacciones como críticas. No olviden hacer referencia a
las instancias de verificación que se vieron en la sesión de hoy.
Caso 1. El usuario utiliza su tarjeta de crédito en una empresa de
electrodomésticos que posee el servicio de postnet para las compras. Se
cargan los datos que validen que quien compra es el dueño de esa tarjeta, y el
sistema se conecta con el sistema de la Tarjeta de Crédito MasterCompra para
validar que puede venderle a ese cliente y que dispone de margen de crédito
para comprar.
El sistema actúa habilitando la operación para la compra de un producto porque
tiene un valor inferior al límite total que la tarjeta. Luego, el sistema guarda los
datos de la compra vinculados a los del cliente y almacena los datos en la base
18
https://docs.google.com/document/d/1hgzRZlOs9j5XeNdv7PEPwCKxTmxy24VkM36jAgm3R0I/edit?usp=sharing
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.
Caso 2. El sistema AsisteMed solicita desarrollar un sistema para agendar citas
de pacientes con médicos en una clínica. Sus funciones son: alta, modificación
y baja de los médicos con su especialidad; alta y baja de un turno o cita; alta y
modificación de los consultorios.
Cuando los médicos acceden al sistema, al presionar el botón de actualizar
horarios de cada uno de ellos, no pueden indicar los días en que los médicos no
se encuentran por operaciones, emergencias, viajes, vacaciones u otras
situaciones, por lo que no pueden indicar qué citas se deben reprogramar.
Caso 3. La empresa Aión se dedica a fabricar y recargar de manera mayorista
matafuegos o extinguidores. Tu consultora está desarrollando el sistema Kairos
que tiene por objetivo manejar el stock de entrada y salida. El stock de entrada
es cuando piden recargas de extinguidores y el stock de salida son los
productos nuevos que venden a comercios del rubro y a comercios que venden
repuestos para autos. La funcionalidad de carga de los datos de entrada: recibe
información de un sistema �Lector de datos), que toma la lectura de todos los
códigos de barra de cada matafuego/extintor a ser recargado. Esta información
es enviada al sistema Kairos para llevar el registro de todos los matafuegos a
recargar en la base de datos del sistema.
Caso 4. El sistema Cronos se está desarrollando para diseñar, confeccionar y
vender ropa de jean a medida. Para ello se utiliza un scanner especial para
tomar las medidas de una persona y fotos 360 grados para mostrar en pantalla
sobre el cuerpo real del usuario cómo quedaría el modelo diseñado o elegido.
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.
La ejecución anticipada de las pruebas reduce el riesgo de que los errores
provoquen fallas críticas en el sistema.
¿Qué puede causar un error y/o un defecto en un programa de
software?
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:
12 No es algo de todos los días, pero es real. Mira
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.
20
https://www.nmdb.eu/public_outreach/es/05/#:~:text=El%20continuo%20flujo%20de%20rayos,campo%20magn%C3%A9tico%20de%20la%20Tierra.
https://www.perfil.com/noticias/actualidad/para-coleccionistas-las-monedas-de-1-con-error-tienen-escaso-valor-porque-hay-56-millones.phtml#:~:text=En%20plena%20%C3%A9poca%20de%20%E2%80%9C1,el%20trabajo%20ya%20estaba%20hecho.
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.
3. Defectos de fabricación �Defects)
Estos son desperfectos en un componente que pueden causar que el
sistema falle en desempeñar las funciones requeridas, por ejemplo, una
sentencia o una definición de datos incorrectos. Failure �Fallo) es una
desviación funcional de un componente o sistema respecto de la
prestación, servicio o resultado esperados.
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.
En la siguiente tabla, tienes algunos defectos para iniciarte en tu detección de
causas. Aquí hemos preparado una copia de la tabla para que puedas trabajar
directamente en ella.
13 Este tipo de “inputs” oingresos 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
https://docs.google.com/document/d/1-afW7Kw8FjXH_LIZC5zvq6hhM24Aw7ZL50_vJwO_Mu0/edit?usp=sharing
https://docs.google.com/document/d/1-tEmRPEC9NGQpf4vibgANVSCQ0eZWbV3GcGHFHXPn9w/edit?usp=sharing
Defecto y situación a analizar Falla
humana
Condición
Ambiental
Defectos de
fabricación
Errores en
el código
El sistema dejó de funcionar luego de
la tormenta del domingo.
El personal de limpieza es nuevo y no
ha tomado una capacitación crítica y
han limpiado el piso con baldes de
agua, provocando un cortocircuito
menor que costó mucho encontrar, ya
que este se produjo en una sala de
reuniones donde los enchufes están
muy cerca del piso.
El equipo de proyecto se ha atrasado
dos días en entregar su trabajo ya que
comparten sala de trabajo con el
equipo comercial, quienes realizan
muchas llamadas telefónicas, y
provocan distracciones en los
desarrolladores.
Durante la demo, el líder del equipo,
Franco, se sintió muy frustrado, ya
que parte del código desarrollado y
testeado el último mes no servirá para
ser puesto en producción. El
responsable de Marketing durante la
reunión le comentó que las políticas
de la empresa habían cambiado por
una decisión del directorio
impactando en varias partes del
sistema, lo cual no se había
comunicado a los empleados hasta
hace dos días.
Al pasar la base de datos al nuevo
sistema (migración de datos), no se
pudo volcar los datos de los clientes,
ya que, en el nuevo sistema, el
apellido está en un campo diferente al
del nombre.
Natalia es la más junior del equipo de
programación. La vemos muy
cansada, se ha quedado varias horas
de más desde hace dos semanas,
intentando comprender cómo
funciona todo en la empresa. Tiene
asignadas tareas en un negocio de
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!
¡Lo hemos logrado! Has llegado al final del quinto encuentro.
Tómense 5 minutos como equipo para conversar sobre la dificultad de
priorizar: ¿qué es urgente? ¿Qué es crítico pero no urgente?
Este tipo de discusiones ocurren en todas las organizaciones y es una
gran deuda de los equipos cuando no cuentan con esta habilidad para
diferenciar entre lo que es crítico y urgente y lo que es urgente y no
crítico.
Poder ejecutar este análisis te ayuda a desarrollar el juicio crítico,
habilidad altamente solicitada en el mercado laboral.
¡Gran momento para recordar y agradecer a nuestro equipo de hoy! En el
próximo encuentro estaremos poniendo a prueba lo aprendido hasta hoy. Si
tienes tiempo de sobra, es hora de recorrer el material de estos primeros 5
encuentros. También te sugerimos hacer preguntas en tu equipo y en el foro de
Discord sobre este encuentro. Tus preguntas o tus respuestas son de gran
ayuda para el aprendizaje de la comunidad.
23
https://discord.com/channels/1042107558485311619/1046866606824890520
https://discord.com/channels/1042107558485311619/1046866606824890520