Así no se hacen las cosas por Ernesto Kiszkurno

Las empresas solían pensar que formar sus propios equipos de tecnología era más barato que tercerizar las funciones. Ahora no tanto. Sí, también está el mito de lo estratégico. De eso hablo de eso más abajo., ahora sigo. ¿Internalizar es menos costoso? Hoy la dificultad para atraer talento, y más importante para retenerlo, está haciendo que muchas empresas revisen su estrategia de internalizar.  En ciertas funciones específicas como puede ser el testing de software (y principalmente en temas de automatización de pruebas) la curva de aprendizaje es lenta y las personas escasas e inquietas. Esto hace que la ecuación de costo beneficio deje de inclinarse hacia internalizar pues a los costos de mantener plantilla propia deben sumársele los de buscar/seducir/inducir permanentemente a los recambios. El razonamiento que hacen es que ya no les sale más barato, son peores lidiando con la rotación (más lentos como mínimo) y muchas veces menos atractivos para la gente que quiere especializars...

El judo fue creado por Jigoro Kano en 1882. Para ello tomó técnicas de artes marciales más antiguas, eligiendo aquellas que servían para cultivar el cuerpo, sin dañar al compañero que presta su cuerpo para la práctica o a nosotros mismos, y la mente. Respecto a este último punto, Kano menciona dos principios básicos y fundamentales que servirán para la práctica del judo y el comportamiento del judoca en su vida: seiryoku zenyo (máxima eficiencia en el uso del cuerpo y el espíritu) y jita k yoei   (prosperidad y beneficio mutuo).  Hasta aquí la teoría. Ahora vamos a por qué relaciono esto con el trabajo del tester. El objetivo del tester dentro de un equipo de trabajo es velar por la calidad del software que estamos construyendo . No está para acumular casos de prueba o empapelar de scripts el proyecto. Ni siquiera está para encontrar errores ya que a mis ojos, si el tester pudiera prevenir esos errores alertando al resto del equipo sobre prácticas o vicios que ...

Últimamente me encuentro cada vez más seguido en conversaciones donde se busca encontrar "el método" para mejorar la calidad en un software, en un proyecto o en un equipo de desarrollo de software.  Veo además que las posturas se plantean en términos de blanco o negro: hacemos testing ágil o hacemos testing tradicional (es decir luego de haber desarrollado) o nos basamos en riesgos o hacemos alguna otra cosa.  Siempre que puedo, en esos casos, trato de dar visibilidad a los puntos grises porque, aunque suene repetitivo, no hay balas de plata y cada caso es un caso. Hay muchas formas de controlar y asegurar la calidad del software, no hay una única forma o una mejor forma . Hay intervenciones sobre el software en sí mismo y también sobre los procesos utilizados para construirlo.  Nuestro deber, si tenemos el rol de custodiar la calidad , es encontrar el mix correcto en cada caso. Es decir planear la estrategia de calidad  adecuada para ese problema cu...

