METODOLOGIA TESTING PARTE UNO

Testing : tarea de demostrar que un programa realiza las funciones para las cuales fue construido, aun
haciendo lo esperado puede contener errores.

Ejecución de programas de software con el objetivo de detector fallos y defectos.

Exitoso el que detecta errores.

No exitoso el que no lo hace.

Smoke test: subconjunto de todos los casos de prueba que cubren la principal funcionalidad de un
componente o Sistema, para determinar que las funciones más cruciales de un programa trabajan
adecuadamente.

CALIDAD:

Software ieee610 : programas de ordenador, procedimientos y documentación y datos de la operación

de un Sistema .

9126 calidad software iso, totalidad de las funcionalidades y características de un producto que
contribuyen a su habilidad de satisfacer las necesidades especificadas

Calidad: ieee std 610: grado en el cual un componente, Sistema o proceso satisfice los requisitos
especificados y/o necesidades del cliente.

SOFTWARE TESTING VS QA

-QA: enfocado a procesos, procedimientos y estándares establecidos para cada una de las fases del ciclo
de vida del software.

-testing : enfocado a productos o servicios, utiliza casos de pruebas para ser ejecutados , se realiza en
una SOLA de las fases del ciclo de vida del software

- similitudes: ambas permiten verificar y afirmar la calidad del producto final/// ambas definen un
conjunto de actividades a realizar dentro del ciclo de vida del software para mejorar y asegurar calidad

Error: accion humana que produce un resultado incorrecto. Ejemplo: error de programación.

Defecto: Desperfecto en un componente o sistema que puede causar que el aplicativo falle al realizar las
funciones requeridas.

Fallo: manifestacion fisica o funcional de un defecto. si un defecto es encontrado durante la ejecución

deun prorgrama este puede causar un fallo. ///desviación de un Sistema respecto a la prestacion,
servicio o resultado esperado, provocando efectos negativos

EJEMPLO (calculadora): un error de programación como poner una suma en vez de una resta, introduce
un defecto en en la operación resta, lo cual se manifiesta en el fallo del resultado de la resta.
Verificacion: comprobacion de la conformida con los requisitos establecidos /// se ha procedido
correctamente con la construcción del Sistema..///En automatización solemos usar verificar para
referinos a algo visual, por ejemplo a ver un botón, o visualizar un mensaje. Ejemplo: verificar que se
visualice el botón de enviar.

Validación: comprobacion de la idoneidad para el uso esperado/// hemos construido el Sistema

software correcto?///En automatización lo usamos para funciones mas que todo. Ejemplo: validar que al
presionar el botón enviar, se realice la acción correspondiente.

Atributos funcionales: basadas en funciones y caracteritisticas y su interaoperabilidad con sistemas

específicos///: correctitud(el Sistema hace lo q debera hacer); completitud (el sistema satisfice todos los
requisitos); idoneidad; precision ;conformidad; interoparebilidad; seguridad. (TODO TIPO DE PRUEBAS,
E2E, SMOKE TEST, ETC..)

No funcionales: describe las pruebas requeridas para medir las caracteristicas de Sistema, software,
hardware, infraestructura; se pueden cuantificar en una escala, y pueden medir velocidad de respuesta
osea rendimiento… esto incluye: fiabilidad, usabilidad, eficiencia, mantenabilidad, portabilidad,
seguridad (PERFORMANCE)

ENTRE AMBOS DEFINEN LA CALIDAD TOTAL DEL SISTEMA… POR LO QUE SE LLAMAN ATRIBUTOS DE
CALIDAD.

Act constructivas: con objeto de prevenir defectos.

Act analíticas: Objeto de detectar defecto///pruebas conducentes a la corrección de defectos y

prevencion de fallos.

POSIBLES CAUSAS DE ERRORES:

Error humanos: defecto introducio en el código, en datos o parametros de configuración.

condiciones ambientales: cambios en las condiciones ambientales..: radiacion, magnetismo, campos,

