Metodologías del Testing Funcional

LTI – Plan 2024 1

 Metodologías del Testing Funcional

Contenido

IMPACTO DE LOS REQUERIMIENTOS EN TESTING ........................................................ 3

Ingeniería de Requerimientos......................................................................................... 3
Concepto de Requerimiento ........................................................................................... 3
Características de los Requerimientos .......................................................................... 3
INVEST ............................................................................................................................ 4
Problemas Comunes en los Requerimientos ................................................................ 5
Ambigüedades................................................................................................................. 5
Inconsistencias ................................................................................................................ 5
Consecuencias y Soluciones .............................................................................................. 6
Tipos de Requerimientos ................................................................................................ 7
Requerimientos versus Calidad del Software ............................................................... 8
Resumen ........................................................................................................................ 15

LTI – Plan 2024 2

 Metodologías del Testing Funcional

IMPACTO DE LOS REQUERIMIENTOS EN TESTING

Ingeniería de Requerimientos

El ciclo de desarrollo del software, conocido como Ingeniería del software, es de vital importancia.

En el mismo, la etapa inicial, conocida como Ingeniería de Requerimientos, es una de las más
importantes.

Dicha etapa, consiste en la definición de los requerimientos, del cual va a versar nuestro producto o
servicio de software.

Concepto de Requerimiento

De acuerdo con el estándar IEEE 830, un requerimiento se define como “la condición o capacidad que
debe poseer un sistema o componente de un sistema para satisfacer un contrato. Un estándar, una
especificación u otro documento formalmente impuesto”.

De acuerdo con el PMI 2016, un requerimiento se puede definir como una condición o capacidad, que
se requiere que esté presente en un producto o servicio, para cumplir con una especificación impuesta
formalmente.

Características de los Requerimientos

Dicha especificación o necesidad documentada, que establece la forma en la cual debe funcionar un
sistema, debe cumplir con ciertas características y/o atributos, para ser considerado de calidad. Los
mismos deben ser:

● Correctos: un requerimiento cumple esta característica únicamente si las definiciones que se

encuentran en el documento corresponden a necesidades reales de los usuarios.

● No ambiguo: se refiere a que las necesidades plasmadas poseen una única interpretación.

● Completos: se considera completo si incluye todas las definiciones de las funcionalidades

deseadas, interfaces (externas y graficas), entradas, salidas, flujos alternos y terminología.

● Verificables: cuando a través de un proceso una persona o herramienta puede constatar que el
sistema satisface lo establecido en el requerimiento, por ejemplo: “la salida se suministra
dentro de los veinte segundo siguientes al evento E el 60% de las veces”.

LTI – Plan 2024 3

 Metodologías del Testing Funcional

● Consistentes: es si y solo si, el conjunto de requisitos allí definidos no se contradice entre ellos
o generan conflicto.

● Priorizables: debe permitir determinar su importancia con relación a las necesidades de los
usuarios.

● Modificables: si al realizar un cambio sobre las definiciones ya establecidas de forma fácil,

completa y consistente, se considera que el requerimiento cumple con esta característica.

● Explorables: también conocida como “trazabilidad”, se cumple cuando es posible rastrear de

forma sencilla el origen de los requerimientos y los componentes del sistema que ejecutarán
las funcionalidades descritas.

● Utilizables: cuando es posible utilizar el documento de requerimientos para las tareas de

mantenimiento.

INVEST

El método INVEST proporciona un conjunto de características clave, para que en el desarrollo ágil del
software, con historias de usuario por ejemplo, las mismas sean de calidad, claras y efectivas en la
comunicación, sencillas de gestionar, de ejecutar y de entregar valor al cliente o usuario final. Las
mismas deben ser:

I - Independent (independiente)
N - Negotiable (negociable)
V - Valuable (valiosa)
E - Estimable (estimable)
S - Small (pequeña)
T - Testable (comprobable)

LTI – Plan 2024 4

 Metodologías del Testing Funcional

Problemas Comunes en los Requerimientos

Las ambigüedades e inconsistencias en los requerimientos de software son problemas comunes que
pueden surgir durante la fase de definición y documentación de los requisitos para un proyecto de
desarrollo de software.