Por estos días veo muchas empresas cortando servicios de proveedores. En particular veo que cortan servicios de testing de software. En estas situaciones escucho usualmente dos racionales para justificarlo: (1) al tener problemas de caja necesitan bajar los costos, (2) tienen menos trabajo y eso hace menos necesario el servicio. Obviamente que el argumento es entendible. Este no es un post para convencerlos de no recortar las actividades de testing. Cuando no te alcanza tenes que recortar y tarde o temprano llegas al hueso. Mi objetivo es conversar sobre el cómo , p orque hay formas y formas de hacer las cosas . La pregunta sería si cortar el testing por ser testing es lógico o si el criterio debería ser un poco más sofisticado. Cortar ciertos servicios que en nuestra estrategia habíamos definido que sean tercerizados como mínimo es peligroso. Sabemos que el servicio es importante, de otro modo no lo tendríamos de entrada (vivimos en un mundo pro recorte de gastos...

Hace unos días publiqué esta nota  que transcribo a continuación en Perspectiva Digital . En estos días nuestras rutinas y costumbres están siendo modificadas en forma abrupta. Hemos tenido que pasar a modalidad remota compulsivamente e iniciar una carrera contra reloj para mantenernos sanos y productivos. ​Empresas e individuos están siendo sometidos a un tsunami de cambios en diversos órdenes de la vida, pero uno de los frentes donde más claramente se ve esta situación es en el del comercio electrónico. Todos estamos teniendo que usar servicios online en una suerte de prueba de estrés coordinada a escala planetaria. El resultado a la vista es que pocos están preparados para algo así. Este es el momento en el que las empresas se acuerdan de aquel especialista (de la calidad, la infraestructura, etc.) les decía que sería bueno hacer pruebas de performance para entender los cuellos de botella del proceso o que si se mudaran a la nube tendrían un nivel de escalamiento ad...

Hace muchos años escribí mi tesis de licenciatura sobre Data Testing . En ella definí un modelo de testing para datos, haciendo un paralelo con el de testing de software. En el trabajo se repensaron varios de los conceptos básicos del testing de software, como por ejemplo el de testing funcional, el de testing de caja blanca y hasta los distintos niveles de prueba (de unidad, integración y de sistema). Días atrás, el director de aquella tesis me envió este articulo  en el que se habla del mismo tema, pero 18 años después. Por un lado, reconocí en él varias ideas de aquella época como la de usar consultas sobre los datos para probar condiciones estructurales sobre la información (los llamados supuestos en el artículo) o la de escribir dichas consultas de una forma particular, haciendo que el resultado arroje sólo las tuplas [1] con error. Por otro, encontré nuevas ideas como la de hacer testing continuo sobre ellos, corriendo las consultas todo el tiempo. En aquel ...

La semana pasada mencioné la necesidad de empezar renovar la práctica de testing  y dije que empezar a entender cómo probar la experiencia era uno de los ejes más importantes. Hoy voy a mencionar algunos otros brevemente y, con tiempo trataré de ir desarrollándolos: El uso de las nuevas tecnologías disponibles , como analítica de datos o inteligencia artificial, podrían mejorar drásticamente la productividad de los equipos de testing. Se imaginan que el mismo software de gestión de casos nos sugiera el próximo caso de pruebas a ejecutar en función de los que ya ejecutamos o que se nos informe la probabilidad de que un caso de error al momento de definirlo? La inserción de la práctica en los nuevos modelos de desarrollo . Con la irrupción de DevOps y BizDevOps , la práctica debe replantearse su rol, sus actividades y sus formas de relacionamiento con el resto del equipo involucrado en el desarrollo de software. Por ejemplo, ¿no debería el rol de testing extenderse...

En el mundo en que vivimos probar que una aplicación hace lo que debería es sólo el comienzo.  Para acompañar la evolución de las necesidades del negocio, el equipo de desarrollo de software debe ocuparse también de vigilar que la experiencia de usar dicha aplicación es adecuada también. Para ello, el rol del equipo de testing -incluido dentro del equipo de desarrollo- debe abarcar también esta premisa. Tradicionalmente los equipos de testing se ocupaban de verificar  que lo definido por el usuario y lo programado coincidían (¿estamos construyendo el sistema correctamente?). Con suerte además, el equipo podía también validar  la coincidencia entre lo que realmente piensa el usuario y lo programado (¿estamos construyendo el sistema correcto?). En nuestros días el equipo de testing tiene un nuevo desafío:  ¿La experiencia que el usuario tendrá, será la correcta? Vengo hablando de ese cambio  desde hace un tiempo, dando pistas de qué herramient...

Aquellos que trabajan haciendo testing saben lo difícil que es conseguir ambientes adecuados para las pruebas. Todos conocemos cómo debe ser un ambiente para garantizar que la prueba signifique algo  y cuando digo todos, no sólo me refiero a la gente haciendo testing, hablo de todos.  Sin embargo es común ver al equipo de pruebas hacer múltiples concesiones para poder siquiera arrancar su tarea. Es como que en ciertas organizaciones se sobreentiende que nunca llegaremos al ideal y que tenemos que conformarnos con lo que se pueda.  Pues la vida no es siempre así. En este  artículo se cuenta cómo Google llegó al extremo de inventar una pizzería, para poder probar la efectividad de sus anuncios, confirmando algo que todos sabemos intuitivamente: A medida que los riesgos aumentan, la inversión en el ambiente de pruebas debe ser mayor. Cuando la prueba es de bajo riesgo, tal vez podemos tener un ambiente menos representativo. Sencillamente la relación c...

Ayer por la noche, como a muchas personas, me llegó un mensaje curioso de Santander Río. Algunos, como @valenzine o @ameter , se lo tomaron a chiste, tal vez sabiendo que no era nada grave. Otros se preocuparon bastante. Muchos imaginaron hackeos o calamidades peores. Todo parece indicar que lo único que pasó fue que alguien hizo pruebas en el ambiente equivocado. La empresa así lo afirma  y les creo. Como truco publicitario sería caro. Lo cierto es que lo que antes era un "Ups!" que solucionabas con una disculpa, ahora se propaga rápidamente y cobra proporciones inimaginables. Tanto que inclusive la noticia sale en los diarios . Estamos ante un ejemplo más d el mundo en el que vivimos : vertiginoso, exacerbado y paranoico. O tal vez dinámico, exponencial e interesante. ;-) En lo que a la disciplina del testing de software se refiere, es claro que [el mundo] deja cada vez menos lugar al error y ese mandamiento que todos nos repetimos de "no probara...

