Pausa

@michaelbolton, en su blog propone una nueva herramienta para los testers. Aunque también quiero hacerlo extensivo a desarrolladores y analistas. Dicha herramienta es la pausa.

El desarrollo de software es una actividad compleja y, cómo toda profesión que requiere de un despliegue intelectual diario, necesita de una pausa. Según Bolton, una pausa es el efecto de aplicar las siguientes cuatro palabras: Huh?, Really?, And? y So? Cada una de ellas da un respiro y predispone al pensamiento crítico.

Wait…huh? Did I hear that properly? 

Um…Really? Does that match with my experience and understanding of the world as it is, or how it might be? 

…And? What additional information might be missing?

Okay…So? What are some consequences or ramifications of those interpretations?

Germán

Read More

Principios esenciales para Automatización de Pruebas Funcionales

La última Testing Experience tiene un interesante artículo sobre principios para tener en cuenta al momento de automatizar tests funcionales. Los quería compartir aquí ya que me parece importante tenerlos bien presentes.

1. Primero, diseñar los tests. Evitar la creación de tests on the fly. Nuestra suite de tests debe crecer orgánicamente.

2. No automatizar todo. Ciertos tests pueden ser fácilmente ejecutados en forma manual, evitando así el alto costo de automatización.

3. Escribir tests cortos. En situaciones en las que uno o más tests fallen, cualquier miembro del equipo debe ser capaz de trackear la causa del error. Es recomendable usar BDD (Behaviour-Driven Development) 

4. Crear tests independientes. Evitar el acomplamiento y aumentar la cohesión de los tests.

5. Enfocarse sobre su readability. El código fuente de cada test debería estar self-documenting. Comentarios en el código deben ser evitados.

6. Tests deben ser rápidos. El testing funcional automatizado debe ser un indicador rápido de la calidad de la aplicación. Además, en un ambiente de continuous delivery, el tiempo de ejecución debe ser de unos pocos minutos.

7. Crear tests resistentes al cambio. Quizás esta es una de las principales desventajas de los tests funcionales automatizados. Los tests debería verificar sólo funcionalidad. Dependiendo del contexto también puede ser posible aplicar DDT (Data-Driven Testing)

8. Los tests automatizados no pueden reemplazar a los humanos. Este no debe ser el único testing que se ejecuta. Otras técnicas, con la intervención de los testers humanos, deben ser aplicadas sobre el software en pos de generar más conocimiento.

Germán

Read More

Basta de "Dev vs. QA"

Uso Feedly para gestionar los post de los blogs que sigo. Diariamente, hago una selección de artículos para leer en el momento y otros los guardo para chusmearlos luego. Esta selección la hago por categoría, nombre de autor (algunos leo con más frecuencia que otros) y también hago selección por título. 

En este contexto, todos los días me encuentro con que aún se sigue escribiendo (bastante) sobre la "rivalidad", "diferencia", importancia de los testers por sobre los developers o viceversa. A esta altura del partido, creo que este debería ser ya un tema superado. Por esta razón, es que he decidido no leer más artículos con estos contenidos. Títulos tales como "Developers vs. Testers", "¿Por qué los programadores 'odian' a los testers?", "El espíritu destructivo de los testers" están para mi obsoletos. Opino que ambos (devs y testers) deberían estar bajo un mismo rótulo: software makers, o simplemente software developers. Ya no tiene mucho sentido volver sobre lo mismo y debería ser un tema superado en la comunidad del software. Hay que pasar al siguiente nivel de la discusión.

Germán

Read More

Hacer testing es también capturar conocimiento - otra vuelta

El post anterior sobre este tema hizo bastante ruido. Recibí muchos comentarios/opiniones al respecto y me pareció interesante dar "otra vuelta". En realidad, esta vez es para dividir en un par de tracks los comentarios que recibí y "generar más conocimiento":

1. Testing Agile: hace un tiempo escribí sobre los principios propuestos en este libro, y efectivamente, de alguna manera, la idea expuesta en el post tiene implícitos estos principios.

