Guía Esencial

Navegue en las secciones

BACKGROUND IMAGE: iSTOCK/GETTY IMAGES

Este contenido es parte de Guía Esencial: Guía esencial de desarrollo de aplicaciones corporativas
Evaluar Conozca los pros y contras de las tecnologías, productos y proyectos que está considerando.

Integración en la nube: desafío para quienes evalúan desarrollos de apps

Las dependencias entre sistemas y aplicaciones pueden complicar las pruebas hasta el punto de detener o renunciar por completo al desarrollo.

Los desarrolladores de software tienen más opciones de tecnología de integración de nube que nunca antes. Sin embargo, las dependencias entre los sistemas y las aplicaciones pueden complicar las pruebas de integración hasta el punto en que los vendedores y organizaciones de desarrollo lo detengan o renuncien por completo. Ningún enfoque es práctico para las organizaciones que desean evitar costosas reparaciones.


"La evaluación de integración es una función regular de software y problemas de calidad en el sentido tradicional, donde se utiliza algo y ese "algo" consiste de muchos componentes creados por muchas personas", dijo James Bach, consultor principal para Satisfice, Inc. "Y es un nuevo reto, ya que hay muchos nuevos componentes interesantes por ahí que representan un desafío real para las pruebas". Aunque las tecnologías y aplicaciones basadas en la nube presentan nuevas oportunidades de integración, también presentan "retos de tecnología y negocios a los que la gente tal vez no esté acostumbrada", dijo Andrew C. Oliver, presidente de Integradores de Software Abierto (Open Software Integrators, LLC).

"Si usted está uniendo un montón de diferentes servicios –Google Maps, Twitter, etc. – algunos de ellos no son gratuitos. Tienen diversas cargas con base en los diferentes usos que se les dan. Usted tendrá que hacer los cálculos de negocio en un principio para averiguar si lo que está haciendo es viable y asegurarse de que puede conseguir los acuerdos de nivel de servicio (SLA) que necesita", dijo. Mientras que el uso y los SLA representan un conjunto de problemas, la disponibilidad representa otro.

"Si una empresa asume que la nube siempre estará ahí, y si se asume que todo el mundo está conectado todo el tiempo, cuando las conexiones bajen puede tener un efecto catastrófico", dijo Bach, de Satisfice. Por ejemplo, algunas aplicaciones, como Evernote, suponen que el usuario está siempre en línea. "Cuando no se está conectado, no se puede acceder a ninguna de sus notas. Todo está en la nube –y sólo en la nube." Realizar pruebas en la nube con una gran cantidad de dispositivos y aplicaciones representa un gran desafío para la comunidad de evaluadores, de acuerdo con Bach. "Es un gran desafío, y el mundo de los encargados de realizar las pruebas se rasca la cabeza, porque no sabemos cómo probar un entorno de nube simulada para que podamos estar seguros de que veremos en la prueba cualquier error que pudiera surgir en la vida real", dijo.

Lisa Crispin, evaluadora para el servicio Fast401k de  ePlan Services, Inc. y co-autora de Agile Testing: Una guía práctica para evaluadores y equipos ágiles, coincide con Bach. "Con grandes aplicaciones como las redes sociales y cosas así, es difícil de probar todo lo que millones de personas podrían hacer", opinó.

A pesar de que las pruebas de integración pueden ser más complicadas, "hay una fuerza que está facilitando las pruebas de integración –empujándola en la dirección opuesta", dijo Bach. "Las personas tienen estándares más bajos." Nos hemos acostumbrado a las llamadas telefónicas que se caen o al retraso de un segundo que se produce cuando se cambia el canal de televisión. Este tipo de problemas de rendimiento solían ser raros, pero se han vuelto más frecuentes y nos hemos acostumbrado a ellos, dijo.

