QDev, ¿Una nueva forma de aplicar el testing?

Introducción

Después de bastante tiempo sin publicar nada debido a que entre otras cosas he estado centrado en el proyecto de la comunidad de NorthemQuality, vengo con un artículo que me hace especial ilusión.

Durante estos dos últimos años, en el equipo hemos tenido que trabajar en varios proyectos que han tenido que hacer que el rol de QA/E tenga que evolucionar a uno nuevo que nosotros mismos hemos definido.

En este artículo me gustaría explicar qué es lo que ha hecho que el rol evolucione y en que ha evolucionado!

El proyecto como punto de inflexión

Todo comenzó cuando tuvimos que enfrentarnos a un proyecto en el que veíamos que íbamos a tener que lidiar contra bastantes infortunios.

El primero de ellos era que no teníamos un product owner para el proyecto por lo que, no íbamos a tener unas tareas bien definidas y por lo tanto, no íbamos a tener unos criterios de aceptación claros.

El segundo era que no había una estrategia de calidad, por lo que el testing que se hacía no era eficiente, y además era un stopper a parte de no tener unos resultados fiables.

Por otro lado, no existía el concepto de equipos multidisciplinares por lo que el testing se hacía por otros equipos que no fueran el equipo owner del proyecto.

Todo esto sumado a otros factores, hacía imaginarnos que la forma de trabajar de la que veníamos como equipo no iba a funcionar.

Nuestro equipo estaba compuesto por un Tech Lead, tres desarrolladores y un QA/E.

La evolución a QDev

Como QA/E era mi responsabilidad el que el producto a parte de responder como se requería. Antes de este proyecto, la forma en la que lo hacíamos era definiendo y desarrollando el juego de pruebas funcionales y mediante la gestión de bugs.

Pero claro… vista la situación a la que nos teníamos que enfrentar, no iba a funcionar.

El equipo siempre ha defendido el modelo estratégico “Prevention & Reaction” que concebí en su día, pero hasta el momento no lo habíamos podido poner en marcha. Igual era la hora de empezar a aplicarlo en la medida de lo posible y comprobar si era viable, había que arriesgar.

Lo primero que hicimos fue pensar como equipo en cómo queríamos trabajar el testing, que necesitábamos y en base a las necesidades, identificar cuál serían las responsabilidad del QA/QE.

Siempre he defendido que el QA/QE en los equipos multidisciplinares debe ser un desarrollador más, al igual que diferenciamos entre fronteder y backender.

De aquí nació el rol de QDev!

El nuevo rol, QDev, tiene que crear una red de seguridad de calidad (QSN) que brinde al equipo la confianza suficiente de desarrollar, para eso debía entre otras cosas debe:

  • Responsabilizarse de definir y aplicar la estrategia de calidad. En nuestro caso nos basamos en el modelo “prevention & reaction”, que va muy alineado al trabajo del QDev.
  • Definir y desarrollar el SUT (system under test) del producto.
  • Trabajar codo con codo con el product owner desde el inicio del proyecto en la definición de los criterios de aceptación. Diseñar el plan de pruebas de cada técnica de testing que posteriormente se desarrollará.
  • Desarrollar las herramientas y frameworks necesarios de testing.

Pero para esto, es muy necesario hacer un cambio de mentalidad y entender que:

  • El QDev es un desarrollador más, especializado en el desarrollo de la estrategia y arquitectura de calidad. Debe hacer partícipe al equipo en las decisiones que se tomen al respecto, siempre de forma consensuada.
  • Todo el equipo es responsable de la calidad del producto. Por ejemplo puede ocurrir que la gestión de los bugs se haga entre todo el equipo.
  • El QDev no es un juez, no dictamina si algo está bien o mal, el es el responsable de desarrollar la QSN que lo hace.
  • Las pruebas son una herramienta más, no son el objetivo.

Ejemplo de trabajo de QDev

Para poder entender mejor el concepto de cómo debería trabajar o cómo debería ser un QDev, vamos a ver un ejemplo.

Imaginemos que el equipo está compuesto por un Tech Lead, un Product owner y varios desarrolladores, entre ellos backenders, frontenders y un QDev (o más).

Desde el comienzo todos deberían participar en la definición del producto y en su arquitectura. El QDev en este punto debería comenzar a definir la estrategia de calidad:

  • Pensar en las necesidades de la QSN. La idea principal es que el equipo trabaje sobre una QSN existente u operativa.
  • Empezar a definir a alto nivel la arquitectura del SUT (system under test).

Supongamos que de ese trabajo, el QDev ha diseñado la siguiente estrategia que apoya su idea del QSN. Lógicamente esto es solo un ejemplo, muy discutible y dependiente del contexto del producto o proyecto.

De esta estrategia lo importante es entender que el QDev va a trabajar desde el comienzo del producto. Trabajará sobre las diferentes técnicas de testing que haya definido en las diferentes fases.

Siguiendo esta estrategia, el QDev no solo deberá centrarse en diseñar las pruebas e integrar las diferentes técnicas de testing, si no que, necesitará desarrollar el SUT aislado (mocks, contenedores etc) para que el equipo ejecute las pruebas de forma aislada. Incluso desarrollará herramientas para facilitar el trabajo del equipo.

Otro punto importante es no olvidarse de la importancia de seguir con el testing en la fase de producción.

Conclusiones

El evolucionar el rol de QA a QDev y comenzar a hacer uso del modelo “Prevention & Reaction” (al menos una pincelada) en nuestro caso fue un caso de éxito, pero todo depende del contexto del producto y de la madurez del equipo.

En mi caso fue muy importante la cultura del equipo y cómo entendíamos la calidad como una responsabilidad de todos. Es más, había tareas de QA que estaban diluidas en el equipo, yo entendía perfectamente que ellos harían pruebas funcionales, ya me encargaría yo de hacer el code review. Algo muy interesante es que también hacíamos pair testing.

Lo más importante es entender que el QDev, es el encargado de la QSN del producto o del proyecto. Para ello deberá tener los conocimientos suficientes para desarrollar y aplicar la estrategia de calidad, así como el SUT.

Ser el encargado no significa que sea el único responsable, como he comentado, la responsabilidad debe ser compartida por todo el equipo, por lo que es muy importante que todos participen en aplicarla.

El éxito depende de la unión del equipo, no del éxito de cada individuo.

Intelligent testing, ¿Llega una nueva era?

Introducción

A través de un tweet de Lisa Crispin, llegue a un artículo del blog de Mabl, en el que hablaban un poco sobre el concepto de “intelligent testing”.


