Dumb ways to Die...haciendo Testing

Es hora que retome este blog y me ponga a escribir, hoy fui inspirado por un compañero que compartió algo interesante con el grupo de QAs de la empresa en donde trabajo. Era un tema técnico, esperaré a que lo postee en su blog y lo compartiré.
Era algo más técnico de lo que me gusta escribir a mi, pero me ayudo a pensar en que debo tomar las riendas de este blog y volver a escribir, de lo que me salga de adentro, de lo que sienta sobre esta profesión.
Hoy quiero hablar de situaciones negativas, de momentos en que los Testers de sistemas nos sentimos "morir", en donde queremos abandonar la profesión. Muchas veces nos causamos a nosotros mismos estas situaciones evitables, que nos hacen sufrir pero que, si aprendemos a sortearlas, podremos disfrutar un poco mas y ver que esta profesión que nos gusta, vale la pena.
El titulo de este post esta inspirado en una campaña del metro Australiano para evitar muertes en las vías y estaciones de trenes, que podrían evitarse fácilmente: Maneras tontas de morir...testeando en nuestro caso.

Molestar a un Oso...o a un desarrollador:

Si, no son dioses, son seres humanos que se equivocan y mas veces de lo que ellos creen. Pero tampoco debemos estar con un palito pellizcando los cada vez que les encontramos un bug, porque nos comerán vivos, harán que el clima laboral se espese y nos entreguen cosas de mala gana o poca calidad. Debemos convertirnos en sus aliados (pero sin amiguismos, ya veremos por qué) en las personas que los ayudaremos a hacer mejor su trabajo y que se vean bien ante los jefes. De esta manera nos ayudaran a hacer mejor nuestro trabajo, a darnos una mano cuando la necesitemos.
Caso contrario, trabajar en un ambiente hostil (recuerden que los Testers/QAs somos pocos en cada equipo) puede volverse una pesadilla de la que no podamos salir, y tal vez le echemos la culpa a trabajar de Testers de software y no queramos hacerlo mas.

Ser comido por pirañas...o tus amigos los desarrolladores:

Llevarse bien con los Devs esta bien, ser amigos fuera del trabajo...genial. Ahora, a la hora de trabajar, el amiguismo puede ser contraproducente. A veces sucede que un desarrollador, especialmente uno que nos cae bien, nos puede pedir "un favor" a la hora de reportar un bug y que no lo hagamos. Otras veces, la propia simpatía y confianza que le tenemos, nos lleva a testear mas "displicentemente". En ambos casos, estos actos de buena fe nos pueden explotar en la cara, por que no estamos haciendo nuestro trabajo correctamente. No somos policías de la calidad ni debemos ser malos tipos con nuestros compañeros (recuerden el oso...) pero a la hora de testear, no hay amigos, no hay amiguismo ni nada, a cara de perro contra la pantalla y a hacer nuestro mejor esfuerzo. Esos amigos, si lo son realmente, apreciaran nuestro feedback y trataran de solucionar el problema rápidamente.
El amiguismo nos puede llevar a hacer mal el trabajo, a que nuestros jefes nos reprendan y a que terminemos odiando el trabajo. Hay que saber separar la paja del trigo.

Hacer testing solo por la plata...o venderte a cualquier precio:

Hay gente que hace cualquier cosa por la plata, inclusive ver al testing como un escalón mas para llegar a otra puesto que nos de mas plata, claro. Es común que a los QAs nos paguen menos, son cosas inexplicables, generalmente por lo mal que ha llevado la industria del software la importancia que tiene el Testing en el ciclo de desarrollo de software. Pero los buenos testers del mundo son muy buenos en lo que hacen y ganan muy bien, como lo hacen? Bueno, se capacitan, desarrollan su profesión, la llevan a nuevos horizontes, resuelven los problemas mejor y mas rápidamente que el resto...y se hacen valer. No solo económicamente, si no moralmente.
Otro problema de los testers, que los lleva a la inanición profesional, es que venden sus ideales, sus creencias del cómo debe desarrollarse su profesión, por unos pesos mas. Algunos lo hacen aceptando procesos y "buenas prácticas" obsoletas de hace años, otros patrocinando en sus empresas la compra de herramientas caras y obtusas, pero de renombre y con respaldo, con las cuales juegan "sobre seguro" (hp, ejem...) A la larga, esos testers se sienten miserables, así como los testers poco cualificados que buscan escalar, pero al no poder hacer bien su trabajo, solo terminan muriendo en la ignominia.