polucion, machas, disco duro, energia.

TERMINOS DE DERROLLO DE SOFTWARE

-código Fuente: programa de pc escrito en un lenguaje que puede ser leido por una persona.
-desarrollo de software: proceso que tiene como objetivo desarrollar un Sistema basado en un pc, sigue
modelo desarrollo software.

-requisito: condición o capacidad que un usuario necesita para solucionar un problema o lograr un
objetivo que debe cumplirse, o que tiene un Sistema para satisfacer un contrato.

-Revisión: evaluación de un Proyecto con el fin de detector discrepancias con respecto a los resultados
esperados y para recomendar mejorar.

Ciclo de vida del software: necesidades, análisis requisitos, diseño del Sistema, codificación, pruebas,
implantación o validación, mantenimiento.

Análisis: análisis necesidades de usuarios, documento con requisitos que contiene especificado todo sin
entrar en detalles internos.

Diseño del Sistema: descompone y organiza sistema en elementos que puedan elaborarse por separado,
aprovechando desarrollo en equipo. A partir de esto, surge documento de diseño que contiene
estructura relacional del Sistema y la especificación de lo que hace cada una de sus partes, así como la
manera en que se combinan.

Codificación: se implementa el código Fuente, hacienda uso de prototipos como de pruebas y ensayos
para corregir errores.

Pruebas: lo que ya se programó, se ensambla para componer el Sistema y verificar que funciona
correctamente y que cumple con los requisitos. Se realiza antes de entregar el producto al usuario final.

Implantación: usuario ejecuta sistema en producción, para esto ya los desarrolladores realizaron
pruebas exhaustivas para comprobar que el Sistema no falle.

Mantenimiento: fase dedicada a mantener y mejorar el software para corregir errores descubiertos e
incorporar nuevos requisitos ///Esto puede llevar más tiempo q incluso el propio desarrollo.

OBJETIVO DE REALIZAR TESTING:

Detectar defectos: Adquirir conocimiento de los defectos en un objeto de prueba = documentarlos para
que sea más fácil su corrección.

Ganar confianza sobre el nivel de calidad: software probado de forma adecuada= cumple funcionalidad
+alto nivel de calidad

Proporcionar información para toma de decisiones: informar sobre posibles riesgos del software = evitar
riesgo en producción.

Prevenir defectos: evitamos un costo alto de encontrar defectos en producción, pruebas más tempranas
en el software = menor costo y tiempo de corrección, porque a medida que avanza, los fallos son más
costosos. un mantenimiento puede valer 1.000.000$, mientras que su detección temprana alcanza
máximo 100.000$
El costo de eliminar defectos se aumenta con el tiempo que permanezca este en el Sistema/// la
detección de estos en etapas tempranas permite la corrección de estos mismos a costos reducidos.

PRINCIPIOS 7 DEL PROCESO DE PRUEBAS.

1. El proceso de pruebas demuestra la presencia de defectos: este demuestra la presencia, pero

no puede demostrar la ausencia de defectos.

2. No es posible realizar pruebas exhaustivas.: en las pruebas exhaustivas se busca abarcar todas
las combinaciones posibles de valores de entrada y precondiciones. ///
-explosión de casos de prueba (test case explosion): incremento exponencial de esfuerzo vs
coste en el caso de pruebas exhaustivas.
-prueba de muestra: incluye de forma sistemática o aleatoria todos los posibles valores de
entrada

3. Pruebas tempranas: early testing: la corrección de un defecto es menos costosa en la medida

de la cual se detecte en fases tempranas al proceso de desarrollo.
La preparación de una prueba también requiere tiempo. (ESTIMAR, ESTIMAR, ESTIMAR BIEN)

4. Agrupación de defectos (defect clustering) : encuentra un defecto y encontrara más defectos

“cerca” /// los tester deben ser flexibles.

5. Paradoja del pesticida: repetir pruebas en la misma condición no resulta ser efectivo., las
pruebas deben ser modificadas y o revisadas regularmente para distintos módulos del código.

