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
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.

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.

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.

1Error es lo que comete el desarrollador al escribir el código, defecto es lo que vemos de manifiesto en el
software.

2
 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.

ID Defecto o bug encontrado Gravedad Valor para el negocio / Prioridad

Defecto -Alta Impacto en los usuarios -P1: urgente
-Media -P2: rápido
-Baja) -P3: puede
esperar

22-FE12 El logo está mal ubicado en la Baja Puede malinterpretarse la rápido

esquina en la pantalla de Inicio. marca del negocio

22- La función de “buscar amigos” Alta
BBDD22 no está funcionando. Ej: al
presionar el botón, no responde ni
da aviso de error. 95% de los
usuarios la utilizan.
Una función clave para casi urgente
todos los usuarios no puede
ejecutarse lo que puede dar
pérdidas

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.
Baja Aunque cuente con sus Puede esperar
dificultades no es una
función que esté tan
pendiente y no todos los
usuarios lo notarán

22-FE13 En la pantalla de “Mi perfil” el Baja Nuevamente se puede Puede esperar

logo aparece en blanco y negro. malinterpretar la marca del
No es adrede. negocio, pero como es en un
sector en particular no
necesariamente puede ser
una molestia

C. 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.

3
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.

4
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?

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.

- 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.

2En 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.”

5
 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.3

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 layouts4, 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.

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.

Es importante hacer este proceso antes de iniciar el trabajo ya que asegura que no se trabaje
en direcciones equivocadas, gastando recursos escasos.

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.

3¿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.
4Layout 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.

6
Para que ya vayas teniendo una idea, en el proceso de validación, estas son las actividades
más relevantes:

1. Testeo de caja negra (Black box testing - BBT)5 - 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.

Verificación Validación

Incluye chequear documentos, diseños,

Incluye el testeo y validación del producto real.
código y programas.

En su mayoría, son pruebas estáticas (static En su mayoría, son pruebas dinámicas (dynamic
testing). testing).

No incluye la ejecución del código. Incluye la ejecución del código.

Los métodos utilizados son BBT (black box

Los métodos utilizados son reviews, repasos, testing), WBT (White box testing) y testeos no
inspecciones de código, demostración y funcionales. También incluye: performance
análisis. testing, regression testing, security testing y
testing de sistema.6

Revisa que el software cumpla con los Chequea que el software cumpla con los
requerimientos. Documenta lo que no cumple requerimientos y las expectativas del cliente.
o lo que falta cumplir. Documenta el feedback del cliente.

Permite encontrar defectos en etapas Permite encontrar defectos que no se pudieron

tempranas del desarrollo. encontrar durante la verificación.

El objetivo de la verificación es la aplicación

y la arquitectura y requerimientos de El objetivo de la validación es el producto en sí.
software.

5Podemos 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.
6Ya profundizarás sobre estos temas en encuentros futuros.

7
 El equipo de desarrollo ejecuta la validación con
El equipo de QA realiza la verificación.
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 En general, consiste en la ejecución de un

documentación y la realizan personas. programa y la realiza una computadora.

¿NECESITAS UN EJEMPLO?
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: 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.

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.

8
 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”.

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
¿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?

MATERIAL DE LECTURA

9
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 UX7.

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

Cuándo se encontró el defecto: 19.11.2022

Prioridad:
- Muy alta
- Alta
- Media
- Baja

Dónde se reportó el defecto: incluir link al ticket8

Cómo se encontró el defecto: Durante una prueba de QA

Responsable de encontrar el defecto: Mariela García

7UX: 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.
8Tickets: 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.

10
 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.
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

11
Ejemplo 3: Facebook

12
Ejemplo 4: Selector de idioma

13
Ejercitación de casos
A continuación, podrás ver algunos casos 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.

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 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.

Nro Funcionalidades críticas que Argumentación esperada (el caso analizado debe te-
de se pueden poner a prueba ner al menos algo similar a esto)
caso

1 -Que el Posnet devuelva los da-
tos asociados a esa tarjeta co-
rrectamente.
-Que el Posnet devuelva el lí-
mite de crédito para esa tarjeta
cuando este no es suficiente.
Si el usuario tiene que introducir datos, el software actúa
de forma correcta y los datos se almacenan de forma se-
gura en la base de datos y son reescritos cuando algo
cambia.

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.

14
Nro de Funcionalidades críticas que se pue- Argumentación esperada (el caso analizado
caso den poner a prueba debe tener al menos algo similar a esto)

2 -Que en el sistema sea accesible al
presionar el botón de actualizar da-
tos.
-Que se puedan indicar qué citas se
deben reprogramar.
Si el médico tiene que introducir datos, el so-
ftware actúa de forma correcta y los datos se
almacenan de forma segura en la base de datos
y son reescritos cuando algo cambia.

-Se puede crear, cambiar y eliminar el

nombre de un médico.
-Se puede crear, cambiar y eliminar la
especialidad de un médico.
-Se puede crear, cambiar y eliminar un
turno.
-Se puede crear, cambiar y eliminar un
consultorio.
-Se puede bloquear un día en el calen-
dario para que ese médico no pueda re-
cibir citas.

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.

15
 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.

4  Que el scanner tome correcta- Si cuando un usuario hace clic en un botón o enlace
mente las medidas de una persona para que suceda algo, por ejemplo, para ir a una nue-
 Que la cámara tome correcta- va pantalla, se abre la pantalla correcta o realiza la
mente las fotografías 360° de una acción solicitada
persona
 Que el sistema muestre cómo
quedaría el modelo diseñado o ele-
gido
 Que el sistema permita cargar
los datos del cliente
 Que el sistema reciba los datos
del scanner
 Que el sistema asocie los datos
recibidos del scanner a un usuario
 Que el botón de simulación nos
permita ver cómo quedarían las
prendas con las medidas solicitadas
por el usuario

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ón9, 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.

¿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
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, ya sea por comunicación
incompleta de requerimientos o en la falta de procesos de verificación.

2. Condiciones Ambientales
9El 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.

16
 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ósmicos10. Y luego algunas fallas en el hardware (los
componentes duros de la tecnología) causadas por elementos externos. Algunos
ejemplos son: 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 funcione11 o que un usuario pueda pedir 1 millón de
hamburguesas mediante una app de pedidos a domicilio.

¡MANOS A LA OBRA!
Ejercicio #5

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.

Defecto y situación a analizar Falla Condición Defectos de Errores en

humana Ambiental fabricación el código

El sistema dejó de funcionar luego de la SI

tormenta del domingo.

El personal de limpieza es nuevo y no ha SI

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.

10No es algo de todos los días, pero es real. Mira

11Este 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.

17
El equipo de proyecto se ha atrasado dos días SI
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, SI

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 SI

(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 SI

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 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.

18