Quick entrance: moving-from-testing-to-development

moving-from-testing-to-development

"Mientras el desarrollo de software genera código, el testing genera conocimientos"

Esta desafiante frase nos debe poner a pensar en la actuación que tenemos colectivamente cuando desarrollamos software, ya que analizada con cuidado nos está diciendo que el Testing es una actividad puramente cerebral, por lo tanto exclusiva de seres humanos.  

La declaración inicial no pretende hacer separaciones entre testers y desarrolladores, sino que por lo contrario, pretende reunirlos en la idea de que cada cosa cumple con un propósito y el propósito del Testing es generar conocimientos, muchas veces en la forma de defectos, errores y/o fallas detectadas, otras veces en el descubrimiento de riesgos, tantas otras al encontrar "huecos" en las ideas, conceptos, requerimientos, modelos y desarrollos.

  

Los nuevos paradigmas (quizás hoy representados en Agile) están en constante evolución para facilitarnos este tipo de concepción de ideas y la implementación depende en toda medida de nosotros mismos, de la inteligencia y esfuerzo que le pongamos al conjunto.  

Hoy más que nunca la premisa del trabajo colaborativo nos obliga a ser hiper-reflexivos y  re-pensar la actividad del testing como el verdadero motor que provoca evolución. Por lo tanto conviene entender que no es una actividad pura y exclusiva de especialista (los mal llamados testers en antiguos paradigmas), sino de toda persona que "ponga materia gris" en el 'estudio', 'experimentación', 'modelado', 'cuestionamiento', 'inferencia', etc. con el propósito de generar conocimientos de lo que estamos desarrollando.  

Como es sabido, existirá un gran volumen de automatizaciones en los diferentes momentos del desarrollo de nuestro software, a lo que yo prefiero darle la denominación de "conjunto de activos del testing". Considero conveniente y necesario hacer diferenciaciones plenas entre el momento en testeamos, lo que hacemos cuando diseñamos, modelamos, exploramos, cuestionamos, comprobamos, etc, y lo que hacemos cuando corremos un conjunto automático de activos del testing (checking). 

Esto hay que remarcarlo cada día más por cuanto por supuesto, no faltan aquellos modelos de trabajo donde se usa al ser humano como un "semi-robot", poniéndolo a ejecutar un conjunto de activos del testing (test cases) para obtener resultados empíricos del tipo 'Pass/Fail'. 

En conclusión, hay ciertas destrezas que solo las podremos desplegar los seres humanos y por supuesto, ejecutarlas con eficiencia requiere entrenamiento en el contexto que se intentan desplegar las destrezas, por lo tanto el Testing no lo hará cualquier persona sino alguien calificado (no necesariamente como tester típico), pero quien lo haga, si cumple el objetivo específico de descubrimiento de lo que aún falta por conocerse sobre el software en cuestión, estará necesariamente haciendo testing. 

As a "QA/Test Manager" what are the challenges comes in Agile/Scrum software development process?

as a QA manager I want to survive the changes induced by Agile in organizations

    I do not consider it's an easy task to sustain the role of "QA/Test Manager" in an Agile environment, since this working model leverages organizations to focus on empowering development teams, where typically the QA (quality assurance) as operational activity in itself, is made by all without a dedicated department or dedicated individual. 
In this same sense, Agile tends to eliminate any role with low operational productivity. 
Then, accepting as valid the existence of this role perhaps the challenge is in terms of changing the mindset, turning from a situation where to drive work with rigid plans, and exhaustive controls is the stright path, to flexibility in the kind of work to perform and services to provide with great technical and communication skills.

In a way is to maintain active communication between teams, facilitating integration with development teams of individuals that leads.

    For something like this to happen, managers must facilitate their employees increase and improve their technical and communication skills through proper training. Investment should also be made in terms of participation in projects of different criticalities and risks, where the role of collaborators has the necessary and sufficient delegation of authority for administrative and technical. 


Also see: The Role of the Test Manager in an Agile Organization

Continuous integration Testing - El desafío de las Pruebas de Integración

En este artículo de se hace una muy breve descripción a cerca del tipo de operaciones que típicamente realizan los "equipos integradores de sistemas", y como impacta su función dentro de entornos Agile.

Ya en uno de mis antiguos artículos menciono la particularidad de este tipo de equipos y sus miembros, ubicados en distintos roles, pero todos colaborando en el 'Big Picture Testing'.

Detrás de grandes desarrollos existe una gran complejidad en relación a la integración y aunque es una ventaja gestionar este tipo de trabajo desde el inicio, no siempre puede ser realizado "derecho" ni en poco tiempo o sin esfuerzos enfocados en la actividad. 

....analizandolo desde un punto de vista XP o Scrum purista, cualquier actividad extra que se realizare fuera del Sprint es una actividad tercerizada, es decir que bajo estos preceptos el Testing de Releases por un equipo diferente al de desarrollo, sería una forma de trabajo que en términos de Lean se consideraría DESPERDICIO (Waste). 
Tiempo atrás supe reflexionar ... y darme cuenta que es posible que la idea de "Ultimate Test" como WASTE, sea válida únicamente si se piensa y organiza el trabajo de manera "tradicionalista". Es posible que el traspaso de trabajo de un equipo a otro sea provechoso utilizando algunos enfoques diferentes en la gestión en toda la cadena de desarrollo, evitando el trabajo desacoplado típico del trabajo en cascada. 
Por ejemplo, utilizando un enfoque ATDD un equipo de pruebas de Releases puede participar desde las fases iniciales en la generación/validación de las Pruebas de Aceptación para satisfacer los Criteria Mínimos de Viabilidad y Calidad de las User Stories. Así se unifican los criterios y se estandariza el conocimiento acerca del producto con enfoques y conocimientos complementario. Una consecuencia valiosa sería el fenómeno de Irradiación de la Información desde el momento en que se genera, por cuanto se amplificaría la interacción de los equipos de pruebas de releases con los equipos de desarrollo. 
Por su lado, hay un enorme beneficio obtenido por el solo hecho de traer tempranamente a la mesa la discusión de "como lo probamos", lo que implica obtener respuestas a niveles de pruebas unitarias y de funcionalidad en base a salidas esperadas para satisfacer los criterios de aceptación. A este mismo conjunto de pruebas iniciales debemos sumar las pruebas para integración, lo cual muy irracionalmente suele dejarse de lado hasta el final desaprovechando oportunidades valiosas en los momentos en que se desarrollan los productos. 
Deben ser discutidos desde un inicio muchos elementos claves con el propósito de integración, como virtualizaciones de entornos de pruebas y conjunto de datos, políticas de respaldo y restauración, métodos, técnicas y procedimientos para instaladores manuales o automáticos, distintos escenarios posibles, etc. También pruebas de conectividad a bases de datos e interacción entre distintos sistemas y subsistemas. 

... la dificultad podría residir en que debe existir el compromiso de los equipos de desarrollos en aprender sobre la actividad del Testing en sí, facilitando el enfoque de pruebas exploratorias en un principio y por ejemplo su consiguiente generación de test-charters, los cuales para un equipo de pruebas de releases serían documentos vivos de las pruebas ejecutadas, defectos encontrados, problemas y riesgos detectados, como también soluciones obtenidas.  

Me alegra saber que tanto Janet Gregory como Lisa Crispin, comparten la idea de que no todo lo que se desarrolla en los Sprint puede ser validado por únicamente pruebas unitarias, ni únicamente por baterías de pruebas funcionales automáticas, ni únicamente por los equipos Scrum. 


Artículo original en Continuous integration testing: Challenges and solutions