En este artículo me gustaría repasar los cuatro principios que se tratan del Intelligent testing. Si bien es cierto que el video del blog habla sobre cómo lo aplican a través de Mabl, intentaré ser agnóstico al producto.

¿Qué intenta resolver “Intelligent testing”?

Para entender el concepto de intelligent testing, creo que es necesario conocer los “defectos” del testing convencional (vamos a llamarlo así).

En mi opinión el testing convencional estaba pensado y muy acoplado a las metodologías de desarrollo convencionales. Con la entrada de las metodologías ágiles, el testing ha sufrido ciertos cambios intentando adaptarse, pero no siempre con el éxito que debería.

Esto ha provocado que el testing llegue a ser el cuello de botella del sistema de CI/CD. Para evitarlo y poder implementar el testing dentro de las metodologías ágiles, en muchas ocasiones se ha tenido que crear estrategias de testing muy acopladas al sistema de CI/CD, lo que tampoco es del todo correcto.

Creo que la evolución del testing siempre ha estado por detrás del desarrollo, cuando debería ir de la mano. También creo que gran parte de la culpa la tenemos los testers y QA/QEs que nos hemos ido adaptando al código y a la tecnología, en vez de estar a la altura. Debemos ser más preventivos y menos reactivos. Todavía nos queda mucho por aprender.

Lo que intenta el “testing inteligente” es básicamente eso, dejar que el testing sea el cuello de botella de nuestro desarrollo, y para eso se basa en cuatro principios.

1.º principio: Adaptarse a los cambios

Uno de los grandes problemas de la automatización, son los falsos positivos. Cuando lanzamos la suite de pruebas podemos encontrarnos con una gran número de fallos que tendremos que analizar, ya que seguramente un porcentaje de los fallos sea debido a falsos positivos.

Algunos falsos positivos vienen dados por cambios en el código que hacen que nuestro test falle, sin que en realidad sea un fallo de la aplicación. Esto suele ocurrir mucho en el caso de las pruebas de UI.

En las pruebas UI, nuestro test está acoplado a los componentes con los que interactúa, lo que hace que el test sea altamente sensible. Cuando por alguna razón el xpath o el selector del componente cambia, nuestro test falla. No quiere decir que sea error de la aplicación, es un caso de falso positivo.

Tenemos que adaptar manualmente el test y volverlo a lanzar. Esto supone una inversión de tiempo alto, por lo que somos un cuello de botella.

Lo ideal sería que el framework de testing sea lo suficientemente inteligente como para identificar el problema (un cambio del selector, en el caso anterior), identificar el cambio, probarlo y hacer los cambios en el test, de las forma que las siguientes ejecuciones vayan correctamente.

Claro, esto es relativamente “fácil” en las pruebas de UI. Pero qué ocurre si realizamos otro tipo de pruebas funcionales o de performance (porque recordemos que podemos integrar las pruebas de performance dentro de nuestro CI).

En estos casos no lo veo tan claro que sea tan fácil de adaptar el test. Supongamos que realizamos pruebas funcionales de API, lanzamos las pruebas y fallan debido a un cambio de contrato. Entiendo que si tenemos los contratos definidos y actualizados o hacemos uso de contract testing, podremos adaptar nuestros tests basados en esas fuentes de conocimiento.  

En el caso de las pruebas de rendimiento, debería depender de qué tipo de pruebas o sobre que se lancen (UI, API etc.), y adaptarse.

Otra opción que se me ocurre sería disponer de un sistema inteligente que “analice” los cambios y notifique o haga los cambios pertinentes en las suites de testing, sea del tipo que sea, funcionales, performance…

2.º principio: Testing desde el Cloud

 

Otra forma de reducir el tiempo de ejecución de las pruebas es la ejecución en paralelo. Las plataformas Cloud nos facilitan este hecho, ya que podremos disponer bajo demanda o escalar el número de ejecuciones y entornos sobre los que queremos lanzar las pruebas.

En el caso de las pruebas funcionales podremos reducir considerablemente el tiempo de ejecución, debido a que dividiremos las pruebas por el número de “ejecutores”.

En el caso de las pruebas de rendimiento podremos aumentar la carga o el número de usuarios virtuales sin penalizar el gestor de carga.Al lanzarlo sobre sistemas cloud podremos beneficiarnos de los servicios de estas plataformas, como sistemas de análisis (para analizar los resultados), heurísticos etc..

Cloud testing

 

3.º principio: El output debería ser más afirmativo y resolutivo

Como he comentado en el primer principio, tras terminar las pruebas, hay una fase de análisis de resultados. En muchas ocasiones (por no decir en la gran mayoría), cuando hay fallos, los resultados no son del todo claros y nos toca invertir tiempo en ver cual es el problema.

Esta inversión de tiempo, una vez más, nos lleva a ser un cuello de botella para los resultados, y en otras ocasiones a que se nos escapen bugs, debido a la falta de atención que ponemos en su resolución.

El que las pruebas den un output con la información necesaria (ni exceso, ni defecto) y esa información llegue a ser resolutiva, es tan importante como unos buenos teses. De nada sirve tener un test perfecto, si los resultados no son lo suficientemente informativos.

Hoy en día sacamos trazas (en ocasiones excesivas) y screenshots (en ocasiones confusos), pero no es suficiente para reducir el tiempo de análisis de los resultados.

Bajo mi punto de vista, tenemos que invertir muchos más esfuerzos en mejorar este punto. La parte buena es que los sistemas heurísticos y de machine learning cada vez están más avanzados, y creo que de alguna forma podremos integrarlo con el testing.

Creo que sería interesante disponer de un output inteligente, donde en base a los resultados obtenidos, comparándolo con una fuente de conocimientos de otros resultados anteriores y los cambios realizados, podamos dar unos resultados, no solo con buena información, si no, con el problema detectado y parte de su resolución.

4.º principio: Testing integrado en el CI

Este último principio creo que es el que está más integrado. Actualmente hay pocas empresas que no tengan el testing integrado en el sistema de CI/CD. Ya son muchos sistema de CI que disponen de plugins para muchos frameworks de testing.

El problema es que si no se cumplen los otros tres principios, el testing seguirá siendo el palo en la rueda del CI.

Conclusiones

El testing inteligente es un muy buen concepto que acerca cada vez más la posibilidad de estar a la altura de la evolución del desarrollo, creo que todavía queda por evolucionar varios aspectos, pero es factible, lo que es muy buena noticia.

Parte de esa responsabilidad recae en los testers y QA/QEs que creo que necesitamos una evolución como concepto y rol. No podemos seguir anclados en el probar el software, ni en la idea idílica de “garantizar la calidad”.

