Exploratory Testing: Olfato e intuición amplificada

Fortalezas y debilidades de las Pruebas Exploratorias

Muchas veces se habla del Testing Exploratorio sin tener una verdadera conciencia de lo que se trata ni del modo en que se debe ejecutar. Los detractores de este tipo de verificaciones, opinan mostrando la práctica como informal, sin procedimiento y fuera de los cánones del Testing y por transferencia intentan establecer que no existe Calidad del Software.

Les doy la razón únicamente en que este tipo de pruebas del software no están en los cánones del Testing, puesto a que es una actividad extremadamente compleja de interpretar y realizar si no se tienen en cuenta los elementos de soporte que finalmente avalan la práctica.

Las pruebas exploratorias muestran sus resultados y garantías en base a los resultados y garantías de prácticas previas y del mismo modo, fallan sus resultados y garantías cuando prácticas que le anteceden son ejecutadas en forma endeble o imprecisa.

Para esta práctica son necesarios ciertos elementos que le anteceden:

  • Conciencia de que todo lo que se verifica está orientado a la detección de problemas que impidan satisfacer requisitos funcionales y no funcionales
  • Capacidad de análisis elevado para entendimiento cabal de requisitos en base a la observación y análisis de la evolución de los mismos
  • Abstracción para la elaboración de circuitos de pruebas de verificación y validación
  • Capacidad de ampliación de caminos de pruebas para mejora espontánea de la cobertura
  • Conocimiento y dominio del negocio al que pertenece el problema
  • Alta proactividad y gran capacidad comunicacional para generar ambiente colaborativo
  • Conocimiento cabal del proceso que rige para reconocer las fallas que se manifiestan en los resultados no deseados
  • Gran capacidad para definir y variar las estrategias, tácticas y técnicas de validación y verificación
  • Olfato e intuición amplificada

Hay que considerar que para el éxito de esta técnica se utilizarán las definiciones que se hacen a nivel de Historias de Usuario y/o Requerimiento,  para verificar mediante pruebas exploratorias (sin script), que el sistema esté haciendo lo que se solicita y se ampliará el grafo de pruebas para verificar que el sistema no haga lo que no debe hacer.
Es decir que básicamente la información disponible conforman nuestros Scripts de ejecución y también evidencia de funcionalidad.

Según este tipo de proceso de verificación y validación, las evidencias de funcionamiento se deben dar inicialmente en la fase de desarrollo y manifestarse en las diferentes integraciones de los sistemas, más no pretender que las pruebas exploratorias indiquen que las funciones del sistema funcionen correctamente, sino entender que el concepto es en si mismo, la detección de fallos y errores.

Advertisements

Generando circulos virtuosos en QA

 

 

 

Tanto la estrategia de gestión de los negocios como la estrategia técnica para el aseguramiento de la calidad del software comparten una “talón de Aquiles” que puede ser diferenciado en los siguientes dos enfoques:

 

 

 

Circulo vicioso

El primero se centra en estrategias de ejecución de pruebas funcionales, tratando de asegurar que la ejecución de todos los juegos de pruebas programados (incluídos los automatizados) cumplan con las espectativas, es decir con los planes. Este método usualmente deja sin cobertura algunos tipos de defectos y problemas de integración mayores, los cuales el equipo debe solucionar una vez que el producto está en el campo.

Este tipo de estrategias suelen carecer de una medición apropiada y buenas definiciones de calidad u objetivos bien establecidos, como también de proyectos de automatización y performance que sustenten una arquitectura general de la calidad esperada. El mayor foco es en la ejecución de pruebas y no tanto en una cultura orientada a la calidad.

Los equipos así conformados, fomentan un círculo vicioso donde prefieren confrontar con los problemas a medida que ellos se presentan, en lugar de anticiparlos y gestionarlos estratégicamente y por lo general el desorden prima hasta tal punto que no les permiten un aprendizaje y evolución continuo.

Círculo virtuoso

El segundo enfoque está orientado a la formación de equipos conformados por personas con muy altas habilidades en el pensamiento de los sistemas, antes de plantearse cualquier plan y quienes pueden ser facultadas en pos de objetivos estratégicos que son apoyados por una gestión que favorece al agregado continuo de valor y la promueven en toda la red organizacional.

