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

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.

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.

¿Los programadores quieren dejar de programar? o ¡A ver cuando me ascienden para dejar de programar!

Entre las muchas ideas que pudimos comentar en la reunión … salió un tema que resulta bastante habitual: Ingenieros que quieren dejar de hacer trabajo técnico. Dejar de programar para pasar a tareas comerciales, de consultoría o de gerencia.

El año pasado en una selección de personal (para programadores) un candidato afirmaba que su objetivo era ascender en la compañía, para dejar de programar y pasar a comercial o consultoría. Según sus palabras: “a puestos con mayor proyección”.

Algunos fragmentos extraídos de la entrevista:

“Un médico de 50 años es una eminencia y un programador de 50 años es un fracasado”

“No podemos negar que el salario, además de la reputación es muy importante”

“Efectivamente, el negocio del software en España funciona así” … “Acá en México la cosa no cambia”  (y por lo que vimos en la reunión de la semana pasada, en Chile pasa lo mismo)

“No hagan líderes de proyecto a sus mejores programadores, porque pierden a su mejor programador y ganan un pésimo líder de proyecto”

“Ser (buen) programador es duro. Muy duro”

“El mérito se lo llevan los comerciales y gerentes, y dentro de las empresas solo se valora a quien tenga contacto con el cliente, ya que es el que paga”

“No entiendo como a un ingeniero informático o a un técnico informático no le parece apasionante el mundo de la Programación de ordenadores. Nunca lo entenderé”.

“Me encanta programar, me apasiona. Es mi vida. Pero sabéis qué me ha sucedido? Mis jefes y superiores me han tratado mal”

esta es una lista que se extrae e inicia de ¡A ver cuando me ascienden para dejar de programar!

Luego de leer atentamente el hilo de discusión, quise ver como se desarrollan las opiniones de los programadores y mis conjeturas son las siguientes:

Como características diferenciadoras, pude observar que algunos reconocen la importancia de los distintos roles en una organización y se expresa que la inoperancia en la ejecución de estos roles esenciales perjudica con gran dolo al programador. Al expresarse aspectos negativos de otros roles y el impacto nocivo en los resultados de los programadores, se deja evidencia de que estos roles bien ejecutados bajo un proceso sinérgico tendrían el impacto contrario en el trabajo (…el de todos), es decir positivo.

En otros casos pareciera ser que para ser programador se necesita de capacidades extraordinarias, desestimando la importancia y aporte de otros roles y peor aún, de otro modelos y/o procesos de desarrollo distintos a los Agiles. De modo tal que se teje en la figura del programador, una suerte de omnipotencia.
Algunos solo admiten el trabajo entre pares y consideran que esto les da la cobertura de pensamiento, análisis y toma de decisión suficiente y necesaria para llevar adelante un trabajo ingenieril en materia de desarrollo de software.
La sugerencia en algún comentario, es de que solo se puede acceder a cargos de liderazgo o comercial, luego de haber transcurrido una carrera como programador en los productos que en la empresa existan.

Como características inclusivas, pude ver que el lenguaje general es de insatisfacción y crítica para el modelo y estilo de liderazgo difundido en las distintas empresas que agrupan a estos programadores, mostrándose fuertes sensaciones de injusticia e incomprensión de los mandos gerenciales y líderes.
Estos caracteres acentúan la necesidad de cambio de rol de algunos programadores, mostrando una necesidad de ser reconocidos en su micro entorno e “impartir justicia” con quienes ellos reconocen como “los más esforzados de toda la organización”.

También se habla del aspecto económico precarizado existente y la sensación de inequidad en relación a los esfuerzos que ejecutan distintos roles.

Algunos exigen acertadamente, la necesidad de procesos de trabajo bien conducidos, principalmente en la gestión de proyectos.

Algunos relatos demuestran la importancia de roles transversales, no para aliviar la carga de los programadores o de cualquier otro, sino para ejecutar una actividad ingenieril digna.