La tecnología de hoy en día, el cloud, la heurística, nos permite dar un paso más adelante y ayudarnos a anteponerse a los errores, más que encontrarlos.

Aislando nuestras pruebas con Testcontainer

Introducción

Hace unos días escribí sobre las pruebas aisladas e integradas. Uno de los mayores retos en nuestra estrategia de testing es el hecho de intentar aislar nuestras pruebas.

Hemos visto cómo aislarlas mediante contract testing, pero; ¿Cómo aislamos nuestras pruebas de integración o las funcionales?

En este post vamos a hablar sobre Testcontainer, una librería de java que nos provee instancias ligeras de cualquier contenedor de Docker (bases de datos, navegadores, servicios etc.).

Como siempre vamos a ver los ejemplos con un proyecto que podréis descargar desde GitHub.

Vamos a ello!

Aislando las pruebas del proyecto

App architecture
El proyecto de ejemplo es sencillamente una aplicación conectada a una base de datos MySQL y que consume a encoder-service,  un servicio propio, que es usado por todas nuestras aplicaciones.

Vamos a desarrollar pruebas de integración. Comprobaremos que nuestra aplicación comunica correctamente tanto con la base de datos, como con el servicio.

Mediante Testcontainer cuando ejecutemos las pruebas, se levantará un contenedor Docker de MySQL y otro de encoder-service.

Una de las preguntas que os podéis hacer, es el porqué levantar un contenedor del servicio, si lo podemos mockear. Hay ocasiones en las que cuando realizamos pruebas, necesitamos recibir un comportamiento real, y no uno esperado. Este ejemplo pretende acercarse a esa realidad.

Test architecture

Añadiendo Testcontainer al proyecto

Vamos a añadir dos dependencias a nuestro proyecto. Las dependencias generales de Testcontainer, y la dependendencia de testcontainer de MySQL.

Además de añadir las dependencias de Testcontainer, deberemos tener las dependencias del conector de MySQL y Spring data.

Pruebas de integración sobre MySQL Testcontainer

Lo bueno de utilizar Spring Data JPA,  es que nos facilita la implementación y por tanto el uso de la capa de datos. Testcontainer se adapta muy bien a Spring Data JPA debido a que nos provee un driver jdbc que gestiona el contenedor de base datos.

Lo que nos interesa es ejecutar el contenedor de MySQL en tiempo de test, por lo que la configuración la vamos a añadir en el directorio test.

En la configuración de JPA, es importante destacar la propiedad de ddl-auto. El valor que vamos a indicarle es create-drop, de esta forma cuando se instancie el contenedor, se creará la base de datos con nuestra entidades.

Para las pruebas vamos a añadir unos datos iniciales a la base de datos, por lo que cuando se creen las tablas, se ejecutará el fichero data.sql. Para ello es importante que la propiedad initialization-mode tenga el valor always, en la configuración de datasource.

Lo más importante es driverClassName, donde indicaremos el driver de Testcontainer. En la propiedad de la url de conexión, el hostname, el puerto y el nombre de la base de datos van a ser ignorados.

El test que es muy sencillo, únicamente comprueba que se almacena y se leen los datos de la base de datos. Lo importante es sacar la conclusión de que el uso de testcontainer es totalmente transparente para el test, es decir, el test no sabe que está ejecutando las pruebas contra un contenedor de MySQL. Por lo que sí tenemos la necesidad de cambiar de base de datos o de versión de la base de datos, nuestras pruebas no se van a ver afectadas.

testcontainer results

 

Pruebas de integración sobre enconder-service Testcontainer

Primero, hemos tenido que “dockerizar” el encoder-service y añadirlo a nuestro local registry. Ahora en la configuración test de nuestra aplicación vamos a añadir el fichero docker-compose, con la configuración mínima para instanciar el contenedor de nuestro servicio.

En este caso, nuestro test si va a estar acoplado a las dependencias de Testcontainer, debido a que tenemos que hacer uso de docker compose.

Como hemos comentado, dado que queremos instanciar el contenedor de nuestro servicio desde el fichero de docker-compose.yml, vamos hacer uso de DockerComposeContainer, indicando el nombre del servicio y el puerto. En el test, obtenemos la url y el puerto del contenedor mediante getServiceHost y getServicePort. Realmente es muy sencillo.

testcontainer result encoder service

Conclusiones

Testcontainer nos permite aislar nuestras pruebas de forma muy sencilla. Mediante Spring data JPA y Testcontainer nuestras pruebas de integración de base de datos estarán totalmente desacopladas.

La mayor pega puede ser el hecho de que si queremos hacer uso de Docker compose, nuestras pruebas no van a disfrutar de la virtud de estar desacopladas de Testcontainer.

Al aislar las pruebas reducimos el tiempo de prueba, debido a que no necesitamos hacer conexiones reales y reducimos el número de falsos positivos por fallos en el otro extremo.

El sistema de CI/CD se puede ver muy beneficiado, dado que no vamos a necesitar desplegar todos estos servicios, BBDD etc. en nuestro entorno, por lo menos en entornos previos al stage o preproducción, y los desarrolladores podrán probar con mayor fiabilidad su código.

Además, Testcontainer nos proporciona librerías para hacer pruebas de UI, por ejemplo con Selenium. Y bueno… como habéis visto en el caso de encoder-service, cualquier aplicación dockerizada se podrá instanciar con testcontainer.

¿Un QA puede ser también developer?

Assert QA == Developer


¿Es un QA un developer?
Me gusta hablar con la gente. Me gusta compartir opiniones. Me gusta debatir. Tras varias conversaciones con compañeros de trabajo, de los que he podido obtener de una forma u otra feedback de lo que creen que es el trabajo de un QA Engineer, me he propuesto a escribir un post que ayude a romper ciertas barreras mentales en el trabajo que creemos que hace un ingeniero de calidad y ver si en realidad es un developer.

Ingeniería de la calidad del software

La realidad es que poca gente conoce lo que es la ingeniería de la calidad. No es algo conocido, no es algo que llame la atención cuando decides estudiar informática, es la realidad.

Cuando un desarrollador habla de un QA, no piensa que desarrolle, no lo trata como un desarrollador. Es más, muchos piensan que los QAs son desarrolladores frustrados, y no es cierto.

¿Porque cuesta tanto ver la ingeniería QA como una rama de la ingeniería del software, del desarrollo?

Cuando se piensa únicamente desarrollamos pruebas se está muy equivocado. La calidad del software no solo se garantiza con teses.

Desarrollamos teses, ¡por supuesto que sí! Y en muchas ocasiones la lógica que implementamos en el test puede ser más compleja que el código o la funcionabilidad que probamos. Y si… sabemos lo que son los patrones… es más, los aplicamos.

