Testing e Integración Contínua - uv.es + IC.pdf · • El objetivo final de este tipo de tests es...

Testing e Integración Contínua

The information contained in this presentation is proprietary.© 2016 Capgemini. All rights reserved. Rightshore® is a trademark belonging to Capgemini.

Indice

1. Conceptos básicos2. Pruebas de carga3. Integración Continua4. Herramientas5. Práctica


Bugs


Conceptos

El Testing, o pruebas de software, es el proceso que verifica y revela la calidad de un proyecto/producto software. Las principales ventajas que ofrece la realización de testing son :

• Comprobar la calidad de la solución.• Detectar fallos de implementación.• Detectar comportamientos inesperados o incorrectos durante el ciclo de construcción del software.• Obliga a modularizar el software correctamente.• Reduce el tiempo de resolución de incidencias.


Conceptos

• Aunque exige dedicar esfuerzo (coste para las empresas) para crear y mantener los test, los beneficios obtenidos son mayores que la inversión realizada.

• Permite delegar responsabilidades ya que el testing manual no se debería realizar por ningún integrante del equipo encargado de implementar la solución para evitar “vicios adquiridos”.

• El testing se puede utilizar incluso para implementar funcionalidad en base a metodologías alrededor de los test (TDD).

• Tranquilidad y seguridad al equipo e indirectamente a la organización.


Coste de reparación de defectos


Tipos de Test

● Unitarios.

● Integración.

● Funcionales.

● Regresión.

● Smoke tests / Sanity tests.


Tests Unitarios

Cuando probamos un programa, lo ejecutamos con unos datos de entrada (casos de prueba) para verificar que el funcionamiento cumple los requisitos esperados. Definimos prueba unitaria como la prueba de uno de los módulos que componen un programa. Por lo tanto no se puede acceder a recursos externos. Este tipo de pruebas deben realizarlas los propios desarrolladores.

public class Suma {

private int num1;

private int num2;

public Suma(int n1, int n2) {

num1 = n1;

num2 = n2;

}

public int sumar() {

int resultado = num1 + num2;

return resultado;

}

}

public class SumaTest {

@Test

public void sumaPositivos() {

Suma S = new Suma(2, 3);

assertTrue(S.sumar() == 5);

}

}


Tests de Integración

• Se prueba cómo es la interacción entre dos o mas unidades del software.

• Estos tests tienen que ser creados por desarrolladores y requieren de configuración.

• Las pruebas de integración son las que comprobarían que se ha mandado un email, la conexión real con la base de datos, lectura escritura en mensajería JMS, etc.

• Este tipo de pruebas son dependientes del entorno en el que se ejecutan. Si fallan, puede ser porque el código esté bien, pero haya un cambio en el entorno.


Conceptos

Un test de integración nos permite comprobar la integración entre varios componentes o módulos de nuestro software.Permite comprobar la integración entres distintos módulos de nuestra solución.Permita comprobar la integración con sistemas de terceros.Sistemas de Mensajería JMSBase de datosNotificacionesEtc


Conceptos


App

Mod. 1

Mod. 2


Conceptos


App

Mod. 1

Mod. 2

App

Mod. 1

Mod. 2


Conceptos


App

Mod. 1

Mod. 2

App

Mod. 1

Mod. 2

App

Mod. 1

Mod. 2


Tests Unitarios VS Tests Integración

Test unitario Test de Integración

El resultado depende sólo del código El resultado depende también de sistemas externos

Fácil de escribir y verificar El setup de los tests puede ser complicado

Se testea una clase o método aislada. Uno o mas componentes son testeados

Comprueba la implementación del código Comprueba la implementación de los componentes individuales

y si comportamiento cuando están conectados.

Sólo usa Junit/TestNG y un framework de mocking (mockito) Usa contenedores reales BBDD reales así como frameworks

específicos como Arquillian o dbunit

Suele se usado principalmente por desarrolladores Usado por QA, DevOps.

Un test que falla, si el negocio no cambia es un test de regresión Si el test falla puede significar que o bien ha fallado el código o

que algo en el entorno ha cambiado.

Los tests pueden durar unos 5 minutos Los tests pueden durar horas.


Tests funcionales

Se comprueba que el software que se ha creado cumple con la función para la que se ha creado.Lo único que importa en este tipo de pruebas es que ante una serie de inputs obtenemos el resultado esperado.Este tipo de pruebas pueden ser manuales o automáticas

