El ser humano comete errores y lo hace continuamente. De hecho, ningún proceso en el que intervengan personas está libre de ellos y los que nos dedicamos al desarrollo de aplicaciones de software lo sabemos desde que las tarjetas perforadas eran el único medio para interactuar con un ordenador.
Los errores son algo inherente a la creación de aplicaciones informáticas y por eso los desarrolladores, desde siempre, han realizado baterías de pruebas para su detección antes de cualquier salida a producción. Pero en la mayoría de los casos estas pruebas se circunscribían a test unitarios (pruebas básicas de funcionamiento de cada módulo desarrollado) y de integración (que analizan el buen comportamiento del software como un todo, una vez integrados todos sus módulos) realizados por el mismo equipo de desarrollo.
Pero tanto las tecnologías como los requisitos de los clientes se sofistican. El time-to-market se acorta y la incorporación de nuevas funcionalidades se vuelve imprescindible frente a una competencia cada vez más feroz. Para cumplir los plazos de entrega sin devaluar la calidad ya no es suficiente con las pruebas tradicionales y un plan «casero» de calidad del código asumido por el mismo equipo que desarrolló la aplicación. Se hace imprescindible la creación de un proceso que asegure la calidad de principio a fin.
Es en este punto donde se hace imprescindible el rol del QA, pero ¿qué es exactamente? Pues según la Wikipedia: “El aseguramiento de la calidad (Quality Assurance, QA) es el conjunto de actividades planificadas y sistemáticas aplicadas bajo un sistema de Gestión de la Calidad para que los requisitos de calidad de un producto o servicio sean satisfechos.”
Si aplicamos este concepto a la producción de software, la necesidad de un QA surge de este compromiso de calidad. Todo equipo de desarrollo medianamente organizado debería contar con al menos un responsable de asegurar que el software que se desarrolla funciona exactamente según las especificaciones pactadas. Esto no debe interpretarse como alguien que constantemente está corrigiendo los posibles bugs que surjan, se trata más bien de un facilitador para la realización de pruebas de testing que demanda el software. no se limita a detectar fallos, su misión es anticiparse y verificar toda la casuística posible para ser validada por el equipo de desarrollo y el cliente.
¿El cliente?, ¿Qué tiene que ver el cliente con los posibles errores en el desarrollo? Como veremos, mucho.
QA Ágil
Normalmente hoy día, cualquier proyecto de software que sea digno de llevar ese nombre, aplica alguna metodología Ágil en su desarrollo. Ya sea la veterana Kanban, Scrum o un “mix” de las dos, el equipo de QA debe someterse a sus plazos de entrega y revisión de los sprints pactados. Además, QA debe ser una de las interfaces entre el cliente y desarrollo, entre el Product Owner y el equipo técnico.
En resumen, el QA y su equipo deben ayudar al negocio (o al PM) a convertir las necesidades del cliente (integradas en los diferentes sprints) en pruebas y después validar los criterios de aceptación del software usados por los desarrolladores.
Con lo dicho hasta ahora no es difícil intuir que un QA está presente a lo largo de todo el ciclo de vida del proyecto. En efecto, el QA participa en la fase preliminar de análisis para obtener el máximo número de datos posibles monitorizando los resultados, y no deja de hacerlo hasta el cierre y las pruebas finales de estabilización antes de la entrega.
Tanto es así que cuando el jefe del proyecto tenga una duda sobre una fase del desarrollo, puede ser el QA el que lo asesore y supervise lo que está ocurriendo. De esta manera mejora la compenetración entre ambos roles y evitamos que los programadores inviertan su tiempo en tareas alejadas de sus responsabilidades.
No nos equivoquemos, un QA no es un Project Manager y tampoco su ayudante. Aunque es cierto que un QA supervisa a todo el mundo, su verdadero objetivo de un QA es anticiparse a los posibles errores presentes o futuros. Pero dado el nivel de conocimiento (tanto funcional como técnico) necesario para ejercer este rol, resultará un valioso aliado para cualquier PM inteligente.
QA en el ciclo de vida del proyecto
Aunque para la realización de un proyecto no existe un ciclo de vida totalmente estandarizado, en la práctica todos sabemos cómo va esto. Desde el punto de vista del QA la cosa no varía mucho, veamos:
FASE 1 – Análisis. La fase más delicada y en la que mayores esfuerzos debemos poner. En este punto gestionar las expectativas del cliente es tan vital como entender exactamente que necesita. Si lo hacemos bien, tanto el cliente como nuestro equipo tendrán perfectamente especificado el trabajo a realizar, eliminado las posibles malinterpretaciones en el futuro. En esta fase el equipo de QA podrá empezar a planificar las baterías de pruebas (manuales y automáticas) que mejor se adapten a las especificaciones recogidas.
FASE 2 – Desarrollo: Esta es la fase más larga, complicada y costosa de todo proyecto, tanto para los programadores como para el QA. Mientras el equipo técnico implementa las especificaciones con los lenguajes de programación, bases de datos y tecnologías más adecuadas, el equipo de QA implantará los entornos de pruebas que mejor se ajusten a las especificaciones y tecnologías implicadas.
FASE 3 – Puesta en Marcha: Ya lo tenemos, el grueso del desarrollo ha finalizado y los sprints se han cerrado satisfactoriamente. Todo debe ejecutarse correctamente y se debe comprobar una y otra vez que cada funcionalidad incorporada funciona según se especificó. Ahora la labor del QA es fundamental ya que no solo debe realizar un control de calidad exhaustivo, sino que también debe coordinar a todo el equipo y comunicarse con el cliente para el visto bueno final.
FASE 4 – Mantenimiento: Dado que el proyecto ha sido ya entregado (y facturado si todo ha ido bien), muchas veces el mantenimiento no se ve como una fase real, pero forma parte del ciclo de vida de cualquier proyecto. El equipo no puede retirarse del todo porque la cosa está lejos de finalizar: Estabilización, reparación de pequeños bugs (si, siempre estarán con nosotros), supervisión, pequeñas (o no tan pequeñas) mejoras, planificación de evolutivos…
El trabajo no ha acabado y para el QA tampoco: Reportes analíticos, control de calidad, soporte al equipo técnico, supervisión de actualizaciones, test de aceptación de usuarios reales (UAT), test de regresión para confirmar que esté todo correcto…
Todos sabemos que lo más difícil de cualquier proyecto es cerrarlo, darlo por terminado y poder irnos a casa con la satisfacción del deber cumplido. Un equipo de QA no hará que esta tarea deje de ser complicada, pero, como habéis visto, nos facilitará mucho las cosas.
Tipos de pruebas
Existen muchos tipos de pruebas y su elección dependerá del tipo de software y de los métodos de desarrollo escogidos en cada caso. A continuación, describiremos las más comunes, pero no es un listado exhaustivo. Incluso pueden desarrollarse baterías de pruebas híbridas compuestas de más de un tipo.
Las pruebas unitarias se encuentran entre las pruebas de control de calidad más antiguas y fáciles, ya que implican probar los módulos o funciones más pequeñas por separado. Son las que todos hacemos una vez desarrollada una pequeña función: probar si funciona. De hecho, en la mayoría de los casos, son los propios programadores los que las diseñan.
Normalmente estas pruebas se ejecutan en local y no están diseñadas para probar componentes vinculados a una base de datos o servicios web remotos. Su sencillez y nula implicación con el resto del proyecto hacen que sea fácil diagnosticar un error.
Pero no por sencillas dejan de ser importantes: Son la base de un buen plan de calidad. Dentro de la metodología TDD – Test-Driven Development (desarrollo guiado por pruebas), cada módulo de código se somete a pruebas unitarias de forma repetitiva y solo se agrega al software cuando ha sido 100% satisfactoria.
Las pruebas de integración son el siguiente paso natural. Aquí se prueban varios módulos o componentes relacionados y se verifica que su comunicación sea óptima. El ejemplo más sencillo es la conexión de nuestro módulo a un servicio web determinado.
Ya no aislamos un componente y observamos su reacción, ahora monitorizamos como dos o más componentes interactúan. Por ejemplo, realizamos un pedido en línea y observamos como se añade a la base de datos o como realiza el envío del correo electrónico de confirmación.
Tanto las pruebas unitarias como las de integración no son ninguna novedad en nuestro oficio, pero son la clave para asegurarnos de que la aplicación o funciona como un todo.
Las pruebas funcionales o Black Box son muy parecidas a las de integración, pero mientras que estas últimas se aseguran de que la interacción entre componentes funciona, las pruebas funcionales nos aseguran de que la salida sea correcta.
Es decir, el código interno no se testea, solo los resultados que nos da (por eso en muchas ocasiones se denominan pruebas de Caja Negra). Por este motivo, para este tipo de pruebas el evaluador no necesita conocer o comprender el código que hay detrás.
Las Smoke Test o pruebas de humo se utilizan para probar la estabilidad de una compilación (build) determinada y determinar si las características más importantes están funcionando o no.
Si todo está bien, dicha compilación puede pasar a pruebas más extensas; si no, los desarrolladores pueden solucionar los problemas primero, antes de pasar más tiempo probándolo.
Las pruebas End-to-End son pruebas de “extremo a extremo”: Se prueba absolutamente todo el sistema según se describe en el modelo funcional realizado en la fase de análisis. Como podéis adivinar son clave para asegurarse de que todo el sistema se ejecuta según lo previsto.
Normalmente son las baterías de pruebas más completas, por lo que requieren mantenimiento frecuente y acceso disponible a cualquier servicio web o base de datos externa que use nuestra aplicación.
En proyectos medianos y grandes son tan relevantes que en ocasiones pueden ocasionar replanteamientos funcionales importantes
Las pruebas de carga y estrés se alejan del mundo funcional ya que se encargan de verificar que nuestra aplicación será capaz de dar respuesta al número de usuarios para la que está diseñada. Con ellas es posible detectar problemas que no veríamos revisando el código: La estabilidad de la base de datos, su integridad a medida que se escribe en ella o el límite de recurrencia de usuarios, por poner ejemplos sencillos.
Las pruebas de usabilidad están diseñadas sobre todo para entornos web y se encargan de verificar que el front-end del usuario cumpla las normas de usabilidad (agrupación lógica de opciones, número de clics utilizados, etc.).
Y por último, pero no menos importante, tenemos las pruebas de regresión que se encargarán de verificar que los cambios introducidos a posteriori en el código no induzcan nuevos errores en el módulo modificado o en la comunicación con los adyacentes.
Como vemos hay muchos tipos de pruebas (no las hemos listado todas, solo las más usadas), pero ¿debemos incluirlas todas en nuestro proyecto?, ¿cuáles?, pues depende… Si bien las pruebas unitarias y de integración son necesarias siempre, sea el proyecto que sea, las pruebas de carga y estrés (por ejemplo) no pintan mucho para una aplicación que usarán dos o tres usuarios. Sin embargo, ¿te imaginas que Facebook o Twitter no hiciera este tipo de pruebas? Sería un desastre asegurado. Lo dicho, depende.
Automatización de pruebas
Por muchos tipos de pruebas que hagamos o por mucho que las planifiquemos, un equipo humano siempre se dejará partes funcionales sin probar o habrá circunstancias especiales en las que nadie habrá caído.
Resulta imposible (además de muy caro) ser totalmente exhaustivo a la hora de probar absolutamente todas las posibilidades y combinaciones que nos plantea una aplicación de tamaño medio. Pero no os preocupéis, ¡vienen al rescate las pruebas automatizadas!
Una prueba automatizada no es más (ni menos) que una pieza de software diseñada para interactuar con nuestra aplicación, con el único objetivo de encontrar vulnerabilidades o inconsistencias en el código. Si está bien programada siempre será más exhaustiva que un operador ya que no dejará ninguna combinación posible por probar.
Básicamente hay dos entornos principales que se pueden automatizar:
- GUI (interfaz gráfica de usuario)
- Código / backoffice
Las primeras son todas las pruebas que replican la experiencia del usuario. Por ejemplo, realizar una serie de clics de ratón y pulsaciones de teclas para asegurarse de que el programa funciona según lo previsto. Las irregularidades o inconsistencias quedan grabadas para su reproducción y revisión.
La prueba se puede ejecutar exactamente igual cada vez, o utilizar diferentes características de la aplicación en cada iteración. De esta manera se consiguen resultados más precisos al generar informes de errores. La ventaja frente a un operador humano es obvia: la automatización acelera muchísimo el proceso y elimina cualquier error humano.
Las pruebas de API se utilizan para probar la aplicación en si sin tener en cuenta el interfaz de usuario, centrándose en las pruebas de comunicaciones y en los componentes de software individuales. Esto puede incluir tiempos de respuesta, formatos de salida de información, reacciones ante ataques de seguridad o el modo en el que nuestro software controla las condiciones de entrada de datos y su posterior procesamiento.
Software de ayuda a la automatización
Después de lo leído, automatizar parece la solución: Es más rápido (más barato) y sobe todo mucho más exhaustivo que las pruebas manuales convencionales, pero ¿Cómo lo hacemos? Hay muchas herramientas en el mercado que nos pueden ayudar y además de código abierto. Algunos ejemplos:
Selenium es una de las herramientas de prueba más populares. Es una plataforma integral en la que se pueden editar acciones o crearlas desde cero. También ayuda mucho en las pruebas de regresión porque guarda las pruebas realizadas para ser reutilizadas cuando sea necesario.
Selenium ofrece plug-ins para una variedad de lenguajes de programación y funciona con múltiples navegadores y sistemas operativos. Por ejemplo, se puede usar Selenium WebDriver para crear pruebas de regresión basadas en el explorador o Selenium Grid para ejecutar pruebas escaladas en varios equipos.
Su popularidad se basa en su buen funcionamiento, facilidad de uso, gran cantidad de plugins disponibles y su gratuidad. Selenium se presenta como software de código abierto (bajo licencia apache 2.0) y puede ser descargado y usado sin pagar un euro.
Cucumber es otra de las estrellas en el software de automatización de pruebas y resulta el compañero perfecto de Selenium. Cucumber es un framework que nos permite automatizar pruebas implementando la metodología BDD (Behavior-Driven Development), con la que podremos ejecutar descripciones funcionales en texto plano como pruebas de software automatizadas.
Gherkin es el lenguaje que permite crear estas descripciones funcionales, con la ventaja de que está diseñado para ser entendible por no técnicos (por ejemplo, personal de negocio, analistas funcionales o incluso representantes del cliente). A partir de esta premisa, una buena definición sería que Gherkin es un lenguaje natural estructurado.
Gracias a esta “claridad universal” del lenguaje, a la vez que se generan las pruebas se crea documentación viva que describe perfectamente cómo se comporta el sistema, enriqueciendo y manteniendo actualizada la documentación.
Cabe destacar que Gherkin es totalmente independiente de Cucumber (y Selenium) y es usado en otras plataformas como SpecFlow.
Ni que decir tiene de que estos tres ejemplos son una pequeña muestra de lo que nos ofrece el mercado. Como siempre busca, prueba y quédate con lo que más te guste
Como veis introducir el rol de QA en un proyecto, lejos de ser un molesto centro de costes que engordará nuestra factura, es una garantía de que las cosas saldrán como deben, con la calidad esperada y en el tiempo planificado.