Estos equipos así conformados, fomentan un círculo virtuoso donde es más fácil generar devoluciones proponiendo metodos de pruebas con técnicas emergentes e innovadoras que son diseñadas y aplicadas en los proyectos actuales, sin esperar a un futuro cercano, medio o lejano.

Empleados Vs Colaboradores

Ahora bien, la ejecución exitosa o el fracaso de los proyectos debe ser pagada y así es con cualquiera de los enfoques mencionados antes. La diferencia quizás radica en que las organizaciones que tienden al primer enfoque, solo consiguen conformar equipos de trabajadores técnicos del día a día y no pensadores de los sistemas.

En su contraparte, las organizaciones que facultan a su personal, dejan de tener simples empleados y forman a fuertes colaboradores estratégicos.

En ambos enfoques, el éxito o el fracaso ha dejado de ser un hecho atribuíble a los equipos para pasar a ser responsabilidad neta de las personas que están en posiciones gestión. Este concepto apunta a que ya no es admisible una razón que se apoye en que los proyectos fallan por una pobre ejecución de las operaciones, sino más bien por una carencia en importante en la estratficación.

Esto quiere decir, que lo que debe primar hoy en día en las organizaciones, aún si sus proyectos eventualmente fracazan, es la sistemática re-evaluación de la visión y los valores que defienden los tomadores-de-decisiones de una organización, para que así los equipos de desarrollo busquen defender esos mismo valores y compartan una visión correcta.

 

Inspirado en Empowering a QA Culture

Equipo QA – El recurso oculto

¿Que es lo primero que viene a mente cuando mencionamos Ingeniero QA o Tester?

Hay quienes piensan y asumen que las actividades típicas del Tester, las puede llevar a cabo cualquiera y esto se piensa independientemente de la metodología utilizada.

La razón puede estar fundada en el concepto erróneo de que cualquier persona puede determinar si una aplicación funciona o no, con solo seguir un plan de ejecución de pruebas predefinidas, lo cual es bastante típico en Waterfall.

También se asume que el aseguramiento de calidad es solo cumplir con actividades formales de Testing, aplicadas a distintas áreas de procesos en su debido tiempo.
Sin embargo con este pensamiento se deja de lado la especialización, enfoque, razonamiento y experiencia de los profesionales del QA-Testing y su importante aporte dinámico para el aprendizaje continuo durante todo el ciclo de vida de un proyecto de software.

La vereda más transitada

En metodologías tradicionales de desarrollo de software se tiene especial cuidado con la planificación detallada de las pruebas, de modo tal que esta sea acorde a la definición detallada de los requerimientos y a la planificación detallada de todo el proyecto. En base a un aprendizaje inducido por la documentación de como debería funcionar el sistema, se ejecutarán respectivos ciclos de pruebas de sistemas para verificar la completitud y correctitud del sistema en base a tales requisitos.

Como contrapartida se supone un Plan de Pruebas rígido, con muy baja adaptabilidad al cambios de requerimientos y a aparición de nuevos requisitos. También está la cuestión del enorme esfuerzo de mantenimiento del plan, la pérdida de tiempo en el circuito comunicaciones y la aplicación de responsabilidades a personas y/o grupos de personas “encargadas de tal artefacto”.

En la vereda del frente

Las metodologías Agiles presuponen una planificación estratégica del Testing en el orden de ser ampliamente adaptativa, acorde a la velocidad de cambios en los requerimientos del sistema e inclusive a la creación de nuevos requisitos para una misma iteración.  Este solo hecho presupone una total participación de los miembros QA-Testing al inicio de los proyectos, no desde el punto de vista de la inspección-auditoría, sino desde el punto de vista de “recorrer un camino” como equipo, hacia el verdadero aseguramiento de la calidad.

En estos dos enfoques diametralmente distintos, la participación del QA-Testing cambia de un rol de “full-Auditoria” para la detección de fallos y asignación de responsabilidades a “full-partner” del resto de los miembros del equipo para la generación de valor inmediato y motor de orientación a proyectos exitosos.
Esta concepción permite revalorizar los roles QA debido al uso potenciado de los mismos, aportando un valor más estratégico para las necesidades de los negocios que atienden los sistemas que se construyen.