6. Las pruebas dependen del contexto: se desarrollan de forma distinta según el

contexto///objetos de prueba diferentes son probados de forma diferente.

7. El fraude “falacia” de la ausencia de errores: un proceso de pruebas adecuado detectara los

fallos más importantes. El proceso no detectara todos los defectos del Sistema (principio 2).
Pero de por si esto no prueba la calidad del software. no se puede construir la calidad con solo
pruebas, esta debe introducirse desde el principio…
Resumido: No se puede afirmar que el código esta bueno porque no encontramos errores.
PROCESO DE PRUEBAS.

Control de pruebas: - plan de pruebas, análisis y diseño de pruebas, implementación y ejecución de

pruebas, criterios de finalización de pruebas y generar informes, actividad cierre de pruebas…

PLAN DE PRUEBAS:

-definir alcance+estrategía+riesgos.

-identificar objetivos +criterios de salida

-tecnica+cobertura+equipo de pruebas

-método+ estrategia + planificación de tiempo

-adquirir recursos: Personal+entorno+presupuesto.

Análisis y diseño de pruebas:

revisar las bases de las pruebas; analizar la trazabilidad; identificar y priorizar condiciones; diseños de
casos de prueba; identificar condiciones de prueba; ambiente de pruebas; infraestructura; herramientas

Implementación y ejecución de pruebas:

finalizar; desarrollar y priorizar procedimiento; verificar entorno de pruebas; verificar y actualizar

trazabilidad; ejecutar manual o automático pruebas; registrar resultados; informa y analiza incidencias;
repetición de acto de prueba.

Repetición de pruebas:

-Re testing: repetición de prueba tras la corrección de un defecto, para garantizar que el defecto fue
eliminado exitosamente.

-Prueba de regresión: pruebas de un programa previamente probado que ha sufrido modificaciones,

para asegurarse que no se han introducido o descubierto nuevos defectos, como resultado de los
cambios.

Criterios finalizacion de pruebas y generacion de informes:

-evaluar la ejecución de la prueba

-valor de registro de salida

- proporcionar información para toma de decisiones y pruebas adicionales.

Actividades de cierre de pruebas.

-recopilación datos; cerrar informes de incidencia; entregables planificados; documentar aceptación

Sistema; documentar y archivar evidencia de pruebas; analizar lecciones aprendidas; mejorar madurez
del Proyecto con información recopilada.

Control de pruebas:

-influye en planificación de pruebas; compara progreso logrado con el plan de pruebas; mide y analiza
resultados; seguimiento evolución; inicia medidas correctivas; preparar y tomar decisiones.

Equipo de pruebas:

-el desarrollo es constructivo/// las pruebas son destructivas a primera vista///el desarrollo y las
pruebas son constructivas: Tanto el desarrollo y las pruebas tienen como objetivo buscar y obtener la
menor cantidad de defectos posibles.

Equipo de pruebas:

Equipo de Desarrollo: implementa requisitos, desarrolla estructura, diseña y programa el software.

Equipo de pruebas.: planificar actividades de pruebas, diseña casos de prueba y encuentra defectos.

PRUEAS INDEPENDIENTES SON MAS SENCILLAS Y APORTAN MEJORES RESULTADOS, AUMENTAN

LA CALIDAD DEL PROCESO DE PRUEBAS

CARACTERISTICAS BUEN PROBADOR:

-curioso, perceptivo atento a detalles: comprende escenarios del cliente, analiza estructura de pruebas,
descubre detalles donde puede haber fallos.

-escéptico y con actitud crítica: por lo general hay defectos y hay que encontrarlos, no creer todo lo que
me dicen en desarrollo (jajajajajaj)///tener precausión para intentar no encontrar ya defectos al final del
Proyecto.

-Aptitudes para la comunicación: necesarios para llevar malas noticias, vencer estados de frustración,
cuestiones técnicas como practicas q sean comprendidas, comunicación positiva, establece relación con
el equipo de desarrollo a corto plazo.

