Testing, Implementación y

Mantenimiento de Sistemas

Mgter. Carlo Corrales Delgado

Escuela Profesional de Ingeniería de Sistemas -
UCSM
ccorrales@ucsm.edu.pe
 Contenido
● Introducción
● ¿Quién hace las Pruebas?
● ¿Cuándo se inicia el testing de software?
● ¿Cuándo finalizan las pruebas?
● Verificación y validación
● Mitos sobre el Testing de software
● QA, QC y Testing
● Auditoría e Inspección
● Pruebas y depuración
● Resumen
 Introducción
● Es el proceso de evaluación de un sistema o de su componente(s)
con la intención de encontrar si cumple los requisitos especificados.

● La prueba se ejecuta en un sistema con el fin de identificar los

vacíos, errores, o los requisitos faltantes en contra de las exigencias
reales.

● De acuerdo con la norma ANSI/IEEE 1059 el Testing se puede definir

como:
● Un proceso de análisis de un elemento de software para detectar las
diferencias entre las condiciones existentes y las requeridas( es decir
defectos/errores/bugs ) y para evaluar las características del elemento de
software.
 Quién hace las pruebas?
Depende del proceso y de los grupos de interés asociados al(os)
proyecto(s).
En la industria de TI, las grandes empresas tienen un equipo con
responsabilidades para evaluar el software desarrollado en el
contexto de los requisitos citados.
Los desarrolladores también llevan a cabo las pruebas llamadas
Pruebas Unitarias.
En la mayoría de los casos, los siguientes profesionales participan en
la prueba de un sistema dentro de sus respectivas capacidades:
● Tester de Software
● Desarrollador de software
● Líder de Proyecto / Gerente
● Usuario final
 Cuándo se inicia el testing?
Un inicio temprano de las pruebas reduce el costo y el tiempo para
corregir y producir el software libre de errores que se entrega al
cliente.
Sin embargo, en el ciclo de vida de desarrollo de software( SDLC) , las
pruebas se puede iniciar desde la fase de recopilación de requisitos y
continuar hasta el despliegue del software.
También depende del modelo de desarrollo que se utiliza. Por
ejemplo, en el modelo de cascada, las pruebas formales se lleva a
cabo en la fase de pruebas; pero en los modelos incrementales, las
pruebas se realizan al final de cada iteración/incremento y toda la
aplicación se prueba en el extremo.
 Cuándo se inicia el testing?
Las pruebas se realizan en las diferentes formas en cada fase del
CVDS:
Durante las fases de recopilación de requisitos, análisis y verificación
de requisitos también son consideran como pruebas.
Revisar el diseño en la fase de diseño con la intención de mejorar el
diseño también se considera como prueba.
Las pruebas realizadas por un desarrollador al finalizar el código
también se clasifican como pruebas.
 Cuándo finalizan las pruebas?
Es difícil determinar cuándo se terminan las pruebas de software,
como las pruebas son un proceso que nunca termina y nadie puede
pretender que un software este probado al 100%.
Los siguientes aspectos son para ser considerados en la finalización
del proceso de pruebas:
● Plazos de pruebas.
● La finalización de la ejecución de los casos de pruebas.
La finalización de la cobertura funcional y de código en cierto punto
●

determinado.
La tasa de Bug’s cae por debajo de cierto nivel y no hay errores de alta
●

prioridad que se identifiquen.

● Decisiones de gestión.
 Verificación y validación
●Estos dos términos son muy confusos para la mayoría de la gente, que
los utilizan de manera indistinta.
Pruebas Exitosas
Diferencias: Validación y Verificación
Nro Verificacion
1 Verificación responde a la
preocupación : "¿Se está construyendo
las cosas bien?“.
2 Asegura que el sistema software
cumple con todas las funcionalidades.
3 La Verificación tiene lugar primero e
incluye la comprobación de la
documentación, código, etc.
4 Hecho por los desarrolladores.
5 Tiene actividades estáticas, que
incluyen la recogida de opiniones,
tutoriales, y las inspecciones para
verificar el software.
6 Es un proceso objetivo y ninguna
decisión subjetiva debe ser necesaria
para verificar un software.
Validacion
Validación responde a la
preocupación : "¿Se está
construyendo lo correcto?“.
Asegura que las funcionalidades
cumplen con el comportamiento
previsto.
La Validación se produce después
de la verificación e implica la
comprobación del producto global.
Hecho por los Testers.
Cuenta con actividades dinámicas,
que incluye la ejecución de
software contra los requisitos.
Es un proceso subjetivo e implica
decisiones subjetivas sobre qué tan
bien funciona el software.
 Mitos sobre testing de software