Como resultado, algunos desarrolladores de software asumen menos responsabilidad sobre el desempeño de su producto. "Desafortunadamente, cuando menciono los riesgos de liberar tecnología basada en diferentes sistemas que tienen que trabajar juntos y mantenerse sincronizados, un montón de gente se encoge de hombros y dice: ‘Oh, bueno, algunas cosas saldrán mal. La gente sólo tendrá que reiniciar o intentarlo de nuevo más tarde’", expresó Bach. Es con esa actitud que algunas organizaciones lanzan aplicaciones a producción sin pruebas formales de integración. En vez de eso, esperan a que los usuarios hagan las pruebas. "Ellos simplemente colocan las aplicaciones y tratan de jalar el dinero antes de que empiecen los problemas. Y si tienen que retirarla, no hay problema. Simplemente liberan nuevamente la aplicación con sus actualizaciones", dijo Bach. "Se puede mejorar tan rápido, que no es necesario probar."

Y eso nos lleva a otro problema asociado con las pruebas de integración: el tiempo. "A veces la gente piensa en las pruebas después de desarrollar el software, pero entonces no tienen tiempo para hacer las pruebas", dijo Crispin de ePlan Services. Las pruebas de regresión automatizada pueden ayudar, pero todavía puede tomar mucho tiempo ejecutar las pruebas en grandes sistemas. Algunas organizaciones deciden liberar el sistema aun cuando están ejecutando la prueba de regresión, y monitorear la aplicación mientras esperan los resultados, dijo. Para evitar estos problemas, los expertos recomiendan no esperar hasta el último minuto. "Desarrolle las pruebas en paralelo con el software. Haga sus pruebas de integración temprana y las pruebas de carga previamente. No intente hacer todo al mismo tiempo al final de alguna fase de la cascada del proyecto. Ese es el momento más caro para solucionar los principales problemas de arquitectura", dijo Oliver de Open Software Integrators. Crispin cree que en las pruebas, como en todas las cosas, es importante planear. "Al iniciar un nuevo proyecto, diga: 'Bueno, estamos implementando esta función. Vamos a empezar a pensar sobre las pruebas de integración que necesitamos. ¿Qué otros sistemas se verán afectados? ¿Qué recursos necesitamos para hacer las pruebas? Luego, programe el tiempo en ese ambiente cuando crea que estará listo para ello", dijo. Por último, sea consciente de la necesidad de probar lo que está construyendo, mientras que lo está construyendo. "La primer cosa que le digo a la gente es que –en términos generales– no han pensado para nada en la capacidad de las pruebas. La capacidad de prueba es muy importante. No es suficiente saber cómo realizar las pruebas. No es suficiente tratar de hacer las pruebas. Ni siquiera es suficiente tener herramientas que le ayuden a hacer las pruebas. Tenemos que construir cada producto con la capacidad de las pruebas en mente", concluyó Bach, de Satisfice.  

Sobre el autor: Crystal Bedell es escritora independiente que se especializa en Seguridad de Tecnologías de Información, cómputo en la nube y redes. Puede ser contactada en cbedell@bedellcommunications.com.

Investigue más sobre Cloud computing (Computación en la nube)

Únase a la conversación

4 comentarios

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

Es importante probar las apps antes de liberarlas para ser usadas por los usuarios
Cancelar
Se trata de componentizar todos los escenarios de integracion y a su vez cada escenario tiene sus componentes por lo que cada funcionalidad es objeto de pruebas unitarias y luego pruebas en conjunto
Cancelar
El desarrollo de software se torna cada dia mas complejo sobre todo si consideramos la gran variedad de ambientes que demandan los usuarios (cloud, SaaS, BYOD,...) por lo que se deberán considerar otras opciones para atacar el problema. Cuidado porque la publicidad nos desorienta y en la realidad la mayoría de las herramientas actuales no resuelven el problema por sí solas.
Cancelar
No hacemos desarrollo solo usamos lo de los principales fabricantes (Microsoft, Linux) y de nuestros proveedores especificos (SAI Open, Envitech, Microcom, Waterlog, etc.)
Cancelar

- ANUNCIOS POR GOOGLE

Close