TESTING y CHECKING Refinado - Traducción al Castellano

Hace un tiempo largo,realicé una traducción de un post de IlariHenrik Aegerter y ahora me he propuesto traducir otros artículos interesantes de otros autores, por que muchos no saben o no tiene tiempo de leer en inglés. No soy traductor profesional, pero trataré de hacer lo mejor posible. Lo único que no traduciré en algunos casos son las palabras Testing, Tester y Checking, para que no haya confusión.

Este articulo es de los autores James Marcus Bachy Michael Bolton, pueden ver mas post en su idioma original aquí y aquí.


Este post es co-escrito con Michael Bolton. Hemos pasado horas discutiendo sobre casi cada frase. También queremos agradecer a Iain McCowatt por su rápida revisión y comentarios.

Las pruebas y el uso de herramientas son dos cosas que han caracterizado a la humanidad desde sus inicios (No las únicas dos cosas, por supuesto, pero sin duda dos de las varias cosas que la caracterizan) Pero mientras que el testing es cerebral y en gran parte intangible, el uso de herramientas está al descubierto. Las herramientas invaden en todos los procesos que tocan y las herramientas cambian esos procesos. Por lo tanto, durante al menos un centenar o un millar de siglos, los más filosóficos entre nuestra especie se han preguntado: "¿Yo hice eso o lo hizo la herramienta? ¿Soy un guerrero o una plataforma de lanzamiento de lanzas? ¿Soy un agricultor o un empujador del arado?" Como dijo Marshall McLuhan "Damos forma a nuestras herramientas, y después de eso nuestras herramientas nos dan forma a nosotros".

Esta evolución puede ser un proceso insidioso que desafía la forma en que nos etiquetamos a nosotros mismos y las cosas que nos rodean. Podemos ser testigos de cómo la industrialización cambió ebanistas por fábricas de gabinetes, y que puede tentarnos a hablar de la evolución del papel del ebanista, pero el trabajador de la fábrica de gabinetes, ciertamente no es un ebanista mutado. Los artesanos del gabinete todavía están allí afuera, menos numerosos es verdad, nunca cerca de una fábrica, haciendo gabinetes costosos y bien hechos. El habilidoso cabineteer (Estaba lo suficientemente motivado para Googlear si había una palabra especial para este tipo de expertos) se encuentra todavía en demanda, para resolver problemas que IKEA no puede resolver. Existe esta posición en el campo de la ciencia y la medicina, también. Existe en todas partes: ¿cuáles son las implicaciones de la evolución de las herramientas sobre el trabajo de la mano de obra cualificada? Cualquier persona que busca la excelencia en su oficio debe luchar con el rol apropiado de las herramientas.

Por lo tanto, no hay que sorprenderse de que el Testing es hoy un proceso que incluye a las herramientas de muchas maneras, y que esto desafía la idea de un tester.
Esto siempre ha sido un problema - He estado trabajando con y discutiendo sobre esto desde 1987, y la literatura de esto se remonta al menos a 1961, pero algo nuevo ha sucedido: la informática móvil y distribuida a gran escala. Sí, esto es nuevo. Esto siempre ha sido un problema - He estado trabajando con y discutiendo sobre esto desde 1987, y la literatura de esto se remonta al menos a 1961, pero algo nuevo ha sucedido: la informática móvil y distribuida a gran escala. Sí, esto es nuevo. Veo que este es el mayor desafío para el Testing tal como lo conocemos desde el advenimiento de las micro-computadoras. ¿Por qué exactamente es un reto? Porque además de la complejidad de los productos y plataformas que han ido creciendo de manera constante durante décadas, ahora existe un gran mercado para los productos de software que se espera que sean distribuidos y actualizados al instante.