A continuación se presentan los mitos más comunes acerca de las
pruebas de software.
Mito 1: Las pruebas son demasiado costosas
●

●Realidad: Hay un dicho, pagar menos por las pruebas durante el

desarrollo de software o pagar más por el mantenimiento o corrección
posterior. Las primeras pruebas ahorran tiempo y costo en muchos
aspectos, sin embargo la reducción del costo sin pruebas puede
resultar en el diseño inadecuado de una versión inútil del producto
software.
Mito 2: Las pruebas consumen mucho tiempo
●

Realidad: Durante las fases del CVDS, las pruebas no son procesos
●

que consuman tiempo. Sin embargo diagnosticar y solucionar los

errores detectados durante las pruebas adecuadas es una actividad
que consume tiempo, pero productivo.
 Mitos sobre testing de software
Mito 3: Sólo Productos completamente desarrollados se prueban
Realidad: Sin duda, la prueba depende del código fuente, pero la
revisión de los requisitos y el desarrollo de casos de prueba es
independiente del código desarrollado. Sin embargo el enfoque
iterativo/incremental como un modelo de CVDS pueden reducir la
dependencia de las pruebas en el software desarrollado
completamente.
Mito 4: La Prueba completa es Posible
Realidad: Se convierte en un problema cuando un cliente o tester
piensa que la prueba completa es posible. Es posible que todos los
caminos hayan sido probados por el equipo, pero la ocurrencia de
pruebas completas nunca es posible. Puede haber algunos escenarios
que no son ejecutados por el equipo de pruebas o el cliente durante el
CVDS y puedan ejecutarse una vez que el proyecto ha sido
implementado.
 Mitos sobre testing de software
Mito 5: El Software Probado está libre de errores
Realidad: Esto es un mito muy común que los clientes, gerentes de
proyecto y el equipo directivo crean. Nadie puede afirmar con
absoluta certeza que una aplicación de software es 100 % libre de
errores , incluso si un probador con excelentes habilidades de prueba
ha probado la aplicación..
Mito 6: Los defectos no detectados se deben a los Testers
Realidad: No es un enfoque correcto culpar a los Testers por los bugs
que quedan en la aplicación, incluso después de la prueba que se ha
realizado. Este mito se refiere al tiempo, costo, restricciones y
requisitos cambiantes. Sin embargo, la estrategia de prueba también
puede resultar en errores que no son detectados por el equipo de
prueba.
 Mitos sobre testing de software
Mito 7: Los Testers son Responsable de la Calidad del Producto
Realidad: Es una mala interpretación muy común que sólo los Testers o
el equipo de pruebas deben ser responsables de la calidad del
producto. Las responsabilidades de los testers incluyen la
identificación de los bugs a interesados y es entonces su decisión si
van a reparar el bug o liberar el software. Liberar el software en el
momento pone más presión en los Testers, ya que serán culpados por
cualquier error.
Mito 8: La automatización de Pruebas se debe utilizar siempre que sea
posible para reducir la duración del proyecto
Realidad: Sí, es cierto que la automatización de Pruebas reduce el
tiempo de prueba, pero no es posible iniciar la automatización de
pruebas en cualquier momento durante el desarrollo de software. La
automatización de pruebas debe iniciarse cuando el software ha sido
probado de forma manual y es estable hasta cierto punto. Por otra
parte, la automatización de pruebas no se puede utilizar si los
 Mitos sobre testing de software
