CURSO DE TESTING MANUAL O QUALITY CONTROL

MATERIAL DE LECTURA

Principios y ciclo de
vida
PARTE 1
 Objetivos de la Guía
En esta guía aprenderemos a:

• Comprender la importancia de cada uno de los

principios de las pruebas.

• Reconocer cómo debe implementarse cada principio.

• Diferenciar los conceptos de gravedad y prioridad.

• Comprender cómo deben evaluarse los errores.

• Diferenciar quién debe evaluar cada atributo del

error.

• Poder clasificar errores.

PINTRODUCCIÓNP
Bienvenido al Módulo 2. Hagamos una breve recapitulación de los que hemos estudiado hasta
aquí. En el módulo 1 aprendimos que no es lo mismo decir QA que tester. Situamos la tarea de
ellos en el desarrollo de software, y para ello aprendimos cómo es el ciclo de vida de los
softwares. Determinamos la importancia del testing en el desarrollo, y diferenciamos varios
conceptos que utilizaremos como vocabulario diario en nuestro camino a convertirnos en testers.

En el Módulo 2 nos sumergiremos en cómo se realizan las pruebas. Es un camino esquematizado

que cuenta con varios pasos a seguir. En la siguiente guía veremos algunos conceptos
importantes previo a comenzar con el proceso en sí. Antes de finalizar el Módulo, veremos cómo
se aplica este proceso en el paradigma actual.

En esta guía analizaremos algunos conceptos que debemos tener como base para
desempeñarnos como testers, veremos los principios que todo tester debe tener siempre en
cuenta a la hora de desempeñarse y cómo clasificaremos los errores. Ambos temas constituyen la
base para el proceso de pruebas.

INFORMACION IMPORTANTE: En esta guía nos referiremos a error tanto cuando hablamos de
bugs, errores o fallo.

PPRINCIPIOS DE LAS PRUEBASP

Recordemos que el objetivo de las pruebas es encontrar los errores. Las pruebas exitosas son las
que descubren errores que hasta ese momento no se manifestaron. El objetivo es lograr que esto
sea lo antes posible para resolverlo también anticipadamente.

Numerosos principios de la prueba han sido sugeridos a lo largo de los últimos 40 años y se han
consensuado en este grupo de siete principios. Los mismos ofrecen una guía común para toda la
prueba, son el punto de partida y que orientan las pruebas en general.

1
 1. Las pruebas muestran la presencia de defectos, no su ausencia

Creo que la mayoría de los testers de aplicaciones del “común” podemos decir que, aunque
hemos encontrado demasiados hallazgos durante nuestro proceso de pruebas, y aun cuando
hemos realizado varias iteraciones, nunca vamos a decir que el sistema se encuentra al 100% en
su calidad de software, y esto lo decimos es porque no podemos estar seguros de que la
aplicación ya no tiene defectos. Y de esto se trata este principio, el hecho de que realicemos
pruebas no quiere decir que se acaben los defectos. Muchas veces nos hemos encontrado que en
Producción siempre sale ese caso atípico que se nos escapó a todos los integrantes del proyecto,
es por ello que las pruebas demuestran la presencia de defectos.

Las pruebas simplemente ayudan a reducir la cantidad de defectos que pueden ser hallados, lo
cual minimiza el riesgo de un mal funcionamiento en las operaciones del sistema.

Ejemplo: la analogía utilizada en la ciencia es útil para explicar este principio, no importa la
cantidad de cisnes blancos que vemos, no podemos decir ‘todos los cisnes son blancos”. Sin
embargo, tan pronto como vemos un cisne negro, podemos decir ‘No todos los cisnes son
blancos”. De la misma manera, sin embargo, que muchas pruebas se hayan ejecutado sin
encontrar un error, no demuestra que “No hay errores”. Tan pronto como nos encontramos con un
error, se ha mostrado ‘Este código no está libre de errores”.

Sin embargo, el objetivo de las pruebas es encontrar cada vez más defectos ocultos utilizando
diferentes técnicas y métodos. Las pruebas pueden revelar defectos no descubiertos y, si no se
encuentran defectos, no significa que el software esté libre de ellos.

Ejemplo: considere una aplicación bancaria, esta aplicación se prueba a fondo y se somete a
diferentes fases de prueba y actualmente no se identifican defectos en el sistema.

Sin embargo, puede existir la posibilidad de que, en el entorno de producción, el cliente real
pruebe una funcionalidad que rara vez se usa en el sistema bancario y los testers pasaron por alto
esa funcionalidad, por lo tanto, no se encontraron defectos hasta la fecha o los desarrolladores
nunca han tocado el código.

