jueves, 30 de junio de 2016

¿Qué podemos aprender del juego maldito de ET?

Semanas atrás me dispuse a ver el documental “Game Over”, que relata una de las leyendas más grandes de la historia de los videojuegos. La misma se remonta al año 1983 cuando Atari, supuestamente, entierra todas las copias del juego de la famosa película “ET el Extraterrestre” en el desierto de Nuevo México, por su fracaso en ventas para la consola 2600, lo que llevó a la empresa a la quiebra, en ese momento, una de las más grandes del mundo en juegos electrónicos.

Si bien el documental gira en torno a ratificar la veracidad o no de este mito, lo primero que me pregunté, es por qué una compañía tan grande pudo tener un derrumbe de semejante tamaño que, no solo llevó a que la empresa cierre, sino que produjo una enorme crisis en la industria. 

La primera respuesta que encontré fue que el tiempo en la entrega del juego atentó contra la calidad del producto.

Universal, el gran estudio cinematográfico que iba a lanzar la película, llamó a Atari para que se encargaran de producir un juego ¡en cinco semanas! cuando lo normal era lo que hicieran en esa cantidad…de meses.

Howard Scott Warshaw, programador del juego, lejos de asustarse, redobló la apuesta y dos días después viajó para reunirse con el mismísimo director del filme, Steven Spielberg, a quien no sólo le afirmó que llegaba a hacerlo, sino también que el mismo iba a tener una historia original, distinta. 

Lo que ahora parece normal, en ese momento no lo era para los videojuegos. ET iba a tener una trama con un principio y un final, acorde a la película. “¿No podés hacer algo parecido al pacman?”, le respondió el director, no convencido con la idea. Warshaw, con la seguridad que tenía por haber hecho juegos exitosos como Yar´s Revenge, que le significaron muchas ganancias a Atari, le contestó que este cartucho tenía que a ser “diferente a todo”.

Tal fue la confianza que le inyectó a Spielberg, que él mismo dio el visto bueno a la versión definitiva del juego en televisión, lo que provocó una ansiedad por tenerlo como pocas veces se había visto en la historia de la Atari. 

Sin embargo, el tiempo fue un enemigo y no alcanzó con que el programador trabaje desde su casa todo el día y coma sólo cuando iba desde su hogar hasta la oficina.

Otra de las respuestas que me surgieron fue la falta de controles de calidad que sufrió el cartucho, producto del poco tiempo de diseño para entregarlo. 

La ambición por las ganancias que podía generar entregar el juego para navidad, obvió la opinión del usuario que, mediante su experiencia e interacción con el juego, seguramente hubiera mejorado la versión final.

Bugs evidentes, como errores en el conteo, o las permanentes caídas del extrarrestre en hoyos sin salida porque los jugadores no conocían bien de que iba la historia del juego, produjeron una desilusión masiva en los usuarios, que devolvían el cartucho con la misma rapidez que lo compraban.

La prensa, de forma exagerada, no dudó en llamarlo el “peor juego de la historia”, lo que catapultó el fracaso a niveles estrepitosos.

Años más tarde, la industria aprendió la lección de Atari y  pudo resurgir de la mano de empresas como Nintendo y Sega, entre otras.

Así, el testing comenzó a ser parte preponderante de los videojuegos. Hoy, una de las firmas más exitosas en la creación de los mismos es Valve, famosa por ser responsable de sagas como: Half Life, Portal, Team Fortress y Left For Dead. La compañía se rige por la premisa de que “el testing es la parte más importante en el desarrollo de un juego, que no se añade al final del desarrollo, para los test de calidad o como herramienta de optimización. Es el principal factor que moldea nuestras decisiones sobre qué sacar a la venta y cuándo hacerlo.”

Valve es la compañía que más testing realiza, la que más temprano lo implementa en el proceso de desarrollo, y la que más cambios introduce en sus productos desde el inicio de la producción hasta el final del proceso. También es una de las empresas que más retrasa sus juegos: nada sale hasta que no sea perfecto. Justamente, lo contrario al proceso que sufrió el juego ET, que fue desarrollado en tiempo récord, sin ser probado y con la única ambición de generar dinero a cualquier costo.

Esta experiencia, que tanto dolor le trajo a la industria, marcó un camino: nunca más saldría a producción un videojuego sin antes ser testeado.

Autor:
Gustavo Lamy Cobarrubia
QA & Testing Specialist