Para garantizar que el software cumple con los requisitos de calidad exigidos los QAs deben diseñar y aplicar las estrategias de calidad necesarias. Y muy seguramente en esas estrategias se implementen diferentes proyectos, desde automatización de pruebas hasta proyectos más complejos, y adivinad, muchos de ellos habrá que desarrollarlos.

Automatización de pruebas

Automatizar pruebas funcionales no siempre significa automatizar el comportamiento de una funcionalidad mediante UI testing. En muchas ocasiones se requiere hacer pruebas funcionales a nivel de API, o probar funcionalidades cross-aplicación y cross-dispotivo.

Aquí os dejo los enlaces a la presentación y explicación de cómo Uber realiza pruebas cross-aplicación y cross-dispotivo para probar sus aplicaciones mediante Octopus.

POST:
https://eng.uber.com/rescued-by-octopus/
SLIDE:
https://docs.google.com/presentation/d/1vYXhkvgLKun72Ix91LQDDWZQdcY5VOBqKVvI1Y6riYo/pub?slide=id.gd8d657045_0_0

VIDEO:
https://www.youtube.com/watch?v=p6gsssppeT0

Para mi es importante entender que un QA no es una persona dedicada únicamente a automatizar pruebas o a realizar testing. Es un ingeniero capaz de desarrollar las herramientas necesarias que ayuden a garantizar la calidad de la aplicación.

Lo que significa que un QA es un desarrollador especializado en la calidad.

Sí, somos un equipo

Una de las cosas que me dijeron era que si el que desarrollaba la tarea hacia bien su trabajo no tenía por qué meter bugs, y ya que sabía lo que estaba desarrollando y donde afectaba él podría hacer las pruebas, por lo tanto, los QAs sobraban.

Bueno, en un mundo perfecto donde el desarrollador está encantado de probar todo lo que hace, y donde el tiempo de entrega no existe, en el que nunca se equivoca, puede ser…¡pues tampoco! Que te diga coca cola o Samsung que no hacen control de calidad de sus productos… igual sus móviles explotarían.

Es necesario desarrollar estrategias y proyectos que garanticen la calidad de nuestras aplicaciones, equipar al equipo de desarrollo con las herramientas suficientes para hacer código de calidad, para agilizar su desarrollo.

Cada equipo somos piezas del desarrollo. Desarrollo, DevOps, Producto, QA etc.

Conclusiones

Antes de ser QA fuí desarrollador, y hoy en día sigo desarrollando casi al mismo nivel que antes, salvo que antes funcionalidades de una aplicación, y ahora herramientas que garantizan su calidad. ¿Qué diferencia hay?

Los QAs también somos desarrolladores, es la realidad, y primero nos lo tenemos que creer nosotros para que los demás se lo crean.

 

 

 

 

Estrategia Prevention & Reaction – Parte III

Introducción

En el segundo capitulo vimos cómo aplicábamos la estrategia Prevention & Reaction en tiempo de producción. En el último post de la serie, vamos a ver un ejemplo de organización de equipos QA que garantizan la estrategia en todas sus fases y contextos.

Equipos de trabajo

stategy teams

Para poder garantizar la calidad del software siguiendo la estrategia se crea una estructura grupal en la que cada grupo de trabajo se dedica o toma la responsabilidad de áreas concretas de la calidad del software.

La importancia de la estructura grupal planteada reside en la necesidad de cohesión de los grupos de trabajo, debido a que las tareas realizadas por un equipo son necesarias para otro.

Esto genera la posibilidad de disponer de personas multidisciplinares, es decir, personas que puedan participar en distintos grupo de trabajo a la vez, o permitir la rotación grupal.

La imagen muestra la cohesión de la que estamos hablando, así como la cobertura de cada grupo.

De forma general, se puede apreciar que el grupo strategy  abarca los demás grupos, debido a que sus decisiones afectan a todos los grupos.

Otro ejemplo es el equipo de Testing, el cual abarca las células de desarrollo dado que tiene que dar servicio y soporte de testing.

Vamos a ver la responsabilidad de cada grupo.

Equipo de estrategia

De forma general, el equipo de estrategia debe procurar mantener la estrategia y tomar decisiones importantes sobre la misma, debiendo corregir el rumbo cuando no se siga el camino previsto.

Las responsabilidades más importantes son:

  1. Diseñar la estrategia: Este equipo debe tener siempre presentes las necesidades en cuanto a la calidad del software se refiere y desarrollar una estrategia de calidad que las cubra.
  2. Definir KPIs: Los KPIs servirán para ver si la estrategia sigue el buen camino. En el caso de que los KPIs nos muestren indicios de que no se cumplen los objetivos preestablecidos, se podrán tomar decisiones con antelación para así poder pivotar la estrategia.
  3. Integrar la calidad en el CI: Hemos visto en las diferentes fases que la estrategia requiere estar presente en el flujo de la integración continua; es, precisamente, el equipo de estrategia el que deberá garantizarlo.

Equipo de datos

Durante el análisis que hemos hecho de la estrategia, hemos recalcado la importancia de obtener los datos de los resultados de las pruebas, de los datos de producción y de disponer de un sistema de predicción de bugs.

Las responsabilidades más importantes son:

  1. Obtención de datos de pruebas: Se deberán desarrollar las herramientas necesarias para obtener los datos de los resultados de las pruebas. Como hemos ido diciendo durante la serie de posts, los datos obtenidos nos servirán para alimentar la heurística del sistema de predicción de bugs, así como para mantener un histórico de resultados.
  2. Obtención de datos de producción: Los datos de producción van a servirnos para disponer de datos objetivos que nos ayuden a crear un mapa de calor de acciones, o bien como datos de entrada para las pruebas. Si nos fijamos en los logs de producción, podremos localizar trazas de errores y adelantarnos a solucionarlos o a reportarlos.
  3. Obtención de datos para KPIs: Los KPIs son indicadores o métricas que nos aportan conocimiento del estado de las acciones que estamos realizando. Mediante los KPIs seremos capaces de detectar defectos en nuestra estrategia o, por el contrario, ver el éxito de la misma. El equipo de datos debe desarrollar las herramientas necesarias para poder obtenerlos.
  4. Análisis y reporte de los datos: El análisis de los datos es de las acciones más importantes que debe realizar el equipo, dado que los resultados de los análisis son decisivos para la estrategia.

El equipo de datos tiene que trabajar estrechamente con los demás equipos de QA, debido a que va a necesitar extraer datos de todas las pruebas, así como de los resultados de la validación de las RCs o de la gestión de bugs. Estos datos serán analizados junto con el equipo de estrategia.