Ejemplo: hemos visto varios anuncios de jabones, pasta de dientes, productos para lavado de
manos o aerosoles desinfectantes, etc. en la televisión y más durante el COVID 19.

Considere un anuncio de lavado de manos que diga en la televisión que “el 99% de los
gérmenes” se pueden eliminar si se usa ese lavado de manos específico. Esto demuestra
claramente que el producto no está 100% libre de gérmenes. Por lo tanto, en nuestro concepto de
prueba, podemos decir que ningún software está libre de defectos.

2. Las pruebas exhaustivas son imposibles

Probar todas las combinaciones de entradas y precondiciones no es posible, excepto en casos

especiales. Debido a esta situación, lo correcto es realizar un análisis de riesgo y así priorizar y
ejecutar los casos de prueba que tienen mayor importancia.

Sería complicado testear todas las combinaciones, pero, debería ser una súper empresa que tiene
el soporte financiero y quiere invertir una gran cantidad de dinero en calidad, pues bueno, ese
será el caso, pero no el de la mayoría.

Normalmente probamos lo más riesgoso o aseguramos cierto porcentaje de calidad en el

software. La generalidad de los testers no probamos absolutamente todo, exceptuando creería
por ejemplo testers que trabajan en la NASA o que testean dispositivos o hardware con objetivos
médicos, donde la vida de las personas está en juego. Este caso ya es un tema muy delicado que
te lleva a pensar que tanto debes invertir en el aseguramiento de la calidad del software, y no
obstante nos encontramos con errores que nadie ha detectado, es por esto por lo que no es
posible realizar pruebas exhaustivas.

2
Consideremos los siguientes tipos de prueba:

• Pruebas exhaustivas (exhaustive testing): enfoque de pruebas donde el conjunto de

pruebas abarca todas las combinaciones de valores de entrada y precondiciones.

• Explosión de casos de prueba (test case explosión): define el incremento exponencial de

esfuerzo y coste en el caso de pruebas exhaustivas.

• Prueba de muestra (sample test): la prueba incluye solamente a un subconjunto (generado

de forma sistemática o aleatoria) de todos los posibles valores de entrada.

En condiciones reales, se utilizan generalmente pruebas de muestra. Probar todas las

combinaciones posibles de entradas y precondiciones solo es económicamente viable en casos
puntuales.

Ejemplo: supongamos que tenemos un campo de entrada que acepta alfabetos, caracteres
especiales y números del 0 al 1000 únicamente. Imagínese cuántas combinaciones aparecerían
para probar, no es posible probar todas las combinaciones para cada tipo de entrada.

Los esfuerzos de prueba necesarios para probar serán enormes y también afectarán el
cronograma y el costo del proyecto. Por eso siempre se dice que prácticamente no es posible
realizar pruebas exhaustivas.

3. Las pruebas tempranas ahorran tiempo y dinero (Early Testing)

Encontrar defectos en etapas tempranas del proyecto equivale a reducir costos de tiempo y
dinero, mientras más tarde se encuentran los defectos, más costoso es arreglarlos. Por esta razón,
las pruebas deben empezar tan pronto como sean posibles de realizar.

Los tester tenemos una gran capacidad de análisis, buscando todos los caminos y variantes que
se pueden presentar, es por esto por lo que apoyamos mucho con nuestra revisión temprana a la
documentación, también durante el proceso de desarrollo de software.

Considere la siguiente imagen que muestra cómo aumenta el costo de la reparación de defectos a
medida que las pruebas avanzan hacia la producción en vivo.

3
Cuando los defectos se encuentran al principio del ciclo de vida, son mucho más fáciles y
económicos de corregir. Es mucho más económico cambiar un requisito incorrecto que tener que
cambiar una funcionalidad en un sistema grande que no coincide con lo solicitado o diseñado.

4. Agrupación de defectos

Por lo general, la mayoría de los defectos tienden a concentrarse en un pequeño número de

módulos; existen distintas razones por lo que esto sucede, una de ellas es que los cambios se
hacen regularmente en un solo módulo, o porque al arreglar un defecto, es posible introducir otro.

Los tester sabemos que cuando encontramos un defecto, encontraremos muchísimos más
defectos cerca, como si se agruparan. Si dibujáramos una curva, veríamos que crece
exponencialmente y si siguen creciendo, debemos advertir de inmediato para parar las pruebas ya
que podemos estar ejecutando las pruebas en la versión incorrecta del sistema, en el servidor
incorrecto o apuntando a una base datos que no es a la que deberíamos estar accediendo. En
algunos casos, no se han ejecutado procesos de actualización que hacen falta antes de terminar
de armar el ambiente donde se están corriendo las pruebas. Descartadas estas opciones, puede
ser que el problema esté del lado de los desarrolladores.