El tester suicida: 

No somos los gatekeepers, los guardianes del producto y su calidad. Somos los responsables de generar información para que los que toman las decisiones, puedan tomarlas sabiendo el estado actual del producto. Somos los responsables de ayudar a todo el equipo a trabajar en la calidad del producto, del primero al ultimo miembro, del primero al ultimo proceso, pero tampoco somos la policía del equipo, ese no es nuestro trabajo. En ambos casos, lo único que lograremos es inmolarnos en nombre de la calidad, haciendo cosas de poco valor. Y cuando todos nos apunten como los culpables, nos querremos morir y dejar el Testing para siempre.

Quemarse la cabeza...por hacer mal el trabajo

El desarrollo de software es una actividad creativa, una actividad pensante, y el testing lo es aún mas. Usamos todos nuestros sentidos, exprimimos nuestro cerebro al máximo para que no se nos escape ningún bug. El cerebro, según cuenta el Dr. Daniel Kahneman en su libro Pensar rápido, pensar despacio, dice que tenemos 2 sistemas, en donde (a grande rasgos) el sistema1 se encarga de las tareas rutinarias y el sistema2 de las tareas de control y de calculo. Si el tester usa su sistema1 únicamente, se le escapará la mayoría de los bugs. Los testers suelen usar este sistema demasiadas veces cuando hacen scripting testing. Un tester de clase mundial, trata de usar su sistema2 mas tiempo, que le permite chequear y verificar cosas que al sistema1 se le escapan. Esto tiene una consecuencia, el sistema2 usa y gasta mas energía que el sistema1, y nos agotamos mas rápidamente. Es por esto que los testers deben realizar sus tareas en sesiones cortas y tomarse descansos entre una sesión y otra, para poder encarar mejor el trabajo. De esta manera uno evitará que bugs obvios se nos escapen, al mismo tiempo que evitamos quemarnos la cabeza y morir de síndrome de Burnout.

Seguramente puedo escribir sobre muchas otras formas de "morir" testeando, pero el post sería muy largo. Si alguien quiere comentar y agregar nuevas formas, será bienvenido.

Finalmente les dejo abajo el video original de Dumb ways to Die, espero que les guste (es muy adictiva la canción)

La primera impresión NO es la que cuenta

Leyendo el post de Gustavo Terrera (@testingbaires) en su blog, se me ocurrió que podría reescribirlo para dar otro punto de vista.

Me gusta el intento de Gustavo por usar una situación que todos pasamos cuando nacemos y vamos creciendo y compararla con el trabajo del tester...pero no me gusta el enfoque, no me gusta lo que intenta enseñar, porque ese tipo de testing ya es obsoleto, debe evolucionar hacia algo nuevo, lamentablemente en Argentina seguimos usando prácticas que tienen más de 30 años.

Ahí va mi intento, espero que no te ofenda Gustavo ;)

Me es grato presentarles a Betore; Betore es un Tester de Software de 4 años de experiencia en la actualidad,es un Tester de software de una aplicación web en un prestigioso Cliente Internacional. Domina Inglés, algo de programación, es muy bueno analizando user stories y es hábil diseñando mapas mentales y tests de cobertura en su software favorito para esto (Hexawise).

Betore era de talla normal, nació por cesárea, en un ambiente tranquilo y sin stress, Betore no lloró, él sonrió…

Betore nació en un hogar cristiano, pero de mente abierta hacia otras culturas y filosofias, lo bañaban y esa obligación era un juego muy divertido, lo hacían dormir (esos ronquidos ya de niño parecía que supieras manejar metralleta) y de allí a jugar al fútbol los domingos por la tardecita, de vez en cuando iban a la iglesia, para cubrir las formas. Cuando le regalaron su primera computadora, lo primero que hizo fue romper el sistema operativo (SYNTAX ERROR!) Seguramente por eso Betore es un maniático de explorar sistemas y ver sus fallas, de conocer si el objeto de estudio sirve a sus propósitos o no (James Bach vive muchach@s!) y es un devoto del Software Testing.

