miércoles, 8 de noviembre de 2017

Trabajando en un equipo distribuido

Cuando en nuestro primer trabajo en sistemas nos comentaron que el proyecto al que íbamos a ser asignados implicaba formar parte de un equipo distribuido, parte en Argentina, parte en Estados Unidos, nos vimos atrapados en una mezcla de temor y felicidad. Es recurrente en nuestra profesión escuchar de otros colegas frases tan dispares como: “es muy dinámico y te abre la cabeza trabajar con gente de afuera”, “la diferencia horaria me mata”, “siempre estás trabajando con lo último en tecnologías”, etc.

En este texto, buscaremos plasmar nuestra experiencia sobre la aventura, con sus desafíos y oportunidades, de trabajar en un equipo distribuido geográficamente.

Desafíos

Sin lugar a dudas, el hecho de trabajar con un equipo que, no sólo no se encuentra en el espacio físico de trabajo de uno, sino que está a casi a un continente de distancia, trae interesantes desafíos que uno debe superar y con los que debe aprender a convivir para poder alcanzar los objetivos planteados en el proyecto.

Uno de los mayores retos a sortear, y con el que nos enfrentamos diariamente, es la comunicación, ya que no tenemos la posibilidad de hablar cara a cara con el cliente para entender qué es lo que quiere y cómo lo quiere. Para mitigar este problema, utilizamos varias herramientas para comunicarnos con el resto del equipo como Slack, Skype y Yammer, que ayudan de gran manera a superar este obstáculo. Sin embargo, hay varios inconvenientes que surgen, como por ejemplo, el estar condicionado al tiempo de respuesta de la otra persona. Uno realiza una pregunta por alguno de estos canales y no puede seguir avanzando hasta que le respondan y esto puede demorar minutos, horas y hasta días, por lo que la paciencia es fundamental.

Otra barrera a superar es la del idioma. Uno no sólo debe pensar cómo decir lo que quiere decir, sino que tiene que hacerlo en un idioma que no es el nativo. Además, no es solo el hecho de hablar o escribir en inglés, sino también escuchar, entender e interpretar lo que la otra persona quiere decir, lo cual muchas veces no es tan sencillo. Todo esto le agrega una complejidad extra al trabajo, no por ello menos placentero.

Por otro lado, nos encontramos con la diferencia horaria que hay entre Argentina y Estados Unidos. Muchas veces uno hace una pregunta a las 10 de la mañana y tiene que pensar que allá son las 8 de la mañana y recién están llegando a sus puestos laborales, por lo cual van a tardar en responder la consulta. 

Otra situación que se da muy seguido es que el mayor nivel de actividad se da cuando acá son las 5 o 6 de la tarde, por lo que muchas de las consultas que nos hacen son en ese momento y recién las vemos al otro día. En este caso, el inconveniente de comunicación que comentamos anteriormente sucede para ambas partes.

Beneficios

Como contracara de lo mencionado anteriormente, hay muchas cosas positivas que rescatar de la experiencia de trabajar con un equipo de Estados Unidos. Lo primero que se nos viene a la mente, sin dudas, es el idioma que, si bien es una de las barreras, el hecho de estar hablando y aprendiendo constantemente en inglés nos ayuda a ponerlo en práctica y perfeccionarlo. 

A su vez, uno aprende muchísimo sobre sus costumbres y la forma en que se desempeñan y viven el día a día. 

Para sorpresa nuestra son bastante liberales y honestos a la hora de comunicarse. Es normal encontrarse con situaciones que acá uno consideraría extrañas como que se vayan de la oficina porque tienen que practicar algún instrumento,  asistir a un evento que realiza la ciudad donde viven o ir a  plantar árboles junto con alguna organización que ayuda al medioambiente. Estas situaciones, que nosotros organizaríamos para  otro momento ,ellos no tienen problema en blanquearlas y hacerlas durante la hora de trabajo, muchas veces avisando en el momento. 

