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 fnalizan las pruebas?
● Verifcació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 especifcados.
● La prueba se ejecuta en un sistema con el fn de identifcar 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
defnir 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 fnal
 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 fnal 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
verifcació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 fnalizar el código
también se clasifcan 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
fnalización del proceso de pruebas:
● Plazos de pruebas.
● La fnalización de la ejecución de los casos de pruebas.
● La fnalizació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 identifquen.
● 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.
Diferencias: Validación y Verificación
Nro Verifcacion
1 Verifcació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 Verifcació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 verifcar el
software.
6 Es un proceso objetivo y
ninguna decisión subjetiva
debe ser necesaria para
verifcar 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 verifcació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 afrmar
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 refere 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 identifcació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 requisitos siguen cambiando.
 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ífca 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.
 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ífca 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.

Aseguramiento de la Calidad
Incluye actividades que
aseguren la implementación de
procesos, procedimientos y
normas en el contexto de la
verifcació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).
Diferencias
Control de Calidad Pruebas
Incluye actividades que Incluye actividades que
garanticen la verifcación de un aseguren la
software desarrollado con identifcación de
respecto a los requisitos bugs/errores/defectos
documentados (o no en algunos en el software.
casos).
Se centra en las pruebas reales Se centra en las
ejecutando el software con el pruebas reales.
objetivo de identifcar
bug/defecto a través de la
implementación de los
procedimientos y procesos.
Actividades orientadas al Actividades orientadas
producto. al producto.
Es un proceso correctivo. Es un proceso
preventivo.
Se puede considerado como Es un subconjunto del
subconjunto de Aseguramiento Control de Calidad
de la 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 identifcació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 : Planifcación, Información general de
Preparación, Reunión de inspección, revisiones y
seguimiento.
 Pruebas y depuración
● Pruebas: Se trata de identifcar bug/error/defecto en un
software sin corregirlo.
● Normalmente profesionales con experiencia en
aseguramiento de la calidad están involucrados en la
identifcación errores.
● Las pruebas se realizan en la fase de pruebas.
 Pruebas y depuración
Depuración: Se trata de identifcar, aislar, y corregir los
problemas/errores.
Los desarrolladores que codifcan 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.
– Probar si 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
Qualifcation Board) tiene un glosario de términos de testing.
www.istqb.org
● Error: La gente comete errores. Cuando son al codifcar los
llamamos bugs. Los errores tienden a propagarse, un error
de requerimiento puede magnifcarse durante el diseño y
amplifcarse aun mas durante la codifcació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 defnició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 fgura 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 defciente.
● 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 defnir 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 especifcaciones,
considere el conjunto S de comportamientos especifcados 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ífcos no han sido implementados? En nuestra
terminología, son fallas de omisión. ¿Qué si ciertos
comportamientos implementados no han sido especifcados?,
esto correspondería a fallas por comisión y a errores que
ocurrieron luego que la especifcación fue completada. La
intersección de S y P es la porción correcta, esto es,
comportamientos que son ambos especifcados e
implementados. Una buena vista de testing es que es la
determinación de la extensión del comportamiento del
programa que es ambos especifcado e implementado.
Visiones desde los diagramas de
venn
En esta nueva fgura 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 especifcados que no son testeados (regiones 2
y 5), comportamientos especifcados que son testeados (regiones
1 y 4), y casos de test que corresponden a comportamiento no
especifcado (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 identifcar
casos de test, tradicionalmente han sido llamados testing
funcional y estructural. Basado en especifcaciones y basado en
código, son nombres más descriptivos, y aquí los usaremos.
Ambas aproximaciones tienen distintos métodos de
identifcació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 especifcaciones 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 especifcaciones hacia la
identifcación de casos de test, la única información usada es la
especifcació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 especifcaciones
sufren frecuentemente de 2 problemas: redundancias
signifcantes 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 fgura 1.5 muestra los resultados de casos de test identifcados
por 2 métodos basados en especifcaciones. El método A
identifca 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 especifcado. Ya que los métodos basados en
especifcaciones están basados en el comportamiento específco,
es difícil imaginar estos métodos identifcando comportamientos
que no estén especifcados.
 Testing basado en código
Es otra aproximación a la identifcació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
identifcar los casos de test. La habilidad para “ver dentro” de la
caja negra permite al tester identifcar 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
frmes. 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 defnició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 signifcativo 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 fnal
● ¿Cuándo se inicia el testing de software?: Mientras más
temprano es mejor. Se hace testing desde la captura de
requerimientos.
● ¿Cuándo fnalizan las pruebas?: nunca hay software probado
al 100%, según el proyecto podría ser: Plazos de pruebas,
fnalización de los casos de pruebas, fnalización de la
cobertura funcional, reducción de la tasa de Bug’s a cierto
nivel, decisiones de gestión.
● Verifcación y validación: la validación se hace posterior a la
verifcació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 identifcación de cualquier error o hueco.
● Pruebas: Se trata de identifcar bug/error/defecto en un
software sin corregirlo.
● Depuración: Se trata de identifcar, aislar, y corregir los
problemas/errores.
 Resumen
● Perspectiva del testing
● Defniciones básicas
● Casos de test
● Visiones desde los diagramas de Venn
● Testing basado en especifcaciones
● Testing basado en código
Gracias!