Por ejemplo, ha pasado que cuando ves que un mensaje está mal escrito o no tiene la ortografía
correcta, se sabe que toda la aplicación será sensible a revisiones de presentación.

Cuando pruebas si un campo de texto valida el tipo de dato o longitud que un usuario ingresa,
cuando vemos que el primer campo “explota” por decirlo de algún modo, lo más probable es que
los demás campos de texto del formulario también “explotarán”.

Es recomendable ser flexibles en estos casos: si hemos detectado un defecto en alguna pantalla y
sabemos que existen muchos más, es posible que sea conveniente volver a considerar el rumbo
de las pruebas posteriores, porque no es el objetivo reportar y reportar y llenar a los
desarrolladores de hallazgos o inconsistencias, sino que debemos plantearnos el objetivo de
ayudar a construir o generar un software de calidad con el apoyo de todos.

Igualmente, hay que tener en cuenta que este agrupamiento de defectos va cambiando en el
tiempo, por eso es importante centrarse en los “puntos calientes”(hot spot). Los testers suelen
utilizar esta información al hacer su evaluación de riesgos para la planificación de las pruebas y se
centrarán en los conocidos “puntos calientes”. Como el “hot spot” de los errores se limpia
tenemos que poner nuestro enfoque en otros lugares.

4
Los testers deben ser flexibles. Cuando se detecta un defecto es conveniente volver a considerar
el rumbo de las pruebas posteriores. La identificación y localización de un defecto puede ser
investigada con un mayor grado de detalle, por ejemplo, realizando pruebas adicionales o
modificando pruebas existentes.

Durante las pruebas, se puede observar que la mayoría de los defectos informados están
relacionados con una pequeña cantidad de módulos dentro de un sistema. Es decir, un pequeño
número de módulos contiene la mayoría de los defectos del sistema. Normalmente, se estima que
el 80% de los problemas se encuentra en el 20% de los módulos, la ley de Pareto.

5. Cuidado con la paradoja del pesticida o insecticida

Cuando se ejecutan los mismos casos de pruebas una y otra vez y sin ningún cambio,
eventualmente estos dejarán de encontrar defectos nuevos. Es necesario cambiar las pruebas y
los juegos de datos de prueba existentes para poder encontrar nuevos defectos. La paradoja del
pesticida o insecticida solo resulta beneficiosa en las pruebas de regresión.

Se llama la “paradoja de pesticida”, después de que el fenómeno de la agricultura, donde los

insectos como el picudo algodonero construye la tolerancia a los pesticidas, provocando la
elección de pesticidas cada vez más potentes seguido de insectos cada vez más potentes.

Para superar esta “paradoja del pesticida”, los casos de pruebas deben revisarse periódicamente
y deben escribirse nuevos casos de pruebas y diferentes, con esto podremos testear distintas
partes del software o del sistema con el objetivo de poder detectar más defectos. Si te quedas
repitiendo las mismas pruebas en las mismas condiciones no vas a ser efectivo. Los bugs se
volverán resistentes a ti, es por eso por lo que deberás cambiar tu pesticida (tu forma de testear)
constantemente para poder encontrar nuevos defectos.

Las pruebas deben ser revisadas/modificadas regularmente para los distintos módulos de código
y es necesario repetir una prueba tras una modificación del código (corrección de defectos, nueva
funcionalidad). La automatización de pruebas puede resultar conveniente si un conjunto de casos
de prueba se debe ejecutar frecuentemente.

Cada vez que se soluciona una falla o se agrega una nueva funcionalidad, debemos hacer
pruebas de regresión para asegurarnos de que el nuevo software modificado no haya roto
ninguna otra parte del software. Sin embargo, esos casos de prueba de regresión también deben
cambiar para reflejar las permutas realizadas en el software para que sean aplicables y luego
detectar nuevos defectos.

Como el “hot spot” de los errores se va limpiando, tenemos que posar nuestro enfoque en otros
lugares, a la siguiente serie de riesgos. Con el tiempo, nuestro enfoque puede cambiar de
encontrar errores de codificación, a mirar los requisitos y documentos de diseño, y en busca de
mejoras en los procesos para que podamos prevenir los defectos en el producto.

6. Las pruebas dependen del contexto

Las pruebas se realizan de manera diferente en diferentes contextos. Por ejemplo, la seguridad
del software será testeada de forma diferente en un sitio de comercio electrónico o e-commerce
que donde se comparten fotografías.

