Informe técnico de negocios. Guía de supervivencia para realizar pruebas en aplicaciones modernas

Transcripción

1 Informe técnico de negocios Guía de supervivencia para realizar pruebas en aplicaciones modernas

2 Por qué modernizar las aplicaciones? De acuerdo con una encuesta de Forrester, los principales impulsores de negocios, después de los esfuerzos por modernizar las aplicaciones, son la agilidad del negocio, la innovación y el ahorro de costos. 1 En una época de expectativas inmediatas, una organización ágil, que puede cambiar rápidamente de dirección, es la que le permitirá tener éxito en los negocios en un mundo en rápida evolución. La innovación es la clave para acelerar el crecimiento y proporcionar diferenciación competitiva. En el caso de las aplicaciones de negocios, esto puede significar brindarles a los clientes los recursos que esperan de sus interacciones en redes sociales: más control sobre cómo se muestra el contenido, más interacción con la aplicación y con otras personas y más experiencias incorporadas como el video. Y todo esto debe realizarse a un ritmo rápido, mientras se optimiza para reducir los costos operativos y mejorar los procesos operacionales. Para cumplir con estas necesidades de negocios, la empresa ágil esta adoptando nuevas tecnologías y arquitecturas como la computación en nube, Web 2.0, aplicaciones compuestas y tecnologías móviles, así como nuevas metodologías como Agile y otros procesos de desarrollo iterativo. Estas importantes y nuevas iniciativas de TI pueden interrumpir los negocios, pero también pueden hacer que las pruebas funcionales sean un gran desafío para la organización de garantía de calidad (QA). Resumen ejecutivo En este informe aprenderá cómo los equipos de pruebas funcionales pueden enfrentar los desafíos que le presentan las nuevas iniciativas de TI. Los procesos de desarrollo iterativo como Agile incorporan la necesidad de realizar pruebas lo más pronto posible, con mayor rapidez y con menos documentación disponible acerca de la aplicación. Estos procesos iterativos han conducido a una creciente necesidad de realizar pruebas exploratorias, donde la prueba del diseño y de la ejecución se realizan al mismo tiempo. Las tecnologías de las aplicaciones nuevas, tales como las arquitecturas de aplicaciones compuestas, la computación en nube y las plataformas móviles, también aportan nuevos desafíos. Entre ellos, se incluye trabajar con nuevas herramientas, realizar pruebas en múltiples plataformas y dispositivos, hacer pruebas en la nube y en el lugar y aplicar pruebas de aplicaciones complejas con múltiples interfaces gráficas de usuario (GUI) y con capas de integración e intermediarios. Para enfrentar estos desafíos, los equipos de control de calidad deben cambiar la forma en que realizan las pruebas funcionales. Las mejores prácticas incluyen iniciar el proceso de prueba tan pronto como sea posible, incluso antes de que una aplicación esté lista para ser probada, mirando el panorama completo de lo que tendrá que ser probado e invirtiendo tiempo inicial para diseñar una estrategia eficaz de prueba lista para el cambio. Considere el uso de un marco de trabajo con componentes de prueba reutilizables, para que la creación y el mantenimiento de la prueba sea más eficiente. Implemente métodos de prueba manuales y modernos para eliminar las tareas repetitivas, propensas a errores de las pruebas manuales, y así facilitar una mejor comunicación. Encuentre nuevas oportunidades para automatizar las pruebas. Y para realizar pruebas más minuciosas de aplicaciones compuestas, siempre que sea posible, utilice la automatización para probar la capa que pertenece a la interfaz gráfica de usuario, la que no pertenece a ella y el proceso de extremo a extremo completo. Las iniciativas de TI significan dolores de cabeza para los equipos de pruebas La afluencia constante de tecnologías y procesos acarrea una mayor complejidad y exige ciclos de prueba más cortos. Un equipo de prueba desprevenido puede ser visto como un obstáculo para lograr la agilidad del negocio y reducir el tiempo de lanzamiento al mercado. Estas son algunas de las razones por las que las pruebas funcionales pueden ser particularmente difíciles para estas iniciativas de TI. Agile: Las organizaciones de TI están adoptando Agile, procesos híbridos y otros procesos de desarrollo de aplicaciones iterativas para acelerar el tiempo de lanzamiento al mercado y reducir los costos del cambio. Estos procesos proporcionan un mecanismo para incorporar los comentarios y minimizar el tiempo que se desperdicia en las fases de larga planificación. Los métodos de pruebas funcionales deben cambiar en consecuencia, para que no eliminen las ventajas de métodos como Agile y similares. Las pruebas deben realizarse lo antes posible en el ciclo de vida, a menudo, en paralelo con el desarrollo. En muchos casos, tanto los evaluadores como los desarrolladores participan en las pruebas en un esfuerzo de "manos a la obra" para mantener una iteración según el cronograma. Los evaluadores necesitan realizar su trabajo incluso si reciben documentación mínima sobre una aplicación y deben comunicar una descripción completa del defecto para facilitar la rápida corrección. Y a menudo necesitan probar aplicaciones y funciones parciales en lugar de una versión final completa. Estos desafíos generan una creciente necesidad de implementar prácticas tales como las pruebas exploratorias. Tras participar con los principales interesados para comprender los objetivos de negocios de una aplicación y sus casos de uso, los evaluadores deben utilizar sus conocimientos y habilidades, incluyendo la creatividad y el pensamiento crítico, para explorar rápidamente la aplicación y descubrir defectos. El principal beneficio de este tipo de pruebas es el ahorro de tiempo, tanto en la realización de las pruebas como en la reducción de los esfuerzos de documentación y de prueba de diseño. 2