Son muchos los momentos en que Betore exploraba al mundo con sus primeros pasos (exploratory testing- como odian los desarrolladores a esta clase de test…) Un día, aun cuando Betore gateaba, se encontraba en la sala de la casa, cuando vio la puerta abierta. Se fue gateando hacia ella para ver que había afuera (los papis lo sacaban mucho a pasear al muchacho pero siempre acompañado), se fue gateando rápidamente y se colgó de la manija de la puerta, cuando pudo sentir por primera vez solo la fuerza de sus piernas, se agarró de la puerta de manera muy hábil pero cayó y rodó por las gradas que daban al jardin, Betore se golpeó todo su cuerpo, Betore lloró, este Betore siempre curioso, muy curioso (característica de un buen Tester). Cuando mamá Moni escuchó el llorar de su amado hijito, fue pronta a socorrerlo, Betore con solo ver a su mamá sentía que ya estaba todo bien, así que sonrió en medio de las plantas que cuidaba su mamá (ella no lo sacaba por esta razón – por curiosear va a romper el jardín y se romperá él).

Betore había ganado un chichón, y un par de moretones en la pierna y brazo izquierdo, pero lo mas importante ganó una experiencia nueva, su primer paso por si solo, y sentir el dolor en medio del Mundo exterior que hay fuera de la seguridad de la casa. Betore probó si su cuerpito era resistente a las caídas y si había algo mas allá de lo que la vista le permitía observar. Primera Sesión de Pruebas realizada, resultado: aprender de sus errores, aprender cosas nuevas, equivocarse! (Va a tener que pasar un buen tiempo para que sus sesiones de pruebas le permitan aprender sin dolor, recuerden muchach@s los errores enseñan más que los éxitos!). Betore aprendió con la puerta abierta, con la colgada de la manija y con la caída, con el daño que se hizo y supo que lo que sintió por si solo con la fuerza de sus piernecitas le permitiría seguir explorando más adelante, había ganado una nueva herramienta para explorar!; con el horror de la cara de mamá al verlo aprendió que siempre habrá gente que nos cuestionará lo que hacemos, pero que los errores son las mejores lecciones en la vida.

Si Betore no fuera curioso y temiera una nueva reprimenda, nunca más hubiera salido a explorar el mundo.

Betore dentro de si, no sabía que un día viviría del Software Testing y que sería su mayor pasión, pero lo que si aprendió es que la primera impresión NO es la que cuenta!

Porqué el CyberMonday falló en Argentina:

 

Comprar Online en Argentina

 El lunes 2 de Diciembre se realizó el CyberMonday en Argentina, un dia en donde las tiendas online hacen ofertas especiales con supuestos grandes descuentos, al mejor estilo de Black Friday norteamericano. Se realiza en varios países y Argentina no fue la excepción, aunque es realizado mas por marketing que por ofrecer buenas ofertas a los clientes.

Pero como el año pasado, los sitios fallaron, si bien no todos, la mayoría se colapsaron y la experiencia se transformó en una tortura china para poder entrar y ver las ofertas, y en una misión imposible intentar comprar online.

Por qué falló? Bueno, Fabio en su blog tiene muy buenas explicaciones, algunas técnicas y desde el punto de vista de alguien que administra sitios, les recomiendo que las lean.

Pero me interesa verlo desde el punto de vista del Testing, porque esto habla muy claramente de cómo se maneja el Testing en nuestro País.

1) Atraso tecnológico y educativo: el testing sigue siendo una materia menor dentro de las carreras de ingeniería, pero especialmente en informática. Algunas universidades no tienen ni una sola materia al respecto, otras solo mencionan al Testing como una fase del desarrollo de sistemas y punto. Unas pocas tienen una materia que atrasa 40 años...

