INSTITUTO NACIONAL DE APRENDIZAJE

NÚCLEO SECTOR COMERCIO Y SERVICIOS

SUBSECTOR INFORMÁTICA Y COMUNICACIÓN
PROGRAMA CONTROLADOR(A) DE LA CALIDAD DEL SOFTWARE
MÓDULO: ELABORACIÓN DE PRUEBAS DE SOFTWARE

CENTRO REGIONAL POLIVALENTE DE PUNTARENAS

Trabajo de Investigación #1

Estudiante:
Norma Chavarría Rojas

Profesor:

Lic. José Martín Aguirre Vargas

26 de noviembre del 2021.

Tabla de Contenidos

Presentación .................................................................................................................................... 1
Desarrollo ........................................................................................................................................ 1
Error ............................................................................................................................................ 1
Defecto ........................................................................................................................................ 2
Fallo ............................................................................................................................................. 2
Relación de los 3 conceptos ........................................................................................................ 2
Diferencia entre los atributos de un defecto: Severidad y Prioridad ........................................... 3
Severidad frente a prioridad ........................................................................................................ 3
Severidad alta: error de prioridad alta ......................................................................................... 3
Severidad alta: error de prioridad baja ........................................................................................ 3
Alta prioridad - error de gravedad baja ....................................................................................... 4
Prioridad baja: error de gravedad baja ........................................................................................ 4
Conclusión ...................................................................................................................................... 5
Bibliografía ..................................................................................................................................... 6
Presentación

Los fabricantes, a medida que van evolucionando, se ocupan también analizar los defectos con el
fin de evitar que se repitan en futuras versiones. En la mayoría de los casos, las marcas llevan un
registro de incidencias recogidas a través de los talleres adheridos y servicios postventa, que les
permite conocer los fallos más habituales, su gravedad, frecuencia, etc.

En el mundo del software esta tarea no es tan habitual o, al menos, no lo era hasta hace poco.
Tradicionalmente, cuando se detecta un defecto en una aplicación que está en fase de pruebas o
una incidencia cuando ya está en producción, la anomalía se reporta al equipo de desarrollo para
que la subsane, pero raramente se analiza el motivo que la produjo con el objetivo de evitar que se
repita en futuras versiones.

El verdadero valor de las pruebas está en sus resultados. Cuando los procesos y equipos de prueba
solo tienen la intención de encontrar defectos y no la de prevenirlos, algo se está haciendo de forma
incorrecta, por ende, la presente investigación tratará del tema.

Desarrollo

Error

Es una acción humana que produce un resultado incorrecto, una idea equivocada de algo. El error
es una equivocación de parte del desarrollador o del analista. Un error puede llevarnos a generar
uno o más defectos.

Ejemplos de errores pueden ser:

• Error en la lógica de la programación

• Un requerimiento que esté mal especificado

1
Defecto

El defecto se encuentra en algún componente del sistema. Es la imperfección de un componente

causado por un error. El analista de pruebas es quien debe reportar el defecto ya que es el encargado
de ejecutar los casos de prueba y encontrar los mismos.

Ejemplos de defecto pueden ser:

• Un módulo de registro de usuarios tiene mala configuración en la función de conexión a

base de datos

• Una función de login cuenta con las variables de usuario y contraseña declaradas
incorrectamente.

Fallo

Es la manifestación visible de un defecto. Es decir que si un defecto es encontrado durante la

ejecución de una aplicación entonces va a producir un fallo.

Ejemplo de Fallo:

• Visualización de un mensaje de alerta que no fue definido previamente por el desarrollador.

• Un formulario de login que contenga los datos de acceso no te permita ingresar a la

aplicación al hacer clic en el botón de ingresar.

Relación de los 3 conceptos

Un error puede generar uno o más defectos y un defecto va a causar un fallo.

Ejemplo de aplicación de los tres conceptos:

Un desarrollador se equivoca al momento de colocar la edad límite para el registro de un usuario

dentro de un aplicativo. Al momento de realizar las pruebas del aplicativo, el analista de pruebas
de software coloca la edad definida en el requerimiento, lo que genera un defecto en el sistema,
provocando a su vez, que se genere un fallo, el cual es un mensaje en pantalla indicando que la
edad no es válida.