Mito 9: Cualquiera puede probar una aplicación de software
Realidad: La gente fuera de la industria de TI piensa y cree que
cualquiera puede probar un software y que las pruebas no son un
trabajo creativo. Sin embargo los Testers saben bien que es un mito.
Se debe pensar en escenarios alternativos, tratar de quebrar un
software con la intención de explorar errores potenciales no es
posible para la persona que lo desarrolló.
Mito 10: La única tarea de un Tester es encontrar errores
Realidad: Encontrar errores en un software es la tarea de los Testers,
pero al mismo tiempo, son expertos en el dominio del software en
particular. Los desarrolladores sólo son responsables de la
componente o área específica que se les asigna, pero los Testers
deben de entender el funcionamiento general del software, lo que las
dependencias hacen, y las repercusiones de un módulo en otro
módulo.
 QA, QC y Testing
La mayoría de la gente se confunde cuando se trata de precisar las
●

diferencias entre Aseguramiento de la Calidad, Control de Calidad y

Testing.
A pesar de que están relacionados entre sí y hasta cierto punto,
●

pueden ser considerados como las mismas actividades, pero existen

puntos distintivos que los diferencian.
 Diferencias
Aseguramiento de la Calidad
Incluye actividades que aseguren
la implementación de procesos,
procedimientos y normas en el
contexto de la verificación del
software desarrollado y los
requisitos previstos.
Se centra en los procesos y
procedimientos en lugar de la
realización de pruebas reales en
el sistema.
Actividades orientadas a los
procesos.
Las actividades preventivas.
Es un subconjunto del Ciclo de
Vida de Pruebas del
software(CVPS).
Control de Calidad
Incluye actividades que garanticen
la verificación de un software
desarrollado con respecto a los
requisitos documentados (o no en
algunos casos).
Se centra en las pruebas reales
ejecutando el software con el
objetivo de identificar bug/defecto a
través de la implementación de los
procedimientos y procesos.
Actividades orientadas al producto.
Es un proceso correctivo.
Se puede considerado como
subconjunto de Aseguramiento de la
Calidad.
Pruebas
Incluye actividades que
aseguren la identificación
de bugs/errores/defectos
en el software.
Se centra en las pruebas
reales.
Actividades orientadas al
producto.
Es un proceso preventivo.
Es un subconjunto del
Control de Calidad
 Auditoria e inspección
●Auditoría: Es un proceso sistemático para determinar cómo se lleva a
cabo el proceso de prueba real dentro de una organización o un
equipo.
●En general, es un examen independiente de los procesos que
intervienen durante la prueba de un software.
Según IEEE, es una revisión de los procesos documentados que las
●

organizaciones implementen y siguen.

Tipos de auditoría incluyen a Auditoría de Cumplimiento Legal ,
●

Auditoría Interna y Auditoría del sistema.

 Auditoria e inspección
●Inspección: Es una técnica formal que implica revisiones técnicas
formales o informales de cualquier artefacto mediante la identificación
de cualquier error o hueco.
●Según IEEE94, inspección es una técnica de evaluación formal en el
que se examinan los requisitos de software, diseños o códigos en
detalle por una persona o un grupo que no sea el autor para detectar
fallas, violaciones de las normas de desarrollo y otros problemas.
Las Reuniones formales de inspección pueden incluir los siguientes
●

procesos : Planificación, Información general de Preparación, Reunión

de inspección, revisiones y seguimiento.
 Pruebas y depuración
●Pruebas: Se trata de identificar bug/error/defecto en un software sin
corregirlo.
●Normalmente profesionales con experiencia en aseguramiento de la
calidad están involucrados en la identificación errores.
Las pruebas se realizan en la fase de pruebas.
●
 Pruebas y depuración
Depuración: Se trata de identificar, aislar, y corregir los
problemas/errores.
Los desarrolladores que codifican el software llevan a cabo la
depuración al encontrarse con un error en el código.
La depuración es una parte de Pruebas de Caja Blanca o pruebas
unitarias.
La depuración se puede realizar en la fase de desarrollo, mientras que
la realización de pruebas unitarias o en fases, mientras se corrigen los
errores reportados.
 Perspectiva del Testing