También es destacable e interesante la visión vanguardista que tienen del mundo. Para citar un ejemplo de esto, el proyecto se trata de un sistema de alquiler de bicicletas como el que presta el Gobierno de la Ciudad de Buenos Aires en Argentina, con la pequeña diferencia de que las estaciones donde se guardan las bicicletas tienen paneles solares con los que recargan las baterías de las mismas. Además, las bicicletas cuentan con una pantalla táctil con la cual pueden elegir el destino al cual quieren ir y un sistema les marca el mejor camino para llegar. Con esto se puede ver que, no sólo están pensando en facilitar y hacer placentera la experiencia del usuario, sino que también tratan de cuidar el medioambiente.

Por último, siempre intentan utilizar nuevas tecnologías o nuevas versiones de las ya existentes con lo cual uno tiene la posibilidad de aprender acerca de estas nuevas herramientas y estar permanentemente actualizado.

Más allá de los desafíos que hay que superar todos los días, consideramos la experiencia en general como muy positiva y placentera. Es ampliamente recomendable incursionar en el mundo del trabajo con equipos distribuidos ya que nos permite crecer tanto en aspecto profesionales como sociales y culturales.


Marcos Caccavaio – Desarrollador .NET
Mauro Corvaro - Desarrollador .NET

jueves, 26 de octubre de 2017

Monitoreo de aplicaciones con Azure Application Insights

¿En algún momento te preguntaste si lo que desarrollaste se usa y cómo se usa? ¿Se te ocurrió qué podría mejorarse, pero no sabés por dónde empezar? ¿Tu aplicación falla, se detiene y no sabés dónde ni por qué?


Tenemos la solución a todas tus preguntas: Azure Application Insights



Esta herramienta de Azure permite recolectar un sin fin de información sobre tu aplicación web y luego generar reportes a partir de los datos obtenidos. Particularmente, Application Insights puede obtener información de todas las capas de la aplicación, desde errores de JavaScript hasta de performance de queries SQL.





Bajando a un nivel más detallado, puede monitorear:

- Tiempos de respuesta de requests, generando a partir de esto, por ejemplo, reportes estadísticos sobre páginas más populares dentro de la aplicación o menos performantes.
- Tiempos de respuesta de servicios externos, logueandotambiénerrores.
- Excepciones, al punto de mostrarnos en que línea de nuestro servicio se dio el error.
- Performance counters del servidor, ya sea Windows o Linux (CPU, memoria, network).
- Cantidad de usuarios conectados, incluyendo su localización geográfica por región o país.
- Eventos custom que uno puede lanzar, en el cliente o servidor de la aplicación.


A partir de la información recolectada anteriormente, Application Insights nos genera en vivo reportes o gráficos que nos pueden ayudar a diagnosticar problemas de performance o errores en producción. 



















Supongamos que tenemos un error de timeout reportado por un usuario en producción, muy difícil de recrear en un ambiente de pruebas, ya sea por falta de volumen de datos o de concurrencia.  La información recolectada nos permite investigar los movimientos realizados por el usuario. Los mismos van desde eventos JavaScript, su paso por la capa de servicios, hasta queries SQL ejecutadas, incluyendo excepciones y tiempos de respuesta, permitiéndonos diagnosticar o darnos una idea de dónde puede estar el problema. 

Monitorea mucha información por default. También se puede agregar información custom fácilmente, e incluso, se puede instalar un componente en el servidor para obtener más información, siendo esto último opcional.


Seguro estás llegando a la siguiente conclusión: esto es solo para aplicaciones alojadas en Azure y, siendo de Microsoft, es solo para apps .NET de Microsoft. Pero no, no es sólo para aplicaciones .NET ni tampoco es necesario que se encuentre alojada en los servidores Azure, ya que lo único que se necesita es una key que la identifique y unas sentencias en JavaScript que envían la información y la key a una URL específica. 



Así que, si tu app web tiene conexión a internet, puede enviar la información a loguear sin problemas y, aunque requiere una suscripción de Azure, se puede recabar hasta una cantidad máxima de información mensual de forma totalmente gratuita.



En conclusión, podemos decir que proponemos Applications Insights porque lo hemos usado en muchos proyectos, propios y para clientes y nos ha sido de gran utilidad para:

Mejorar la performance y detectar errores productivos “aleatorios” reportados insistentemente por los usuarios. 
Saber si los issues reportados se condicen con lo que realmente sucedió.
Informarnos que es lo que sucede con los proyectos que creamos.


Application Insights, según Microsoft, no miente.




Autores:

Alejandro Olivera .Net Dev SSr
Verónica Bo .Net Technical Expert 

miércoles, 11 de octubre de 2017

Negociación (Parte I) - Hablando se entiende la gente

Vivimos en un mundo de negociaciones. En casa negociamos continuamente con nuestra pareja, hijos, padres y hasta con las mascotas. En el trabajo negociamos con jefes, colaboradores, colegas, clientes y proveedores. Estamos compelidos a negociar y, a veces, hasta lo hacemos sin darnos cuenta, dedicándole gran parte de nuestro día. No hay forma de escapar.

La habilidad para negociar se vuelve cada vez más importante y hasta fundamental a medida que se avanza en la carrera profesional. Es inconcebible pensar en un líder de proyecto, jefe o gerente sin esta característica. Entonces, todo aquel que quiera progresar en su carrera laboral y no haya pulido sus habilidades de negociación deberá concentrarse en hacerlo. Pero, ¡a no desesperar! Como casi todo en la vida, se puede aprender.

Empecemos por las bases: ¿qué es una negociación? Podemos entenderla como una comunicación entre dos partes para llegar a acuerdos. Esas partes pueden ser empresas, equipos de trabajo, naciones, etc, pero siempre terminará llevándose a cabo por personas.

Si acordamos en la definición anterior, propongo ahora que reflexionemos un poco. ¿Cuántas veces al día tomamos una decisión “en solitario”? En lo personal, es raro para mí tomar alguna decisión sin coordinar al menos con mis compañeros. Cada día más la toma de decisiones se hace en función de las negociaciones llevadas adelante.

Ahora bien, al momento de negociar suele plantearse un dilema: ¿negociamos “fuerte” o “suave”?

Si decidimos negociar “fuerte” veremos a nuestra contraparte como adversarios, el objetivo de la negociación será la victoria, mantendremos una posición rígida, seremos intransigentes, desconfiaremos de la otra parte y trataremos por todos los medios de ganar la confrontación.

Si decidimos negociar “suave”, veremos a nuestra contraparte como colegas y el objetivo de la negociación será llegar a un acuerdo. Para ello mantendremos una posición flexible, haremos ofertas y concesiones, confiaremos en la otra parte y trataremos por todos los medios de evitar la confrontación.

Gente que ha estudiado cómo se comportan los negociadores expertos ha notado que no suelen utilizar ninguno de estos dos enfoques. Este tercer punto de vista que suelen utilizar los expertos no es un punto medio entro los otros dos, sino que toma elementos de cada uno de ellos. En general, los negociadores expertos son “suaves” con la gente y “fuertes” con el problema que se necesita resolver. 

Ser “suave” con la gente significa que no hay que olvidar jamás que nuestra contraparte es inherentemente una persona y que, como persona, debemos tener el cuidado y respeto que merece. Así mismo, debemos entender que cada individuo tiene una forma de ser, de expresarse,de entender la realidad ysus propios valores. Por otra parte, ser “fuerte” con el problema significa que hay que abordarlos con seriedad y no perder el foco de qué es lo que queremos solucionar.

En la segunda parte de esta nota veremos las etapas que tiene una negociación. 

Autor
Ing. Leo Viegas
Desarrollador

miércoles, 2 de agosto de 2017

Nadie hace las cosas como las hago yo

¿Nunca te encontraste diciendo esa frase o alguna parecida? Creo que todos en algún momento la hemos dicho. Yo lo hice y lo confieso. Pero delegar cierto trabajo en un colaborador es una de las piedras angulares del trabajo en equipo. Como muchas cosas, delegar no es algo muy complejo: es pedirle a alguien que haga algo. Pero para delegar de manera efectiva, es importante tener en cuenta algunas cuestiones que, en mayor o menor medida, para algunos pueden resultar intuitivas.