Ambigüedades

Las ambigüedades en los requerimientos de software se refieren a aquellas situaciones donde una
declaración, especificación o requisito puede interpretarse de más de una manera. Estas
ambigüedades pueden causar confusión y malentendidos entre los desarrolladores, los clientes y
otros interesados, lo que a menudo resulta en un producto final que no cumple con las expectativas.
Las ambigüedades pueden ser de varios tipos:

● Ambigüedad Léxica: Se da cuando una palabra o frase puede tener múltiples significados. Por
ejemplo, "El sistema debe ser rápido" puede interpretarse de varias formas dependiendo de
lo que cada parte considere como "rápido".

● Ambigüedad Sintáctica: Ocurre cuando la estructura gramatical de una oración permite

múltiples interpretaciones. Por ejemplo, "El usuario puede modificar los datos y eliminarlos"
puede interpretarse como que el usuario puede modificar y luego eliminar los datos, o que
puede hacer ambas acciones independientemente.

● Ambigüedad Pragmática: Se da cuando el contexto no está claro, lo que lleva a diferentes

interpretaciones. Por ejemplo, "El sistema debe generar reportes semanalmente" no
especifica si la generación de reportes debe ser automática o manual.

Inconsistencias

Las inconsistencias en los requerimientos de software se refieren a situaciones en las que los
requerimientos se contradicen entre sí o no se alinean con otras partes del sistema. Estas
inconsistencias pueden llevar a problemas durante el desarrollo y la implementación, ya que los
desarrolladores pueden recibir instrucciones contradictorias. Las inconsistencias pueden ser de varios
tipos:

● Inconsistencias Internas: Ocurren dentro del mismo documento de requerimientos. Por

ejemplo, un requisito puede decir que el sistema debe enviar notificaciones
instantáneamente, mientras que otro dice que debe hacerlo en intervalos de una hora.

LTI – Plan 2024 5

 Metodologías del Testing Funcional

● Inconsistencias Externas: Ocurren entre diferentes documentos o entre los requerimientos y

otros elementos del proyecto, como el diseño o las especificaciones técnicas. Por ejemplo, un
requisito en el documento de requerimientos puede especificar una característica que no está
soportada por el diseño de la base de datos.

● Inconsistencias de Dominio: Surgen cuando los requerimientos no son consistentes con el

conocimiento del dominio o las expectativas del usuario final. Por ejemplo, un sistema
financiero que no considere las regulaciones vigentes del sector.

Consecuencias y Soluciones

● Consecuencias: Las ambigüedades e inconsistencias pueden llevar a un incremento en el costo

y tiempo del proyecto debido a la necesidad de retrabajo, ajustes y aclaraciones constantes.
También pueden causar insatisfacción del cliente y errores críticos en el sistema final.

● Soluciones: Para mitigar estos problemas, es importante:

o Revisión y Validación: Revisar los requerimientos con todos los interesados para
asegurar un entendimiento común y detectar posibles ambigüedades e
inconsistencias.

o Lenguaje Claro y Preciso: Usar un lenguaje claro, preciso y libre de jerga técnica que
pueda ser malinterpretada.

o Modelos y Prototipos: Utilizar modelos visuales y prototipos para representar los

requerimientos de manera más clara.

o Herramientas de Gestión de Requerimientos: Emplear herramientas que ayuden a

documentar, rastrear y gestionar los requerimientos de manera efectiva.

o Revisiones Formales y Pruebas: Implementar revisiones formales y pruebas de los

requerimientos para asegurar que sean completos, consistentes y no ambiguos.

Al abordar y resolver las ambigüedades e inconsistencias de manera proactiva, se puede mejorar

significativamente la calidad del software desarrollado y la satisfacción del cliente.

LTI – Plan 2024 6

 Metodologías del Testing Funcional

Tipos de Requerimientos

Los requerimientos pueden ser clasificados en dos tipos, los requerimientos funcionales y los no
funcionales. Dentro de los no funcionales, podemos encontrar los relativos al producto de software,
de dominio internos y de dominio externos.