-experiencia: factores personales influyen en la ocurrencia de errores, la experiencia ayuda a identificar

donde se pueden acumular errores.
TIPS TESTING EFECTIVO:

- Definer resultados esperados,

- Debo evitar probar mi propio código
- Una organización no debe probar sus propios desarrollos. (pero nosotros sí porque somos los
mejores jeje)
- Revisar test en profundida.
- Los test deben incluir entradas inválidas y validas
- Revisar que el codigo haga lo que debe hacer es la mitad, debo revisar que no haga lo que no
debe hacer
- No tirar test a la basura al menos que el programa sea basura
- No planear esfuerzos de pruebas asumiendo q no se encontrarán errores
- La probabilidad de encontrar errores en un segmento del programa es proporcional al número
de errores ya hallados.
- El testing constituye una tarea creativa e intelectualmente desafiante.

Pruebas A TRAVÉS DEL MODELO EN V

Requisitos(pruebas de aceptación)

Diseño funcional (pruebas de Sistema)

Diseño técnico (pruebas de integración)

Especificaciones de componente (pruebas de componente)

Programación jojojo

PRUEBAS
PRUEBAS FUNCIONALES:

-pruebas de componente (unitarias): se realizan durante toda la construcción del Sistema.

prueba el diseño y comportamiento de cada uno de los componentes del Sistema una vez construido.

objetivo: detector errores en los datos, lógica y algoritmos.

lo realiza los programadores.

ambiente desarrollo.
Método caja blanca. (este consiste en que no se conoce el código, cuando hablemos de caja negra, es
que no se conoce el código, solo su interfaz de usuario)

**

-prueba de integración (interfaz): se realizan durante la construcción del Sistema.

comprueba la unión correcta de los componentes del Sistema entre sí a través de sus interfaces, y si
cumplen con la funcionalidad establecida/// también sirve para identificar si se requiere pruebas no
funcionales.

Objetivo: detector errores de interfaces y relaciones entre componentes.

Lo hace programadores o tester.

Se realiza en ambiente de desarrollo.