El cliente se sorprendió cuando lo mencionamos. "¿Testear el journey de cliente?" preguntó. Sí dijimos. Si el lineamiento es mejorar la experiencia de cliente, debemos diseñar una forma de probarla. Cada tipo de testing tiene un objetivo, una razón de ser. Vamos construyendo certeza acerca de la calidad apilando distintos tipos de prueba. No tenemos que usar todos, todo el tiempo. Pensar la estrategia de pruebas justamente es elegir qué haremos y qué no haremos . El journey de cliente nos da una mirada distinta sobre el proceso y las aplicaciones donde se apoya, por lo tanto requiere diseñar una prueba diferente.  A veces será relevante hacerlo y otras no. Es un lente más a través del cual ver la calidad. Seguimos pensando..

El otro día leí por ahí a alguien que decía en el futuro imagino una profesión que sea "Diseñador de Tests para cualquier cosa"  y pensé ¿por qué no?  Hoy, en el marco de la práctica de testing de software, la habilidad principal del tester es la de saber diseñar pruebas . Encuentro un montón de ejemplos y situaciones que, en definitiva, mapean a eso: Plantear una estrategia de pruebas para un proyecto grande. Probar una aplicación sistemáticamente, definiendo casos de prueba, que garanticen cierto cubrimiento. Probar un cambio, minutos antes de pasarlo a producción, en forma intuitiva, utilizando técnicas de smoke testing. ... En forma más planificada o menos, siendo más formales o menos, trabajando en equipo o individualmente, siempre estamos diseñando pruebas. Doy un paso más. Creo que la habilidad de diseñar las pruebas es más importante que la de ejecutarlas. También hoy, en el campo de UX, la habilidad de diseñar pruebas para entender la experienc...

Hace un tiempo di una charla  en la que hablaba del futuro del testing y por donde podrían los testers ampliar sus horizontes.  En ese entonces decía que la gente que trabaja en testing no debía preocuparse mucho por la pérdida de puestos de trabajo a manos de la robotización y hablaba, por ejem plo, de usar las capacidades de testing en todo lo que tiene que ver con probar la experiencia de cliente . Hoy pensando en lo mismo, les traigo otra punta: RPA ( robotic process automation ). La idea detrás de RPA es entrenar a un robot para hacer acciones sobre una o varias aplicaciones, emulando lo que haría un humano.  Los beneficios de hacer algo así son los imaginables: optimización de las operaciones, reducción de costos, mejora en la experiencia del cliente, etc. Pero lo interesante, para la gente acostumbrada a hacer automatización de pruebas es que  Las habilidades necesarias para automatizar procesos en este nuevo contexto (RPA), son muy parecid...

En los 70s, en una planta japonesa había 12 clases de trabajos. En una planta en EEUU había 67 clases de trabajo. Además el trabajador japonés tenía 10 veces más horas de capacitación que el americano.  El trabajador japonés era más versátil y podía desempeñar una mayor cantidad de roles. Esa versatilidad era acompañada con una actitud flexible para aceptar hacer distintos tipos de trabajo.  Como resultado de esto, la diferencia de productividad entre plantas resultaba enorme. Sería interesante traer ese concepto a nuestra realidad de hoy y ver cómo estamos: ¿Cuán v ersátiles somos? ¿Cuán flexibles somos para desempeñar distintos roles? Si todos podemos y estamos dispuestos a hacer de todo, los tiempos ociosos disminuyen y po r consiguiente la productividad aumenta. Seguimos pensando..