No todos los sistemas de software llevan el mismo nivel de riesgo y no todos los problemas tienen
el mismo impacto cuando se producen. Algunos de los problemas que encontramos en el uso de
software son bastante triviales, pero otros pueden ser costosos y perjudiciales – provocando
pérdida de reputación, de dinero, tiempo o de negocios – e incluso puede resultar en lesiones o la
muerte.

5
Ejemplo: fallos de media por KLOC (kilo lines of code) que confirman que las prueba son
dependientes del contexto:

• 3 a 10 fallas por cada mil líneas de código (KLOC) típico de software comercial
• 1 a 3 fallos por KLOC típico de software industrial
• 0,01 fallos por KLOC para el código de lanzamiento de la NASA.

Ejemplos:

Las diferentes metodologías, técnicas y tipos de pruebas están relacionadas con el tipo y la
naturaleza de la aplicación. Por ejemplo, una aplicación de software en un dispositivo médico
necesita más pruebas que un software de juegos. Un software vinculado a dispositivos médicos
requiere pruebas basadas en riesgos, cumplir con los reguladores de la industria médica y
posiblemente técnicas de diseño de pruebas específicas y vinculadas al hardware.

Del mismo modo, un sitio web muy popular debe pasar por rigurosas pruebas de rendimiento, así
como pruebas de funcionalidad para asegurarse de que el rendimiento no se vea afectado por la
carga en los servidores.

Ejemplo: hay varios dominios disponibles en el mercado como banca, seguros, médicos, viajes,
publicidad, etc. y cada dominio tiene una serie de aplicaciones. Además, para cada dominio, sus
aplicaciones tienen diferentes requisitos, funciones, diferentes propósitos de prueba, riesgo,
técnicas, etc. Los diferentes dominios se prueban de manera diferente, por lo que la prueba se
basa exclusivamente en el contexto del dominio o la aplicación. Probar una aplicación bancaria es
diferente a probar cualquier aplicación de publicidad o comercio electrónico. El riesgo asociado
con cada tipo de aplicación es diferente, por lo que no es efectivo utilizar el mismo método,
técnica y tipo de prueba para probar todos los tipos de aplicación.

Debemos considerar los entornos al probar: el entorno de prueba (test environment, cama de
prueba – test bed) vs. entorno de producción (production environment): las pruebas tienen lugar
en un entorno distinto del entorno de producción. El entorno de pruebas debe ser muy similar al
entorno de producción y contener datos similares, donde se protejan los datos que no pueden ser
compartidos o publicados, llamados datos sensibles. Siempre habrá desviaciones entre el entorno
de pruebas y el entorno de producción. Estas desviaciones ponen en tela de juicio las
conclusiones que se obtuvieron tras las pruebas.

Cuando tu cliente pregunta cuánto tiempo te vas a demorar, y es que las pruebas dependen del
contexto. Y sin irnos muy lejos, como es bien sabido, un único aplicativo dependerá su
funcionamiento si está en un ambiente de pruebas a un ambiente de desarrollo. Por esto, todo
depende del contexto o ambientes, no es lo mismo caminar 1 kilómetro subiendo una montaña
rocosa, subir por un sendero en el bosque o si es solo un paseo por la playa.

7. La falacia de ausencia de errores

Es posible que la mayoría de los defectos críticos de una aplicación hayan sido corregidos, pero
esto no asegura que el software sea exitoso. Se puede dar el caso de que este no cumpla con las
expectativas del cliente o tal vez, que sea peor en comparación a sistemas similares.

Este punto es uno de los más importantes, porque el hecho de pruebas no es solamente detectar
y corregir los defectos, de nada servirá el sistema si no es usable, o si no cumple con las
expectativas o las necesidades de los usuarios finales.

Ver Video: https://www.youtube.com/watch?v=7oeFwgijWus

6
Nunca digamos que, por el simple hecho de que al software que estés probando ya no le
encuentras errores, todo está bien, porque no nos podemos olvidar nunca del usuario final, qué es
lo que quiere, si le sirve la aplicación que se ha construido y si es que cumplimos con la
experiencia de usuario que se desea. Recuerda siempre que no se puede introducir la calidad a
través de las pruebas, la calidad tiene que construirse desde el principio del proyecto y la hacen
todos los miembros del equipo.

Las personas y empresas que compran y utilizan software como ayuda en su día a día no están
interesadas en los defectos o el número de defectos, salvo que sean directamente afectados por
la inestabilidad del software. La gente que usa software está más interesada en que la aplicación
los apoye en la realización de sus tareas de manera eficiente y eficaz. Por eso revisiones en las
primeras etapas (requisitos y diseño) son una parte importante de las pruebas y si los verdaderos
usuarios del sistema no han estado involucrados en el proceso de prueba en algún momento,
entonces es probable que no obtengan lo que realmente quieren, por ejemplo, las páginas web
pueden parecer libre de errores, pero si han sido diseñadas de una manera que no es compatible
con los procesos de negocio del sistema no se podrán utilizar.