martes, 14 de junio de 2016

¿Qué son las Mobile Enterprise Application Platforms?


En la actualidad, existe un conjunto de acrónimos que representan una nueva línea de productos y plataformas que intentan solucionar los principales problemas del desarrollo de aplicaciones móviles. 

El primer inconveniente, más conocido y claro, es el de la multiplataformidad, relacionado con la heterogeneidad intencional que existe entre las diversas plataformas móviles, siendo hoy las tres principales: iOS, Android y Windows Phone. El segundo, está relacionado con la integración de las aplicaciones móviles a servicios de backend y la provisión de servicios cross-platform, pero que son comunes a todas las aplicaciones móviles como ser: CDN, notificaciones, autenticación, servicios, APIs, etc.

Este artículo, tiene como fin dar a conocer los diferentes tipos de plataformas existentes, tanto abiertas como comerciales, los servicios y características de cada una, y los principales proveedores que las ofrecen, brindando así una guía de gran utilidad para gerentes de sistemas y asesores técnicos.

Los acrónimos

De manera un tanto difusa, estos acrónimos representan los distintos servicios ofrecidos por las plataformas disponibles para el desarrollo de aplicaciones.

MEAP (Mobile Enterprise Application Platform): plataforma de integración de servicios empresariales, generalmente lightweight (REST), que se disponibilizan para todas las plataformas móviles. Permite atacar el problema de la multiplataforma desde el lado de la concentración de servicios claves en una plataforma común, limitando la responsabilidad de las aplicaciones nativas exclusivamente a aspectos de UX.

MCAP (Mobile Consumer Application Platform): similar a la anterior, pero orientada a las necesidades de una aplicación directa para el público masivo. Probablemente tenga más componentes de integración con redes sociales y, quizás, la sincronización offline no sea un feature obligatorio.

MADP (Mobile Application Development Platform): en este caso, la plataforma es un ambiente de desarrollo mobile multiplataforma completo que, eventualmente, puede también ser cloud. El foco está puesto en las herramientas de desarrollo que permite construir aplicaciones mobile multiplataforma. Desde esta perspectiva, incluye a los dos anteriores, ya que al centrarse en el ambiente, no importa su uso final.

MBaaS (Mobile Backend As A Service): básicamente, un backend cloud pensado para mobile, pero que carece de las funcionalidades client-side, como compilación multiplataforma y funcionalidades asociadas. En este esquema, en general, queda excluido el cómo desarrollar las aplicaciones móviles que se conectan al BaaS, y generalmente se limita a proveer un SDK para poder consumir los servicios.

Ejes y servicios