Pruebas relacionadas con el funcionamiento del sistema, comprueba que se cumplan las funciones específicas para las cuales han sido desarrollado

El tester, debe tener un nivel de conocimiento del negocio similar al del cliente.


Tests Funcionales

Mediante las herramientas adecuadas se pueden automatizar

App

a=3 b=4

res = 7


Tests Funcionales

Mediante las herramientas adecuadas se pueden automatizar

App

a=3 b=4

res = 7

App

a=3 b=4

res = 7


Tests de Regresión

• Cuando se evoluciona una aplicación o se resuelve un bug, se esta realizando una modificación en el código. Esto es un riesgo, el riesgo de que algo que funcionaba deje de hacerlo.

• Por este motivo y para solucionar este problema existen las pruebas de regresión, que lo que esencialmente hacen es verificar que ciertas funcionalidades siguen intactas después de un cambio en el código.

• El objetivo final de este tipo de tests es asegurar que no se ha roto nada de lo que estaba “funcionando”


Smoke tests / Sanity tests

Se comprueba que lo más esencial del software que estamos probando funciona, son tests muy sencillos.Tienen que ser tests muy rápidos.Dan paso a que el resto de tests puedan ser lanzados.


Conceptos

La cobertura de código es una medida (porcentual) que indica la cantidad de código fuente abarcado por los test ejecutados contra nuestro proyecto.Permite :

Conocer cuánto porcentaje del código está probado.Detectar código no testeado.Fijar un porcentaje sobre el cual una entrega o proyecto puede ser considerado “NO APTO”.Ej: “El grado de cobertura de código debe superar el 60%”


Tipos de Test - Resumen

● Unitarios.

● Integración.

● Funcionales.

● Regresión.

● Smoke tests / Sanity tests.


Tipos de Test - La aproximación de la caja

Caja Negra

Caja Blanca

Test Unitarios

Tests Funcionales

Caja Gris


Principios F.I.R.S.T.

• Fast. Los tests deben ser rápidos del orden de milisegundos, tienes cientos de tests en tu proyecto.

• Isolated/Independent. Los tests no deben depender del entorno ni de ejecuciones de tests anteriores.

• Repeatable. Los tests deben ser repetibles y ante la misma entrada de datos, los mismos resultados.

• Self-Validating. Los tests tienen que ser autovalidados, es decir, NO debe de existir la intervención humana en la validación

• Thorough and Timely. Los tests deben de cubrir el scenario propuesto, no el 100% del código, y se han de realizar en el momento oportuno.


Test Driven Development ( TDD )

Práctica de ingeniería de software, implica dos técnicas básicas:• Escritura de los tests en primer lugar• Refactorización

El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione.

La idea es que los requisitos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que el software cumple con los requisitos que se han establecido.


Behaviour Driven Development (BDD)

BDD sigue el principio de que cada unidad de software ha de ser testeada de forma individual. Por norma general el proceso esde la siguiente forma:• Se diseña un tests para una unidad de software especifica.• El test se desarrolló para que fallase.• La unidad es implementada entonces• Se lanza el test otra vez, verificando que la implementación hace que el tests sea válido.

Permite un testing a bajo nivel (Test unitarios ) y a alto nivel evaluando el comportamiendo de la unidad funcional del software


Behaviour Driven Development (BDD)

Qué es JBehave?JBehave es un framework que implementa BDD.


Data Driven Testing (DDT)

Data-driven testing

Se basa en la creación de tests para ejecutarse en simultáneo con sus conjuntos de datos relacionados en un framework. El framework provee una lógica de test reusable para reducir el mantenimiento y mejorar la cobertura de test. La entrada y salida (del criterio de test) pueden ser resguardados en uno o más lugares del almacenamiento central o bases de datos, el formato real y la organización de los datos serán específicos para cada caso.

Los datos incluyen variables usadas para la entrada como la verificación de la salida. En casos avanzados (y maduros) los entornos de automatización pueden ser obtenidos desde algún sistema usando los datos reales o un "sniffer", el framework DDT por lo tanto ejecuta pruebas sobre la base de lo obtenido produciendo una herramienta de test automáticos para regresión.


Indice



Tests de Rendimiento

Pruebas de carga