Equipo de automatización

El equipo de automatización deberá desarrollar los proyectos o herramientas necesarias para la ejecución de las pruebas automáticas. Los proyectos no tienen por qué ser únicamente desarrollo de pruebas automáticas; el equipo de automatización también se encargará de desarrollar los frameworks necesarios para el desarrollo de las mismas.

Las responsabilidades más importantes son:

  1. Framework de desarrollo de pruebas: Para muchos casos es necesario desarrollar, adaptar o mejorar un framework de testing. El equipo de automatización tiene que proveer ese framework a los equipos que desarrollen pruebas automáticas, ya sean ellos mismos o los desarrolladores.
  2. Desarrollo de pruebas funcionales: A pesar de que los desarrolladores implementen pruebas funcionales de sus tareas, es posible que el equipo de automatización necesite realizar unas pruebas automáticas de más alto nivel. Dentro de estas pruebas, se pueden listar también pruebas E2E, API, Mobile etc.

Es necesario que el equipo de automatización trabaje estrechamente con los departamentos de producto y de desarrollo, debido a que las pruebas que se desarrollen van a depender mucho de las conversaciones entre los diferentes departamentos.

Equipo de Rendimiento y Seguridad

El rendimiento y la seguridad de nuestra aplicación son unos de los valores más importantes que tenemos que garantizar, pero no siempre son los más sencillos. El equipo de rendimiento y seguridad se deberá encargar de desarrollar las pruebas necesarias que garanticen la calidad de ambos aspectos.

Las responsabilidades más importantes son:

  1. Pruebas de rendimiento: Disponer de una suite de pruebas de rendimiento (pruebas de carga, estrés, estabilidad, etc.).
  2. Pruebas de seguridad: A pesar de que los desarrolladores implementen pruebas funcionales de sus tareas, el equipo de automatización es posible que necesite realizar unas pruebas automáticas de más alto nivel. Dentro de estas pruebas, se pueden listar también pruebas E2E, API, Mobile etc.

El equipo de rendimiento y seguridad debe trabajar estrechamente con el departamento de sistemas o sysop, debido a que sus pruebas van a tener impacto en los entornos y en la aplicación.

Equipo de Testing

Dentro de las tareas más importantes se encuentra el validar o rechazar la RC y para ello es necesario que el equipo de testing realice las pruebas correspondientes. Por otro lado, el tratamiento de bugs y las pruebas bajo demanda también son tareas del equipo de testing.

Las responsabilidades más importantes son:

  1. Validación de RCs: Sacar la RC adelante es la finalidad de todos (desarrolladores, sys, QA, producto etc.), por lo que es la tarea más importante del equipo de testing. En caso de que en tiempo de RC en la fase de prevención todo haya ido bien, en fase de reacción los testers deberán buscar cualquier fallo crítico y, en caso de localizarlo, rechazar la RC.
  2. Pruebas bajo demanda: En ocasiones es necesario realizar pruebas bajo demanda sobre una tarea en concreto. Se suele hacer cuando la tarea es compleja o crítica. De esta forma, nos podremos asegurar que no vamos a meter fallos en la RC.
  3. Diseño de casos de prueba: Sin casos de pruebas no se sabe qué probar. El equipo de testing deberá diseñar los casos de prueba necesarios para la validación de la RC, o para el testing bajo demanda.
  4. Tratamiento de bugs: Cuando en producción se localiza un fallo o un bug es necesario reportarlo. El equipo de testing tiene que reproducirlo y aportar la información necesaria al equipo de desarrollo para que lo solucionen. Un aspecto, en mi opinión, importante y a veces olvidado es que disponer del conocimiento suficiente para entender el código de la aplicación ayudará al tester a obtener más información del error. De este modo, el desarrollador invertirá menos tiempo en solucionarlo.

El equipo de testing tendrá que trabajar estrechamente con el equipo de producto y desarrollo para obtener la información necesaria que permita preparar los casos de prueba frente a posibles bugs.

Conclusión final

Durante la serie de posts, hemos visto en qué se basa la estrategia de “Prevention & Reaction”. Es una estrategia teórica, basada en mi experiencia como QA, en lo que he aprendido estos años y en cómo hoy en día enfocaría el trabajo para garantizar la calidad en un entorno de desarrollo ágil.

La finalidad de la estrategia es garantizar la calidad desde una etapa temprana. Su base principal son los datos y el análisis de los mismos, pero también puede ser su punto débil, debido a que al comienzo de la implementación de la estrategia no disponemos de los datos suficientes. No obstante, como suele ocurrir, su punto débil también es su punto fuerte.

A medida que dispongamos de más datos, la heurística de nuestro sistema de predicción de bugs será mejor y, por lo tanto, nos ayudará a reducir el riesgo de dejar pasar fallos a producción.

Estrategia Prevention & Reaction – Parte II

Introducción

En el capitulo anterior vimos en qué se basaba la estrategia de Prevention & Reaction y cómo la aplicábamos en tiempo de RC. En esta segunda parte vamos a ver qué es el tiempo de producción y qué herramientas de calidad utilizamos para poder aplicar la estrategia Prevention & Reaction.

Tiempo de Producción

production time

Denominamos tiempo de producción al estado en que la release ha llegado a desplegarse en los entornos de producción. El software ya se encuentra disponible para que los usuarios lo utilicen, por lo que los errores que hayamos dejado pasar en tiempo de RC serán detectables por los usuarios. Las herramientas de calidad que actúan en tiempo de producción nos ayudarán a prevenir esta situación.

Prevención en tiempo de Producción

Prevention in production time
Las herramientas de prevención en tiempo de producción tratan de obtener información del estado y de las acciones de los usuarios y así poder utilizarlas en tiempo de RC. La información que obtengamos del entorno de producción nos servirá para adelantarnos a problemas aún no descubiertos por los usuarios, así como servirnos de datos para nuestras pruebas previas.

La información principal que obtendremos de producción es la siguiente:

  1. Trazas de errores: Lo que nos permitirá detectar bugs antes de que los usuarios sean conscientes, o proveernos de información para solucionar los fallos.
  2. Acciones de usuario: Hay ocasiones en las que los usuarios realizan acciones que no son contempladas por el equipo QA; con esta información podremos obtener mapas de calor de acciones y ajustar y mejorar nuestros casos de prueba.
  3. Datos de entrada: Obtener datos de entrada reales para nuestras pruebas puede ayudarnos a aumentar de alguna forma nuestra cobertura.

 

Como se puede observar, las herramientas que se plantean intentan obtener información para ayudar a las fases anteriores de la estrategia y así minimizar el riesgo de inserción de bugs en RCs futuras.