Queremos probar un producto rápidamente. ¿Cómo lo hacemos? Es tentador decir "Hagamos que las herramientas lo hagan!" Esto pone una enorme presión sobre los testers de software especializados y aquellos que crean herramientas para que los testers usen. Mientras tanto, las personas que no son expertos testers de software, tienen visiones de la industrialización del Testing similares a aquellas primeras fábricas de gabinetes. Sí, siempre ha habido estas presiones, en algún grado. Ahora el toque de tambor de "despliegue continuo" ha abierto otro frente en esa guerra.
Creemos que el trabajo cognitivo calificado no es trabajo de fábrica. Por eso es más importante que nunca entender lo que es Testing y cómo las herramientas pueden apoyarlo.

Checking vs Testing

Por esta razón, en la metodología de Rapid Software Testing, distinguimos entre los aspectos del proceso de pruebas que las máquinas pueden hacer frente a los que sólo los humanos capacitados pueden hacer. Lo hemos hecho lingüísticamente mediante la adaptación de la palabra comun en Inglés "checking", para referirse a lo que las herramientas pueden hacer. Esto es exactamente paralelo con la convención de larga data de distinguir entre "programar" y "compilar".
La programación es lo que los programadores humanos hacen. La compilación es lo que hace una herramienta en particular para el programador, a pesar de que un compilador  podría ser, técnicamente, lo que los programadores hacen. Ahora que lo pienso, nadie habla de la programación automática o programación manual. Hay programación, y hay un montón de otras cosas hechas por las herramientas. Una vez que se crea una herramienta para hacer esas cosas, nunca se llama de nuevo programación.

Ahora que Michael y yo hemos tenido más de tres años de experiencia trabajando con esta distinción, hemos agudizado nuestro lenguaje aún más, con las definiciones actualizadas y una nueva distinción entre la comprobación humana y la comprobación de la máquina.
Primero echemos un vistazo a Testing y Checking. Aquí están nuestras nuevas definiciones propuestas, que pronto sustituirán a los que hemos utilizado durante años (sujeto a revisión y comentario por colegas):

Testing es el proceso de evaluación de un producto mediante el aprendizaje sobre él a través de la experimentación, que incluye hasta cierto punto: cuestionamiento, estudio, modelado, la observación y la inferencia.

(Un Test es una instancia del Testing)

 Checking es el proceso de hacer las evaluaciones mediante la aplicación de reglas de decisión algorítmica a las observaciones específicas de un producto.

(Un check es una instancia del Checking.)

Notas explicativas:

• "Evaluar" significa hacer un juicio de valor; ¿es bueno? ¿es malo? pasa? falla? qué bueno? lo malo? Cualquier cosa por el estilo.
• "Evaluaciones" como un sustantivo se refiere al producto de la evaluación, que en el contexto de Checking va a ser un artefacto de algún tipo; una cadena de bits.
• "Aprendizaje" es el proceso de desarrollo de la mente de uno. Sólo los humanos pueden aprender en el más amplio sentido del término, como lo estamos usando aquí, porque nos estamos refiriendo al conocimiento tácito y al explícito. 
• "Experimentación" implica la interacción con un objeto y la observación , ya que está en funcionando, sino que también nos estamos refiriendo a los "experimentos mentales" que involucran la interacción puramente hipotética. Al hacer referencia a la experimentación, no estamos negando o rechazando otros tipos de aprendizaje; simplemente estamos tratando de expresar que la experimentación es una práctica que caracteriza al Testing. También implica que el Testing es congruente con la ciencia.
• La lista de palabras en la definición Testing no son exhaustivas de todo lo que podría estar involucrado en las pruebas, sino que representan los procesos mentales que pensamos que son más vitales y característicos.
• "Algorítmico" significa que se puede expresar de manera explícita en una manera que una herramienta podría realizar.
• "Observaciones" pretende abarcar todo el proceso de observar, y no sólo el resultado.
• "Observaciones específicas" significa que el proceso de observación resulta en una cadena de bits (de lo contrario, las reglas de decisión algorítmica no podían operar en ellos).

Hay ciertas implicaciones en estas definiciones:

• Testing abarca Checking, mientras que Checking no puede abarcar Testing
• Checking es un proceso que puede, en principio ser realizado por una herramienta en lugar de un ser humano, mientras que el Testing sólo puede ser apoyado por herramientas. Sin embargo, las herramientas se pueden utilizar para mucho más que comprobar.
• No estamos diciendo que la verificación deba ser automatizada. Pero la característica definitoria de una verificación es que puede ser completamente automatizada, mientras que el Testing es intrínsecamente una actividad humana.
• Testing es una investigación abierta - piensa en "Sherlock Holmes"- mientras que Checking es la abreviatura de "Checking de hechos" y se centra en los hechos y las normas específicas relacionadas con esos hechos.
• Checking no es lo mismo que confirmación. Checking se utiliza a menudo en un modo de confirmación (típicamente durante las pruebas de regresión), pero también podemos imaginarlos utilizarse para des-confirmación o para la exploración especulativa (es decir, un conjunto de controles generados automáticamente que pisa al azar a través de un vasto espacio, en busca de algo diferente). 
• Un problema común en nuestra industria es que checking se confunde con Testing Nuestro propósito aquí es reducir la confusión.
• Un verificación es descriptible; una prueba podría no serla (eso es porque, a diferencia de una verificación, una prueba implica conocimiento tácito)
• Una afirmación, en el sentido de las Ciencias de la Computación, es una especie de verificación. Pero no todas las verificaciones son afirmaciones, e incluso en el caso de las afirmaciones, puede haber código antes de la afirmación que es parte de la verificación, pero no es parte de la afirmación.
• Estas definiciones no son juicios morales. No estamos diciendo que la comprobación es inherentemente, hacer algo malo.Por el contrario, la comprobación puede ser algo muy importante que hacer. Nosotros afirmamos que para el checking  se considere bueno, debe ocurrir en el contexto de un proceso de inspección. Checking es una táctica de Testing.

¿Hacia dónde va la Sapiencia?

Si usted sigue nuestro trabajo, ya sabe que le hemos dado mucha importancia a la sapiencia. Un proceso sapiente es un proceso que requiere un ser humano debidamente capacitado para llevarlo a cabo. Sin embargo, en varios años practicando con esta etiqueta, hemos encontrado que es casi imposible de evitar dar la impresión de que un proceso no sapiente (es decir, uno que no requiere de un ser humano, pero podría implicar un ser humano muy talentoso y hábil, no obstante) es un proceso estúpido para gente estúpida. Eso es porque la palabra sapiencia suena como la inteligencia. Algunos de nuestros colegas han tomado una fuerte excepción a nuestra discusión de los procesos no sapientes sobre la base de ese malentendido. Por consiguiente, consideramos que es hora de ofrecer a este término en particular del arte, su jubilación.

Checking Humano vs Checking mecánico

Aunque sapiencia es problemática como etiqueta, todavía tenemos que distinguir entre lo que los seres humanos pueden hacer y lo qué las herramientas pueden hacer. Por lo tanto, además de la distinción básica entre control y prueba, también distinguimos entre checking humano y checking mecánico. Esto puede parecer un poco confuso al principio, ya que checking es, por definición, algo que se puede hacer por las máquinas. Usted podría ser perdonado por pensar que el control humano es lo mismo que checking de la máquina. Pero no lo es. No puede ser.

En el checking humano, los seres humanos están tratando de seguir un proceso algorítmico explícito. En el caso de las herramientas, sin embargo, las herramientas no están simplemente cumpliendo ese proceso, ellas lo encarnan. Los humanos no pueden encarnar dicho algoritmo. He aquí un experimento mental para demostrarlo: dígale a cualquier humano que siga una serie de instrucciones. Consiga que esté de acuerdo. Ahora observe lo que ocurre si usted lo hace imposible para él completar las instrucciones. Él no va a sentarse allí hasta que muera de sed o de la exposición. Él se detendrá a sí mismo y cambiará o saldrá del proceso. Y ahí es cuando se sabe a ciencia cierta que este ser humano, desde el principio, estaba encarnando algo más que el proceso que él acordó seguir y trató de seguir. No hay forma de evitar este caso si estamos hablando de personas con capacidad cognitiva normal, o incluso mínima. Cualquiera que sea el procedimiento que parecen estar siguiendo los humanos, ellos siempre están haciendo algo más, también. Los seres humanos están constantemente interpretando y ajustando sus acciones en formas que las herramientas no pueden. Esto es inevitable.