●¿Por qué testeamos? Dos razones: para hacer juicios sobre Calidad o
Aceptabilidad para descubrir problemas. Testeamos pues sabemos
que somos falibles. Esto es verdad especialmente en dominios de
software y sistemas controlados por software.
Las pruebas deben centrarse en dos objetivos :
●

–Probar si el software no hace lo que debe hacer.

–Probarsi el software hace lo que no debe hacer, es decir, si provoca efectos
secundarios.
La meta de esta presentación es crear un marco dentro del cual
●

podamos examinar el testing de software.

 Definiciones Básicas
●La mayoría de la literatura sobre testing es confusa (y hasta
inconsistente). La ISTQB (International Software Testing Qualification
Board) tiene un glosario de términos de testing. www.istqb.org
●Error: La gente comete errores. Cuando son al codificar los
llamamos bugs. Los errores tienden a propagarse, un error de
requerimiento puede magnificarse durante el diseño y amplificarse
aun mas durante la codificación.
●Falla: Es el resultado o representación de un error. Es el modo de
expresión, tal como un texto narrativo, tal como los diagramas UML,
charts jerárquicos y código fuente. Los defectos son sinónimos de
fallas o de bug. Las fallas pueden ser elusivas. Un error de omisión
resulta en una falla la cual algo falta que debería estar presente en la
representación. Una falla de comisión ocurre cuando ingresamos algo
en una representación incorrecta. Fallas de omisión ocurre cuando
fallamos en ingresar información correcta. Las de omisión son las mas
difíciles de detectar y resolver.
 Definiciones Básicas
●Failure (fallo) ocurre cuando el código correspondiente a una falla se
ejecuta. El failure solo ocurre en una representación ejecutable. Esta
definición relaciona failures solo con fallas de comisión. ¿Cómo tratar
con failures que corresponden a fallas de omisión?¿Qué pasa con las
fallas que nunca suceden o no ejecutan por largo tiempo?
●Las Revisiones previenen muchas failures hallando fallas, de hecho,
revisiones bien hechas pueden hallar fallas de omisión.
●Incidente: Cuando un failure ocurre, puede o no aparecer ante el
usuario (o cliente o tester). Un incidente es el síntoma asociado con un
failure que alerta al usuario de la ocurrencia de una falla.
●Test: Testing está obviamente relacionado con los errores, fallas,
failures e incidentes. Un test es el acto de ejercitar al software con
casos de test. Un test tiene 2 metas: hallar failures o demostrar la
ejecución correcta.
 Definiciones Básicas
●Caso de Test: Un caso de test tiene una identidad y está asociado con
el comportamiento del programa. Tiene un conjunto de entradas y
salidas esperadas.
●En la siguiente figura vemos el modelo del ciclo de vida para el
testing. Note que en la fase de desarrollo en 3 oportunidades llegan
los errores, resultando en fallas que pueden propagarse a través de lo
que resta del proceso de desarrollo. El paso de resolución de fallas es
otra oportunidad para introducir nuevos errores y fallas.
Cuando una solución causa que el software correcto se comporte mal,
●

esta solución es deficiente.

El proceso de testing puede ser dividido en: Planeación de test,
●

desarrollo de casos de test, Ejecución de casos de test, y evaluación

de resultados de test.
 Casos de test
La esencia de testing de software es determinar un conjunto de casos
●

de test para el ítem a ser testeado.

●Un caso de test es un producto de trabajo reconocido. Un caso de test
completo contendrá un id, una frase descriptiva del propósito,
precondiciones, las entradas del caso de test, las salidas esperadas,
una descripción de las postcondiciones esperadas, y una historia de la
ejecución. La historia de la ejecución es para uso del mantenimiento
del test. Puede contener la fecha de cuando se ejecutó, la persona que
lo hizo, la versión en la cual se ejecutó, y el resultado (pasó o falló)
●La porción de salida de un caso de test es la parte difícil. Suponga
por ejemplo que se está probando software que determina una ruta
óptima para una nave, dado ciertas restricciones de la Administración
de la Aviación federal y el clima correspondiente al día de vuelo.
¿Como sabremos cual es la ruta óptima?
 Casos de test