Ejemplo: si el software se prueba completamente y si no se encuentran defectos antes del

lanzamiento, podemos decir que el software está libre de defectos en un 99%. Pero ¿qué pasa si
este software se prueba con requisitos incorrectos? En tales casos, incluso encontrar defectos y
arreglarlos a tiempo no ayudaría ya que las pruebas se realizan sin considerar las necesidades del
usuario final. Supongamos que la aplicación está relacionada con un sitio de comercio electrónico
y los requisitos de la funcionalidad 'Carrito de compras' se interpreta y prueba incorrectamente.
Aquí, incluso encontrar más defectos no ayuda a mover la aplicación a la siguiente fase o al
entorno de producción.

Ver Videos: https://youtu.be/J5IEsO57BhI

LAS DIFERENCIAS ENTRE PRIORIDAD Y GRAVEDAD EN LAS

PRUEBAS
Un error es la entidad más importante en el ciclo de vida de las pruebas de software. Y los
atributos más importantes que se pueden asignar a un error son Prioridad y Gravedad.

Cada vez que se encuentra un nuevo error, un tester o un cliente, lo registra. Los atributos
adjuntos al error pueden ser muchos, como la descripción, la versión de la aplicación, los detalles,
los pasos para reproducir, los datos de prueba, la fecha de creación, etc., pero la gravedad y la
prioridad son los atributos más utilizados. Ayudan a los equipos a corregir errores de manera
eficiente y pasar por los procesos de programación de lanzamiento, sin dejar que ningún
problema crítico se pierda.

Una vez informado, otros equipos que necesitan conocer el estado de un proyecto se referirán a
un error, incluidos los equipos de prueba y desarrollo, propietarios de productos, gerentes,
clientes y analistas comerciales.

COMPRENDAMOS LA GRAVEDAD Y LA PRIORIDAD Y SUS DIFERENCIAS

SUBYACENTES.
Según ISTQB:

La gravedad es “el grado de impacto que tiene un error en el desarrollo o el funcionamiento de un

componente o sistema”.

Prioridad es “el nivel de importancia (comercial) asignado a un error”.

7
#Al hablar de prioridad, nos referiremos a la prioridad asignada únicamente a un error.

La gravedad del error se refiere a la gravedad con la que el error ha afectado la funcionalidad de
la aplicación.

La prioridad de error define el orden en que los desarrolladores corregirán los errores (porque la
prioridad define la importancia comercial). Tenga en cuenta que cuanto mayor sea el impacto de
un error en el resultado final de una empresa, mayor será la prioridad que se le asigne.
Entendamos esto en detalle a continuación.

Gravedad

El tester decide la gravedad de un error. Después de analizar el impacto que tiene un error en las
funciones de la aplicación, la gravedad del error se puede categorizar como:

1. Crítico

Un error que ha bloqueado completamente la funcionalidad de una aplicación donde el usuario o

el tester no puede continuar o probar nada. Si toda la aplicación es inaccesible o no funciona
debido a un error, dicho defecto se clasifica como un error crítico.

En un entorno de producción, los clientes pueden informar sobre los errores que afectan a la
aplicación en vivo y su UX. Estos errores también se clasifican por su prioridad y gravedad.

No hace falta decirlo, pero independientemente de quién informe el error, los errores críticos
deben corregirse de inmediato. Si el error se informó en un entorno de prueba, la prueba se
bloquea hasta que se solucione el error. Si el error se informó en producción, los usuarios no
pueden usar su aplicación por completo.

Por ejemplo: cuando la pantalla de inicio de sesión de una aplicación no funciona y el usuario no
puede iniciar sesión, toda la aplicación se vuelve inaccesible para el usuario.

2. Mayor

Cuando un error no afecta a toda la aplicación, pero aún impide que funcionen las funcionalidades
principales de un sistema, se convierte en un error mayor.

No habrá un apagado completo del sistema (que sería el caso de un error crítico). Aun así,
impedirá que funcionen funciones importantes, a veces incluso básicas, de la aplicación.

Por ejemplo, en una aplicación bancaria, un usuario no puede transferir dinero a ningún
beneficiario, pero eso no afecta su capacidad para agregar nuevos beneficiarios.

3. Menor o Moderado

El comportamiento de una aplicación no es el esperado, pero esto no afecta la funcionalidad.

Por lo general, los errores de gravedad menor tienen una solución, por lo que es posible que no
bloqueen una funcionalidad por completo (a diferencia de los errores de gravedad mayor en los
que no hay solución).