3 Aplicaciones compuestas: La organización de control de calidad debe desarrollar habilidades y capacidades para probar aplicaciones modernas y compuestas con arquitecturas complejas, incluyendo interfaces gráficas de usuario ricas, capas de lógica de negocios que no pertenecen a la interfaz gráfica de usuario, servicios compartidos (a menudo basados en nuevas arquitecturas orientadas al servicio -SOA-) e integraciones de paquetes de aplicaciones. Es necesario validar no sólo los servicios y componentes que pertenecen y los que no pertenecen a la interfaz gráfica de usuario, sino también visualizar, validar e informar sobre un escenario de prueba integrada del proceso del negocio que atraviesa las múltiples capas de una aplicación compuesta. Sin embargo es más fácil decirlo que hacerlo a la hora de probar componentes que no pertenecen a la interfaz gráfica de usuario. Realizar pruebas en la interfaz gráfica de usuario de la aplicación implica esperar hasta una fase más avanzada del ciclo de vida de la aplicación y descubrir los errores cuando cuesta más corregirlos. Las pruebas en la interfaz gráfica de usuario podrían probar solo un subconjunto de la funcionalidad de la capa lógica, dejando defectos que serán descubiertos en otros lugares de la aplicación o cuando otra aplicación la ejecute. Y si acepta el reto de probar servicios y componentes que no pertenecen a la interfaz gráfica de usuario, podrá comprobar que sus herramientas de pruebas actuales no admiten las tecnologías necesarias. Además, las interfaces y los comportamientos esperados para los componentes que no pertenecen a la interfaz gráfica de usuario no se comprenden ni se han documentado muy bien en comparación con los componentes basados en la interfaz gráfica de usuario. Por ejemplo, cómo prueba una transacción bancaria que inicia un depósito, ejecuta una llamada de la base de datos y envía un texto al cliente al tiempo que le confirma al usuario que el depósito fue exitoso? Muchos de estos procesos no revelan su funcionalidad mediante la interfaz gráfica de usuario y deben validarse de otra forma. Y si el servicio que envía un texto al cliente también se utiliza en una transacción que envía un aviso de sobregiro, habrá otros defectos que han pasado desapercibidos? Con tantos componentes utilizados por varias aplicaciones, puede ser difícil para el equipo de prueba comprender las dependencias entre los componentes y las aplicaciones que los utilizan, especialmente cuando algunos de los servicios no están disponibles o son cajas negras proporcionadas por terceros. Con todas las permutaciones de casos de prueba necesarias para probar completamente una aplicación compleja y compuesta, muchas organizaciones utilizan la automatización de pruebas. Sin embargo, existen desafíos inherentes. A menudo se subestima el trabajo necesario para automatizar pruebas. La automatización implica el desarrollo de software y tiene que estar adecuadamente dotada con recursos calificados para el diseño, validación y mantenimiento. Además, encontrar un conjunto de herramientas para dar cabida a todos o a la mayoría de los escenarios de pruebas requeridos puede ser difícil. Utilizar herramientas especializadas para diferentes tecnologías o aplicaciones puede resultar en mayores costos de la herramienta, además de limitar la capacidad de estandarización en toda la organización. Por otro lado, existe el problema de los scripts de prueba que cambian de propietario con el tiempo, sin la documentación adecuada. A menudo, estas pruebas se ejecutan por años sin saber por qué son importantes o qué requisitos cumplen. Consulte los cuadros sobre Computación en nube y Web 2.0 para obtener más detalles. Movilidad: Las aplicaciones empresariales que se extienden a interfaces móviles deben probarse tan exhaustivamente como sus homólogas para PC. Los usuarios, cuyas expectativas de calidad se establecen con base en las aplicaciones personales de su smartphone, no tienen paciencia para aplicaciones empresariales móviles que no funcionan correctamente. Por lo tanto, realizar pruebas para asegurarse de que funcionan a la perfección es fundamental para la productividad y la lealtad del cliente. Las aplicaciones móviles poseen las mismas complicaciones en las pruebas que las aplicaciones compuestas, simplemente no imitan el entorno de escritorio. Tienen requisitos de interfaz de usuario, flujos de procesos de negocio y dependencias de infraestructura propios. Y son un desafío particular para la organización de control de calidad porque hay muchos dispositivos posibles a los que proporcionar soporte. Según Forrester, "sus clientes poseen muchos dispositivos diferentes que dependen de varios entornos de desarrollo Las múltiples versiones del mismo SO, diferentes tamaños de pantalla y un elevado número de dispositivos significan que los gastos de traslado, mantenimiento y promoción de las aplicaciones seguirán siendo altos. 2 Las pruebas manuales pueden ser muy intensas cuando se trabaja en smartphones, PDA, tableta PC y equipos especializados como un dispositivo handheld de un agente de alquiler de vehículos que se utiliza para escanear e imprimir. Es peor aún si se consideran las permutaciones exponenciales de datos, escenarios de uso, las condiciones de la red móvil y los transportistas. Aunque la implementación puede ser un desafío, esta es un área que está lista para las soluciones de automatización de prueba. Aplicaciones de computación en nube Los equipos de pruebas funcionales a menudo necesitan probar aplicaciones compuestas que incluyen algunos servicios que se basan en la nube. Para probar la aplicación compuesta completa, incluyendo la capa de nube, el equipo de prueba debe ser capaz de acceder y administrar un proyecto de prueba en toda la infraestructura. Además, el equipo de prueba puede tener dificultades para acceder a determinados servicios basados en la nube para efectos de la prueba. Por ejemplo, la aplicación compuesta para ordenar un par de zapatos en línea contratará servicios basados en la nube, como el procesamiento de una tarjeta de crédito y servicios de envío. Debido a que las tarjetas de crédito y el envío son servicios de terceros que probablemente ya se encuentran en producción, es posible que no se pueda volverlos a probar o que sea algo costoso. Esto puede causar retrasos en la prueba de la aplicación compuesta. Por otro lado, el acceso a la nube trae grandes oportunidades para el equipo de prueba porque proporciona capacidad según demanda, aparentemente ilimitada, para probar las aplicaciones. Esto es particularmente útil para las pruebas de rendimiento. 3