-método caja blanca; top down( se diseña resumen, y luego cada parte nueva es redefinida con más
detalle, hasta q se detalla mucho pa validar

-se usa también método caja negra; bottom-up(al contrario, se diseña cada parte con detalle y se van
aglomerando hasta tener el Sistema., se conoce todas las variables q puede afectar el Sistema).

-pruebas de Sistema (requisitos funcionales y no funcionales) se realizan después de la construcción

del Sistema:

Prueban a fondo el Sistema probando su funcionalidad e integridad globalmente, en un entorno lo más

parecido a producción.

-prueba funcional: prueban requisitos para un uso específico previsto han sido satisfechos(validación)

-prueba no funcional: verifican los atributos de calidad no funcional: usabilidad, eficiencia, seguridad,
performance.

Objetivo: detector errores en la implementación de requerimientos a trasvés de casos de prueba.

Lo hace tester y analistas.

Ambiente, también parecido a producción.

Método: caja negra, blanca

-Pruebas de regresion: Se realizan después de realizar modificaciones en el Sistema.

probar el objeto después de cambios.

objetivo: comprobar q los cambios generados en el Sistema, no generan errores adicionales a otros
componentes no modificados.

Lo realizan tester

Ambiente en q se realizan las pruebas: semejante a producción.

Método: caja negra y blanca

Pruebas aceptacion: se realiza después de terminar satisfactoriamente las pruebas funcionales.

-pruebas del Sistema por parte del cliente.

-objetivo: verificar q Sistema cumpla todos los requisitos establecidos y permite que los usuarios del
sistema den el visto Bueno para su paso a producción.

-who? Los tester, analistas, cliente.

-ambiente semejante a producción.

Método caja negra.

-Pruebas de implantacion: se realiza durante la implantación en el entorno de producción.

comprueba el correcto funcionamiento del Sistema dentro del entorno real de producción.

objetivo: detector fallas en la implementación del Sistema.

¿Quien? Analistas y cliente

Ambiente: producción.

Método: caja negra.

PRUEBAS NO FUNCIONALES:

-PERFORMANCE: después de realizar bien las funcionales.

requerimientos y calidad del software con base a las pruebas de carga, estrés y escalabilidad.

Objetivo: verificar la eficiencia y efectividad de las transacciones de la app o Sistema.

Who? Expertos técnicos tester.

Ambiente: de pruebas semejante a producción.

Me todo: caja blanca.

-Pruebas de Seguridad: despues de las funcionales

Evalúa Sistema, la app o ambos contra accesos, internos o externos no autorizados, vulnerabilidad,

Objetivo: identificar problemas de seguridad

-who? Expertos tester.

Ambiente semejante a producción.

-método: caja negra

CAPACITACION DE PRUEBA DE DESARROLLO

Prueba unitaria de desarrollo.

-refinar desarrollo software, Nuevo o mantenimiento.

-arranca en estado mínimo complete( una fn ya o todo)

-multirol: usuario final, analista sistemas, desarrollo sistemas y análisis pruebas

- documentación punto final antes de entrega.

-no hay formato porque no es entregable

-finaliza cuando la funcionalidad es total y se documenta.

Posible Origen de la prueba:

-mail: Mandan datos a cambiar por email.

-caso de uso si aplica: autenticar usuario en el centro y huella y el otro apuntan a él, las personas
lineas sencillas.

-Documento de requisitos: documentos de requisitos de Bancolombia inclusion leyenda.

FORMAS DE REALIZAR UNA PRUEBA UNITARIA

-prueba línea de comando: llamado a programa mediante comandos de maquina y paso parámetros.
(CMD)

-prueba ruta de usuario: se realiza el llamado al programa atraves de las opciones que utiliza el usuario
-prueba debug: trabajo debug, selección puntos de análisis, y al final uso prueba línea comando o
atraves del menú.

DEFINICIÓN DE SET DE REGRESION Y PRUEBA E2E

E2E: flujo completo del negocio.

-se conectan otros sistemas para validar los resultados esperados en salidas y entradas.

-validación de transacción y recepción de datos. En integración con otra app o subsistema// puede fallar
conexiónes, transformación de datos, maduración de datos, etc.

TRANSACION O PROCESO DE NEGOCIO E2E:

-involucran experiencia completa de un usuario interno o externo

-acorde a criterios se implementa validación de entradas, salidas y trasformaciones en cada uno de los
componentes, sistemas o app que conforman el proceso de principio a fin.

DURANTE E2E se verifica lo sgt:

-reglas de negocio.

-comunicación entre los sistemas q intervienen en proceso.

-validación logs.

-Generación o actualización de datos, ejem: cambio saldo en depósitos.

-trasformación datos.

……..-.-.-………..

REGRESION:

-ejecución prueba corregida o/y la ejecución de pruebas para asegurar que no se han introducido
defectos en áreas no alteradas del software o que la corrección de un defecto no introdujo algunos
nuevos (ISTQB)

-set de regresión: conjunto pruebas (manuales o automaticas), construido a partir de funcionalidades,

transacion o parte de la solución, que se consideran rutas críticas y no deberían fallar al realizar algún
cambio.
-se valida:

se comprueba partes criticas del proceso después de realizar un cambio

se verifican partes que por su importancia no deberían fallar después de un cambio.

para ejecutar, se debe conocer el riesgo que implica el cambio e identificar que parte del set de
regresión usar o si es necesario nuevas validaciones.

cuando el riesgo por los tiempos de ejecución del set de regresión lo permiten, este se debe realizar
completo..

Regresión: ejecuta la transacción completa pero las verificaciones se orientan a el cambio que hubo

Comparativa entre E2E Y REGRESIÓN:

TANTO REGRESION COMO E2E SON PROCESOS BATCH (que se ejecutan secuencialmente)

Inicio Ejemplo de una regresión Vs la E2E:

Tomemos como ejemplo el proceso de Pago de Factura a través de la Sucursal Virtual (Ingresar a la
sucursal virtual personas con usuario y contraseña, ir a la opción de Pago de Facturas, Ingresar la
información y Pagar)

Supongamos que debido a cambio en la firma de pago por SVP, se modificó el tamaño del campo saldo.

Regresión: Se ejecuta la transacción completa validando con un saldo de acuerdo al tamaño que se
modificó y se revisa que el resto de los campos (trama) no se hayan visto afectados.

Nota: Como se puede ver aquí se ejecuta la transacción completa, pero se realizan las verificaciones
orientadas únicamente al cambio que hubo y lo que posiblemente se afectó.

La prueba E2E seria:

• Revisar que en los logs de STI y canales coincida la información con lo ingresado en el Front, • Revisar
en Finacle que el pago se haya registrado en las tablas correspondientes acorde a lo ingresado por el
Front • Revisar el archivo de saldos que si se disminuya la cantidad pagada y por ultimo revisar que en el
front se genere el mensaje de éxito y genere el movimiento.
NOTA: Para este ejemplo solo ilustramos las validaciones en los logs del canal y en finacle pero la idea es
hacer las validaciones en cada uno de los componentes que serían:

Depósitos (cierre)// SAP (contabilidad)

Y así lograríamos cubrir el ecosistema completo. Fin ejemplo.

DevOps: es una metodología para creación de software.

DevOps se basa en la integración entre desarrolladores software y administradores de sistemas.

DevOps permite fabricar software más rápidamente, con mayor calidad, menor coste y una altísima
frecuencia de releases (entregas)

DevOps: un modelo de desarrollo de productos digitales

Como conclusión, quedémonos con una definición simple de DevOps con la que todos podamos estar de
acuerdo: DevOps es una metodología de desarrollo software basada en la integración entre
desarrolladores y administradores de sistemas, que permite que los desarrolladores puedan enfocarse
sólo en desarrollar y puedan desplegar su código en segundos.

DevOps es especialmente útil en el nuevo entorno de la transformación digital y el desarrollo de

productos digitales, para los que el usuario final y/o el cliente interno de negocio demanda TTM (time-
to-market), más flexibilidad, más calidad, menos coste y una altísima frecuencia de releases.)