Reacción en tiempo de Producción

reaction in production
Cuando el software se encuentra en producción es probable que el usuario reporte bugs o, en el peor de los casos, que sea necesario tratar un fallo bloqueante que requiera de un hotfix. Las estrategias en tiempo de producción intentan manejar estas situaciones.

Bien es cierto que el tratamiento de bugs y el protocolo de actuación frente a la necesidad de realizar un hotfix es muy personal a la empresa, pero  lo que aquí intento mostrar es una estrategia básica del tratamiento de un caso de hotfix.

Aparte de las dos etapas clave de desarrollo de la solución y posterior fase de pruebas por parte del equipo de QA, es muy importante recabar la información necesaria para alimentar la heurística del sistema de predicción de bugs del que hablamos en el capítulo anterior, así como para hacer análisis y retrospectivas.

Conclusiones y adelanto

El capítulo aporta puntos bastante importantes en cuanto a las estrategias que seguimos en el tiempo de producción. Cuando la aplicación se encuentra en producción, los usuarios se toparán con los errores a no ser que podamos prevenirlos mediante la información que vamos obteniendo a lo largo del proceso.

Debemos disponer de un protocolo para tratar los errores bloqueantes: el protocolo debe ser lo suficientemente eficaz para que el impacto, tanto para el usuario como para el negocio, sea mínimo. Esto se traduce en un protocolo que nos aporte garantías en cuanto a la validez de la solución, así como rapidez en el desarrollo de la misma. Estos errores nos deben ser de ayuda para prevenir errores futuros.

La mayor fuerza estratégica de Prevention & Reaction la encontramos en tiempo de RC, ya que un error en producción es una muestra de que la estrategia no se está aplicando correctamente. No obstante, no debemos darle menos importancia al tiempo en producción ya que nos aporta una gran información con la que podremos mejorar nuestras pruebas.

En el próximo y último capitulo veremos como aplicar la estrategia mediante grupos de trabajo.

Estrategia Prevention & Reaction – Parte I

Introducción

Con las metodologías ágiles, el software se encuentra en un desarrollo continuo, de una forma iterativa e incremental, de forma que la mayoría de empresas despliegan diariamente una o más versiones de su aplicación.

Este hecho provoca que las estrategias de aseguramiento de la calidad (de ahora en adelante QA) deban adaptarse, dado que únicamente cubrían las necesidades de las metodologías tradicionales.

Actualmente existen empresas que implementan metodologías ágiles sin la necesidad de perfiles de calidad, siendo los desarrolladores quienes la aplican, mediante el desarrollo de pruebas unitarias y de integración. Esto es debido a que los equipos de calidad pueden demorar o ser un bloqueo en dichas iteraciones de desarrollo.

Otorgar la totalidad de la responsabilidad de la calidad del software a los equipos de desarrollo puede ser una estrategia poco acertada, por lo que es necesario re-definir el concepto o la idea de la calidad en el software y adaptar los equipos de QA a las nuevas metodologías.

Tras en análisis anterior se me ocurrió como trabajo personal desarrollar una estrategia que aplicara esa idea. La estrategia “prevención y reacción” pretende adaptarse a las metodologías y equipos ágiles garantizando la calidad del software, tanto en fases de desarrollo como en fases posteriores y puesta en producción.

Contextos de prevención y reacción

El término de prevención se refiere a evitar la inserción de bugs en el desarrollo; por el contrario, el término de reacción se refiere a la actuación de localizar los fallos y al tratamiento en caso de hacerlo.

Diferenciamos dos contextos o tiempos diferentes en los que operan las estrategias tanto de prevención como las de reacción: Tiempo de la release candidata (en ahora en adelante RC) y tiempo de producción.

Tiempo de RC

rc_time_contexts

Llamamos tiempo de RC al estado en la que la release no ha sido desplegada en producción. Comienza en la toma de requisitos del desarrollo hasta la fase de pruebas de la RC.

Prevención en tiempo de RC

strategies
Las estrategias de prevención en tiempo de RC tratan de evitar la inserción de bugs o errores en la RC, de tal forma que la RC llegue a la fase de pruebas lo menos impactada posible.

Las estrategias operan fundamentalmente en tres fases del desarrollo de la RC:

  • Fase de diseño: En la fase de diseño, el equipo de calidad debe obtener información de los criterios de aceptación por parte del equipo de producto. Se podría obtener en fase de requerimientos pero es probable que en la fase de diseño estén más definidos, por lo que aquella (la fase de requerimientos) sigue siendo una etapa temprana.
  • Fase de desarrollo: Implementación de un sistema de predicción de bugs. Nos garantizará una información objetiva de los riesgos de los desarrollos realizados en la RC, puntos conflictivos y propensos a fallo. Mediante un sistema de predicción se pueden focalizar las pruebas con mayor precisión y así reducir el tiempo de ejecución de las mismas.
  • Fase de pruebas: Antes de generar la RC (la cual se enviará a pruebas finales) es necesario que pase  pruebas de análisis estático, unitarias, integración y funcionales. El equipo de desarrollo será el encargado de desarrollarlas. La petición finalizará  una vez esté el desarrollo junto con las pruebas. Se realizarán pruebas bajo demanda por parte del equipo de calidad. Todos los resultados se analizarán y se utilizarán para el sistema de prevención y futuras retrospectivas.

Aplicación estrategias

La imagen muestra una forma de aplicar las estrategias de prevención en tiempo de RC.

  1. Se desarrolla la petición junto con las pruebas por parte del equipo de desarrollo. El sistema de predicción obtiene los datos de los cambios realizados.
  2. Se ejecutan las pruebas desarrolladas unitarias y de integración. Los resultados se almacenan para un posterior análisis. Esos datos servirán para alimentar la heurística del sistema de predicción de bugs.
  3. Se despliega la petición en un nuevo entorno.
  4. Se ejecutan las pruebas funcionales. Los resultados se almacenan tanto para el análisis como para el sistema de predicción.

 

Reacción en tiempo de RC

Reaction in RC time

Las estrategias de reacción en tiempo de RC tratan principalmente de localizar los errores que se nos han “pasado” en la fase de prevención. Dado que la RC ya ha sido generada, los errores ya se encuentran ella, por lo que es tiempo de reaccionar y localizarlos.

Es bien cierto que en esta fase se implementan estrategias o acciones que garantizan la calidad de la aplicación que en la fase anterior no se podrían aplicar.

Como se puede ver, la intención no es solo asegurar la calidad desde un aspecto funcional, si no que intentamos realizar pruebas que garanticen el rendimiento y la seguridad de la aplicación.

reacción rc