4 Cómo modernizar las pruebas para obtener una empresa ágil Las organizaciones de control de calidad pueden enfrentar estos problemas y convertirse en socios completos a la hora de implementar aplicaciones modernas, como parte de una empresa con verdadera capacidad de respuesta. Las organizaciones de control de calidad pueden prepararse y modernizarse al expandir sus habilidades y comprometerse más con los aspectos de negocios que se les pide probar. Ellos deben asociarse con los equipos analistas de negocios y desarrollo, compartiendo mediciones y resultados. Deben participar en actividades de administración de calidad que generen una entrega de aplicaciones más previsible, con mejor satisfacción para el cliente y menos defectos. Pueden lograr todo esto si emplean procesos y prácticas que permitan realizar pruebas lo antes posible en el ciclo de vida, si aumentan la automatización siempre que se pueda y si se sienten cómodos al realizar pruebas sin documentos detallados del diseño de prueba. En general, las organizaciones progresistas de control de calidad consideran sus pruebas prácticas de manera holística, invierten en el diseño de la prueba y como resultado: realizan más pruebas, con mayor rapidez y lo antes posible. Aquí verá algunos pasos específicos que el equipo de prueba funcional puede implementar a la hora de modernizar. 1. Comencemos con el diseño: Aunque a menudo se descuida este paso, tomarse el tiempo necesario para diseñar cuidadosamente la estrategia de la prueba vale la pena, ya que se logran pruebas más eficientes y más fáciles de mantener. Se recomienda utilizar un marco de trabajo, crear un modelo del proceso del negocio y construir una biblioteca de componentes de prueba reutilizables que pueden montarse en flujos. Por ejemplo, supongamos que hay tres procesos de negocios para validar: crear, eliminar y actualizar una orden. Una vez que se modelan los procesos de negocios, es fácil identificar las Figura 1 Reduzca los tiempos de mantenimiento y creación de la prueba mediante la validación de procesos de negocios con componentes de pruebas reutilizables. duplicaciones; los tres utilizan la misma función de inicio de sesión (consulte la figura 1). Con un enfoque modular, el componente de prueba para la función de inicio de sesión sólo debe crearse una vez, no tres veces, eliminando la duplicación de esfuerzos. Si se realiza un cambio en la función de inicio de sesión, solo es necesario cambiar el componente de prueba asociado una vez y se actualizarán todas las pruebas que utiliza ese componente. Este método de "prueba de composición" puede reducir el esfuerzo y el tiempo de creación y de mantenimiento de la prueba. Y esta mayor eficiencia se consigue si estas pruebas se automatizan o se realizan manualmente. El software HP Business Process Testing (HP BPT) proporciona un marco de trabajo para crear una biblioteca de componentes de pruebas reutilizables que pueden montarse en flujos. Les permite a los equipos de pruebas aumentar la calidad de la aplicación, reduciendo el tiempo necesario para la creación y el mantenimiento de la prueba. Y disminuye el costo de calidad ante un cambio regular y rápido. Otra ventaja de tomarse el tiempo inicial para diseñar una estrategia de prueba con HP BPT es la capacidad de determinar rápidamente qué componentes probar manualmente y cuáles automatizar. En la mayoría de los casos, los componentes comenzarán a probarse manualmente y pasarán a pruebas automatizadas cuando y si tiene sentido hacerlo. HP BPT proporciona el beneficio adicional de la generación automática de documentación del plan de pruebas y la creación de vínculos detallados en los requisitos del software HP Quality Center. Las pruebas bien documentadas y bien administradas siguen siendo útiles a través de iteraciones de pruebas futuras, incluso si las pruebas cambian de propietario. Aplicaciones Web 2.0 Las tecnologías Rich Internet Application (RIA) y Web 2.0 son conocidas por proporcionar una interfaz gráfica de usuario rica que trae su propio conjunto único de desafíos de pruebas. Las herramientas de pruebas funcionales deben poder probar un conjunto de herramientas diversas y en constante expansión, tales como aquellos que aprovechan Microsoft Silverlight, y las ofertas de la amplia gama de Ajax incluyendo el kit de herramientas de Dojo, la interfaz de usuarios Yahoo! (YUI), ASP.NET AJAX, y el kit de herramientas web de Google (GWT), por nombrar unos pocos. Mientras no cambien la mayoría de la infraestructura subyacente de la web, cada kit de herramienta tiene controles web diferentes con comportamientos únicos, que no pueden ser reconocidos automáticamente por herramientas de pruebas funcionales. Agregue a la situación la naturaleza dinámica de los datos y los datos compartidos entre aplicaciones y obtendrá un escenario de prueba complejo. 4