Git: sistema de control de versionamiento: sirve para volver en el timpo a recuperar código; sirve para
administrar individualmente lineas paralelas de trabajo y luego juntarlas; deja trabajar en forma remota.

Api: Una API es un conjunto de definiciones y protocolos que se utiliza para desarrollar e integrar el
software de las aplicaciones. API significa interfaz de programación de aplicaciones.

Las API permiten que sus productos y servicios se comuniquen con otros, sin necesidad de saber cómo
están implementados. Esto simplifica el desarrollo de las aplicaciones y permite ahorrar tiempo y dinero.
Las API le otorgan flexibilidad; simplifican el diseño, la administración y el uso de las aplicaciones, y
proporcionan oportunidades de innovación, lo cual es ideal al momento de diseñar herramientas y
productos nuevos (o de gestionar los actuales).

Visual Studio Team System:

Microsoft Visual Studio Team System (VSTS) es un conjunto de herramientas de gestión del ciclo de vida
de desarrollo de software que abordan las necesidades de una variedad de roles dentro de la
organización. VSTS viene en cinco ediciones diferentes e incluye una plataforma de colaboración
denominada Team Foundation Server (TFS) que permite administrar y dar seguimiento al avance y al
estado del trabajo en base a una serie de servicios Web y repositorios integrados.

PRUEBAS E2E

-probar flujo app se realiza según especificado principio fin

-determina rendimiento app según requisito, de principio a fin en escenarios reales como comunicación
de app con hardware y otras apps.