2. Cualquiera puede hacer Testing: sinceramente, me cuesta creer en esto. He trabajado con gente que no es del palo y han tenido un excelente desempeño. Sin embargo, hay cuestiones técnicas, de análisis, gestión, etc. en las cuales hay una clara ventaja del informático. Seguramente en testing funcional es más factible,  pero si queremos ir en esta dirección deberíamos apuntar a gente informática, sin dudas. En otro momento, retomaré el tema.

3. El Testing no puede automatizarse completamente: No puedo estar más de acuerdo con esta afirmación. No hay dudas. Lo que sí surge aquí es, ¿qué automatizar y qué no?, ¿qué herramientas son las adecuadas?

4. Un fail como puerta de entrada hacia más conocimiento: Un bug permite a los developers explorar escenarios, situaciones, y código aún no explorado y con un fuerte impacto (potencial) en la funcionalidad de software. La forma operativa de capturar conocimiento en testing es a través de un bug.

Para terminar, no deja de sorprenderme la cantidad de comentarios y de gente que tiene las mismas inquietudes. Los lectores son como los testers que ayudan a generar más conocimiento en este blog!

Les dejo unos links a los comentarios que recibí -> 1, 2, 3, 4

Read More

Hacer testing es también capturar conocimiento

Varias veces he escuchado la siguiente frase: "Los desarrolladores tiene un pensamiento constructivo y los testers tienen un pensamiento destructivo". Esta falacia se está derrumbando con el paso del tiempo (por suerte). Los testers también construyen, nada más ni nada menos que calidad. Ernesto Kiszkurno ya habló de esto en su blog.

En esta dirección, la dependencia de la gente en el software es cada vez mayor y, por lo tanto, este tiene que ser cada vez más confiable. Debe resolver el problema para el cual fue construido. Leandro Caniglia siempre me dice que para él, construir software es capturar conocimiento y que los testers son el complemento indispensable en la cadena de valor. Es decir, los testers también participan en la captura del conocimiento tan importante a la hora de modelar dominios reales y, por lo tanto, complejos.

En conclusión, es hora de integrar definitivamente a los testers y a los developers para que ambos colaboren desde las fases tempranas de un producto. El testing NO debe ser una etapa en el ciclo de construcción de software sino que debe ser una actividad parte del criterio de "Done".

"Tested is part of 'Done'"

[1] La imagen fue extraída del blog http://www.agilebuddha.com/

Read More

El condensador de flujo para nuestros proyectos

Sin bien la película no aclara cómo funciona exactamente, el condensador de flujo consiste en una caja con tres pequeñas lámparas incandescentes centelleantes (nuestras prácticas QA, ágiles y de desarrollo), colocadas en forma de "Y", y situada detrás entre los asientos de la máquina del tiempo. Cuando el automóvil (nuestro proyecto) se aproxima a una velocidad de 88 millas por hora (140 km/h), la luz que emiten las lámparas del condensador de flujo destellan con más rapidez, hasta emitir una luz constante (flujo constante de prácticas). Entonces el condensador se activa posibilitando el viaje en el tiempo.

Si logramos incorporar buenas prácticas a nuestro equipo y a nuestros procesos a medida que el proyecto alcanza 88 millas por hora, vamos a viajar al tiempo del "buen" software. Es el espacio/tiempo donde habitan los productos de calidad, aquellos que realmente aportan valor y desarrollados por equipos altamente motivados y skilled.

En cambio, si no logramos incorporar estas buenas prácticas a nuestro equipo y a nuestros procesos, viajaremos al tiempo del software de baja calidad, con equipos estresados y con poco valor para aportar.

Condensador de Flujo

Nota 1 (para nostálgicos): aquí dejo el momento en el que el Doc le hablaba a Marty sobre cómo viajar en el tiempo y por qué es posible aplicar esto al desarrollo de software :)

Nota 2: No creo que existan las "mejores prácticas" ya que su aplicación efectiva depende 100% del contexto en el cual serán aplicadas. Prefiero usar el concepto de "buenas prácticas" e involucrar el concepto de "contexto". Algunas prácticas pueden ser buenas para un determinado contexto y no tanto para otro.

Read More