5 Figura 2 Es una buena práctica probar la iteración actual manualmente y automatizar las pruebas de la iteración anterior. Enero 1 Febrero 2 Marzo 3 Abril 4 Mayo 5 Junio 6 Julio 7 Agosto 8 Septiembre 9 C1 C1 C1 C1 C1 C1 C1 C2 C2 C2 C2 C2 C2 G1 G1 G1 G1 G1 C3 C3 C3 C3 Automatice las pruebas cuando los componentes disponibles se vuelven estables G2 G2 G2 G3 G3 BP1 Prueba de regresión al final de cada iteración o como parte del desarrollo continuo BP2 Componente sin interfaz gráfica de usuario (GUI) Elemento de la interfaz gráfica de usuario (GUI) Proceso de negocios Componente estable 2. Aumente y mejore la automatización: Aunque la automatización nunca reemplazará a las pruebas manuales por completo, encontrar áreas para automatizar ayudará a la organización de control de calidad a realizar más pruebas de manera más rápida. Al permitir que los equipos de control de calidad prueben más configuraciones e iteraciones con recursos limitados, la automatización facilita una mejor cobertura de la prueba, lo que puede reducir el riesgo de fallas en la producción. Para obtener el máximo provecho de la automatización, es importante aplicarla juiciosamente. Aquí están nuestras recomendaciones sobre qué y cuándo automatizar: Pruebas de regresión: las pruebas de regresión son un conjunto de pruebas de "referencia" que se utilizan en conjunto con las pruebas manuales pero que se pueden automatizar fácilmente. Normalmente, no se utilizan para encontrar errores en una versión nueva sino para asegurarse de que los cambios más recientes no han alterado nada de lo que funcionaba anteriormente. Utilice la automatización para crear conjuntos de pruebas de regresión repetibles y de rápida ejecución que se pueden realizar las 24 horas del día. Incorporar estas pruebas de regresión automatizadas en el proceso de compilación puede permitir una práctica de "desarrollo continuo" que encuentra los problemas rápidamente y les permite a los desarrolladores trabajar sobre una base estable y conocida. La iteración anterior: en métodos iterativos como Agile, puede ser difícil automatizar y obtener resultados dentro de una iteración o sprint. A menudo no hay suficiente tiempo y el código puede estar todavía en flujo. Pero, a igual que las pruebas de regresión, es una buena práctica probar la iteración actual manualmente y automatizar las pruebas de la iteración anterior (consulte la figura 2). Esto ayuda a los equipos de control de calidad a realizar pruebas con mayor rapidez y lo antes posible, lo cual es necesario para un proceso Agile. Aplicaciones y componentes más estables: es importante analizar el retorno de la inversión (ROI) de la automatización. Los beneficios de la automatización con el tiempo deben compensar los costos para desarrollar y mantener la secuencia de comandos de automatización. Mientras que algunas herramientas, como el software HP Unified Functional Testing, tienen recursos incorporados para proteger las pruebas contra los cambios y guiar a los evaluadores a través de las actualizaciones de secuencias de comandos en tiempo real, una aplicación que se encuentra en un estado de flujo puede requerir demasiados cambios en las secuencias de comandos de automatización como para considerarse rentable. Aplicaciones móviles: aunque en la actualidad principalmente se prueban con métodos manuales, es útil automatizar las pruebas de permutaciones de dispositivos, sistemas operativos, escenarios de uso y las condiciones de red necesarias para las aplicaciones móviles. 5