El primer punto a tener en cuenta para delegar de manera efectiva es que hay más de una manera de hacer las cosas bien. Se le adjudica a Voltaire la frase “Lo perfecto es enemigo de lo bueno”, lo que quiere decir que es preferible hacer algo lo suficientemente bien para que cumpla con lo establecido en un tiempo razonable que hacer algo perfecto, dedicándole un tiempo desmesurado. Yo digo que, como muchas cosas de la vida, hay que encontrar un balance. Podría ser verdad que si vos hicieras una tarea en lugar de delegarla, la harías mejor. Pero tomate un tiempo para reflexionar si es realmente necesario que la hagas vos o si alguno de tus colaboradores podría hacerla suficientemente bien mientras vos te dedicás a hacer alguna otra cosa (que probablemente tus colaboradores no podrían hacer). Se observa a primera vista, entonces, que el comienzo de todo se asienta en decidir qué tareas delegar y a quién delegarlas.

Para decidir cuáles tareas delegar y cuáles no, hay que pensar en la complejidad de la misma, en la confianza que le tenemos al colaborador y en la motivación de éste. Podemos hacer un análisis simple respondiendo dos preguntas:

  • ¿Confío en la capacidad de mi colaborador para realizar la tarea? (aquí es donde la complejidad del trabajo se vuelve relevante)
  • ¿Está motivado para realizar la tarea?

Cada una de estas preguntas puede responderse por sí o por no, lo que nos deja cuatro opciones:

  • Sí confío, sí está motivado: se puede delegar sin mayores problemas.
  • Sí confío, no está motivado: se puede delegar pero es importante que se aclaren las expectativas y los plazos de cumplimiento.
  • No confío, sí está motivado: se puede delegar y aprovechar para capacitar al colaborador. Deberá hacerse un seguimiento o asignar a otra persona con más experiencia como un supervisor. Este escenario debe tomarse como una oportunidad.
  • No confío, no está motivado: no se debe delegar la tarea. También este escenario puede tomarse como una oportunidad para trabajar, si es necesario, sobre las aristas que hacen que el colaborador no sea elegible para la tarea en particular.

El segundo punto a tener en cuenta para delegar de manera efectiva es la correcta comunicación de la tarea que vas a encargar. Para ver claramente este punto, lo mejor es un ejemplo. Supongamos que, cerrando una reunión del equipo de trabajo, el líder hace el siguiente pedido: “Por favor que alguien me envíe un mail con el resumen de la reunión”

…entonces nadie manda ningún mail. ¡En serio! A nadie se le pidió puntualmente que lo haga.

Regla 1: Indicar inequívocamente quien es el encargado de la tarea.

Aplicando la regla 1: “Cosme Fulanito, por favor enviame un mail con el resumen de la reunión”.

…entonces Cosme Fulanito no manda nada, porque no se le indicó cuándo debía enviar el mail.

Regla 2: Indicar cuándo realizar la tarea y para cuándo se espera que esté terminada. Podría en este punto en particular entablarse una negociación con el colaborador.

Aplicando la regla 2: “Cosme Fulanito, por favor enviame un mail en la próxima hora con el resumen de la reunión”.

…entonces Cosme Fulanito envía un mail con una sola línea: “Todos nos pusimos de acuerdo en los temas tratados.”

Regla 3: Detallar los alcances de la tarea.

Aplicando la regla 3: “Cosme Fulanito, por favor enviame un mail en la próxima hora con el resumen de la reunión detallando cada uno de los temas tratados”.

…entonces Cosme Fulanito manda un mail en cuyo cuerpo detalla todo el contenido de la reunión.

Regla 4: Explicar el contexto de la tarea.

Aplicando la regla 4: “Cosme Fulanito, por favor enviame un mail en la próxima hora con el resumen de la reunión utilizando el template formal y detallando cada uno de los temas tratados para que yo se lo reenvíe al cliente”.

…entonces Cosme Fulanito hace la tarea de acuerdo a las expectativas del líder.

El tercer punto a tener en cuenta, para delegar de manera efectiva, es poder determinar el grado de libertad que se le dará al colaborador para realizar la tarea. Una posible escala para medir esto podría ser la siguiente:

  1. Hacé la tarea exactamente como te lo indico.
  2. Investigá y decime qué opciones encontraste para hacer la tarea.
  3. Evaluá y haceme una recomendación para que yo decida.
  4. Evaluá y decidí, pero infórmame antes.
  5. Hacé de acuerdo a tu criterio.

Podría haber otras escalas intermedias, pero lo importante es que se entienda el concepto. No a todos nuestros colaboradores podemos darles el mismo grado de libertad. A mayor capacidad y experiencia, también aumenta la autoridad que puede delegarse al colaborador. Esta decisión es importante porque incide directamente en su motivación.