Los requerimientos funcionales hacen referencia a las actividades y servicios que debe ejecutar el
sistema, este tipo de requerimientos tiene en cuenta las entradas, salidas y el procesamiento y
almacenamiento de los datos; también son conocidos como requerimientos de comportamiento. Por
lo general, están descritos en términos de usuarios (lenguaje natural) y tradicionalmente se detallan a
través de la sentencia “debería”.

Los requerimientos no funcionales se relacionan con a las propiedades que debe poseer el sistema a
fin de soportar las funcionalidades definidas por el usuario; en este tipo de requerimientos se describen
las capacidades técnicas que el sistema debe poseer, tales como fiabilidad, tiempos de respuesta,
disponibilidad, rendimiento, etc. Este tipo de requerimientos en ocasiones son más críticos que los
requerimientos funcionales, ya que la omisión de alguno de estos requisitos puede hacer que el sistema
sea inútil para el usuario.

A continuación presentamos, un esquema de la tipología respecto a los requerimientos no funcionales,

de acuerdo a la novena edición del Ian Somerville. Y luego, un esquema mucho más detallado, basado
en la norma UNIT ISO/IEC 25010, de acuerdo al modelo de calidad del producto de software, para los
requerimientos no funcionales sub categoría producto.

LTI – Plan 2024 7

 Metodologías del Testing Funcional

El modelo de calidad representa la piedra angular en torno a la cual se establece el sistema para la
evaluación de la calidad del producto. La calidad del producto software se puede interpretar como el
grado en que dicho producto satisface los requisitos de sus usuarios aportando de esta manera un
valor.

Son precisamente los requisitos no funcionales los que se encuentran representados en el modelo de
calidad, el cual categoriza la calidad del producto en características y sub características. El modelo de
calidad del producto definido por la UNIT ISO/IEC 25000 (SQUARE), (específicamente 25010), (ANTES
UNIT ISO IEC 9126), se encuentra compuesto por las características de calidad, y su evaluación, que se
muestran:

Requerimientos versus Calidad del Software

Los requerimientos se ven influenciados por múltiples factores, un ejemplo son las perspectivas de los
usuarios respecto al sistema o las políticas organizacionales, lo cual puede llegar a incidir de forma
negativa en las etapas posteriores del desarrollo de software.

El Informe del Caos o Chaos Report, que se publica anualmente, por el Standish Group, desde 1994,
dando una visión sobre el éxito o fracaso de los proyectos de software.

En el informe del año 2015, se estudiaron unos 50.000 proyectos de todo el mundo, desde
mantenimientos pequeños hasta gigantescos proyectos de re ingeniería.

La siguiente es una estadística, realizada desde el año 1994 al 2015 (Chaos Report statistics for IT
software projects from 1994 to 2015). En color rojo podemos apreciar los que fallaron (failed), en color
azul los re ejecutados, discutidos, hay dudas sobre si fallaron o no (challenged) y en color verde los que
resultaron exitosos (successful).

LTI – Plan 2024 8

 Metodologías del Testing Funcional

Al 2015, The Standish Group muestra que:

● el 19% de los proyectos es cancelado o falla antes de su culminación

● un 52% de los proyectos propuestos incrementará su costo con respecto a las estimaciones
originales y

● un promedio del 29% de los proyectos de software finalizan exitosamente (ajustándose a los
calendarios y fechas de entrega así como al presupuesto estimado)

También podemos ver, que se desprende de la gráfica del Standish Group, que la tendencia de éxito
de los proyectos, ni sube ni baja, sin que se muestra oscilante sobre los mismos valores, en el entorno
del 29%, un porcentaje realmente bajo, en 21 años. Este dato es interesante, ya que parece que no hay
influencia de ciclos de vida, metodologías, tools, sino de otro tipo de factores, que afectan al éxito o
no de los mismos.

Chaos Report statistics for IT software projects from 1994 to 2015

Según la investigación 48% de los ejecutivos de empresas de tecnología creen que existen más fallas
en el software desarrollado en la actualidad que en los proyectos de hace cinco años. Mientras que el
50%creen que el número de fallas en la actualidad es menor o igual que hace cinco o diez años.