Leyendo sobre la historia de Lean y cómo la productividad de la industria japonesa empieza a opacar a la norteamericana en los 70 me encuentro con una métrica interesante: Sugerencias por Empleado.  Me pregunto: Si en nuestras empresas tenemos un buzón de sugerencias. Si vemos que hay allí en algún momento. Si implementamos algunas de las sugerencias que allí se hacen. Si revisamos si analizamos los resultados de haberla implementado. ¿Produjo ahorros? Si premiamos a la persona, cuya sugerencia fue implementada exitosamente y produjo ahorros. Si no hacen estas cosas, no se pregunten por qué sus procesos no mejoran y, menos aún, por qué sus buzones están vacíos. Es bastante claro. Seguimos pensando..

En nuestros días ya no es necesario recordar la importancia de la estrategia de testing a nadie. Todos somos conscientes de que es necesario pensar antes de actuar, si queremos cuidar los -siempre escasos- recursos y tiempos asignados a las pruebas. Lo que no es tan común es tener designado un rol de estratega de testing en el equipo, cuya responsabilidad principal es pensar (o cuestionar) la estrategia de cada prueba.  Un rol así es importante pues nos previene de un error recurrente en los equipos de prueba, el de quedarse enamorados de una estrategia "default" .  A veces encontramos una fórmula que nos sirvió en el pasado y la adoptamos como única para todo lo que viene. Está en la naturaleza humana hacerlo. El problema es que en testing tenemos la famosa paradoja del pesticida : los bugs se acostumbran a nuestros pesticidas, por lo que tenemos que cambiar. Seguimos pensando..

Hace unos meses di una charla en Argentesting llamada Testeando el Estadio Aumentado . Les dejo el link aquí para el que quiera verla. Aprovecho para agradecer a los organizadores por el esfuerzo realizado, el resultado obtenido y el espacio que me dieron. Espero sinceramente que el evento siga creciendo año a año. Seguimos pensando..

En otra época instalar pocas veces en producción era un mérito. Se buscaba minimizar la cantidad de veces que se ponían cosas en producción, como forma de minimizar los riesgos. Hoy las empresas necesitan poner continuamente software en producción. Obviamente, la necesidad de minimizar riesgos permanece, la diferencia es que ya no es posible esperar y espaciar las instalaciones. Cuando una organización entiende esto, cae en la necesidad de planificar e implementar estrategias de continuidad para el Testing, el Delivery o para la Integración de su código . Seguimos pensando..

Es difícil negar que la práctica de testing, y en particular el rol del tester, está cambiando. La ola (o tsunami) de cambios tecnológicos que vivimos impacta también en dichas costas. El miedo existente en mucha gente, a ser reemplazados o quedar obsoletos por dicha ola, está patente en el mundo del testing. Pero ¿hay motivos? ¿Los testers deberían estar preocupados por los cambios que hay? ¿Los testers son una raza en extinción? Mi respuesta rápida es NO. El mundo consume cada vez más tecnología y por consiguiente cada vez más software. Esto, indefectiblemente hace que necesitemos seguir haciendo testing. El problema está en qué entendemos por testing cada uno de nosotros y aquí sí hay gente que debe preocuparse. En un interesantísimo artículo de 2013  (sí, de hace tiempo!), James Bach hace una distinción fundamental entre "checking" y "testing" que transcribo a continuación: "Testing is the process of evaluating a product by learning about i...

Me encuentro muy seguido con gente que piensa la calidad como un firewall que limita todo lo que pasa hacia producción, en lugar de pensarla como un proceso continuo en el que hacemos las cosas cada vez mejor, colaborando a lo largo de la cinta infinita de la imagen. Mejorar la calidad es movernos por esta verdadera cinta de Moebius  cada vez más rápido y en forma más fluida (sin detenernos). Cuando entendemos esto es que, por ejemplo, empezamos a apostar por otras formas de automatización que van más allá de lo obvio o empezamos a pensar en el next step as a customer  para facilitar las cosas. Seguimos pensando..