Los seres humanos pueden realizar acciones motivadas; las herramientas sólo pueden mostrar un comportamiento programado (ver el brillante libro de Harry Collins y Martin Kusch La Forma de las acciones, para obtener una explicación completa de por qué esto es así). La conclusión es: puedes definir una verificación con bastante facilidad, pero un ser humano realizará por lo menos un poco más durante esa verificación - y también menos en algunas formas-que una herramienta programada para ejecutar el mismo algoritmo.

Por favor comprenda, un papel sólido para las herramientas en el Testing debe ser aceptada. A medida que trabajamos hacia un futuro de Testing calificado, potente y eficiente, esto requiere una cuidadosa atención tanto a la parte humana y la parte mecánica de la ecuación de Testing. Las herramientas nos pueden ayudar de muchas maneras que van mucho más allá de la automatización de las verificaciones. Pero en esto, ellas juegan necesariamente un papel de apoyo a los humanos capacitados; y el uso torpe de herramientas puede tener terribles consecuencias.

Aprender experimentando, incluye el estudio, el cuestionamiento, el modelado, la observación, la inferencia, etc.

También puede preguntar por qué no nos limitamos a llamar al checking humano, "testing". Bueno, lo hacemos. Tenga en cuenta que todo esto está ocurriendo en el ámbito de Testing. El checking humano es parte de Testing. Sin embargo, creemos que cuando un ser humano está tratando de forma explícita de restringir su pensamiento a los confines de una verificación - a pesar de que no podrá hacer eso completamente- es ahora una táctica específica y restringida de Testing y no toda la actividad de Testing. Se merece una etiqueta propia dentro de Testing.

Con todo esto en mente, y con el objetivo de despejar la confusión, afilar nuestra percepción, y promover la colaboración, recuerde nuestra definición de checking:

Checking es el proceso de hacer las evaluaciones mediante la aplicación de reglas de decisión algorítmica a las observaciones específicas de un producto.

A partir de esto, hemos identificado tres tipos de checking:

Checking humano es un intento de proceso de comprobación en donde los seres humanos recogen las observaciones y  aplican las reglas sin la mediación de las herramientas. 

Checking mecánico es un proceso de comprobación en donde las herramientas recogen observaciones y  aplican las reglas sin la mediación de los seres humanos. 

Checking humano/mecánico es un intento de proceso de comprobación en el que los seres humanos y las herramientas interactúan para recoger observaciones y aplicar las reglas.

Para explicar esto a fondo, tendremos que hablar de ejemplos específicos. Puedes buscarlos en un próximo post.

Mientras tanto, te invitamos a comentar sobre esto.

ACTUALIZACIÓN 10 de abril 2013: Como resultado de intensas discusiones en la conferencia de pares SWET5, he actualizado el esquema de control y prueba. Tenga en cuenta que Testing está sentado fuera de la caja, ya que está describiendo toda la cosa, una descripción de Testing está en el interior de la misma. Checking humano se caracteriza por una nube, ya que su límite con aspectos no verificables del Testing no siempre es claramente discernible. Checking Mecánico se caracteriza por una línea punteada precisa, porque a pesar de su límite está claro, es una actividad opcional. Técnicamente, la comprobación humana también es opcional, pero sería un proceso de prueba verdaderamente extraño que no incluya al menos algunas comprobaciones humanas. Doy las gracias a los asistentes de SWET5 por ayudarme con esto: Rikard Edgren, Martin Jansson, Henrik Andersson, Michael Albrecht, Simon Morley, y Micke Ulander.

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