Los Testers encuentran en Agile su máxima posibilidad de expansión, con actividades operativas que ayudan a los desarrolladores a promover la generación de soluciones más eficientes y en instancias cercanas al inicio del desarrollo, e inclusive previas.
A su vez como miembros del equipo QA podrían ser fuentes de información constante referido al comportamiento del sistema en construcción, permitiendo adelantarnos a cambios en los requerimientos, requerimientos mal concebidos o desarrollados en modo no deseado, promover mejoras y una lista larga de etcs. que en definitiva orientan a traves de todo el ciclo de vida del proyecto e inclusive supera las fronteras ayudando en el training a clientes y acercando el conocimiento a las áreas de soporte.

En ambas veredas

Esta revalorización del QA-Testing no debe ser abarrotada detrás de las metodologías Agiles, ya que el concepto puede ser aplicado a cualquier proceso de desarrollo. De hecho, las metodologías Agiles no han planteado este paradigma ni es algo que les pertenece, aún cuando se utilice la terminología “Testing Agile” y se explique algo similar a todo lo que digo.

La evolución de SQA-Testing

Aún cuando muchos “pseudoagilístas” consideran a un Tester como un recurso de menos rango y hasta despreciable para la organización por no generar aporte productivo, “los del palo del SQA-Testing”  nos damos cuenta de la evolución por la misma adaptación que debimos sufrir acorde a la velocidad de respuesta que requieren los procesos de desarrollos actuales.

Asumamos que un cambio de paradigma QA es posible aún dentro de procesos tradicionales. Aún así, el cambio no puede gestarse por si solo, debe surgir de un cambio en el paradígma organizacional.

Fuentes de inspiración:
Testers: The hidden resource

Stress Agile

En los últimos tiempos he visto como algunos miembros de equipos Agiles se expresan negativamente a cerca de las reuniones típicas, como la de iniciación y planificación, reuniones diarías de sincronización de trabajo (Stand Up), revisión final de los incrementos (demo), considerándolas de algún modo una gran pérdida de tiempo y mera actividades modales.
Me he puesto a observar el carácter de estas personas en particular y básicamente ellas tienen un patrón de comportamiento uniforme.
Tienden a evitar discusiones de consenso, expresan su punto de vista con bastante irreflexión y son inflexibles, planifican por su cuenta sin consenso, suelen no abarcar a otros involucrados, evitan la comunicación efectiva cara-a-cara, son en extremos desconfiados, alimentan un estilo de crítica destructiva, son extremadamente detallistas.
Este conjunto de características en definitiva los torna por lo general, en personas de un humor cambiante (bastante acorde al estado de avance de sus actividades), suelen frustrarse si hay una gran incertidumbre, por lo que al principio de cualquier proyecto Agile, sufren por no tener una documentación en extremo detallada, justifican sus retrazos y fallos en la falta de información disponible y evitan reconocer que no se han dedicado a hacer preguntas adecuadas para obtener data.
Técnicamente son personas muy capaces, seguramente lograrán los objetivos, pero se esfuerzan demasiado y sufren el estress de una manera dañina, quizás por que no usan el soporte de otros.
Si les preguntas, se sienten invadidos y suelen confundir reportar con transferir información colaborativamente. También consideran que el término de autogestión se aplica al individuo en lugar de al team.
Bueno, no es de extrañar que haya personas así, cuando en realidad hay toda una cultura educativa y empresaria que las concibe, alimenta y fomenta su existencia profesionalmente.
Lo que si es extraño, es que logren filtrarse en equipos Agiles.

Esto me recuerda que no solo estoy hablando de personas en el área operativa,  sino por supuesto también de quienes son parte de las altas gerencias y es obvio, por que Agile suele causar dolor.

Al rescate del 60%

Recientemente leí un artículo interesante en la versión digital de La Nación, el cual en su marco principal trata sobre “qué hacer y cómo tratar a las nuevas generaciones de empleados que nacieron entre 1981 y 2000, y que traen en su ADN una nueva manera de insertarse en el mundo del trabajo”. En este artículo me interesó un concepto particular y es que según estudios recientes, se determinó que el 60% de la fuerza laboral estaría representado por empleados desmotivados cuyo aporte es el mínimo indispensable para la organización y que en lugar de hacer un aporte efectivo estarían generando pérdidas.

Esto me llevó a reflexionar sobre mi participación en distintas empresas de Argentinas y de las cuales finalmente me desvinculé, principalmente por cuestiones de motivación y una falta de misión y compromiso de tales empresas con su empleados, o por el parcialismo que representó su accionar.