Este es el tipo más sencillo de pruebas de rendimiento. Una prueba de carga se realiza generalmente para observar el comportamiento de una aplicación bajo una cantidad de peticiones esperada. Esta carga puede ser el número esperado de usuarios concurrentes utilizando la aplicación y que realizan un número específico de transacciones durante el tiempo que dura la carga. Esta prueba puede mostrar los tiempos de respuesta de todas las transacciones importantes de la aplicación. Sila base de datos, el servidor de aplicaciones, etc.. también se monitorizan, entonces esta prueba puede mostrar el cuello de botella en la aplicación.

Pruebas de estrés

Esta prueba se utiliza normalmente para romper la aplicación. Se va doblando el número de usuarios que se agregan a la aplicación y se ejecuta una prueba de carga hasta que se rompe. Este tipo de prueba se realiza para determinar la solidez de la aplicación en los momentos de carga extrema y ayuda a los administradores para determinar si la aplicación rendirá lo suficiente en caso de que la carga real supere a la carga esperada.


Tests de Rendimiento.

Pruebas de estabilidad

Esta prueba normalmente se hace para determinar si la aplicación puede aguantar una carga esperada continuada. Generalmente esta prueba se realiza para determinar si hay alguna fuga de memoria en la aplicación.

Pruebas de picos

La prueba de picos, como el nombre sugiere, trata de observar el comportamiento del sistema variando el número de usuarios, tanto cuando bajan, como cuando tiene cambios drásticos en su carga. Esta prueba se recomienda que sea realizada con un software automatizado que permita realizar cambios en el número de usuarios mientras que los administradores llevan un registro de los valores a ser monitorizados.


Testing Manual

Cuando ya hemos probado con los tests unitarios, de integración, hemos lanzado los smoke tests, hemos probado la corrección funcional de la aplicación y hemos realizado las pruebas de carga y de estrés y las de pico, hemos probado los webservices con soapUI, y hemos usado Jmeter para ver como de bien va nuestra solución. Cuando hemos probado de forma automática todo esto ¿Es nuestra aplicación la leche?

Pues NO, seguramente hemos encontrado cantidad de bugs, de errores, de fallos, de funcionalidades que no se adecuan a lo establecido, pero seguramente nuestros tests han localizado todo lo que nos proponíamos encontrar y mas. Y han hecho que se pasaran los tests de aceptación y que tengamos un gran producto en el mercado con unos costes asumibles.

Pero seguramente tendremos algún fallo escondido, que tarde o temprano saldrá a la luz, pero nos queda un último tipo de pruebas que podría localizar problemas de otra manera, nos queda el testing exploratorio.


Testing exploratorio

• Un objetivo que queremos conseguir con la sesión de testing exploratorio (por ejemplo establecer flujos que podrían seguir los usuarios de la aplicación y probarlos, ver cómo se integra la aplicación con software externo, vulnerabilidades de seguridad en el login etc.), que puede ponerlo el propio tester, el equipo de testing, o el test manager

• Limitar de alguna manera el tiempo que vamos a dedicarle a esa actividad de testing (sesiones de 1 hora, 25 min etc.).

El tester es el responsable del camino que debe seguir para conseguir ese objetivo, que puede ir cambiando a medida que va aprendiendo sobre la aplicación durante el tiempo establecido.

Por ello, para hacer buenas pruebas exploratorias, es necesario que los testers tengan una mente abierta, pensamiento crítico, sean observadores, creativos, y curiosos para detectar bugs más complejos y evaluar riesgos.

Esto requiere mayor actividad intelectual y experiencia que verificar funcionalidades, pero por experiencia, suele motivar más a los testers experimentados, ya que pone a prueba sus habilidades, es un reto.Normalmente los bugs que se encuentran durante el tiempo que dediquemos a hacer testing exploratorio se reportarán al final.


Indice



Integración continua

¿Qué es la integración continua?

Es una práctica de desarrollo de software donde los miembros de un equipo integran su trabajo frecuentemente

Cada integración es verificada por una construcción para detectar errores de integración tan rápido como sea posible

Esta aproximación conduce a una reducción significativa de los problemas de integración y permite al equipo desarrollar un software cohesionado con mayor rapidez.


CI en Arquitectura

Desarrollador


CI en Arquitectura

Desarrollador

Control de versiones


CI en Arquitectura

Desarrollador


Compilación


CI en Arquitectura

Desarrollador


Compilación

Test Unitarios


CI en Arquitectura

Desarrollador


Compilación

Control de calidad

Test Unitarios