Dichos errores menores pueden esperar a que se corrijan hasta la próxima versión porque no
restringen la funcionalidad de la aplicación.

Por ejemplo, el enlace de descarga en la sección de Ayuda de una aplicación no funciona. Sin
embargo, el usuario aún puede leer el documento en línea.

8
 4. Bajo

Defectos de naturaleza estética que no afectan directamente la funcionalidad de la aplicación o

UX. Pero son defectos válidos, no obstante.

Por ejemplo, faltas de ortografía en la página web. Estos son defectos válidos, pero pueden
esperar a que se solucionen, ya que no afectan la funcionalidad de la aplicación.

Prioridad

A estas alturas ya sabe que Gravedad significa la urgencia con la que el equipo de desarrollo
debe corregir el defecto. La prioridad, por otro lado, responde a la rapidez con la que se debe
reparar el defecto.

Tenga en cuenta que la prioridad puede cambiar en relación con otros defectos, por lo que es de
naturaleza subjetiva. Categorías de prioridad de defectos-

1. Alto

Si un defecto afecta los resultados o la experiencia de usuario directamente, se marca como de

alta prioridad. Estos errores pueden afectar a toda la aplicación. Necesitan una resolución lo antes
posible, y asignarles una alta prioridad garantiza que el tiempo de resolución sea bajo.

Por lo general, una gravedad alta también significa una prioridad alta. Pero este no es siempre el
caso.

2. Medio

Los defectos que no afectan al negocio ni a los clientes suelen tener una prioridad media. No son
tan urgentes como los defectos de alta prioridad y se pueden corregir cuando el equipo de
desarrollo tiene el ancho de banda para abordarlos. Dichos errores se pueden corregir en la
misma versión o en la siguiente.

3. Bajo

Los defectos que tienen la menor prioridad para arreglarse se arreglan después de que todos los
defectos de alta y media prioridad se hayan arreglado. La solución para defectos de baja prioridad
generalmente se proporciona junto con algunas soluciones para defectos de prioridad alta o
media.

DIFERENCIA ENTRE PRIORIDAD Y GRAVEDAD

Ahora que comprende lo que realmente significa cada uno de ellos, veamos diferencias más finas
entre prioridad y gravedad:

9
Ejemplos con combinación de prioridad y gravedad

Por lo general, los errores en las rutas de usuario más críticas de la aplicación se aclaran como
errores de alta gravedad y alta prioridad. Por lo tanto, se recomienda probar todos estos casos
para cada cambio en el producto cada vez.

Para comprender mejor la prioridad y la gravedad con las combinaciones, tomemos el ejemplo de
una aplicación bancaria.

1. Gravedad alta y prioridad alta

La aplicación bancaria tiene una página de inicio de sesión donde se autentica al usuario. Los
pasos involucrados son:

• El usuario ingresa el nombre de usuario y la contraseña y hace clic en el botón 'Iniciar

sesión'.

• Se navega al usuario a la página de inicio del perfil de usuario.

Ahora, por ejemplo, no se puede hacer clic en el botón 'Iniciar sesión' en el formulario de inicio de
sesión. Después de completar los detalles de inicio de sesión, el usuario no puede hacer clic en el
botón 'Iniciar sesión' y, por lo tanto, el usuario no puede iniciar sesión.

Este ejemplo cae en la categoría de: alta gravedad y alta prioridad. Desde la perspectiva de la
aplicación, toda la aplicación está bloqueada y el usuario no puede acceder a ninguna de las
funciones, por lo que se trata de una gravedad alta.

Desde una perspectiva comercial, si alguna aplicación no permite que los usuarios inicien sesión,
¿cuál es el uso de dicha aplicación? Los usuarios evitarán tales aplicaciones y el negocio se verá
afectado. Tal defecto es el defecto de prioridad alta y debe corregirse lo antes posible.

Estos problemas también se denominan problemas de bloqueo porque impiden que el usuario
siga trabajando y necesitan una solución urgente.

El lugar más común para estos errores de alta gravedad y alta prioridad es la ruta crítica del
usuario, una ruta por la que un usuario típico pasará cada vez que use la aplicación. Y la buena
noticia es que estos errores se pueden evitar fácilmente si se detectan antes de que se publiquen.

2. Gravedad baja frente a prioridad alta

A veces, los navegadores muestran las páginas de manera diferente, la misma página puede
verse diferente en otros navegadores, los elementos pueden perderse en lugares, el ajuste del
texto no se ve bien, los botones clave no se muestran correctamente, la funcionalidad funciona
pero la experiencia del usuario no es buena o incluso mala. Estos son de baja gravedad, pero de
alta prioridad para la experiencia del usuario.