Los M**P cubren distintos servicios o funcionalidades. Algunos sólo lo hacen de forma parcial, mientras que otros los abarcan de manera completa:

  • Server: la plataforma base en el servidor sobre la que se construye toda la solución (e.g. IIS).
  • Database: motor de base de datos, sea Relacional o NoSQL.
  • ORM: motores de Object Relational Mapping (e.g. Hibernate), para disponibilizar modelos de datos basados en objetos con un soporte en una base de datos relacional.
  • REST Services: generalmente, los servicios implementados en el servidor se disponibilizan como servicios RESTFul en arquitecturas de microservicios.
  • Identity Management Services: motores que permiten realizar autenticación y autorización de transacciones, generalmente contra federadores externos (e.g. Google, Facebook, Office365.
  • Security: layers de seguridad específicos para Mobile, como encripción adicional, implementación de políticas y reglas centralizadas.
  • iOS / Android / WindowsPhone Integration: cada una de las plataformas provee servicios específicos que requieren de una integración particular.
  • Enterprise Integration: integración con servicios típicos empresariales contra Services Bus (Enterprise Service Bus), mediante transacciones SOAP o similares.
  • CDN, Content Delivery Network: particularmente, aquellas soluciones basadas en Cloud ofrecen también la red de distribución de contenido para obtener alta disponibilidad y performance acorde al origen de cada request.
  • Data Synchronization                                                                                             -Offline Data Synchronization: las aplicaciones mobile operan en OCS, Ocasionally Connected Scenarios, escenarios ocasionalmente conectados donde las aplicaciones pueden tener períodos de conectividad parcial o de desconexión completa.
  • Cross Platform Support: posibilidad de utilizar un único codebase y compilarlo directamente o, por ejemplo, utilizarlo en diferentes canales a la vez.
  • Deployment Methodology: cómo y dónde se implementará el servidor centralizado corporativo que da soporte a la solución mobile.                                                     -Multi-tenant: un servicio Cloud centralizado administrado compartido entre diferentes clientes. | Dedicated: un servicio Cloud centralizado dedicado para cada cliente. | On-premises: servidores directamente instalados en un datacenter propietario.
  • Open Source: las herramientas de desarrollo, la plataforma y los SDK disponibles para desarrollar las aplicaciones mobile son de código abierto. En algunos casos, pueden coexistir una versión abierta comunitaria y una comercial con features adicionales.
  • Push Service: los servicios Push son sistemas de notificaciones iniciados desde el servidor que permiten enviar mensajes específicos a cada dispositivo particular.  Cada proveedor Mobile tiene su esquema de envío de notificaciones y su SDK para operarlo. Un servidor MEAP puede implementar todas las API con cada proveedor y de esta manera centralizar las notificaciones independientemente de la plataforma.
  • SMS Support:  envío de SMS.
  • Email Relay Support: servicio customizado de envío de emails, desde transacciones puntuales hasta envíos masivos para campañas o como parte de los propios procesos de la organización.


MBaaS

Es un modelo que proporciona a desarrolladores de apps móviles y web una manera de vincular sus aplicaciones mediante una API a servicios en la nube. Los servicios ofrecidos en la nube pueden incluir capacidad de gestión de usuarios, notificaciones de inserción e integración con sistemas de terceros, notificaciones push, integración con los servicios de redes sociales, noticias y otros recursos de recopilación de datos como editoriales y similares. Estos servicios se prestan a través del uso de kits de desarrollo de software (SDK) e interfaces de programación de aplicaciones (APIs). Además, ofrecen un control de acceso minucioso a todas las aplicaciones móviles alojadas en una plataforma en particular. 
Los empleados y clientes empresariales pueden acceder e intercambiar datos desde cualquier dispositivo móvil y realizar operaciones multicanal.
La idea general de MBaaS es que los servicios comunes puedan ser compartidos entre aplicaciones móviles en lugar de ser desarrollados a medida para cada una. Utilizando MBaaS, las aplicaciones móviles siguen una arquitectura distribuida débilmente acoplada.

Una plataforma MBaaS debería incluir, al menos:
  • Una infrastructura Cloud.
  • Capacidades de integración completa - conectividad a sistemas corporativos como ERP, CRM, etc.
  • Desarrollo de aplicaciones móviles - entorno de desarrollo integrado (IDE) para la creación de aplicaciones móviles.
  • Gestión de dispositivos móviles (MDM) - apoyo para el aprovisionamiento de dispositivos, transmisión segura de datos, configuración remota, seguimiento de datos móviles, la identificación de políticas y la adaptación, etc.
  • Mobile Application Management (MAM) - aprovisionamiento y control de acceso a las aplicaciones móviles utilizadas en los entornos empresariales (ajustes de configuración, autenticación de usuarios, servicios de notificación de inserción, análisis de uso de aplicaciones, etc.).

Según Gartner, las principales empresas que ofrecen servicios MBaaS son:

 


Plataformas MBaaS


Las soluciones disponibles actualmente en el mercado tienen algunas características comunes: 
  • Cuentan con almacenamiento utilizando una base de datos NoSQL o disponen de un ORM que permite operar la base de datos de esa manera, almacenando y operando sobre objetos JSON.
  • Ofrecen un diseño de interfaz de usuario para las aplicaciones móviles similares.
  • Están disponibles en una nube multiusuario.
  • Poseen documentación en línea.
  • Proporcionan las API para notificaciones Push y de Identity Manager. 
  • Tienen soporte iOS y Android.
  • Poseen capacidad para que los desarrolladores implementen la lógica del servidor de manera customizada.

 Entre los productos comerciales y abiertos, se destacan:

  • Windows Azure Mobile Service
  • AnyPrescence
  • Appcelerator
  • FeedHenry
  • Kinvey
  • Parse
  • CloudKit
  • Kony MobileFabric
  • Cognito
  • Pivotal CF
  • BAASBox
  • built.io
  • moBack.com

A continuación, nos centraremos en la solución MBaaS: WAMS, Windows Azure Mobile Services, una de las líderes del mercado y que brinda una excelente relación costo beneficio para el desarrollo de aplicaciones móviles corporativas, tanto las orientadas a la compañía internamente (in-house development) como comerciales para el público masivo.

Windows Azure Mobile Services

Microsoft ofrece una completa plataforma MBaaS bajo la denominación WAMS. La misma incluye la mayoría de los ejes típicos de servicios de integración mobile. Particularmente, ofrece un SDK Mobile Multiplataforma, un servidor REST en NodeJS con un ORM incorporado que detrás se conecta con una base de datos lightweight SQL Server Azure, optimizada para alta carga transaccional, pero de limitado espacio de almacenamiento.  Además, ofrece un servicio de Identity Manager por autenticación federada (Facebook, Twitter, Outlook y Google), incluyendo integración contra ADFS y Office365, un Service Bus Hub para envío de notificaciones PUSH, un Relay Server de SMTP, un Blob Storage (almacenamiento de archivos), máquinas virtuales y servicios de networking y seguridad (e.g. VPN).

  
 

  
En Baufest, extendimos el esquema tradicional ofrecido por Microsoft, para adicionarle características específicas requeridas por nuestros clientes. Dotamos a la arquitectura de un mecanismo multiplataforma, basándonos en el framework Apache Cordova (i.e. Phonegap).  Esto permite que las aplicaciones construídas sobre WAMS sobre un único codebase, puedan compilarse y ejecutarse sobre las tres principales plataformas mobile del mercado actuales: iOS, Android y Windows Phone.  Adicionalmente, desarrollamos un motor de notificaciones basado el Notification Hub provisto por Azure, con conectores externos para obtener la información de contactos desde sistemas legacy corporativos (SOAP, REST, FTP, File Shares) y agregándole una interfaz de backend para la administración y el disparo puntual de las notificaciones.   Finalmente, enriquecimos la plataforma de Azure con un esquema adicional para la distribución de documentos digitales (e.g. facturas) mediante un protocolo seguro diseñado para obtener estos documentos, disponibilizarlos temporalmente seguros en la nube para que el usuario los visualice. 

Elección de la Plataforma

Existen diversos factores que pueden determinar el éxito o fracaso de un proveedor Mobile Empresarial para cada corporación. Los mismos son:

1.Codificación nativa. ¿Se requieren habilidades de codificación nativa para completar los proyectos o hacer cambios? Algunos vendedores MEAP, no completan el proceso de creación de la aplicación móvil para el dispositivo de destino. Se requiere la programación y el ajuste manual del código. Hay que evaluar cuidadosamente si la plataforma MEAP es verdaderamente una solución multiplataforma de extremo a extremo o si es un generador de código. ¿Los ajustes se reflejan en el IDE del MEAP?  Es decir hay un único codebase o diferentes fuentes generados una vez y que luego tienen que mantenerse en forma separada para cada plataforma.

2.Depuración nativa. ¿Vamos a necesitar utilizar el depurador nativo para probar nuestras aplicaciones? Si la plataforma MEAP despliega sus capacidades de depuración en un dispositivo de destino, entonces es probable que sea necesario escribir código para arreglar cualquier problema que encuentre.  La situación ideal es que exista  un único esquema de depuración multi-plataforma, multi-canal y no tener que utilizar depuración nativa cada vez que se necesite arreglar un bug.

3.Soporte de plataformas tradicionales. ¿Puede la plataforma MEAP crear también aplicaciones de escritorio, cliente-servidor y aplicaciones web? Algunas plataformas MEAP´s son solo para implementaciones móviles y tienen poca o no cuentan con capacidad para soportar otros tipos de aplicaciones. Esta falta de soporte significa codificación duplicada para esos ambientes y la imposibilidad de aprovechar las aplicaciones existentes. Una plataforma MEAP más robusta debería ser capaz de poder implementar una lógica de aplicación compuesta por su servidor Java existente, .NET y servicios web habilitados para SOA para una mejor productividad.

4.Soporte HTML5 y GUI nativo. ¿La plataforma MEAP permite a los desarrolladores controlar la apariencia de la aplicación, para que puedan desarrollar una interface nativa para cada dispositivo? ¿Aplicaciones BlackBerry se parecerán a otras aplicaciones BlackBerry? ¿Será una aplicación para iPhone vista como una aplicación para  iPhone? Alternativamente, ¿si se necesita tomar un enfoque más uniforme con un branding específico corporativo, se puede utilizar la plataforma MEAP para crear aplicaciones HTML5 como una opción al enfoque de dispositivo nativo? Para algunas organizaciones, algunas aplicaciones pueden necesitar tener una mirada nativa, mientras que para otras pueden ser aceptables en una versión HTML5 genérica (basado en el navegador). ¿La plataforma da la flexibilidad para tener ambos enfoques?

5.Opciones de integración. ¿El proveedor de plataforma MEAP tiene una sólida integración de servicios en segundo plano? ¿Tienen un conjunto completo de herramientas de integración para que pueda integrar los sistemas de IT de la empresa, datos y procesos con la plataforma? La Integración con los sistemas de backend es un componente crucial para proporcionar aplicaciones B2E, B2B, B2C. Sin una solución sencilla para la integración, pueden terminar gastándose meses de tiempo de desarrollo para tratar de integrar aplicaciones móviles a los sistemas empresariales existentes.

6.Solución Global multilingüe. ¿Es la solución multilingüe y puede el vendedor proporcionar apoyo multilingüe? Algunos vendedores tienen un alcance que se limita a América del Norte y no más allá. Algunas plataformas MEAP no tienen la suficiente robustez en cuánto a experiencia de integración y puede ocurrir que presenten falencias en ese aspecto. Para el caso de soluciones móviles globales, este podría ser un factor decisivo en favor de un proveedor MEAP más relacionado con soluciones empresariales globales.

7.Longevidad del vendedor. ¿Cuánto tiempo tiene el vendedor MEAP en el negocio? Muchos vendedores están en modo startup sin ninguna garantía de que van a quedarse. La industria es volátil, las fusiones y adquisiciones son probables. La elección de un proveedor con una historia más estable asegurará que la plataforma que elegida se mantenga en el futuro y permita acompañar la evolución, pero a la vez, una nueva solución generalmente proveerá mecanismos más innovadores y más disruptivos en cuánto a soluciones implementadas.

8.Estado financiero del vendedor. ¿El proveedor proporcionará sus estados financieros? ¿ Está el proveedor certificado o implementa estándares tradicionales ?   Para algunas soluciones particulares, puede ser necesario que todos los productos involucrados, incluyendo el MEAP, sean compliance con ciertas normativas internacionales de seguridad y calidad.

9.Estrategia de la compañía. ¿El proveedor MEAP tiene objetivos diferentes de los del proveedor de software independiente que la adquirió? Esta problemática se ha presentado en los últimos tiempos con grandes empresas que han salido a cazar startups más pequeños para usarlos de base para sus propios  productos MEAP.  Si la empresa matriz adquirió la plataforma MEAP para servir a las necesidades de su base de clientes más grande, habrá que estudiar los propósitos cruzados de sus necesidades. Uno de los vendedores MEAP más conocidos es sólo una pequeña parte de un gran proveedor de ERP, por ejemplo.

10.Hoja de ruta y visión de integridad. ¿El proveedor MEAP tiene una estrategia coherente para los sistemas empresariales, aplicaciones móviles y la nube? ¿Puede el proveedor asegurar que todas estas soluciones puedan basarse en la misma arquitectura orientada a servicios (SOA)? ¿Es la plataforma capaz de tener una composición lógica de la aplicación existente de Java, .NET, COBOL, RPG y otros ambientes? Una buena plataforma MEAP será capaz de aprovechar y facilitar la integración con otros subsistemas y tener una estrategia coherente para la implementación y evolución de la misma.

Centrarse en las preguntas correctas le permitirá hacer una comparación efectiva para evitar caer en un laberinto de programación, caro para desarrollar y casi imposible de mantener. Cuando se trata del cambiante mundo del desarrollo de aplicaciones móviles, la elección de herramientas que faciliten al desarrollador los detalles técnicos subyacentes de los entornos de los heterogéneos dispositivos son hoy, más importantes que nunca.

Referencias:

Excelente artículo: 
Architecting.Mobile.Solutions.For.The.Enterprise.Dino.Esposito.2012


Autor:
Rodrigo Ramele
Baufest Mobile Dev Leader 

miércoles, 1 de junio de 2016

Factores que afectan la calidad del software


Antes de iniciar con el tema me gustaría compartir la siguiente frase de Joseph Juran:

“Calidad es la idoneidad de uso. Es decir, las características del producto que satisfacen las necesidades del cliente y por tanto producen satisfacción de producto. La Calidad es la inexistencia de deficiencias”.

Ahora sí, comencemos con la definición de la palabra calidad. Existen varias: algunas más formales que otras, algunas más enfocadas al producto, otras al cliente  y, otras, al servicio.  Sin embargo, todas incluyen el mismo propósito  de garantía.  

En la actualidad, existen diversos factores que pueden afectar los procesos de calidad. Estos provocan desde procesos tardíos hasta el fracaso de los mismos.

Con el fin de aumentar la calidad en un producto de software o proceso, es recomendable establecer una metodología que cubra nuestras necesidades. Esto nos llevará a definir buenas prácticas y nos permitirá llevar un control de lo que se está realizando en cada una de las etapas del producto. También,  se podrá  realizar una evaluación, la cual nos ayudará  a saber en qué punto se falló para poder mejorarlo.

Algunas de las actividades que se llevan a cabo en la gestión de la calidad  son: aseguramiento, planificación y control de la calidad.

Entre los factores más importantes que intervienen en la calidad encontramos: procesos y prácticas, herramientas, personal y métricas.







Fuente: Guía mejores Prácticas de calidad Producto (INTECO) https://www.incibe.es/file/TnOIvX7kM5orWmEwNq53IQ


A  continuación, se mencionan algunos de factores que intervienen en el  mal uso de las prácticas para el aseguramiento de calidad.

No contar con gestión de pruebas

Al no contar con un plan de pruebas, no tener casos de pruebas o datos y sólo mirar la funcionalidad del sistema, se obtendrán como resultado altos índices de errores y, como consecuencia de la mala gestión, el producto se liberará demasiado tarde y/o incompleto, ocasionando un posible disgusto del cliente. Por ende, esto traerá aparejado costos demasiados elevados.

La complejidad y el tiempo planificando están subestimados

La complejidad de un proyecto, en ocasiones, es la principal causa en la demora del inicio de un desarrollo. Otros factores son la falta de un plan de pruebas, o bien, no tener la estimación adecuada, lo cual impacta en el tiempo para el diseño de pruebas y la ejecución de las mismas.

Es necesario que la gestión de pruebas comience con el proyecto. El diseño de caso de pruebas y las pruebas pueden comenzar con los requisitos.

Deficiencia en la gestión de datos de prueba

Al definir y desarrollar los casos de pruebas, es importante tener en mente los parámetros a utilizar para su ejecución. En muchas ocasiones, sólo se definen los casos olvidando los datos de pruebas.

Es fundamental definir y gestionar los datos de prueba que serán necesarios junto con los casos de prueba. Para ello, cabe recordar que se debe contar con datos de prueba primarios y secundarios, lo cual ayudará bastante para las pruebas de regresión.

Automatización de pruebas

Muchas veces sólo se piensa en las pruebas GUI (Interfaz Gráfica de Usuario), sin pensar qué hay del código, interfaces, rendimiento, etc. Una buena práctica, es comenzar temprano con el control de código, usando una métrica de cobertura. Además, es importante  comenzar con las pruebas de la GUI, sólo si la GUI está estable (recuerde que es necesario contar datos de prueba correctos para su funcionamiento). 

Conocimiento del negocio

¡Pieza importantísima! En muchas ocasiones se utilizan recursos para diseñar tareas del proyecto, sin tener el suficiente dominio o conocimiento del negocio. Es indispensable que se cuente con personal capaz de realizar cada una de las tareas referentes a su área, de lo contrario, es importante capacitarlos antes de comenzar con las actividades del proyecto. Esto ayudará a agilizar y terminar en tiempo y forma cada una de las etapas del proyecto.

Técnicas de pruebas

Los gestores y los recursos no están familiarizados con las técnicas de pruebas. Las técnicas sistemáticas de diseño de casos de prueba reducen bastante el número de casos de prueba, ahorrando tiempo y costos.


No se usan herramientas de pruebas, o se usan las inadecuadas

Las herramientas de pruebas  ayudan a mejorar los procesos para la calidad de software y existen diferentes opciones que se pueden utilizar en el proceso de desarrollo.  Cabe mencionar que, aparte de los beneficios que nos ofrecen, también existen algunos riegos a los que se está expuesto al no tener el conocimiento con exactitud de cada herramienta:

  
Beneficios

•Mejora la eficiencia: utilizar herramientas de pruebas nos ayuda en las  actividades de pruebas  de regresión.
•Automatización de pruebas: diversas herramientas cuentan con la funcionalidad para realizar pruebas de carga, volumen y estrés.  Estas pruebas no es posible realizarlas manualmente.
•Utilizar una herramienta de  pruebas nos facilita el acceso a la información (generación de informes).
•Fiabilidad de prueba.
•Consistencia  y responsabilidad: una vez realizadas las pruebas exitosas, estas se pueden reutilizar las veces que sean necesarias.

Riesgos

•Subestimación de costos y esfuerzos: utilizar por primera vez una herramienta de pruebas y no tener claros los costos de mantenimiento o no darle funcionamiento, es      un claro ejemplo.
•Exceso de confianza en las herramientas: no tener una expectativa clara de lo que se puede llevar acabo con cada una de las herramientas.
•Conocimiento y control de las versiones de pruebas: no tener conocimiento suficiente de las herramientas provoca que no se pueda o no se lleve un control de los casos de pruebas diseñados, así como scripts.
•Mala integración en la organización.
•Características del proveedor: respuesta inesperada en la solución de incidentes o mantenimiento de las mismas herramientas.
•Portabilidad: puede que la herramienta adquirida no cumpla con la funcionalidad esperada o no sea funcional en la plataforma con la que se cuenta.

Fuente: Beneficios y Riesgos - Herramientas de Pruebas ISTQB 
(https://www.youtube.com/watch?v=lt9vm8TftvQ)


Existen diferentes tipos de herramientas, entre las cuales encontramos las siguientes:

Herramientas de gestión de pruebas

·  QaManager
·  QaBook
·  RTH (open source)
·  Salome-tmf
·  Squash TM
·  Test Environment Toolkit
·  TestLink
·  Testitool
·  XQual Studio
·  Radi-testdir
·  Data Generator
·  HP Quality Center/ALM
·  QA Complete
·  QaBook
·  T-Plan Professional
·  SMARTS
·  QAS.Test Case Studio
·  PractiTest
·  SpiraTest
·  TestLog
·  ApTest Manager
·  Zephyr

Herramientas para pruebas funcionales

·  Bugzilla Testopia
·  FitNesse
·  Selenium
·  Soapui
·  Watir (Pruebas de aplicaciones web en Ruby)
·  WatiN (Pruebas de aplicaciones web en .Net)
·  Capedit
·  Canoo WebTest
·  Solex
·  Imprimatur
·  SAMIE
·  ITP
·  WET
·  WebInject
·  QuickTest Pro
·  Rational Robot
·  Sahi
·  SoapTest
·  Test Complete
·  QA Wizard
·  Squish
·  vTest
·  Internet Macros


Es necesario contar con las herramientas adecuadas con el fin de tener un correcto control del proyecto.  También es importante que cada recurso cuente con el conocimiento de las mismas.

Herramientas inadecuadas

Tener un proceso de pruebas inadecuado: lamentablemente en la actualidad existen lugares donde no establece o no se toma importancia a los proceso de pruebas, así como tampoco se tiene una metodología con las herramientas adecuadas.

Utilizar una herramienta paga y no explotar su funcionamiento al máximo es un gran error. Por poner un ejemplo, tener la herramienta HP Quality Center/ALM, la cual  tiene un costo por adquirirla, y no llevar una gestión de pruebas correcta, no generar o ejecutar los casos prueba de forma efectiva.

•Dejar para el final las pruebas de rendimiento y de carga

Las  pruebas de rendimiento y carga se pueden ejecutar en paralelo con las fases de desarrollo. Si esto es posible,  planifique y programe las pruebas con anterioridad, ya que en algunas ocasiones,  pueden ser muy complejas.

Recuerde que el rendimiento de un software está principalmente relacionado con su arquitectura. Es más fácil y más barato cambiar la arquitectura del software en las primeras etapas del desarrollo.


Ejemplos de herramientas para pruebas de carga y rendimiento

-FunkLoad
-FWPTT load testing
-LoadUI
-JMeter - es una herramienta de pruebas permite realizar pruebas     funcionales y rendimiento es una aplicación de escritorio.
-HP LoadRunner
-LoadStorm
-NeoLoad
-WebLOAD Professional
-Forecast
-ANTS – Advanced .NET Testing System
-Webserver Stress Tool
-Load Impact


Autor:
Jesús María Martínez
Tester & QA