CI en Arquitectura

Desarrollador


Compilación

Deploy

Control de calidad

Test Unitarios


CI en Arquitectura

Desarrollador


Compilación

Deploy

Test Integración

Control de calidad

Test Unitarios



Características

De forma automática compila, realiza tareas de integración con la base de datos lanza tests, inspecciones de código, despliegue y ofrece feedback de este trabajo.El entorno de IC puede reducir los riesgos más comunes así pues se llega a una mejora de la confianza y una mejor comunicación

El “Build”, la construcción es una serie de actividades como son la generación, testeo inspección y despliegue del software



Valor de la Integración continua

• Reduce los riesgos• Reduce los trabajos manuales repetitivos• Crea o genera un software desplegable en cualquier momento y en cualquier lugar• Mejora la visibilidad del proyecto• Mejora la confianza en el producto por parte del equipo de desarrollo



Buenas prácticas de IC

• Escribir tests automatizados• Commits de código de forma frecuente• Nunca hacer un commit de algo que no compile• Evitar coger código “roto”• Solucionar los problemas rápidamente• Todos los tests e inspecciones deben pasar



¿Qué conseguimos con IC?

• Elimina el acoplamiento entre IDE y el proceso de construcción• Se usa una máquina aislada para la integración• Asegura que todo el el código está en el control de versiones • Se crea un sistema de IC que ejecuta el script de construcción del proyecto cada vez que se detecta un cambio en el

repositorio


IBM


Cisco


Integración Continua

Alternativas para orquestar la Integración continua:

• Jenkins• Bamboo• Hudson• Go• Travis CI


Indice



XUnit

Xunit

Es el nombre dado a una serie de frameworks de test tales como Junit, Nunit, RubyUnit, PyUnit,PhpUnit, PerlUnit, CppUnit, etc….

Los orígenes de estos frameworks se encuentran en SmallTalk, Junit fue el primero de todos y lo que se hizo fueSustituir la J por X y así nació Xunit, que se convirtió en un estándar que el resto siguió para los distintos lenguajes


Junit

• JUnit es un “framework” para automatizar las pruebas de programas Java

• Escrito por Erich Gamma y Kent Beck

• Open Source, disponible en http://www.junit.org

• Adecuado para el Desarrollo dirigido por las pruebas (Test-driven development)

http://www.junit.org/


JUnit

Las tres partes del Test: AAA

• Arrange (Preparar)• Act (Actuar)• Assert (Afirmar)

• Componentes principales de Junit:El concepto fundamental en estas herramientas es el caso de prueba (test case), y la suite de prueba (test suite). Los casos de prueba son clases o módulos que disponen de métodos para probar los métodos de una clase o módulo concreta/o. Así, para cada clase que quisiéramos probar definiríamos su correspondiente clase de caso de prueba. Mediante las suites podemos organizar los casos de prueba, de forma que cada suite agrupa los casos de prueba de módulos que están funcionalmente relacionados.


JUnit Clases

Junit ofrece básicamente dos tipos de clases para poder realizar los tests:

Las clases de Test, son clases cuyos métodos están anotados por @Test y las Suites que son clases a las que se les anota con @RunWith y @SuiteClasses en las que le configuramos el motor de ejecución y la ejecución de los tests.

import org.junit.runner.RunWith;

import org.junit.runners.Suite;

import org.junit.runners.Suite.SuiteClasses;

@RunWith(Suite.class)

@SuiteClasses( { TestResta.class, TestSuma.class })

public class AllTest {

}

import org.junit.Test;

import static org.junit.Assert.*;

public class TestSuma {

@Test

public void TestSuma {

Suma suma = new Suma();

double resultado = suma.getSuma(1.0, 1.0);

assertEquals(2.0, resultado);

}

}


Junit - Anotaciones@BeforeClass