En Argentina casi no se desarrollan conferencias de nada, y las pocas que hay son mas por marketing que por compartir y desarrollar conocimiento. Obviamente no hay conferencias sobre testing en donde los Testers podamos juntarnos y compartir experiencias, herramientas y conocimiento, la comunidad de testing está muy desperdigada y poco organizada.

Muchos siguen pensando en términos de testing de la epoca en donde trabajar con metodologías de CMMI y Waterfall era algo normal, no buscan actualizarse.

2) A las empresas no les importa el Testing:  la propia industria del software, en su mayoría, no desarrolla especialistas en testing como debiera, usualmente contratan a juniors sin experiencia en desarrollo, diseñadores gráficos o cualquiera que no parezca lo suficientemente bueno como para programar. Se busca pagar poco, capacitar menos y “zafar” antes los requerimientos de los clientes (internos o externos) sobre la calidad de los productos que se desarrollan.

Durante el CyberMonday, grandes tiendas de electrodomesticos y electronicos (si, grandes empresas, no son pymes o startups) vieron desbordados sus sitios por tráfico, en un país de 40 millones de personas en donde apenas el 20% de la población hace compras online (y no muy asiduamente si bien el número crece) y encima rediseñaron sus sitios para este dia especial, haciéndolo mal y feo. A simple vista se veía, si podías entrar claro, que había cosas mal diseñadas, mal programadas, fuera de lugar, dropdowns que tardaban una eternidad en cargar valores traídos de la base de datos, etc.

Básicamente, se cagaron en el testing y por lo tanto, se cagaron en la calidad de su sitio, para finalmente cagarse en el cliente. Se notó, y mucho, que hubo más inversión en Marketing que en IT, no es que no pudieron prever estos problemas, es que no les importó. El año pasado les había pasado algo similar, y las lecciones aprendidas las deben haber guardado en un cajón, y obviamente no contrataron Testers para mejorar y revisar la performance del sitio ante un día

como este, no contrataron testers para revisar el rediseño del sitio, no contrataron testers para revisar que el workflow del carrito de compras funcione correctamente.

Este es un mal endémico en todas las industrias, hay cientos de sitios con problemas, desde Clarín hasta el más pequeño de los negocios con web propia, pasando por los gobiernos federales y provinciales,  pocos tienen en cuenta la importancia del Testing, pocos se preocupan por la calidad de sus sitios y sistemas, pocos se preocupan por la gente que debe usarlos.

3) Las leyes no amparan a los usuarios: Nadie hará nada contra estos sitios por el problema que le causó a los usuarios, hasta hace unos años a las empresas telefónicas no les hacían nada cuando sus sistemas de telecomunicaciones se caían, por suerte ahora eso está cambiando, pero...quien ampara al consumidor que no pudo comprar durante el CyberMonday? habrá sanciones a estas empresas por presentar sistemas defectuosos y fraudulentos?

Se habla mucho en todo el mundo si se puede legislar o no sobre la calidad de un producto de software, pero al menos los gobiernos deberían hacer algo al respecto en casos sonoros como este o el de Healtcare.gov en EEUU.

4) Los Testers no nos hacemos respetar: por último, nosotros debemos hacer un mea culpa, por no replantear nuestra profesión, por no profesionalizarse, porque aún somo “la poca cosa” dentro de un equipo de desarrollo, porque no nos capacitamos y actualizamos como es debido, porque no demostramos nuestra importancia durante el proceso de desarrollo, porque no informamos como es debido sobre el estado actual de la calidad del software a la gente que toma decisiones al respecto. Debemos tomar relevancia, no somos un escalón hacia un trabajo mejor dentro de IT, somos una pieza vital dentro del desarrollo del software, y podemos ayudar, y mucho, al éxito de un producto o empresa. No nos podemos hacer los tontos, es hora que nos pongamos los pantalones largos.

Encontrá el error..se la robé a Fabio.com.ar :)

Un tester suelto en una Hackathon

El sábado 7 de Septiembre de 2013 participé como parte del grupo organizador de la Hackatrix 2013, la primera Hackathon organizada por Belatrix, empresa en donde trabajo.

Decidí participar por que quería conocer ese universo, el de programadores codificando una app en pocas horas, y sacar ideas para futuros eventos que estén más relacionados con el Testing.