Por último, quiero agregar algo que aprendí por las malas: La responsabilidad no se delega. Esto significa que aunque la tarea sea realizada por un colaborador, la responsabilidad de su ejecución siempre es del líder del equipo. Este es quien tendrá que dar explicaciones en el caso de que haya algún incumplimiento. Lo que se delega entonces, es la autoridad para tomar ciertas decisiones de acuerdo al grado de libertad que se le otorgue.

Delegar no es complicado. Lo importante es animarse y no empezar el primer día tomando decisiones arriesgadas. Cuando se comienzan a ver los primeros resultados positivos de la delegación se pueden empezar a arriesgar un poco más. El proceso de aprendizaje se va dando en el tiempo con la práctica.

Autor
Ing. Leo Viegas
Desarrollador

miércoles, 12 de julio de 2017

Pruebas de humo o smoke test

Las pruebas de humo, también conocidas como “smoke test”, permiten evaluar en un período relativamente corto la operatividad de un sistema o componente, con el objetivo de asegurar que las funciones importantes de un programa se ejecutan sin inconvenientes.
A través de este conjunto de pruebas, puede verificarse si ciertos caminos de la aplicación funcionan correctamente. Para ello, normalmente se elige un grupo de funcionalidades significativas de la aplicación sin detenerse a verificar íntegramente a todas, asegurándonos de que el comportamiento sea el esperado. 
En caso de que las pruebas no hayan corrido satisfactoriamente, procederemos a reportar los defectos encontrados y el área de Desarrollo los arreglará, dándonos una nueva versión sobre la que nuevamente ejecutaremos el smoke test. Repetiremos este procedimiento hasta que la misma se encuentre estable y lista para comenzar con la ejecución del plan de pruebas diseñado previamente.

A continuación, un ejemplo de smoke test

Supongamos que una universidad utiliza una aplicación que administra todos los registros de sus estudiantes y la misma cuenta con quince módulos, de los cuales cuatro componentes son los más importantes: la página de inicio de sesión, la adición de detalles de los estudiantes, su actualización y, por último, la eliminación de la misma. Como parte de las pruebas de humo vamos a probar la página de inicio de sesión con una entrada válida, después de la conexión se pondrá a prueba la adición, actualización y borrado de registros. Si los cuatro componentes críticos funcionan bien, entonces la construcción es lo suficientemente estable como para proceder con la prueba detallada. 

Principales ventajas de las pruebas de humo:
  • Ayudan a detectar los errores en las primeras etapas de la prueba. 
  • Permiten verificar que los problemas corregidos en la versión anterior NO estén impactando en las principales funcionalidades de la aplicación.
  • Se requiere un número muy limitado de casos de prueba para llevarla adelante. 
  • Las pruebas de humo pueden llevarse a cabo en poco tiempo.

Aún así, estos tests presentan algunas pocas desventajas que vale la pena mencionar:   
  • No realiza una prueba detallada de la aplicación.
  • Al ser una prueba no exhaustiva, no seremos capaces de encontrar todos los otros problemas críticos en la aplicación.

En conclusión, el uso del smoke test contribuye a validar la estabilidad de la entrega y nos permite detectar errores en las funcionalidades críticas de forma temprana. De esta manera si los resultados no son los esperados entonces no vale la pena realizar un esfuerzo mayor ejecutando pruebas más complejas. 
Además, el tiempo invertido para la realización de esta prueba tiene un impacto mínimo en la planificación del ciclo de vida de pruebas.

Autor:
Germán Gustavo Molina
Analista de Testing

miércoles, 28 de junio de 2017

Recomendaciones para un mejor assessment de testing

El objetivo del assessment de testing es analizar la situación actual del área, identificando sus fortalezas y las posibilidades de aplicar mejoras. En esta instancia, se evalúan distintos procesos hasta llegar a definir el estado de madurez actual. 
Antes de profundizar en el tema, quiero destacar la importancia de buscar la mejor manera de hacer el relevamiento de información sin impactar en la ejecución de las actividades del día a día de los equipos de la organización.
Actualmente, hay herramientas como las encuestas online que representan una forma sencilla de relevar la información. A continuación, les menciono algunas:
Survio
Survey Monkey
Google Drive
Zoho Survey