6 Figura 3 HP Sprinter proporciona un registro automático de todas las acciones del usuario en formato de texto con una cronología detallada. 6 HP Unified Functional Testing (HP UFT) admite todas las principales aplicaciones de software y entornos para pruebas automatizadas. Al asociarse con empresas de vanguardia e innovadoras, HP está ampliando sus recursos líderes del sector en materia de pruebas funcionales para aplicaciones móviles e infraestructura de computación en nube que se utilizan en las plataformas y sistemas operativos más comunes. HP UFT incluye el reconocido software de automatización HP QuickTest Professional, junto con el software HP Service Test y HP Service Test Management para probar servicios avanzados y recursos de administración. En el caso de las aplicaciones Web 2.0, HP UFT admite una creciente gama de kits de herramientas que habilitan las tecnologías Web 2.0, incluyendo Microsoft Silverlight y el kit de herramientas más comúnmente usado de Ajax: el kit de herramientas web de Google (GWT), la interfaz de usuarios Yahoo! (YUI), ASP.NET AJAX, y el kit de herramientas de Dojo. La capacidad de extensión del complemento adicional Web le permite desarrollar soporte para probar los controles web personalizados y de terceros que no son compatibles inmediatamente con el complemento Web. El Acelerador de la capacidad de extensión es un entorno de desarrollo integrado (IDE) que facilita y acelera el diseño, el desarrollo y la implementación del soporte para los controles web personalizados y de terceros que no son compatibles inmediatamente. 3. Modernice pruebas manuales: Aunque cada vez más organizaciones intentan aprovechar las pruebas automatizadas, las pruebas manuales todavía representan alrededor del 75% de todas las pruebas funcionales. Sin embargo, los evaluadores pueden adoptar métodos modernos de pruebas manuales para simplificar y reducir al mínimo sus tareas más tediosas y propensas a errores. En lugar de escribir manualmente datos desde hojas de cálculo, tomar notas durante la ejecución de las pruebas, escribir los resultados en el conjunto de la prueba y ejecutar las pruebas una y otra vez con diferentes entornos y configuraciones, deben buscar una solución de prueba que ayude a optimizar estos pasos. HP Sprinter, la nueva solución de prueba manual, se concentra en simplificar y agilizar las pruebas manuales y aumentar la colaboración en equipo. HP Sprinter registra casos de prueba directamente desde HP Quality Center y los presenta en la pantalla de manera automática. Para minimizar los procesos propensos a errores, HP Sprinter inyecta automáticamente los datos desde una hoja de cálculo externa a la aplicación sometida a prueba. HP Sprinter registra automáticamente los casos de prueba desde el software HP Quality Center o HP Application Lifecycle Management (HP ALM) y los presenta en la pantalla de la "aplicación sometida a prueba". Desde aquí, el usuario puede desplazarse para ver los pasos de la prueba, abrir un defecto, agregar comentarios y registrar los resultados reales. HP Sprinter registra automáticamente todas las acciones del usuario en tres formatos: una descripción textual de todas las acciones del usuario (consulte la figura 3), una captura de pantalla de todas las acciones del usuario y una grabación en video de la ejecución de toda prueba. Los evaluadores pueden adjuntar esta descripción detallada a un defecto nuevo con el clic de un botón. Esto mejora significativamente el defecto de comunicación para los desarrolladores y facilita la rápida corrección.