Es importante probar las aplicaciones en todos los navegadores y sistemas operativos para
detectar este tipo de errores. Para detectar estos errores de forma automática y rápida antes de
que los pueda ver un cliente, es necesario automatizarlos a través de una herramienta que admite
pruebas exhaustivas entre navegadores.

Veamos un ejemplo específico: en la página de inicio del usuario después de iniciar sesión, la
aplicación bancaria muestra todas las opciones de: depósitos, transferencias, resumen de cuenta,
etc. En nuestro ejemplo, la ortografía de 'Transferencia' está mal escrita como 'Transferencia'. Este
error no tiene efecto en la funcionalidad de la aplicación porque el usuario puede hacer clic y
realizar una transferencia con éxito.

Sin embargo, esto es un inconveniente desde la perspectiva de la reputación del banco. Por lo
tanto, la gravedad es Baja porque no hay ningún problema en cuanto a la funcionalidad, pero la
prioridad es Alta, ya que está relacionado con el negocio y debe solucionarse lo antes posible.

10
 3. Gravedad alta frente a prioridad baja

Por ejemplo, hay pocos usuarios reales que todavía usan las versiones anteriores de IE como IE8.
La aplicación bancaria cuando se accede en versiones anteriores de IE, la página no se carga por
completo y los campos del formulario se superponen. Esto dificulta la accesibilidad del sitio web
para los usuarios de IE que utilizan las versiones anteriores.

Por lo tanto, la gravedad es alta porque toda la aplicación se ve afectada. Sin embargo, habrá muy
pocos usuarios reales que usen IE 8 y otras versiones anteriores, esto hace que la prioridad sea
Baja porque esta solución puede esperar.

Para detectar dichos errores antes de que el cliente los detecte, también es esencial ejecutar
casos de prueba en versiones antiguas del navegador.

4. Gravedad baja frente a prioridad baja

La sección de 'Ayuda' del sitio web del banco tiene una subsección, cuyo tema no coincide con
todo el sitio web. Este defecto no obstaculiza la funcionalidad del sitio web, tampoco muchos
usuarios accederán a esta sección en particular. Por lo tanto, este defecto cae dentro de la
categoría de Gravedad Baja y Prioridad Baja.

Ver video:

A. https://youtu.be/7oeFwgijWus
B. https://youtu.be/fSnox2EhM78

Escenarios comunes relacionados con la gravedad y la prioridad

Considere un error que no permite que el tester continúe con la prueba a toda costa o que hace
que la aplicación se bloquee. Incluso la funcionalidad básica/principal no funciona como se
esperaba. Dicho error se considera de alta prioridad con alta gravedad.

Un error que es visible para el cliente pero que no es probable que afecte la funcionalidad de la
aplicación como un problema con el logotipo o un error ortográfico se considera un defecto de
alta prioridad con gravedad baja.

Un error que hace que el sistema se bloquee y quede inutilizable, pero que ocurre solo cuando el
usuario hace clic en cualquier enlace que no se usa normalmente, se considera un defecto con
gravedad alta, pero prioridad baja.

Un error estético que no es visible durante el uso normal se considera un defecto de baja
prioridad con baja gravedad.

11
CLASIFICACIÓN DE DEFECTOS
La clasificación de defectos es un proceso que intenta reequilibrar el proceso en el que el equipo
de pruebas se enfrenta al problema de la disponibilidad limitada de recursos. Por lo tanto, cuando
hay una gran cantidad de defectos y testers limitados para verificarlos, la clasificación de defectos
ayuda a tratar de resolver la mayor cantidad de defectos en función de parámetros de defectos
como la gravedad y la prioridad.

Cómo determinar la clasificación de defectos:

La mayoría de los sistemas utilizan la prioridad como criterio principal para evaluar el defecto. Sin
embargo, un buen proceso de clasificación también considera la gravedad.

• El proceso de clasificación incluye los siguientes pasos

• Revisar todos los errores, incluidos los errores rechazados por el equipo.

• La evaluación inicial de los errores se basa en su contenido y la respectiva configuración

de prioridad y gravedad.

• Priorización del error en función de las entradas.

• Asigne el error a la liberación correcta por parte del gerente de producto.

• Redirige el error al propietario/equipo correcto para tomar medidas adicionales.

• Directrices que todo tester debe tener en cuenta antes de seleccionar una gravedad.

El parámetro de gravedad lo evalúa el tester, mientras que el parámetro de prioridad lo evalúa el

gerente de producto o el equipo de clasificación. Para priorizar el error, es imperativo que un
tester elija la gravedad correcta para evitar confusiones con el equipo de desarrollo.