2
Diferencia entre los atributos de un defecto: Severidad y Prioridad

Tanto la gravedad como la prioridad son atributos de un defecto y deben proporcionarse en el

informe de error. Esta información se utiliza para determinar la rapidez con la que se debe corregir
un error.

Severidad frente a prioridad

La gravedad de un defecto está relacionada con la gravedad de un error. Por lo general, la gravedad
se define en términos de pérdida financiera, daño al medio ambiente, reputación de la empresa y
pérdida de vidas.

La prioridad de un defecto está relacionada con la rapidez con la que un error debe corregirse e
implementarse en servidores activos. Cuando un defecto es de alta gravedad, lo más probable es
que también tenga una alta prioridad. Del mismo modo, un defecto de gravedad baja normalmente
también tendrá una prioridad baja.

Aunque se recomienda proporcionar tanto Severidad como Prioridad al enviar un informe de

defectos, muchas empresas utilizarán solo uno, normalmente de prioridad. En el informe de error,
la persona que escribe el informe de error normalmente completa la gravedad y la prioridad, pero
todo el equipo debe revisarlas.

Severidad alta: error de prioridad alta

Esto es cuando se rompe la ruta principal a través de la aplicación, por ejemplo, en un sitio web de
comercio electrónico, todos los clientes reciben un mensaje de error en el formulario de reserva y
no pueden realizar pedidos, o la página del producto arroja una respuesta de Error 500.

Severidad alta: error de prioridad baja

Esto sucede cuando el error causa problemas importantes, pero solo ocurre en condiciones o
situaciones muy raras, por ejemplo, los clientes que usan navegadores muy antiguos no pueden

3
continuar con la compra de un producto. Debido a que el número de clientes con navegadores muy
antiguos es muy bajo, no es una alta prioridad solucionar el problema.

Alta prioridad - error de gravedad baja

Esto podría suceder cuando, por ejemplo, el logotipo o el nombre de la empresa no se muestra en
el sitio web. Es importante solucionar el problema lo antes posible, aunque es posible que no cause
mucho daño.

Prioridad baja: error de gravedad baja

Para los casos en los que el error no causa un desastre y solo afecta a un número muy pequeño de
clientes, tanto la gravedad como la prioridad se asignan a un nivel bajo; por ejemplo, la página de
la política de privacidad tarda mucho en cargarse. No mucha gente ve la página de la política de
privacidad y la carga lenta no afecta mucho a los clientes.

Los anteriores son solo ejemplos. Es el equipo quien debe decidir la gravedad y la prioridad de
cada error.

4
Conclusión
Los Productos Software, sistemas y/o aplicaciones son creadas, desarrolladas e implementadas por
seres humanos y por ende en cualquiera de sus etapas de creación se puede presentar una
equivocación, al generarse esa “equivocación” se puede conllevar a un defecto en el software, por
ejemplo, mala digitación, distracción al codificar, mala elaboración de un documento entre otras.
Si no se ha identificado ese defecto y el software o la aplicación se ejecuta, hay un alto riesgo de
que la aplicación no haga lo que debería hacer o el objeto para lo cual fue creada, es decir se genera
un fallo o desperfecto, lo que podría generar una catástrofe como las que se han mencionado en
este documento y muchas otras más, es importante conocer que los fallos también se pueden
presentar por situaciones del entorno, como la radiación, descarga eléctrica, contaminación,
inundaciones, Húmeda, Fuego, etc.

Los Ingenieros de sistemas entonces deben estar en la capacidad de conocer y aplicar las diferentes
normas, procesos y procedimientos para garantizar la calidad de los productos software, aplicando
las pruebas de calidad de software necesarias para que con ellas se pueda ayudar a reducir los
riesgos en las aplicaciones, logrando que se identifiquen los defectos antes de que se ejecuten, así
de forma proactiva tomar decisiones que permitan hacer las actividades necesarias para mejorar
las condiciones del software y ofertar un producto que satisfaga las necesidades del cliente.

5
Bibliografía
Sánchez J. (2011), Pruebas de Software. Fundamentos y Técnicas, Universidad Politécnica de
Madrid, Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación. Recuperado de:

https://oa.upm.es/40012/1/PFC_JOSE_MANUEL_SANCHEZ_PENO_3.pdf