La imagen muestra una forma de aplicar las estrategias de reacción en tiempo de RC.

  1. Se despliega la RC en un entorno de pruebas.
  2. Se ejecutan las pruebas de calidad. (Funcionales, UAT, security, performance…) Los resultados se almacenan para un análisis posterior y como heurística del sistema de predicción de bug.
  3. Se acepta o rechaza la RC.

La fase de reacción en tiempo de RC es la última antes del despliegue en producción, lo que significa que localizar un bug en producción que se ha insertado en la RC es un caso de fracaso.

Conclusiones y adelanto

Hemos visto cómo aplicar la calidad del software en tiempo de RC en dos contextos diferentes: Preventivo y reactivo.

Entender los dos contextos nos ayudará a conocer las diferentes estrategias que aplicamos y saber el porqué. Garantizaremos la calidad del software desde etapas tempranas y focalizaremos la mayoría de nuestros esfuerzos a generar RCs validas. De esta forma ahorraremos tiempos en el testing, dado que centralizamos las pruebas y en el desarrollo, dado que minimizamos la aparición de bugs.

En esta fase es muy importante la obtención de los datos. Los resultados de las pruebas sirven para realizar retrospectivas que ayuden a valorar el éxito de la aplicación de nuestra estrategia de calidad, debido a que si en la fase de pruebas no encontramos fallos que posteriormente se encuentran en producción deberemos tomar medidas. En el caso de los datos de predicción, nos ayudarán a focalizar nuestras pruebas, por lo que tendremos más opciones de encontrar posibles fallos y reduciremos nuestro tiempo de testing.

En el próximo post de la serie analizaremos los contextos de prevención y reacción en tiempo de producción. Veremos cómo los datos de producción nos pueden ser de gran ayuda para adelantarnos a fallos y cómo nos servirán para objetivizar nuestras pruebas.

 

Explorando el “Exploratory Testing”

Introducción

 

Después de leer en varios blogs entradas sobre “exploratory testing” y como ha evolucionado desde 1.0, 1.5, 2.0 y 3.0 me he propuesto hacer un pequeño artículo para ayudar a valorar su importancia más allá de la teoría y ver su practicidad.
No voy a entrar a hablar sobre la evolución del testing exploratorio dado que James Bach ya lo explica de forma bastante detallada en en su artículo.

Exploratory testing

 

El ET (exploratory testing) sigue siendo una parte importante en la garantía de la calidad de nuestro software, a la que en menor o mayor medida no damos tanta importancia. La mayor importancia en los test exploratorios y clave para su éxito son sus bases o sus características:

  • Aprendizaje de la aplicación
  • Diseño de tests
  • Ejecución de tests

Resultado de imagen de exploratory testingEl QA deberá garantizarlas de forma simultanea a medida que va probando la aplicación, es decir, va diseñando las pruebas y ejecutándolas al tiempo que va adquiriendo conocimientos de la aplicación.

Esto puede generar disparidad de opiniones dado que al tester se le puede exigir un conocimiento del funcionamiento de la aplicación para poder validar las diferentes funcionalidades que la componen. Pero debemos ir un paso más adelante.  No estamos hablando de basar la calidad de la aplicación en este tipo de teses, si no de hacer uso de ellos para potenciar las habilidades de los testers y la búsqueda de bugs.

Algunos podréis estar de acuerdo conmigo, en el hecho de que cuando realizamos pruebas sobre una nueva funcionalidad o una nueva aplicación nuestra atención es mayor (menos comodidad, menos monotonía, desconocimiento de la funcionalidad etc), esto suele generar mejores resultados en cuanto a encontrar bugs.

Y como hemos podido observar la herramienta más importante para este tipo de test son las skills o las capacidades del tester en cuestión. Es importante disponer de la capacidad de pensar o diseñar los casos de prueba a medida que se avanza en las pruebas, discernir lo que es importante probar durante la sesión de pruebas, localizar los criterios de aceptación, en resumen, disponer de cierta experiencia e imaginación para el testing.

No obstante la experiencia se gana a medida que se hacen pruebas, por lo que es una muy buena herramienta para que los testers ganen y mejoren sus habilidades.

Experiencia y opinión

 

En el tiempo que llevo como QA lo cierto es que tengo más experiencia en la automatización de pruebas funcionales o manuales que exploratorias por lo que he dispuesto de un test plan (ya sea heredado o diseñado por mi) para desarrollar o ejecutar las pruebas.

Ahora cumpliré casi 10 meses en la empresa actual y realizamos  tanto automatización como pruebas manuales. Durante mi proceso de aprendizaje de la aplicación enfoque una gran parte del tiempo y del esfuerzo para realizar pruebas exploratorias lo que me ha llevado a tener un amplio conocimiento de la aplicación y a encontrar bugs que se salían del circuito “básico” de de pruebas. Hoy en día a pesar de que tenga interiorizado ese conocimiento y realice pruebas basadas en un test plan (que intento actualizar) suelo buscar un hueco para realizar pruebas exploratorias y sorprendentemente siempre suelo encontrar algún bug.

Siempre hay que tener en cuenta la situación o la estrategia del aseguramiento de la calidad de la empresa, pero como opinión personal creo que es importante implementar en la estrategia de calidad unas horas por recurso para que se realicen pruebas exploratorias. Esto va a ayudar a encontrar más fallos en la aplicación y sobre todo a mejorar las habilidades del tester.

Bibliografía

  1. http://www.satisfice.com/blog/archives/1509

 

Y que me dices de “Agile Testing Quadrants” – Parte III

Introducción a “Agile Testing Quadrants”

En los anteriores post de la serie hemos dado una pequeña introducción de lo que son los cuadrantes del testing  y las pruebas que realizamos en el primer cuadrante en “Y que me dices de “Agile Testing Quadrants” – Parte I” .

La importancia del segundo cuadrante y sus pruebas las tratamos en el post Y que me dices de “Agile Testing Quadrants” – Parte II” .

En este artículo vamos a hablar sobre el tercer cuadrante de los !Agile Testing Quadrants.

Agile Testing Quadrants

Tercer cuadrante – Q3

Para el cliente no solo es importante que el software funcione, el cliente espera que la aplicación funcione como tiene que funcionar en todos sus aspectos, es decir, que se cumplan todas sus necesidades y las “features” que se ofertan.

El tercer cuadrante de los “Agile Testing Quadrants” se preocupa de probar que el producto es el deseado, que la aplicación dispone de las funcionalidades que se han definido y que estás son correctas. En ocasiones nos encontramos con que se desarrolla una nueva funcionalidad que no es lo que espera el cliente, esto puede ser debido a que no se ha entendido bien los requerimientos, no se ha realizado un buen análisis o faltan casos por contemplar.