• Entender bien el concepto de prioridad y severidad

• Siempre asigne el nivel de gravedad según el tipo de problema, ya que esto afectará su
prioridad

• Comprender cómo un escenario particular o caso de prueba afectaría al usuario final

• Debe considerar cuánto tiempo llevaría reparar el defecto en función de su complejidad y

el tiempo para verificar el defecto.

Conclusión:

En ingeniería de software, asignar una gravedad incorrecta a un defecto puede retrasar el proceso
STLC y puede tener una implicación drástica en el rendimiento general del equipo. Por lo tanto, la
persona responsable debe ser precisa y precisa en su llamada para la asignación de defectos.

12
PESCENARIOS DE ANÁLISISP
Te presentamos varios escenarios de análisis en donde veremos aplicados algunos de los
conceptos que estudiamos hoy. Te invitamos a que tomes algunos minutos de reflexión con tus
compañeros de equipo y discutas cada escenario y su respuesta. Cada uno deberá exponer las
razones por las que elige cada opción. Podrán coincidir o no entre ustedes, no se preocupen,
intenten llegar a una opinión unánime, pero de no hacerlo cada uno enviará sus propias
respuestas.

En el formulario de fin de guía encontrarás estos mismos escenarios y sus respuestas, envienlas
de forma individual luego de haberlo discutido.

1. María está trabajando en su primera experiencia como tester. Ha vuelto a casa muy
angustiada ya que las pruebas que realizo hoy determinaron que hay varios errores de
desarrollo que debe reportar.

a) María debe estar nerviosa, ya que esos errores retrasaran la entrega del producto
desarrollado.

b) María debe rehacer las pruebas para verificar si esos errores no fueron causados por
sus pruebas.

c) María debe sentirse aliviada, encontrar errores era el objetivo de esas pruebas. Ella
hizo bien su trabajo.

2. El jefe de Pedro le ha encargado probar una app. Al comunicarle su tarea, puso mucho
énfasis que Pedro debe probar TODAS Y CADA UNA de las funcionalidades de la app.
Pedro está un poco confundido, ya que no es una app de la NASA, ni pone en riesgo
datos sensibles (ej: bancarios). Pedro debe:

a) Decirle a su jefe que hacer pruebas exhaustivas no solo no es posible, sino

innecesario.

b) Hacer todas las pruebas que dice su jefe, pero indicarle que demorará bastante
tiempo.

c) Solicitar más equipo para realizar el pedido de su jefe.

3. Juan y Mario están planificando las pruebas de una plataforma en desarrollo. Juan está
muy relajado, ya que la plataforma apenas acaba de comenzar a codearse y afirma que
realizará todas las pruebas necesarias una vez que la plataforma esta lista. Mario no está
de acuerdo, él quiere realizar pruebas tan pronto se desarrolle una funcionalidad de la
plataforma. Para convencer a Juan, ¿Qué justificación deberá usar Mario?

a) Que al hacer las pruebas antes de la finalización del desarrollo, podrán terminar antes
con este proyecto y comenzar otro.

b) Que si realizan las pruebas a cada funcionalidad serán contratados por más tiempo por
la empresa desarrolladora.

c) Que hacer pruebas parciales a medida que se desarrollan funcionalidades ahorra

tiempo y dinero, ya que los errores pueden corregirse antes de ser muy grandes, por
lo que será más fácil y barato arreglarlos.

13
4. Laura se encuentra realizando distintas pruebas a un software. Ha realizado una minuciosa
planificación de todas las pruebas que realizará. Una de las pruebas ha detectado varios
errores en una de las funcionalidades. Recomendarías a Laura:

a) Seguir al pie de la letra su plan de prueba redactado al inicio, sin realizar modificación
alguna.

b) Seguir con su plan de pruebas y contratar otro tester que planifique y ejecute pruebas
alternativas para esa funcionalidad.

c) Flexibilizar su plan de pruebas y analizar mas en detalle esa funcionalidad, ya que

acorde a la ley de Pareto, varios errores se agruparán alrededor de ese.

5. Alberto ejerce su profesión de tester desde hace 30 años. Es realmente un conocedor en

el tema y ha probado softwares diversos. Con el tiempo, sabe que cuando debe volver a
probar una funcionalidad la mejor estrategia es:

a) Realizar cambios en las pruebas. Repetir las pruebas harán que no encontremos
nuevos defectos.

b) Repetir pruebas, todos los softwares pueden probarse con las mismaspruebas siempre
y cuando las mismas sean diseñadas de forma genérica.

c) Reutilizar las pruebas con las que ya probamos ese software, detectarán errores
nuevos una vez que las volvamos a utilizar igual que la última vez.

14