Importante: la app complete se prueba para funciones criticas como comunicación con otros sistemas,
interfaces, base de datos, redes y otras apps.

Propósito.: identificar dependencias Sistema y asegurar q la información q se espera no se modifica

entre pasos de componentes del Sistema u otros sistemas.

POR lo general se hace después de pruebas funcionales y de Sistema de cualquier aplicación

Porque: fallos subsistemas afectan proceso sean o no sean de la misma organización.

- Mantener y verificar flujo Sistema controla riesgos.

- Aumentar área de prueba cobertura controla riesgos.
- Detecta problemas subsistemas y aumenta productividad de todo el Sistema soft.

ACTIVIDADES:

-estudio detallado requisitos.

-configuración de entorno adecuada

-estudio detallado software y hardware, pruebas performance o seguridad si aplican

-descripción de todos los subsistemas, así como el principal

-recolectar función y responsabilidades de todos los sistemas y subsistemas

-métodos de ensayo usados en esta, y normas

-diseño casos prueba, matriz requisitos rastreo

-grabe o guarde los datos de in out de cada sistema.

COMPARATIVO ENTRE E2E Y PRUEBAS DE SISTEMA.

-Valida subsistemas y sistemas Valida solo en el Sistema propio de software

-flujo de prueba extremo a extremo
-mientras se realizan las pruebas, se toman en
consideración todas las interfaces q incluye back-
end
-las pruebas manuales se prefiere porque como
pruebo interfaces externas y todo, automatizar
esto es más difícil
-verificación y comprobación de características
funcionalidades del Sistema de software
-mientras se realizan las pruebas se incluyen
áreas funcionales y no funcionales y sus
características para las pruebas.
-tanto manuales como automatizadas pueden
realizarse como parte de las pruebas de Sistema.

CONCLUSION: para la salida a producción de un software, la prueba e2e es súper importante porque
prueba toda la app y en un entorno que imita lo más cercanamente al mundo real, como la red, base de
datos etc.

Por lo general con manuales, el costo de automatizar es cara. Esto no es solo para validar Sistema, si no
q sirve mucho para probar integración externa.

PRUEBAS INTEGRALES

-Se centra en probar las comunicaciones entre sus componentes y sus comunicaciones ya sea hardware
o software.
-describe como verificar q las interfaces entre los componentes del software funcionen correctamente
-determinar como la base de datos de pruebas será cargada.
-nos ayuda a tomar decisiones cuando se descubren problemas.
CARACTERISTICIAS:
-ensamblar o integrar los módulos para formar el paquete completo.
-la prueba de integración de dirige a todos los aspectos asociados, tanto la verificación, como la
construcción del programa.
-un módulo puede tener un aspecto adverso o inadvertido sobre otro.
-Integración no incremental:
Combinar todos los módulos y probar todo el programa en conjunto.
-integración incremental:
Se va probando el programa en pequeñas porciones y al final se prueba todo convirtiéndose en
No incremental.
¿PORQUE DUDO Q TODO FUNCIONE EN CONJUNTO SI FUNCIONA BIEN SOLO?
-integración sistemática (ensamble de los actores, uno o más)
-verificación de integración: ¿ensamble hecho según plan?, implementación adecuada de una o más
funciones?
-validación de integración: ¿se construye lo correcto?, el software construido corresponde con los
requerimientos.

PROBLEMAS: módulos no listos para integrar

Se integran módulos parcialmente desarrollados.
Evitar integración explosiva.

Temas involucrados: modelos de casos de uso:

-casos de prueba: datos de entrada
-procedimientos de pruebas: manual, auto.
-Evaluación de prueba: resumen, defectos.
-Plan de pruebas: alcance y estrategia orden global
-Componentes de las pruebas: código Fuente etc.
-Defectos: informe defectos encontrados clasificados en una herramienta.