public static void ejecutaAntesTests() {

logger = Logger.getLogger(“TestAnotacionesJUnit");

logger.info(“Se van a ejecutar los Tests…");

}

@AfterClass

public static void ejecutaFinTests() {

logger.info(“Se han ejecutado los Tests…");

logger = null;

}

@Before

public void ejecutaAntesCadaTest() {

simpleMath = new SimpleMath();

}

@After

public void ejecutaFinCadaTest() {

simpleMath = null;

}

@Test

public void sumar() {

assertEquals(12, simpleMath.add(7, 5));

}

@Test

public void restar() {

assertEquals(9, simpleMath.substract(12, 3));

}

@Test(expected = ArithmeticException.class)

public void dividirPorCero() {

simpleMath.divide(1, 0);

}

@Ignore("Aún no lo he implementado")

@Test

public void multiplication(){

assertEquals(15, simpleMath.multiply(3, 5));

}


Mocking

Para poder crear un buen conjunto de Pruebas Unitarias, es necesario que centrarse exclusivamente en la clase a testear, simulando el funcionamiento de las capas inferiores.

De esta manera se crean test unitarios potentes que permitirán detectar y solucionar los errores que se cometan durante desarrollo de la aplicación


Mockito

El objetivo de un Test unitario es probar la responsabilidad de una clase/componente pero normalmente una clase se relaciona con otras clases que deben ser instanciadas y funcionar correctamente (en un contexto Web necesitamos acceso a la sesión, request,…)

En muchos casos para simplificar el test unitario y controlar todos los aspectos es muy útil reemplazar los objetos que colaboran con dobles.

Mockito puede usarse de dos formas:

1. Con el método estático mock:

Flower flowerMock = Mockito.mock(Flower.class);

2. Con la anotación @Mock (en este caso nuestro runner JUnit debe ser MockitoJUnit4Runner)@MockPrivate Flower flowerMock;


Mockito

Estos son los comportamientos que ofrece Mockito:• @Mock• @Spy• @Captor• @InjectMocks

Con los métodos Mockito.when() y thenReturn() Mockito nos permite definir cómo debe comportarse el Mock:// you can mock concrete classes, not only interfaces

LinkedList mockedList = mock(LinkedList.class);

// stubbing appears before the actual execution

when(mockedList.get(0)).thenReturn("first");

// the following prints "first"

System.out.println(mockedList.get(0));

// the following prints "null" because get(999) was not stubbed

System.out.println(mockedList.get(999));


Selenium

• Herramienta para la automatización de pruebas de capa vista.

• Permite la grabación de casos de prueba y la posterior reproducción.

• Permite ampliar la funcionalidad mediante scripts.

• Generación de informes detallados.

• Versiones para los sistemas operativos y navegadores más conocidos.

• Integrado con Jenkins para lanzar la ejecución de las pruebas desde las tareas.


SoapUI

¿Qué es SoapUI?

SoapUI es una solución libre y Open Source para testing funcional. Dispone de una interfaz gráfica que permite crear y ejecutar de forma fácil y sencilla test automáticos funcionales de regresión de aceptación y de carga.

¿Qué puede hacer?

• Testeo automático para tests dirigidos por datos, tests de carga y tests basados en escenarios, entre otros• MockServices, provee de una funcionalidad que permite crear y ejecutar tests funcionales y de carga que aún no han sido

implementados• Informes


Jmeter

• Herramienta Open source.• Puede cargar y ejecutar tests de rendimiento de diferentes tipos de servidor:

• Web - HTTP, HTTPS • SOAP • Database via JDBC • LDAP • JMS • Mail - POP3(S) and IMAP(S)

• Comparado con otras herramientas el interfaz gráfico es amigable. • Es un entorno de trabajo totalmente multihilo. • Puede cachear la información y trabajar con Cookies para emular lo máximo possible al navegador.• Los Controllers son configurables y es capaz de monitorizar el rendimiento del servidor.• Comparado con otras herramientas los resultados de los tests tienen una alta fiabilidad.• Los resultados de los tests pueden ser capturados en varios formatos tales como summary report, Graph, Aggregate report,

Aggregate graph, Results in tree y Results in Table.


Jmeter

Tal vez la “mejor” funcionalidad de Jmeter es la de establecerse como proxy y ser capaz de grabar las acciones que realicemos sobre una aplicación web.Esto nos permite reproducir las acciones que hemos realizado modificando los siguientes aspectos entre otros:

• Parametrización, se pueden modificar lo datos para crear juegos de pruebas.• Simular condiciones de acceso de usuarios, se puede recrear las condiciones en las que los usuarios acceden a la aplicación

para determinar de un modo lo más realista posible como trabaja la aplicación ante distintas cargas de trabajo

Hay que tener una cosa clara Jmeter NO es un navegador. Aunque en ciertos momentos y aspectos pueda parecerlo, puesto que entre otras cosas trabaja a nivel de protocolo.


Herramientas

• Load Runner, commercial load testing tool from HP• JMeter, an open source tool from Appache• RPT, commercial load test tool from IBM • NeoLoad, commercial, for Windows, Linux, Solaris • Microsoft Visual Studio Team System 2010, commercial, for Windows, which includes Load Test Analyzer and Load Test

Monitor tools. • OpenLoad, commercial load testing tool and hosted service • OpenSTA, an open source tool • PureLoad, commercial, multiplatform load testing tool • PushToTest TestMaker, an open source testing framework (load testing and more) • QEngine, free and commercial, from AdventNet (free edition supports 5 virtual users) • SQLQueryStress Performance Testing Tool, free, for testing SQL Server StressIT, commercial and free • The Grinder, an open source tool • Flood, open source from and for Apache• WAPT, Web Application Testing tool, a commercial product, for Windows • WatchMouse, commercial hosted load testing service • WebKing, commercial, multiplatform • WebServer Stress Tool, commercial and free, from Paessler


Herramientas: Subversion / GIT

• Herramienta de control de versiones y repositorio de código fuente.

• Sistema centralizado.

• Gestión de históricos de los cambios realizados sobre los ficheros.

• Facilita la ramificación de los proyectos.

• Permite etiquetar los proyectos y su versionamiento.


Maven

• Herramienta para la gestión y construcción de aplicaciones.

• Facilita la gestión del ciclo de construcción de proyectos software.

• Permite la reutilización de la lógica de construcción.

• Gestión de librerías y dependencias entre módulos y proyectos.

• Gran cantidad de plugins disponibles.


Nexus

• Sistema de control y almacenamiento de librerías o artefactos.

• Permite centralizar en un único punto la gestión de las dependencias.

• Sirve como repositorio donde instalar los artefactos generados por los proyectos.

• Permite versionado de artefactos.

• Gestiona los dos estados de desarrollo de un artefacto (snapshot y release).


Nexus


Jenkins

• Herramienta de integración continua.

• Identifica las distintas tareas en jobs.

• Mantiene un histórico de la ejecución y el resultado de los mismos.

• Los jobs son altamente configurables, permitiendo lanzar desde compilaciones de aplicaciones java, android, iOs, hasta

deploys contra servidores de aplicaciones.

• Notifica a los afectados en caso de eventualidades.

• Monitorización de resultados.

• Enorme cantidad de plugins disponible.


Jenkins

¿Por qué Jenkins?

• Fácil de instalar, fácil de actualizar y fácil de configurar• Construcciones distribuidas , probablemente la funcionalidad más potente• Monitorización de Jobs externos• No existe un limite de Jobs o de número de esclavos• Arquitectura de plugins• Provee acceso remoto a sus funcionalidades.• Posee una gran cantidad de plugins.


Jenkins


SonarQube

• Herramienta utilizada para evaluar la calidad del software.

• Recopila, analiza y permite visualizar las métricas de la calidad del software.

• Realiza análisis estático del código en función de unas reglas configurables y ampliables.

• Nos permite conocer el porcentaje de cumplimiento de las reglas en los proyectos.

• Monitoriza la evolución de la calidad.


SonarQube


Preguntas


Indice



Demo

• Test Funcional con Selenium• Uso de Selenium Grid• Tarea Jenkins• Informes Generados


Práctica ejercicios Testing

https://github.com/joseripla/uvtesting


Preguntas

[email protected]

© 2016 Capgemini. All rights reserved.

Acerca de CapgeminiCon alrededor de 120.000 empleados en 40 países, Capgemini es uno de los principales líderes en

servicios de consultoría, tecnología y outsourcing del mundo. El Grupo Capgemini ha alcanzado unos

ingresos globales de 9.700 millones de euros en 2011.

Capgemini en colaboración con sus clientes, crea y proporciona las soluciones tecnológicas y de

negocio que mejor se ajustan a sus necesidades y que conducen a alcanzar los resultados deseados.

Siendo una organización profundamente multicultural, Capgemini ha desarrollado su propia forma

de trabajar, la Collaborative Business Experience TM, basada en su modelo de producción Rightshore

®.

Para más información: www.es.capgemini.com

Rightshore®

is a trademark belonging to Capgemini

Testing e Integración Contínua - uv.es + IC.pdf · • El objetivo final de este tipo de tests es...

Documents

Transcript of Testing e Integración Contínua - uv.es + IC.pdf · • El objetivo final de este tipo de tests es...