7 Para aplicaciones que principalmente se prueban de forma manual, incluyendo aplicaciones móviles, la capacidad de "pruebas en espejo" del software de HP Sprinter ayuda a clonar una prueba varias veces para diferentes entornos y configuraciones. Esto permite que el evaluador ejecute una prueba solo una vez, mientras que HP Sprinter la replica en hasta cuatro equipos al mismo tiempo. Se ha demostrado que incrementó la productividad general de las pruebas manuales en un 50 70%. 3 Con HP Sprinter, HP BPT, y HP UFT, los resultados de las pruebas y toda la documentación pertinente se guardan automáticamente en HP ALM o HP Quality Center. De esta manera, los evaluadores, así como otras partes interesadas, obtienen plena trazabilidad de los resultados de las pruebas en los casos de prueba, los requisitos y defectos en un sistema único de registro. 4. Realice pruebas en servicios y componentes que no pertenecen a la interfaz gráfica de usuario: En el caso de las aplicaciones compuestas, en lugar de depender solo de pruebas de la interfaz gráfica de usuario para validar la lógica subyacente, recomendamos probar la capa de servicios (también llamada la capa sin encabezado) directamente. Estos servicios a menudo están disponibles para realizar pruebas antes que la interfaz gráfica de usuario esté lista y les posibilita a los encargados de control de calidad el inicio de las pruebas y la puesta en práctica de la automatización lo antes posible en el ciclo de vida de la aplicación. Esto tiene grandes ventajas, ya sea que el equipo esté utilizando procesos Agile o no. Es más sencillo identificar la ubicación del defecto cuando se trata de componentes aislados y es más fácil corregir los errores cuando se encuentran más cercanos al momento de inyección. La mayoría de la lógica empresarial de una aplicación reside en la capa sin encabezado, que a menudo aprovechan varias aplicaciones. Un defecto que pasa desapercibido en estos servicios puede tener ramificaciones generalizadas e inesperadas. Realizar pruebas de estos servicios de manera independiente reduce el riesgo y refuerza los componentes básicos de las aplicaciones compuestas. A medida que hay más componentes, recomendamos realizar pruebas de aplicaciones compuestas en múltiples capas mediante la automatización de una transacción completa a través componentes que pertenecen y que no pertenecen a la interfaz gráfica de usuario. HP UFT les permite a los equipos de control de calidad probar la capa de la interfaz gráfica de usuario, la capa sin encabezado y el proceso de extremo a extremo. Ayuda a mejorar la calidad de las aplicaciones compuestas ya que se realizan pruebas de más funcionalidad a través de varias capas de la aplicación. Además, ayuda a encontrar defectos que de lo contrario se omitirían cuando solo se prueba la interfaz gráfica de usuario. En el caso de las aplicaciones de computación en nube, es necesario realizar pruebas de componentes que pueden residir en la nube o en las instalaciones. HP SOA Systinet puede utilizarse como un depósito de metadatos para comprender las dependencias de aplicaciones y servicios reales y replicados, incluyendo servicios simulados. Mediante la combinación del software HP SOA Systinet y HP UFT los equipos de control de calidad pueden probar los procesos de aplicaciones de computación en nube de extremo a extremo. Además, si un componente no se encuentra disponible para realizar pruebas en una aplicación compuesta o en un escenario de pruebas de proceso de negocio de varios pasos, se puede producir un retraso. Esto puede suceder si un componente compartido es una aplicación o un servicio crítico para los negocios que ya está en producción o es un servicio de computación en nube que es costoso de probar. La virtualización de servicios es un enfoque que puede utilizarse para evitar el estancamiento de los esfuerzos de pruebas. Con la virtualización del servicio, el componente del servicio o aplicación en el backend de la prueba se emula y se crea un servicio virtual que imita el comportamiento y la respuesta del servicio real. El servicio virtual puede utilizarse repetidamente para realizar pruebas sin incurrir en un cargo de servicio de nube o interrumpir un entorno de producción. 7