La armamos con mucho esfuerzo y dedicación, no queríamos que fuera un simple evento de marketing o un evento de poca monta hecho en las oficinas de la empresa y con unas pizzas (hubo ejemplos en Mendoza en estos últimos meses, a mejorar chicos...ejem...)

Por suerte tuvimos algo de repercusión mediática, se lograron los objetivos internos que se planteó la empresa, pero sobre todo logramos que todos los participantes se comprometan con lo que estaban haciendo, no vinieron a comer o a pavear, si hasta muchos se perdieron el coffee break de las 11 por que estaban muy concentrados codeando!

Salió todo muy bien, y estamos súper felices y cansados, pero con ganas que este evento se vuelva anual y marque la agenda "tecnológica" de Mendoza.

Las cosas que rescato de la Hackatrix:

• Comida! si, un evento con comida es mas agradable y llevadero. Nunca dejen ese punto descuidado.

• Más allá que participen áreas que no tienen que ver con desarrollo, como Marketing y RRHH, es fundamental que el núcleo de la organización pase por gente que tiene experiencia con esta clase de eventos y desarrolladores, que entienden lo que les gustaría que pase durante el evento, y además tienen en cuenta cosas importantes como cableado eléctrico e internet, 2 puntos fundamentales para que sea un éxito un evento hoy en día.

•  Relacionarse: si algo me faltó fue relacionarme más con la gente que participó en la hackathon, al ser tester y no tener un equipo al que ayudar directamente, no me involucré mucho con la gente, prometo romper ese hielo en la próxima, entre los equipos y los demás organizadores que sí eran programadores hubo buen feeling y feedback y se complementaron muy bien aunque no se conocían.

• Nacionalizar: Aunque tu evento sea local, no dejes de pensar a lo grande, hay que invitar gente de otros lugares a que venga y participe. Desde Córdoba vinieron cuatro chicos de la UTN Villa María, y la pasaron muy bien. Su proyecto fue el que mas integrantes tuvo, ya que se sumaron 4 mendocinos al mismo.

• Prensa: hoy en día se puede hacer mucho ruido con las redes sociales, pero los periodistas ayudan mucho a contar lo que pasó y eso puede ayudar a que los proyectos que se generaron puedan tener difusión post evento, uno nunca sabe el vuelo que puede tener un proyecto más allá de la hackathon.

•  Hacerlo con ganas: ninguno de los organizadores cobró por hacerlo, fue simplemente ganas de hacer algo bueno que ayude a desarrollar tecnología en Mendoza y mostrar de lo que somos capaces. Interactuar, "salir de la cueva" en la que estamos cada uno para ver que se puede hacer y aprender juntos, esa era la idea y creo que la logramos

• Seguir haciendo y participando: hay que generar más hackathones y eventos de este tipo, no sólo para desarrollo sino también para Testing, DBA, diseño y todo lo relacionado con tecnología. Que no quede nada en "un evento por única vez", ojalá que la Hackatrix se vuelva un evento anual y que cada año participe más gente.

Les dejo para el final un Storify que hice con lo sucedido en la Hackatrix2013:

Primera Hackathon Social en Mendoza - Hackatrix

Siempre he dicho que es bueno participar y generar participación en esta industria que es la del software. El software se genera a partir de ideas y necesidades de la comunidad, a veces con fines de lucro, a veces para ayudar a los demás.
En Mendoza, la empresa en donde trabajo, Belatrix, organiza la primera Hackathon con fines sociales de la provincia, y tal vez del país, en donde mucha gente se juntará durante un día a pensar y desarrollar ideas que puedan ayudar a nuestra comunidad.

Será el sábado 7 de Septiembre de 2013, en el Le Parc. Pueden anotarse o dejar su idea en la web del evento.


Pronto publicarán los premios y todas las novedades que se vayan generando. Allí también encontrarán mucha data para prepararse previamente y estar lsitos para ese día.

Ojalá entre todos podamos hacer una hackathon divertida y que genere muchas cosas constructivas para todos, los esperamos!

Estos amargos no vienen...

Charla de James Bach en TestBash 2.0