Por lo que puedo observar, lo que realmente falla es el estilo de liderazgo organizacional y la falta de comprensión y aplicación de un verdadero proceso de ingeniería, independientemente del modelo que lo rija.
Sucede que en todas partes del mundo se ahorra en gente, se ahorra en procesos, procedimientos y mejores prácticas y los resultados finales se traducen en mala calidad laboral y de vida. El recorte es una característica que se reconoce en todos los casos de fracaso en los proyectos, pero sucede así por que se recorta sin criterio y con total arbitrariedad y luego se estandariza el proceso dejándolo estático, en lugar de adaptarlo para cada proyecto.
Por otro lado, esta sensación de insatisfacción generalizada se presenta aún en personas que aman su profesión, independientemente del rol. Puede variar la perspectiva, pero todos tenemos a la corta o a la larga, la necesidad de reconocimiento general o de nuestros pares, un salario digno, horarios laborales tan flexibles como nuestra flexibilidad horaria, beneficios e incentivos por hacer cada día más productiva nuestra labor, posibilidades de crecimiento y proyección, respeto y trato justo, entre otras cosas.
Entonces si la percepción es la misma, tal vez la solución no sea mirar de reojo y con desmedro a nuestros colaboradores de otras fases, sino demostrar que el trabajo en equipo es mucho más que una ambición utópica y lo podemos hacer.

Referencias:

¿Los programadores quieren dejar de programar? at Chile Ágil.
A ver cuando me ascienden para dejar de programar

El Liderazgo de Alto Desempeño

Saber manejar conflictos y discusiones son dos de las principales prioridades que deben conocer los líderes. Poder escuchar e imponerse en el momento justo, tener sólidos conocimientos sobre negociación y principalmente, inspirar a sus seguidores.

Kohlrieser, supo expresar cuáles son los pilares sobre los que se erige un líder:

“Debemos ser centrados en todo momento, utilizar el ojo de la mente, presentar lo que nos molesta y comenzar a negociar”

“A la hora de la negociación tenemos que estar motivados e inspirados. Además, hay que estar abiertos a la pronta resolución de conflictos y crear una buena energía”.

“Algo muy importante para un líder es contar con una estrategia y tener bien en claro hacia dónde se va; aunque también debe poseer la flexibilidad para ajustarse a los cambios!”.

“Tenemos que tener la capacidad de lograr un diálogo”.

“Debemos eliminar las interferencias para llegar al desempeño pico”.

” Hay que bloquear los estados negativos y activar los estados positivos”.

“Cultivar los factores que mejoran el alto desempeño”.

Según Kohlrieser existen distintos tipos de líderes de acuerdo a los estilos que pueden existir:

“Se puede ser democrático, coercitivo, autoritario, “marca pautas” o entrenador. Cada una de estás posibilidades tiene sus características, que se ajustan a las distintas personalidades”.

Kohlrieser indica también cuales son las bases para un liderazgo de alto desempeño:

• Autoconocimiento
• Autogestión
• Habilidades sociales
• Conciencia social

Con respecto a los máximos escollos que deben saber sortear los líderes, Kohlrieser, expresa que uno de los más importantes es el conflicto, por lo que “todos deben saber qué hacer y qué no en una situación de este tipo”. El diálogo es de vital importancia en estas situaciones.

Para estos casos, lo primero que se debe hacer es plantear la diferencia entre las dos o más personas que son parte del conflicto y encontrar una salida de manera racional y efectiva para todas las partes, lo que en otras palabras no significa más que dialogar con los otros para zanjar las dificultades o diferencias que pudieran tener.

El diálogo, para Kohlrieser, es la mejor salida a los problemas, pero, desde ya, existen varios inconvenientes que pueden hacer mella a la hora de dialogar.
Según el académico, los obstáculos se dividen en primarios y secundarios:
En el primer grupo están la pasividad, la ignorancia, la redefinición y el exceso de detalles, y en el segundo demasiada racionalidad, emoción y generalización, abstracción, falta de apertura y de honestidad.

Sorteando estos impedimentos, la negociación entre el líder y quienes lo cuestionan tendrá 10 etapas diferentes:

1. Crear un vínculo
2. Separar a la persona del problema
3. Identificar las necesidades y deseos propios
4. Identificar las necesidades y los deseos del otro
5. Dialogar
6. Crear un objetivo
7. Presentar opciones y propuestas
8. Beneficios mutuos
9. Acuerdo
10. La relación continúa o finaliza en forma positiva

Por último se debe tener en cuenta que dicen las últimas investigaciones sobre el cerebro de los líderes de alto desempeño:

“El cerebro siempre puede cambiar. Ello dependerá de las relaciones con las que el individuo vaya creando. Además, la experiencia, el conocimiento, pueden reemplazar la predisposición genética, si no es propia de un líder”
“Las nuevas experiencias pueden crear circuitos que reemplacen a las experiencias pasadas”.

Referencia: El Liderazgo de Alto Desempeño.