●La academia responde a este problema postulando la existencia de
un oráculo que sabe todas las respuestas. La industria es saber como
testing de referencia, donde el sistema es testeado en la presencia de
usuarios expertos. Estos expertos hacen juicios si las salidas de un
conjunto ejecutado de entradas de casos de test son aceptables.
●La ejecución de casos de test implica establecer las precondiciones
necesarias proveyendo entradas de casos de test, observando las
salidas, comparándolos con las salidas esperadas, y luego asegurando
que las postcondiciones esperadas existen para determinar si el test
pasó. De todo esto, se aclara que los casos de test son valiosos, por lo
menos tan valiosos como el código fuente. Los casos de test necesitan
ser desarrollados, revisados, usados, administrados y guardados.
 Recomendaciones
No deben hacerse planes de prueba suponiendo que, prácticamente,
●

no hay defectos en los programas.

El developer no debería probar su propio código.
●

Cada caso de prueba debe definir el resultado de salida esperado.

●

Al generar casos de prueba, se deben incluir tanto datos de entrada

●

válidos y esperados como no válidos e inesperados.

●La experiencia parece indicar que donde hay un defecto hay otros, es
decir, la probabilidad de descubrir nuevos defectos en una parte del
software es proporcional al número de defectos ya descubierto.
●Las pruebas son una tarea tanto (o más?) creativa que el desarrollo de
software. Siempre se han considerado las pruebas como una tarea
destructiva y rutinaria.
 Visiones desde los diagramas de
venn
●Consideremos un universo de comportamientos de programa (nótese
que se está forzando la atención a la esencia del testing). Dado un
programa y sus especificaciones, considere el conjunto S de
comportamientos especificados y el conjunto P de comportamientos
implementados. Con este diagrama podremos ver más claramente los
problemas que confronta un tester. ¿Qué si ciertos comportamientos
específicos no han sido implementados? En nuestra terminología, son
fallas de omisión. ¿Qué si ciertos comportamientos implementados no
han sido especificados?, esto correspondería a fallas por comisión y a
errores que ocurrieron luego que la especificación fue completada.
La intersección de S y P es la porción correcta, esto es,
comportamientos que son ambos especificados e implementados. Una
buena vista de testing es que es la determinación de la extensión del
comportamiento del programa que es ambos especificado e
implementado.
 Visiones desde los diagramas de
venn
En esta nueva figura mostrada se aprecia el nuevo círculo para los
Casos de test. Noten la discrepancia con nuestro universo en
discusión y el conjunto de comportamientos de programas. Ya que un
caso de test causa un comportamiento de un programa, los
matemáticos deben perdonarnos. Ahora, consideren la relación entre
los conjuntos S, P y T. Debe existir comportamientos especificados
que no son testeados (regiones 2 y 5), comportamientos especificados
que son testeados (regiones 1 y 4), y casos de test que corresponden a
comportamiento no especificado (regiones 3 y 7).
Similarmente debe haber comportamientos implementados que no
son testeados (regiones 2 y 6), comportamientos implementados que
son testeados (regiones 1 y 3) y casos de test que corresponden a
comportamientos que no son implementados (regiones 4 y 7)
 Identificando casos de test
Dos aproximaciones fundamentales son usadas para identificar casos
de test, tradicionalmente han sido llamados testing funcional y
estructural. Basado en especificaciones y basado en código, son
nombres más descriptivos, y aquí los usaremos. Ambas
aproximaciones tienen distintos métodos de identificación de casos de
test; son generalmente llamados métodos de testing. Son llamados
métodos en el sentido de que 2 testers siguiendo el mismo método
divisarán casos de test muy similares (o equivalentes?)
 Testing basado en especificaciones
●La razón por la que el testing basado en especificaciones fue
originalmente llamado “testing funcional” es que cualquier programa
puede ser considerado para ser una función que mapea valores desde
sus dominios de entrada hasta los valores en sus rangos de salida.
Esta noción es comúnmente usada en ingenierías, cuando los sistemas
son considerados como cajas negras. Esto conduce a otro término,
testing de caja negra, en el cual el contenido (la implementación) de
la caja negra no es conocido, y la función de la caja negra es
entendida completamente en términos de sus entradas y salidas.
 Testing basado en especificaciones