Más de una vez me pregunté que ocurre con aquellas personas que por sus características personales y capacidades profesionales o adecuaciones realizadas de su aprendizaje, fueron seleccionadas para pertenecer a un equipo de trabajo para el cual se le brinda inicialmente una apertura y participación amplia, pero con el correr del tiempo, proyecto a proyecto la resultante es un un aporte operativo básico, carente de participación en opinión analítica, crítica constructiva y pensamiento diferenciado.

Creo que las insistentes “conversaciones en pasillos” entre empleados, sobre las malas políticas de RRHH, sueldos bajos, falta de capacitación o el exceso de las mismas, más la poca o nada de relación esfuerzo/compensación, en realidad tienen mucho más que ver con la falta de participación y opinión que se le ofrece a los empleados, que con los ítems negativos.

Es allí donde veo la falta de preparación de las diferentes líneas gerenciales y jefaturas, quienes manifiestan a las claras su falta de liderazgo al no saber declarar una misión, transmitir la visión, conseguir el compromiso y motivar para el cumplimiento de los objetivos.

Creo que gran parte de ese 60% de empleados desmotivados fueron finalmente empujados a esa actitud nociva y destructiva. Es posible que de alguna manera su accionar sea un acto de ajusticiamiento y revancha.

No se debe “tirar a la hoguera” a un soldado que aún vivo huye, sino rescatarlo, curarlo, re reclutarlo y aliarlo bajo un nuevo compromiso. Es importante considerar que, si como líderes y organización no estamos listo para “el rescate”, nuestra vida laboral también será complicada y en camino hacia un valle de desánimo, con un tendal de gente que “no trabaja motivada” y otros que poco a poco planifican su huida.

Segundas Jornadas Latinoamericanas sobre METODOLOGÌAS AGILES

Profesionales relacionados al desarrollo del software, unidos por el objetivo de crear un espacio amplio de discusión sobre las metodologías Agiles y su adopción en América Latina, han organizado para el mes octubre de 2009 en Florianópolis, Brasil, las SEGUNDAS JORNADAS LATINOAMERICANAS SOBRE METODOLOGÍAS AGILES.

Están confirmadas las presencias de importantes figuras del medio como:

– “Brian Marick” (uno de los 17 visionarios que firmaron el Manifesto for Agile Software Development en el año 2001)

– “Diana Larsen” (co-autora del libro “Agile Retrospectives: Making Good Teams Great!” y co-fundadora de la conferencia Agile Open Northwest y del evento internacional Retrospective Facilitators Gathering)

– Entre otros referentes internacionales de la comunidad ágil, se contará con la participación de Matt Gelbwaks, Naresh Jain, Dave Nicolette y Joshua Kerievsky como invitados especiales.

La información oficial del evento está aquí

Sede: Rod Admar Gonzaga, 2765
Florianópolis – SC, 88034001, Brazil

desde LinkedIn: Debate: ArgenTIna – Software y Servicios Informáticos.

Reblog this post [with Zemanta]

El aprendizaje de un nuevo lenguaje

Están convencidos de que el aprendizaje de un nuevo lenguaje de programación aporta al aprendizaje de nuevos paradigmas?

Siempre entendí que un paradigma va más allá de un lenguaje en particular; es una representación que encierra problemas y soluciones con un enfoque particular.

Entiendo la necesidad de los programadores de aprender más lenguajes de programación y es válido si lo vemos como proponentes de soluciones técnicas útiles en los proyectos.
Entiendo que un arquitecto de sistemas debe poder comprender muy bien estos lenguajes que su equipo de desarrollo opera, sin embargo deberán darse cuenta que en otras capas de las organizaciones, otros analistas tienen otro dinamismo con la lingüística relativa a los ámbitos que les competen y también debe existir un nexo con estas personas que administran otros paradigmas.

El lenguaje de los negocios tiene su propia lingüística y así ocurre con cada capa que se presenta donde deba ser gestionada la transformación de las ideas.

Por lo tanto, pienso que los lenguajes de programación son solo los medios para hacer tangible lo abstracto de las ideas analizadas y puestas en un plano distinto al de su origen, de las cuales se espera un resultado utilizable. Sostengo también, que el aprendizaje de nuevos lenguajes no tienen relación con herramienta alguna, sino con la “lingüística conductiva” que trasciende a través de todo un equipo concluyendo en soluciones óptimas.