La clave de las pruebas del tercer cuadrante es ponernos en la piel del cliente, ya que vamos a intentar garantizar que se cumplen sus necesidades y que las funcionalidades son correctas.

En este tipo de pruebas emularemos el comportamiento del usuario mediante pruebas manuales. Realizar pruebas manuales requiere de ciertas habilidades por parte del tester:

  • Organización: Antes de realizar las pruebas es necesario organizar correctamente tanto las rutas de test para garantizar una buena cobertura como disponer de los datos necesarios para realizarlo.
  • Curiosidad: Durante el transcurso de las pruebas no puede faltar la curiosidad dado que vamos a tener que probar funcionalidades que probablemente no hayamos probado anteriormente.
  • Intuición: En muchos casos se detectan fallos o errores debido a que anteriormente nos hemos peleado con un escenario similar en el que hemos encontrado algún fallo. Este conocimiento nos dará cierta intuición en las pruebas.
  • Empatía: En muchos casos tenemos que ponernos en la piel del usuario para realizar ciertas pruebas. El usuario no siempre hace uso de las funcionalidades correctamente o no las utilizan como o para lo que se hicieron.

Me gustaría centrarme un poco más en el “Exploratory testing” pilar del tercer cuadrante. Este tipo de pruebas requiere de cada una de las habilidades que hemos hablado anteriormente. Durante la sesión el tester diseñará y ejecutará las pruebas analizando los resultados. La clave de este tipo de pruebas es que nos ayudará a aprender y a obtener mayor conocimiento de la aplicación que se está probando y lo más importante, a encontrar la mayoría de los bugs.

Como en los posts anteriores os hablaré de mi experiencia. Donde trabajo actualmente las aplicaciones que tenemos tienen muchos casos de prueba, muchas funcionalidades que aportan una mayor complejidad y mayor reto a los QAs. Normalmente me dedico a probar las RCs, a desarrollar pruebas automáticas y  a comprobar los bugs que se publican, pero cuando saco un rato libre me dedico a realizar “Exploratory testing” donde encuentro la mayor parte de los bugs, cierto es que son bugs antiguos que no han entrado con las nuevas funcionalidades. El realizar este tipo de pruebas me ha hecho aprender de la aplicación y a plantear dudas que se han podido traducir en conocimiento, bugs o en casos que no se han contemplado para dicha funcionalidad.

Conclusiones

 

El tercer cuadrante de los “Agile Testing Quadrants” se centra en comprobar que se cumplen las necesidades del cliente y que las funcionalidades de la aplicación son correctas. Para ello el tester tendrá que ponerse en la piel del usuario y disponer de ciertas habilidades que apoyen y den valor a las pruebas.

Uno de los pilares del tercer cuadrante es el “Exploratory testing” donde el tester durante la sesión diseñará, probara y analizará los resultados de las pruebas que va ejecutando manualmente, siendo el conocimiento aprendido de la aplicación uno de los objetivos más importantes.

Enlaces a la serie de posts

Y que me dices de “Agile Testing Quadrants” – Parte II

Introducción a “Agile Testing Quadrants”

En el post “Y que me dices de “Agile Testing Quadrants” – Parte I”  hablamos de lo que eran los cuadrantes del “testing” y dimos una pequeña introducción a las pruebas que se realizaban en el ámbito del primer cuadrante.

En este capítulo de la serie vamos a hablar de la finalidad de las pruebas del segundo cuadrante.

 

Testing Quadrants

Segundo cuadrante – Q2

Las pruebas del segundo cuadrante dan soporte al equipo de desarrollo desde un nivel más alto. Mediante las pruebas manuales y automáticas verificaremos que se cumplen los requerimientos de negocio.

Lo importante de las pruebas del segundo cuadrante es que intentaremos automatizar la mayoría de las mismas, cierto es que posiblemente haya algunas pruebas que tengamos que hacerlas manualmente debido a la complejidad de la automatización o al interés mismo de la prueba bajo el coste de automatización.

A diferencia del primer cuadrante en el segundo se realizan mayor tipo de pruebas para verificar los requerimientos de negocio:

  • Pruebas funcionales para verificar la funcionalidad de la aplicación. El mayor ejemplo lo podemos ver en las pruebas a nivel GUI, que validan las funcionalidades de la aplicación desde la capa visual. Se desarrollan con frameworks que ayudan a automatizar las acciones en el navegador, como por ejemplo selenium.Pero las pruebas funcionales no solo se realizan a nivel GUI, también se realizan otro tipo de pruebas funcionales como por ejemplo de API.
  • Pruebas de historia, para verificar que se cumplen correctamente las historias definidas desde negocio.

Estas pruebas nos exigen tener un conocimiento amplio de las necesidades a cumplir por lo que nos exigirán tener una gran comunicación tanto con negocio como con desarrollo, así como disponer de ejemplos que nos ayuden a diseñar las pruebas.

Al igual que en post Y que me dices de “Agile Testing Quadrants” – Parte I”  voy a aportar un poco de experiencia personal.

En una empresa anterior en la que trabajé en uno de los proyectos nos encargábamos de la calidad de las aplicaciones del cliente. El cliente nos hacia llegar un documento enorme con las pruebas que hacían manualmente para que las fuéramos automatizando. Nosotros no conocíamos la aplicación, por lo que cada dos por tres teníamos que ir con el equipo funcional para preguntarles que querían automatizar y lo más importante , que querían verificar dado que la funcionalidad era tan compleja que hasta a ellos mismos a veces les costaba conocerlo. Aquí se ve la importancia de la comunicación en el proceso del diseño de las pruebas.

En la empresa que estoy actualmente es todo muy diferente, el seguir una metodología ágil lo simplifica todo. Los QA disponemos de un tablón el que vemos lo que se está desarrollando, tenemos comunicación directa con los desarrolladores y con producto por lo que las dudas las solventamos rápidamente. Esto se resume en que el diseño de las pruebas se pueden realizar antes de que la historia esté desarrollada por lo que la automatización posterior será mucho fácil.

Conclusiones

Mediante las pruebas que se realizan en el segundo cuadrante verificaremos los requerimientos de negocio de nuestra aplicación pero para poder diseñar las pruebas es muy importante la comunicación tanto con desarrollo como con negocio.

Es posible que en algunos libros o artículos se categoricen las pruebas del segundo cuadrante como pruebas de aceptación, pero en realidad las pruebas de aceptación abarcan mucho más dado que no solo compruebas los requerimientos de negocio, también los de sistema, usabilidad y rendimiento.

Enlaces a la serie de posts