RECOMENDACIONES:
-implementación de casos de uso completes.
-construir interfaz pronto para probar desde ella
-organización metódica de un numero grandes pruebas.
-congelar versions para las pruebas
-acompañar estas pruebas de las de regresión.
-generar nuevas versions después de pruebas.

PRUEBAS DE MIGRACION:

-transferencia a un Nuevo ambiente operativo, manteniendo toda su funcionalidad y datos originales. Se

pretende posibilitar mantenimiento y posterior adecuación a nuevos requisitos.

-complejo por costos, recursos, tiempo, Pero se justifica.

-seguridad, rotulación, cambios, disposición, transporte, iteración, calidad de datos, riesgos

ENFOQUE:

-corrección funcional del Sistema, el Sistema debe implementar y funcionar bien según su
especificación, se propone los casos de prueba del Nuevo basados en el Viejo y el análisis de las
actualizaciones.

POR Q HACERLO:

-razones: migrar software, ahorra costos, mejora actualización Sistema, optimización rendimiento y
cambio estructura corporativa.

-con el fin de que esto se haga bien la realización de pruebas y el control de calidad son fundamentales.

-súper relevante (datos apps) por lo que el Sistema debe tener la misma eficiencia y operatividad del
entorno anterior.

ETAPAS:

1. Analisis previo Sistema.

2. Escoger mejor tecnología
3. Migración lógica de negocios
4. Lol
5. Optimización de rendimiento
6. Pruebas de Sistema
7. Despliegue
8. Mantenimiento.

RIESGOS:

-costos elevados.

-alteración datos.

-daños en la funcionalidad

-fallas performance

-cronograma

PRUEBAS EN REQUISITOS:

-los requisitos soft son las características y funciones del sistema.

Nos comunican las expectativas de los consumidores de productos de software.

-el objetivo: de las pruebas de verificación es buscar discrepancias entre en los requerimientos y la
ejecución del software

FASE PARA PRUEBAS EN REQUISITOS.

-planeación: estimación de tiempo y recursos, alcance, estrategia

-diseño de casos de prueba: checklist de verificación del requerimiento.

-ejecución: evaluación de los requisitos, reporte de errores, aclaración y ajuste de lo reportado.

-cierre: entregables pruebas de requerimiento/// visto Bueno para la aprobación.

CARACTERISTICAS:

-completo: todo está incluido.

-correcto: cada ítem es libre de errores.

-preciso: cada ítem es exacto, una sola interpretación, es entendido.

-consistente: ninguno entra en conflicto con otro

-Relevante: pertinente al problema y su solución.

-probable: se le puede hacer test

-factible: está dentro de lo que podemos hacer.

-Registrable,: trazable en el tiempo

-libre de estalle de diseño

-manejable: se podría cambiar sin gran impacto en los demás.

PRUEBAS DE SISTEMA:

-SIMILARES A PRUEBAS Caja negra, sin embargo estas ven el Sistema como un todo. Basadas en
requerimientos generales y probar todas las partes combinadas del Sistema.

-el ambiente debe corresponder con el entorno de producción en la medida posible.

CARACTERISTICAS.
-puede incluir pruebas basadas en riesgos o requerimientos, procesos de negocios, casos de uso,
interacciones con el Sistema operativo y recursos del Sistema.

-tiene como objetivo primordial verificar que se han integrado adecuadamente todos los elementos de
Sistema.
PRUEBAS Q LO COMPONEN:

-recuperación: se provoca fallas en el software y se verifica que la recuperación se haga correctamente;

Si es automatico, se verifica los mecanismos respaldo, recuperación datos y arranque del Sistema..

-seguridad: comprueba que los mecanismos de seguridad implementados en el sistema lo protejan de

accesos impropios.

-resistencia: se enfrenta el programa ante situaciones anormales, se requiere cantidad y frecuencia de

recursos anormales.

-desempeño: probar desempeño software en tiempo de ejecución dentro del contexto Sistema
integrado… suelen vincularse con pruebas de Resistencia, y requerir hardware o software adicional para
mediciones puntuales de recursos.