La siguiente es una estadística, presentada el año 2020 en el informe Chaos Report Beyond Infinity (IT
software projects). En color rojo podemos apreciar los que fallaron (failed), en color amarillo los re
ejecutados, discutidos, hay dudas sobre si fallaron o no (challenged) y en color verde los que resultaron
exitosos (successful). Si bien desde el 2015 al 2020, el porcentaje de proyectos exitosos sube un 2%,
dicho valor es muy bajo, realmente bajo en relación.

LTI – Plan 2024 9

 Metodologías del Testing Funcional

Chaos Report Beyond Infinity 2020

Muchos de estos proyectos de desarrollo de software, no tienen el éxito esperado, debido a varias
razones, entre las cuales una de ellas, que ocupa el mayor porcentaje de los motivos y/o causas, es la
información deficiente, en cuanto a requerimientos, con la que cuenta el proyecto.

Las siguientes, son tablas que presentan, los principales factores, motivos o causas del porque los
proyectos fallan, tanto para los proyectos en color azul (challenged) como los de color rojo (failed). En
ambas es posible observar, como el mayor porcentaje, es debido a especificaciones de requerimientos
deficientes/incompletas (12%).

Project Challenged Factors

LTI – Plan 2024 10

 Metodologías del Testing Funcional

Project Impaired Factors

De la siguiente gráfica de Apiumhub 2021 Situación actual del software, también se desprende, que
además de la falta de claridad en los entregables definidos (13.48%), seguido de expectativas y
estimaciones poco realistas, la priorización de los requerimientos (9.57%), es otro de los principales
factores, motivos o causas del porque los proyectos fallan.

Gráfica de Apiumhub 2021 Situación actual del software

LTI – Plan 2024 11

 Metodologías del Testing Funcional

Otro dato interesante, a tomar muy en cuenta a la hora de dar prioridad a la Ingeniería de
Requerimientos, es la cantidad de defectos que se inyectan en un proyecto, dependiendo de la etapa
del ciclo de vida del desarrollo del software.

Como se puede apreciar, en la siguiente gráfica de Laporte y April 2018, en la detección de defectos
aplicando revisiones de pares, el análisis presenta, que el mayor porcentaje, de inyección de defectos,
se produce en la etapa de requerimientos, prácticamente la mitad de los defectos se introduce en la
etapa previa de análisis del sistema (50%). Las otras etapas también contribuyen con el problema de
introducir defectos pero en un porcentaje muchísimo menor.

Gráfica de Laporte y April 2018 / Inyección de defectos por etapa

De las gráficas anteriores, pudimos ver que se desprende, por un lado los principales factores, motivos
o causas, siendo en un 12%, el mayor porcentaje, la especificación deficiente/incompleta de los
requerimientos.

Por otro lado, el porcentaje en un 50%, de que la mayor cantidad de defectos se da en la etapa de
requerimientos.

Según la gráfica del PMI 2017, un factor que corresponde a tener una comunicación deficiente en los
proyectos, presenta un valor del 19%, valor realmente alto, el cual bien se puede trasladar a la etapa
de requerimientos y ver cómo impacta en todo lo que es análisis, recolección y validación de los
requerimientos.

LTI – Plan 2024 12

 Metodologías del Testing Funcional

Gráfica del PMI 2017 / Causas fracaso de proyectos

Otro dato a tomar muy en cuenta, es el costo relativo de detectar y reparar un defecto (bug). En la
siguiente gráfica, podemos observar, que conforme pasa el tiempo, en las sucesivas etapas del ciclo
de vida del desarrollo de software, este costo relativo aumenta sustancialmente, conforme se pasa de
la prevención a la detección, y de la falla interna a los de la falla externa.

Se desprende de la gráfica de Pressman 2006, que estando ya el producto de software en producción,

un defecto, no identificado en la etapa de requerimientos, puede costar hasta 1000 unidades de
tiempo corregirlo. Esto se debe a que se debe analizar el impacto de la corrección en cada una de las
etapas del desarrollo de software y actualizar documentos, modelos, componentes de software, casos
de software y la configuración del software afectadas.

Gráfica de Pressman 2006 / Costo relativo de corregir una falla

LTI – Plan 2024 13

 Metodologías del Testing Funcional

Otra modalidad de gráfica

Otra gran área a analizar es la del Testing, etapa fundamental para determinar el nivel de calidad del
software.