Muchas veces operamos muy efectivamente con el conocimiento de
cajas negras, de hecho esto es fundamental a la orientación a objetos.
Como ejemplo, la mayoría de gente maneja satisfactoriamente los
automóviles con solo el conocimiento de caja negra.
Con la aproximación basada en especificaciones hacia la
identificación de casos de test, la única información usada es la
especificación del software. Por tanto los casos de test tienen 2
ventajas distintas: Primero, son independientes de cómo el software
es implementado, así si la implementación cambia, los casos de test
son aun útiles. Segundo, el desarrollo de casos de test puede ocurrir
en paralelo con la implementación, por tanto reducen el tiempo de
desarrollo del proyecto en general. En el lado negativo, los casos de
test basados en especificaciones sufren frecuentemente de 2
problemas: redundancias significantes pueden existir a lo largo de
los casos de test, compuesto por la posibilidad de agujeros de
software no testeado.
 Testing basado en especificaciones
La figura 1.5 muestra los resultados de casos de test identificados por 2
métodos basados en especificaciones. El método A identifica un
conjunto mayor de casos de test que el método B. Note que para
ambos métodos, el conjunto de casos de test está completamente
contenido dentro del conjunto del comportamiento especificado. Ya
que los métodos basados en especificaciones están basados en el
comportamiento específico, es difícil imaginar estos métodos
identificando comportamientos que no estén especificados.
 Testing basado en código
Es otra aproximación a la identificación de casos de test.
Para contrastarlo con el testing de caja negra, es a veces llamado
testing de caja blanca. La diferencia esencial es que la
implementación en el de caja negra es conocida y usada para
identificar los casos de test. La habilidad para “ver dentro” de la caja
negra permite al tester identificar casos de test con las bases en cómo
son implementadas las funciones.
El testing basado en código ha sido sujeto de varias teorías firmes. Es
esencial el familiarizarse con la teoría de grafos lineales. Con esto el
tester puede describir exactamente qué es lo que se está probando.
Por su base fuertemente teórica, el testing basado en código se presta
a la definición y uso de métricas de cobertura de test.
Las métricas de cobertura de test proveen una manera de establecer
la extensión de lo que un ítem de software ha sido probado y esto hace
significativo a la administración del testing.
 Resumen
●Testing: Un proceso de análisis de un elemento de software para
detectar las diferencias entre las condiciones existentes y las
requeridas.
●¿Quién hace las Pruebas?: según la dimensión: Tester, Desarrollador,
Líder de Proyecto / Gerente, Usuario final
¿Cuándo se inicia el testing de software?: Mientras más temprano es
●

mejor. Se hace testing desde la captura de requerimientos.

●¿Cuándo finalizan las pruebas?: nunca hay software probado al 100%,
según el proyecto podría ser: Plazos de pruebas, finalización de los
casos de pruebas, finalización de la cobertura funcional, reducción de
la tasa de Bug’s a cierto nivel, decisiones de gestión.
Verificación y validación: la validación se hace posterior a la
●

verificación.
 Resumen
●Mitos en el testing de software: existen muchas presunciones sobre las
pruebas de software que van desde la parte operacional, los costes del
proyectos y las funciones, papeles y responsabilidades de los testers de
software.
QA, QC y Testing: el Aseguramiento de la Calidad engloba al Control de
●

Calidad y éste al Testing.

Auditoría: Es un proceso sistemático para determinar cómo se lleva a cabo el
●

proceso de prueba real dentro de una organización o un equipo.

●Inspección: Es una técnica formal que implica revisiones técnicas formales o
informales de cualquier artefacto mediante la identificación de cualquier error
o hueco.
●Pruebas: Se trata de identificar bug/error/defecto en un software sin
corregirlo.
● Depuración: Se trata de identificar, aislar, y corregir los problemas/errores.
 Resumen
Perspectiva del testing
●

Definiciones básicas
●

Casos de test
●

Visiones desde los diagramas de Venn

●

Testing basado en especificaciones

●

Testing basado en código

●
Gracias!