En mi experiencia en assesstments, utilicé Survey Monkey. Muy completa para el seguimiento de la encuesta, correos, URL personalizada, múltiples opciones del generador de preguntas, páginas de agradecimiento, descarga de informes, datos, etc.



Así como la herramienta a utilizar va a disminuir los tiempos del proceso, también es importante la planificación de las distintas etapas para el relevamiento efectivo de información. De esta forma, podremos evaluar de manera organizada plasmando la situación actual y proponiendo la solución más acorde a la necesidad del cliente, las buenas prácticas y nuestra experiencia.

Las etapas del assessment son:

- Setup – Inicio
- Relevamiento previo
- Assessment AS - IS
- Modelo TO - BE
- Cierre

Para el análisis del área y sus procesos, nos basamos en la metodología de TPI (Test Process Improvement), que asiste en las mejoras de los procesos de pruebas dentro de la organización y permite establecer pasos de mejoras controlables y graduables definidas por niveles. Su creador es la empresa SOGETI.

Para asegurar la clasificación objetiva de los niveles, se deben definir puntos de verificación, llamados dimensiones, que representan los aspectos principales que forman esa práctica o área de IT.

Las dimensiones a evaluar son las siguientes:

1. Estrategias y políticas de pruebas.
2. Estimación y planificación. 
3. Diseño y ejecución de los casos de prueba
4. Pruebas no funcionales.
5. Gestión y preparación de datos de prueba.
6. Herramientas de pruebas y la automatización.
7. Gestión de procesos de prueba.
8. Métricas de gestión de procesos de prueba y reportes.
9. Gestión de defectos.
10. Gestión de la documentación.
11. Organización de las pruebas.
12. Entorno de prueba.
13. Compromiso de las otras áreas.
14. Profesionalismo.
15. Comunicación.
16. Metodología de prueba.
17. Grado de participación de prueba.

El enfoque de las preguntas para cada dimensión fue obtener respuestas cerradas, de selección simple, múltiples y, en algunos casos, que pudieran incluir comentarios.

Ejemplo de preguntas:





Al relevamiento de información se lo debe dividir en 2 fases:
Relevamiento por encuestas online
Relevamiento de aspectos a profundizar (entrevista personalizada en un tiempo reducido con el responsable del proceso que se requiere mayor información).

¿Qué beneficios podemos obtener de este método?
Reducción de tiempo de parte del cliente en suministrar la información
Recopilación de manera organizada
Visión clara del estado de la madurez del cliente 
Identificar los puntos fuertes del cliente 
Focalizar el esfuerzo en aplicar las mejoras a los procesos necesarios

Es importante profundizar en esta etapa ya que nos va a permitir identificar la situación actual de la organización y, de acuerdo a las necesidades, plantearemos las mejoras al área de testing y las posibles propuestas a otras áreas por la necesidad de desarrollo de un modelo de ciclo de vida de pruebas efectivo.
En el próximo artículo, trataremos la mejor forma de armar el informe de la situación actual (AS-IS) y como plantear las mejoras (TO – BE).

Links:
https://es.surveymonkey.com/
http://www.tmap.net/around-tmap

Autor:
Alvaro Guaramato
QA Technical Expert
ISTQB® Certified Tester, Foundation Level

miércoles, 21 de junio de 2017

Pruebas de Nivel 2

En el mundo de las pruebas de software existen muchas maneras de clasificar o agrupar los tipos de pruebas, ya que el ámbito o destino de las mismas puede variar. Una de las maneras de realizar dicha clasificación es por Niveles, entonces ¿Que son las pruebas por nivel?, ¿De qué se tratan?


Lo primero que debemos saber es que las Pruebas de Nivel son un grupo de actividades de pruebas que están organizadas y gestionadas conjuntamente. Un nivel de pruebas siempre está conectado a las distintas etapas del proceso de desarrollo.

Existen 3 niveles: 

Nivel 1 - Pruebas Unitarias (Un módulo único): Verifican el funcionamiento aislado de piezas de software que pueden ser probadas de forma separada.

Nivel 2 - Pruebas de Integración (Un Grupo de módulos): Verifican la interacción entre componentes del sistema de software.