La calidad del software refiere al conjunto de características de un producto de software y que

determinan su utilidad, existencia, eficiencia, flexibilidad, mantenibilidad, seguridad, integridad,
portabilidad, sinónimos todos de su calidad.

Las pruebas permiten determinar si el software cumple o no con los requisitos y de satisfacer las
condiciones previamente definidas, continuar con las sub siguientes etapas. Aquí hallar la mayor
cantidad de defectos posibles del software, antes de continuar, es un “must”.

Una gráfica interesante de analizar, es la gráfica de gestión de los recursos, y como tradicionalmente
la mayor cantidad de recursos y el esfuerzo, en detectar y corregir errores, es puesta en la etapa de
pruebas.

Vemos entonces que en una fase tradicional de pruebas, el esfuerzo se encuentra concentrado allí, lo
cual supone que los defectos se vienen a buscar/encontrar casi al final del proyecto.

LTI – Plan 2024 14

 Metodologías del Testing Funcional

Gráfica de gestión de los recursos

Resumen

A modo de resumen, podemos analizar que:

● de la gráfica de gestión de los recursos, tradicionalmente el tiempo y el esfuerzo, en detectar y

corregir defectos, está concentrado en el etapa de pruebas.

● de la gráfica de Pressman 2006, el costo de detectar y corregir defectos, en la etapa de testing,

cuesta de 40 a 70 unidades de tiempo más, que detectarlo y corregirlo en la etapa de
requerimientos. Además de que el defecto detectado puede ser alto y riesgoso, ya que es posible
encontrar errores bien complejos que requiera un tiempo considerable para su solución, lo cual
afectaría el cronograma y el presupuesto, o que no son factibles de solucionar, incumpliendo así
los requerimientos del usuario.

● de la gráfica de Laporte y April 2018, vemos que en la etapa de testing, el porcentaje de inyección
de defectos, es menor que la etapa de requerimientos.

● de las tablas y gráficas, tanto del Chaos Report, como de Apiumhub 2021 Situacion actual del
software, el 70% de los proyectos fallan, donde los principales factores, motivos o causas del
porqué, viene dado por las deficientes, incompletas, ambiguas, falta de claridad y mala
priorización de las especificaciones de los requerimientos.

Por todo ello, es que se debe garantizar la calidad del software desde el inicio del proceso, realizando
una adecuada definición de los requerimientos y validando desde el inicio que estos cumplan con las
características de un buen requerimiento, para esto se recomienda:

LTI – Plan 2024 15

 Metodologías del Testing Funcional

● incluir de forma temprana al equipo de pruebas, a fin de que se realicen determinadas pruebas,
que permitan identificar los defectos de forma temprana.

Muchas veces durante el proceso de testing y creación de test cases el Tester puede descubrir
requerimientos que no están claramente definidos o ambiguos, en estas situaciones se ve en la
obligación de comunicar esto y de ser necesario solicitar una actualización/mantenimiento de los
requerimientos.

En muchos casos el Tester es el primero en identificar si hay inconsistencias o desactualización entre

la funcionalidad del software y los requerimientos iniciales, la mayoría de las veces los cambios en los
requerimientos no son claramente reflejados y solo son evidentes cuando un usuario nuevo o nuevo
integrante del equipo empieza a trabajar con la aplicación.

Entre ellas las distintas pruebas, las pruebas de revisión estática, se conocen como revisiones ya que
detectan manualmente defectos en cualquier producto del desarrollo, dentro de las técnicas de
revisiones estáticas, se encuentran las Revisiones informales, las Inspecciones, Walkthrough y
Auditorías

● Revisiones informales: consiste en un intercambio de opiniones entre los participantes

● Inspecciones: son un método de análisis para verificar y validar un producto de software

manualmente. Son un proceso definido donde un equipo de personas analiza el producto
través de una técnica de lectura, a fin de detectar defectos antes que inicie la fase de pruebas
funcionales.

● Walkthrough: consiste en simular la ejecución de casos de prueba, es decir, se recorre le

programa imitando lo que haría la computadora.

● Auditorías: contrastan los artefactos generados durante el desarrollo con estándares

generales o de la organización

LTI – Plan 2024 16