8 La jornada para el equipo de prueba funcional Para que los equipos de control de calidad atiendan las necesidades emergentes del mercado, incluyendo la adopción de la computación en nube, la Web 2.0, las aplicaciones móviles y compuestas, debe haber una transformación en la forma de realizar las pruebas funcionales. Los equipos de pruebas funcionales exitosos inician el proceso de prueba lo antes posible en el ciclo de vida de la aplicación. Incluso antes de que una aplicación esté lista para probarse, analizan de manera holística el problema de la prueba y dedican tiempo para diseñar su estrategia de prueba. La estrategia incluye el uso de un marco de trabajo y la creación de componentes de prueba reutilizables. Se involucran con la empresa e incorporan las pruebas lo antes posible en el ciclo de vida, llevando a cabo pruebas exploratorias con modernos métodos de prueba manual, incluida la documentación y el sistema de informes automático. Y empiezan a probar la capa sin encabezado incluso antes de que la interfaz gráfica de usuario se encuentre disponible. Lo equipos de control de calidad con visión de futuro buscan oportunidades para automatizar pruebas cuándo y dónde tiene sentido hacerlo. Y en las áreas donde continúan realizando pruebas manuales, aceleran el proceso al automatizar las tareas tediosas y repetitivas para reducir el tiempo de prueba. Finalmente, validan plenamente las aplicaciones compuestas, realizando pruebas en la capa de la interfaz gráfica de usuario, la capa sin encabezado y el proceso completo de extremo a extremo. Notas 1 Base: 206 encargados de tomar decisiones de TI con perspectivas sobre las actividades de modernización presupuestadas. Fuente: "Clearing Your Path to Modern Applications and Business Agility" (Mejorar el camino hacia las aplicaciones modernas y la agilidad de negocios), Informe de Forrester, 6 de abril de Informe sobre liderazgo de ideas de Forrester Consulting, encargado por HP. 2 Forrester, "2011 Mobile Trends" (Tendencias de movilidad en 2011), Thomas Husson y Julie A. Ask, 24 de enero de Los testimonios de los clientes están disponibles en techvalidate: consulte techvalidate.com/portals/hp-sprinter HP proporciona soluciones de pruebas funcionales integradas y amplias para ayudar en cada paso del camino. Para obtener más información sobre las soluciones de pruebas funcionales de HP, descargue las versiones de prueba gratuitas de estas soluciones de HP: HP Unified Functional Testing HP Sprinter Conéctese hp.com/go/getconnected Obtenga una visión experta sobre tendencias tecnológicas, alertas y soluciones de HP Compartir con colegas Copyright Hewlett-Packard Development Company, L.P. La información contenida en el presente documento está sujeta a cambios sin previo aviso. Las únicas garantías para los productos y servicios HP se establecen en las declaraciones expresas de garantía que acompañan a dichos productos y servicios. Ninguna información contenida en este documento debe interpretarse como una garantía adicional. HP no se responsabilizará por errores técnicos o de edición ni por omisiones contenidas en el presente documento. Microsoft y Silverlight son marcas comerciales registradas en los EE.UU. Google es una marca registrada de Google Inc. 4AA3-5237SPL, creado en junio de 2011; actualizado en abril de 2012, Rev. 1 Esta es una impresión digital HP