enero 24, 2014

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ónestará 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 StoriesAsí 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

marzo 26, 2013

Las reuniones de trabajo para la resolución de problemas

Una reunión permite la comunicación de ideas y la participación de todos en las decisiones. La participación en cualquier tipo de reunión debe seguir unas ciertas pautas de comportamiento si se pretende que sean  interesantes y productivas.


La sinergia del grupo

La sinergia de un grupo se expresa así en términos matemáticos: 
2 + 2 > 4 
Dos más dos suman algo más que cuatro. Esto significa que el rendimiento del grupo es superior a la simple suma de las contribuciones individuales, lo cual es fantástico: 
un buen grupo produce plusvalía y genera sinergia. Juntos pueden llegar a descubrir aspectos que ninguno de ellos sería capaz de ver por su cuenta.
La gente rinde más cuando trabaja en equipo, cuando se reúne y pone en común sus conocimientos y sus opiniones.
Lógicamente hay que tener en cuenta determinadas normas a la hora de reunirse. Sin embargo, las reglas no tienen que echar por tierra la alegría natural que sienten, al estar juntos, quienes comparten objetivos comunes y disfrutan de la amistad.


Evitar los prejuicios

Para que una reunión no derive en discusiones estériles, se recomienda no empezar por proponer cada uno su propia alternativa, aunque a primera vista parecería lógico el procedimiento contrario.
Los miembros de un grupo harán bien en estudiar previamente el tema que van a tratar en la reunión, pero no han de formalizar conclusiones que serían prematuras. Hay que evitar los prejuicios y todo tipo de juicios poco fundados. Antes de la reunión sólo conviene desbrozar el camino, abrir  horizontes, documentarse en datos y hechos para poder aportarlos luego al grupo.   


El método científico de toma de decisiones


Interesa mucho que las decisiones que se toman en las reuniones sean las mejores. Por eso se propugna un procedimiento que recuerda la sistemática que observan los investigadores científicos.
Es la misma que suele seguir cualquier médico, que empieza por recoger información (los síntomas que le cuenta el enfermo, los datos que percibe mediante su exploración), llega luego a concretar un diagnóstico y finalmente busca entre los posibles remedios el que mejor se adecua.

El método científico de resolución de problemas propone este esquema de trabajo:
1. definir el problema
2. formular las posibles soluciones
3. elegir una alternativa
Y lo que más importa, que todo este proceso se siga en la reunión, abierta a la intervención de todos, sin juicios previos, tratando de ser objetivos y de descubrir entre todos la mejor solución.


La definición del problema

La definición del problema empieza por constatar lo que ocurre, recopilando datos y hechos, pasa luego por definir lo que debería ocurrir, de acuerdo con los principios y los objetivos que asumen los miembros del grupo, y culmina en observar la desviación producida entre lo que ocurre y lo que debería ocurrir, entre lo que es y lo que debería ser.
· LO QUE OCURRE (recopilar hechos y datos)
· LO QUE DEBERÍA OCURRIR (determinar el ideal)
La realidad se compara con la utopía y en el contraste se perfila el problema.
Es importante profundizar en el análisis y llegar a precisar las causas de la desviación. En muchos supuestos, el estudio de las causas va a orientar eficazmente la elección de la mejor solución, la que ataca la verdadera raíz del problema.


La formulación de alternativas

Con frecuencia, la mejor idea está escondida y sólo aparece después de que algunos sugieran otras varias “ideas-puente”. Desde el punto de vista de la actitud con la que se ha de encarar cada etapa del proceso, se puede hablar de objetividad en la definición del problema, de creatividad en la búsqueda de soluciones y de actitud crítica y rigurosamente lógica en la toma de la decisión final.
Hay que encender la luz verde del semáforo a la hora de recopilar hechos y datos y en el momento de formular alternativas. Pero ha de tornarse roja la luz cuando se trata de valorar las distintas opciones. No deben confundirse ni mezclarse las actitudes, sino proceder sucesivamente a su utilización.
  

El coste de la solución

La toma de decisiones es el objetivo de la reunión. Se ha planteado un problema y se han propuesto diversas soluciones. Es hora de elegir la mejor. 
Hasta este momento, el proceso seguido ha sido de índole intelectual, el razonamiento anterior culmina finalmente en una decisión. Pero hay que ser conscientes de que un auténtico problema no tiene una solución plenamente satisfactoria. Las soluciones suelen suponer la creación de otros problemas distintos. 
Es lo que se llama el coste de la solución... si no hay coste se puede decir que no hay problema.
Al resolver un problema, hay que ponderar el punto en el que se alcanza un máximo de ventajas con el mínimo de inconvenientes. Si se pretenden todas las ventajas, haciendo desaparecer totalmente el problema, se pueden provocar consecuencias negativas más graves que las que entrañaba el mismo problema primitivo. 


Existe toda una serie de vías para la toma de decisiones en un grupo:

Por imposición de uno

Es lo que se podría llamar una decisión dictatorial. La reunión ha servido para que el que detenta el poder en el grupo tome su decisión individual y los demás miembros se adhieran a ella.


Por imposición de una minoría

Una situación similar a la anterior. En el grupo hay una minoría que se une para imponer su criterio a la mayoría. En el lenguaje político se hablaría de oligarquía.


Por mayoría

El grupo asume como propia la decisión que sustenta la mayoría de sus miembros. Normalmente, los individuos que se suponen en mayoría son los que proponen la votación, en aras de lograr más eficacia o por razones democráticas. Aunque a veces no se llega a votar y basta la presión social que ejerce la mayoría para que los demás acaten su solución. Influye la conveniencia de llegar a un pronto acuerdo.


Por negociación

Los criterios se manifiestan claramente distintos, pero se llega a un pacto, se acuerda una solución de  compromiso, cediendo parte de sus opiniones y de sus derechos. A nadie convence por completo la solución adoptada. Pero todos salen moderadamente satisfechos de la negociación y aceptan el pacto. Los intereses se mantienen contrapuestos.


Por concertación

Los criterios fueron inicialmente dispares, pero tras la confrontación de opiniones, el grupo ha llegado a un consenso. Se ha llegado al convencimiento y todos asumen como propia y no impuesta la solución que finalmente adopta el grupo. Los intereses eran compatibles y se han vuelto afines.


Por unanimidad

Los intereses son ahora coincidentes desde un principio. El acuerdo se toma sin esfuerzo, todos opinan de igual forma.


Por la no oposición de nadie

No es una vía tan extraña. La reunión se ha alargado quizás demasiado o el tema no afecta a intereses vitales. Alguien propone algo y nadie se opone. 
A nadie se le escapa que las imposiciones son funestas, que el acuerdo por mayoría no es una solución perfecta, que el pacto sólo es un mal menor, que el ideal bien puede ser la unanimidad, pero que el verdadero mérito de una reunión es llegar vía concertación al consenso.  

Extraído de LAS REUNIONES DE TRABAJO