Nivel 3 - Pruebas de Sistemas (Un sistema complejo): Verifican el comportamiento del sistema en su conjunto. 


Elaborado por: Lili Ayala


Ahondar en el nivel dos de pruebas es la finalidad de este artículo por lo que detallemos un poco más sobre el mismo.

Las pruebas de integración se basan típicamente en el diseño del sistema, la arquitectura, los flujos de trabajo, los casos de uso, los esquemas de la base de datos y los flujos de datos, si se realizaran pruebas basadas en los riesgos se utilizarían adicionalmente los riesgos de calidad para guiar las pruebas.

Dichas pruebas pueden incluir varios tipos de pruebas (Ej. Funcionalidad, utilización de recursos, rendimiento, etc.). Estas pueden incluir las pruebas estructurales como los flujos de llamadas y los flujos de datos.

El ítem sometido a prueba es una colección de unidades (o componentes) a menudo referida como una “construcción”. Estas construcciones pueden incluir una implementación de la base de datos de un subsistema, una infraestructura, interfaces, una configuración del sistema y datos de configuración. La selección de las unidades o los componentes, para que sean incluidos una construcción, es influenciada por el hecho de que las pruebas de integración consisten en probar las interfaces entre los componentes, las interacciones con diferentes partes de un sistema (como el sistema operativo, el sistema de archivos y el hardware), y las interfaces entre las unidades, componentes o sistemas.

Al igual que las pruebas unitarias o componente, las pruebas de integración requieren con frecuencia arneses y herramientas, debido a que las construcciones no son siempre independientes y comprobables. Estos arneses pueden actuar en el nivel de la interfaz de programación de aplicaciones (API). También pueden estar en el nivel de la interfaz de línea de comandos. A veces, si estamos probando en la interfaz de usuario, las herramientas de interfaz gráfica de usuario son útiles, pero eso es algo raro. Hay herramientas tanto gratuitas como comerciales necesarias para las pruebas de integración.

Existen principalmente dos tipos de integración: La integración incremental y la no incremental. La integración incremental consiste en combinar el conjunto de módulos ya probados (al principio será un conjunto vacío) con los siguientes módulos a probar. Luego se va incrementando progresivamente el número de módulos unidos hasta que se forma el sistema completo. En la integración no incremental o Big Bang se combinan todos los módulos de una vez. 

Para ambos tipos de integración se deberán preparar los datos de prueba junto con los resultados esperados. Esta tarea debe ser realizada por personas ajenas a la programación de los módulos. No es necesario que la lleven a cabo una vez codificados los módulos puesto que basta con conocer qué módulos compondrán el sistema y cuál será la interfaz entre ellos.

En cuanto a quien es el responsable, tanto los probadores como los programadores colaboran idealmente. Desafortunadamente, a menudo nadie es responsable. Los probadores nos siempre tienen las habilidades técnicas necesarias para diseñas y ejecutar las pruebas de integración, y a los programadores no siempre se les da el tiempo y la indicación para ayudar. Esto da lugar a muchas dificultades durante las primeras semanas de las pruebas del sistema, debido a que la primera parte del periodo de ejecución de la prueba del sistema se convierte de hecho en una prueba de integración big-bang (Tipo de prueba de integración en el que los elementos software, elementos hardware o ambos son combinados de forma simultánea en un componente o un sistema global en lugar de hacerlo por fases.).

Finalmente, las pruebas de integración son particularmente complejas, ejemplo de ello podrían ser los sistemas que han sido desarrollados por diferentes organizaciones e incluso en diferentes periodos de tiempo, con tecnologías e interfaces diferentes y tal vez no completamente compatibles, lo cual hace que los cambios en los sistemas sean al mismo tiempo más peligrosos. 

Por situaciones como la antes expuesta, es de vital importancia contemplar las pruebas de nivel dos al momento de plantearse la estrategia de pruebas para los proyectos de desarrollo de software, muchas veces son omitidas o no se les da la relevancia que tienen por la utopía o el peso que tienen las pruebas de sistemas.

Referencias externas:

· Descarga del Syllabus del ISTQB (2011, International Software Testing Qualification Boards).

Autor:
Amlivledif Rivero
QA Technical Expert
ISTQB® Certified Tester, Foundation Level