Me encantó esta charla (en inglés) posteada en TestBash 2.0 de James Bach, a él también le gustó,obvio:

One of my best talks. "@damimj: another great lesson by @jamesmarcusbach ministryoftesting.com/2013/04/testba… #testbash"

— James Marcus Bach (@jamesmarcusbach) 26 de abril de 2013

El Tester Arquero

Genios.

Arquero: En el fútbol, el guardameta (también llamado meta, cancerbero, arquero, portero, o golero) es la posición que representa la última línea de defensa entre el ataque del oponente y la propia portería. Es una de las posiciones más difíciles de jugar, debido a su gran complejidad y responsabilidad. La función principal del jugador en esta posición es la de defender directamente la portería y evitar que el contrario marque gol. 1

"Y que queres? Si es Arquero!"  Diego Maradona

En el fútbol, yo soy arquero. Desde chico. También he jugado como delantero, me encanta hacer goles, pero tal vez por mandato paterno, porque no soy tan bueno en otros aspectos que debe tener un goleador, porque nadie quería hacer ese trabajo ingrato de ser arquero en el equipo, me decidí por atajar, volar de palo a palo, tocar con la punta de los dedos la pelota y que se vaya besando el poste, mientras mis compañeros dejan de respirar por un segundo. Muy poético...pero nos odian, nos menosprecian durante 89 de los 90 minutos de un partido y cada gol en contra es una sentencia de muerte para el arquero, culpable de todos los males, poco saludado y apreciado en las alegrías.

El trabajo del arquero es ingrato.

En el trabajo, yo soy Tester. Desde hace poco más de un año. También he sido analista, me gusta analizar los problemas y ver que solución se le pueden dar, cual es la mejor manera de encarar una solución. Pero por razones de la vida, mudarme  a una nueva ciudad, no aburrirme escribiendo innumerables documentos, hacer algo novedoso, porque nadie quiere ser Tester, me decidí por hacer este trabajo, encontrar defectos que nadie encuentra antes de que el producto llegue a producción, ver como ese defecto se arregla, y los desarrolladores suspiran cuando un nuevo release sale a producción y nos felicitan, aunque ellos son felicitados por su gran trabajo, y a los testers nos felicitan con una palmadita por hacer lo que debíamos hacer.

El trabajo del Tester es ingrato.

Dicen que el Tester es el "gatekeeper" de la calidad de un producto. Muchos estamos en contra, como James Bach en su blog, o Joel Montvelisky en el suyo.

Yo propongo que nos comparen con el "goalkeeper", el arquero.
Nosotros no frenamos un release, intentamos que nos hagan la menor cantidad de goles en contra (bugs en producción) de manera que los mayores aciertos de nuestro equipo nos permitan ganar (salir a producción). Los goles son culpa de todo el equipo (atacantes, centros, defensas y el arquero), los bugs son culpa de todo el equipo (desarrolladores, diseñadores, analistas y testers).
El arquero tiene una visión diferente del juego, lo ve todo desde atrás, por lo que puede ver facetas del juego que otros (incluido el técnico) no pueden ver. Por eso es muy importante que tenga buenas habilidades de comunicación, para poder ordenar la defensa y el juego de contraataque. El Tester también tiene una visión diferente del desarrollo de un producto, tiene que ver las cosas desde otro contexto (incluso de sus Managers). Y sus habilidades de comunicación son imprescindibles, para poder hacer las preguntas correctas, a los actores correctos, en el momento justo, para solucionar problemas o bien evitarlos a futuro.
Los mejores arqueros tienen habilidades que normalmente no se le piden, como jugar bien con los pies, transformándose en el ultimo defensor del equipo, o patear penales, que en ciertos momentos de un partido pueden ser importantes para el equipo. Los mejores testers también requieren habilidades que normalmente se cree que no tienen, como el conocimiento de lenguajes de desarrollo, o la aplicación de herramientas para mejorar el trabajo.

Los mejores equipos de fútbol, quieren y miman a sus arqueros de clase mundial, porque saben que los van a necesitar cuando más necesarios son. Debemos lograr lo mismo en los equipos de desarrollo, debemos convertirnos en los "Goalkeepers" del desarrollo de software.