Primera Meetup de TestingAR

Bueno, hace mucho que no escribo, pero esto valia la pena.

Se viene la primera Meetup en Buenos Aires de Testing. Una nueva comunidad empieza y esperemos que de a poco crezca y tenga un alcance mayor.
La idea es dar 2 charlas sobre diferentes temas, compartir un rato y hablar sobre lo que nos interesa.
En un futuro trataremos de dar algun workshop y si podemos lograr que tenga una frequencia bimestral, sería genial. Pero eso depende de la participación de todos.

Pueden anotarse aqui
Compartan!

Apenas tenga mas informacion sobre las charlas, lo comentare en este post.

Mi set de Herramientas de Testing 2015: Basta de screenshots, hola GIFs!

Cuando empecé a trabajar en Marzo en Mulesoft, me encontre con que me habian dado una MacBook Pro, mi primera Apple! Siempre fui un "chico PC" por razones obvias, este pais no esta hecho para Mackintoshs, iphones, ipads o MacBooks, no, somos un pais-PC.
Junto con la MacBook me encontre tambien con que muchas de las herramientas de escritorio que usaba para testear, no me servían porque eran para PC, como el Snag-it o el Qtrace (que ya no existe en su forma gratuita) asi que me tuve que armar un nuevo set de herramientas, pero no hay mucho para Mac propiamente dicho.

Por suerte mi jefe me recomendó mi primera herramienta para Mac: Lice-Cap

Con esta pequeña herramienta puedo armar  videos cortos en donde mostrar problemas que encuentro en formato GIF, por lo que el developer no tiene que hacer nada mas que abrir el GIF y verlo repetirse. Es útil para videos cortos, cosas mas largas se complica por que no se puede pausar.

Por suerte hay muchas herramientas online como add-ons de los browsers, algunas de las que mas uso son:

Awesome Screenshot: Aunque ya no lo uso tanto, de vez en cuando sigo utilizando este excelente add-on para sacar y comentar screenshots, se puede agregar tanto a Chrome como a Firefox

MindMup: La mejor herramienta para hacer mapas mentales, sencilla de usar, agradable a la vista, con muchas funcionalidades utiles, la estamos usando mucho en nuestro proceso de testing (Comentaré mas de esto en un futuro post) Puede compartirse mapas con Drive, Github o la herramienta propia

Postman: Me gusto siempre que fuera sencilla de usar, ahora que tengo que testear APIs mas seguido, me es fundamental. Tiene un add-on para chrome y una version de escritorio

BugMagnet: comente de esta herramienta hace poco, sigue evolucionando, aunque no está funcionando muy bien en Firefox, anda perfecto en Chrome. Herramienta fundamental para el testing exploratorio.

Seguiré buscando herramientas para Mac o nuevos add-ons, y los iré posteando aqui.

El Fin Del Mundo

Gracias Belatrix, Hola Mulesoft!

 





Acá en Argentina no se acostumbra mucho esto. En EEUU si (obviamente si te fuiste bien del lugar en donde estuvistes) escribir sobre tu cambio laboral en tu blog es algo mas común en aquellos pagos.
Pero la verdad es que queria hacerlo porque estoy muy emocionado y contento con este gran paso que he dado.
He dejado buenos amigos y grandes compañeros de trabajo, con los cuales comparti mas de 3 años de alegrías, asados, trabajo duro y aprendizaje. Realmente Belatrix es una gran empresa para aprender y mejorar tu forma de trabajar. Es una empresa con gran crecimiento y que seguirá expandiendose por todo latinoamerica. Si quieren irse a vivir al interior no hay mejor lugar para elegir y empezar una nueva vida que Belatrix, les deseo lo mejor.

Y por que Mulesoft? Bueno, creo que era el momento de dar el paso y seguir creciendo en mi carrera como Software Tester, en una startup que crea un producto propio, no un producto que será vendido por otro. Quiero sentir la sensación de crear algo y que mi influencia sea importante en el resultado final.
Mulesoft es genial, te obliga a cambiar tu mentalidad, a autoexigirte porque tenes al lado gente muy capaz, ademas te sentis parte de lo que sucede en el crecimiento de la empresa y sus productos.
Otro gran motivo ha sido que Mulesoft esta apostando a mejorar la calidad de sus productos, que la calidad sea un agente diferenciador frente a la competencia. Por lo que hay mucho por hacer y crear y en donde podré aportar ideas nuevas para lograr un mejor proceso de testing utilizando las ultimas tendencias. Mucho por aprender y mucho por aportar, me encanta este nuevo rumbo.
A veces uno no puede elegir en donde trabajar, yo tengo la suerte de poder hacerlo en donde quería estar.  Uno no debe bajar los brazos e insistir, porque la primera vez que me postulé, no quedé. Pero no me desanimé y apenas surgió otra posibilidad, la aproveché.
Ojalá pueda contarles en futuros posts, que estamos creando en Mulesoft sobre testing.

Si quieren conocer más de Mulesoft o postularse pueden verlo aquí

viejos y nuevos amigos en mi escritorio

The Testing Manifesto

Así como existe un Manifiesto Agile, está bueno que exista uno sobre el testing de hoy en día. Una propuesta es el que ven acá arriba. Son 5 cuestiones básicas que deben regir sobre como actuamos mientras hacemos testing y que resumen qué es, realmente, hacer Testing.

Probar durante antes que probar al final: Si estas en un proyecto bajo la metodologías ágiles y pruebas solamente cuando el desarrollo está completo, no estás siendo ágil y tampoco estas haciendo bien tu trabajo. Es mucho mejor ir testeando a medida que los desarrolladores van completando sus tareas, de manera de poder darles un feedback rápido y solucionar los problemas antes del final del sprint.

Prevenir los defectos antes que encontrar defectos: Generalmente nos contratan para encontrar defectos...pero ese no es nuestro trabajo principal. Lo que debemos lograr es prevenir que se creen esos defectos antes que lo encontremos. Como? ayudando a los desarrolladores a testear mejor sus desarrollos, a que entiendan los posibles caminos alternativos. Analizando los requerimientos, buscando fallas en los mismos o cosas asumidas y que no son claras.

Entendimiento del testing antes que chequear funcionalidad: Verificar que la funcionalidad nueva ¨funcione como se espera¨ no  es hacer testing, es solo hacer un checking manual, el cual podría automatizarse a futuro, pero no es hacer testing.
Testing es entender la funcionalidad, su contexto, quienes la pueden usar, como afectara a las viejas funcionalidades, que cosas le faltan, que cosas le sobran, y cualquier otra información necesaria que nos permitirá entender mejor qué estamos testeando y generar luego un reporte con la información obtenida a partir de nuestro trabajo, para que la gente que decide sobre la calidad del producto, pueda tomar decisiones.

Construir el mejor sistema antes que romper el sistema: aparte de encontrar defectos, los demás creen que lo que hacemos es romper el sistema, y nos ven como seres negativos y oscuros porque rompemos eso tan bonito que pensaron, diseñaron y construyeron. Pues les tengo noticias, los testers no rompen el sistema...ya estaba roto. Nuestro trabajo es ayudar a los que lo construyen a hacerlo lo mejor posible, con la mayor calidad posible, somos parte de ese proceso de construcción, no los agentes de destrucción!

Responsabilidad del equipo por la calidad antes que responsabilidad del tester: No somos los guardianes de la calidad, no somos los policías que van descubriendo los crímenes de los desarrolladores. Como testers, somos responsables de ayudar al equipo en su totalidad a comprometerse con la calidad del producto. El producto se realiza entre todos, y la calidad también. Debemos asegurarnos que el equipo desarrolle practicas que ayuden a mejorar la calidad, ya sea desde el análisis, el diseño, el desarrollo o el mismo testing. La calidad es responsabilidad de todos, si eso es entendido por todos, será mucho mas fácil mejorar.

Creen que falta algún punto? algo para mejorar? Seguramente que si, pero con estos principios básicos, la calidad del producto, y nuestro trabajo, será mucho mejor.

Bug Magnet - Pequeña herramienta para facilitar la vida

Me encanta cuando los testers que se dan mañana para programar, hacen pequeñas joyas como esta. Hoy les presento Bug Magnet, un add-on originalmente para Chrome, creado por Gojko Adzic que facilita la vida haciendo un checklist con diferentes tipos de inputs a tan solo un  click derecho de distancia.

Podemos usar Lorems, diferentes tamaños de textos, tipos de nombres, emails validos/inválidos, números, espacios en blanco, SQL injection y un largo etcétera. Muy útil para no olvidarse ningún tipo de combinación rara.

Muy fácil de usar, me encanta cuando las ideas simples se vuelven herramientas imprescindibles.

Les dejo acá bajo donde bajarlo, espero que les sea útil

Chrome: http://gojko.github.io/bugmagnet/

Firefox:  https://addons.mozilla.org/en-us/firefox/addon/bugmagnet-firefox/?src=search

Como trabajar en el interior del país y no morir en el intento

Este post está dirigido a los "porteños", los cuales nos referimos al resto del país como "El Interior", y especialmente a los que sueñan con irse de la gran ciudad y vivir mas tranquilos en alguna provincia.
Por razones personales, debo volver a Buenos Aires, es por eso que antes quiero contar mi experiencia en Mendoza y mi búsqueda previa y primeros tiempos aquí.

la dura vida en el interior...

Todos vemos normalmente en las películas y series estadounidenses, que los protagonistas se van de una ciudad a otra, ya sea por trabajo o por estudio, pero generalmente cuando es por trabajo, lo hacen ya con el trabajo conseguido desde su lugar de origen. Tal vez no sea algo tan común o fácil de hacer, pero es mas normal que en Argentina.
En nuestro país, generalmente la gente "del interior" viene a la Mega ciudad de AMBA (Area Metroplitana de Buenos Aires...o sea Capital y Gran BsAs) a vivir y tratar de conseguir trabajo, muy pocos llegan ya con un trabajo. Lo mismo sucede con los locos que nos vamos a otra provincia, la mayoría primero llega y luego consigue el trabajo. Es muy dificil conseguir el trabajo estando lejos, la mayoría de las empresas tiene procesos arcaicos en donde en un punto u otro te quieren ver en vivo y en directo. Hoy por hoy hay 2 rubros en donde se puede conseguir trabajo antes de llegar: Turismo (mayormente trabajos temporales) o en Informática, como es mi caso.

Camino al trabajo

En 2011, cuando estaban terminando mi carrera, empecé mi búsqueda de oportunidades en las provincias Argentinas. Lamentablemente, como en casi todos los rubros, la mayoría de las empresa tecnológicas se encuentran en el AMBA y en menor medida en las grandes ciudades (Córdoba, Rosario, Mar del Plata, Tucuman y Mendoza), en los polos tecnológicos (San Luis, Paraná, Tandil, Posadas, entre otros) o en el único lugar en donde se hace tecnología de punta: Bariloche (Centrales Nucleares y Satélites tambien necesitan ingenieros en sistemas).

La mejor forma de empezar es tratando de saber primero a donde queremos ir a vivir (y tener más de una opción por las dudas) y luego armar una lista con todas las empresas que están en esa zona. A veces es dificil ir hasta el lugar y conocerlo en persona, aunque es lo ideal, hay que aprovechar unas vacaciones para ir y conocer.
Hoy en día ayuda mucho Linkedin y Google, buscando palabras claves como "relocalización", "relocarse","trasladarse", etc.
Luego hay que empezar a hacer networking en Linkedin con los de RRHH y empleados de las empresas de la zona que nos interesa. Los reclutadores por razones obvias, y los empleados por que a veces te pueden dar información a cerca de la empresa que trabajan ( es solo cuestión de pedirlo amablemente)
Una vez que tenemos la ciudad donde queremos vivir, las empresas disponibles, y los contactos, hay que empezar la búsqueda. Muchas veces las empresas no publican en los medios tradicionales que usamos, como los portales de trabajo o Linkedin mismo, por eso hay que mandarles nuestro curriculum igual, uno nunca sabe.

El asadito se hace con Leña!

Lo ideal es empezar por las empresas que hacen búsquedas activas y una vez que entremos en contacto ir tanteando cuales están dispuestas a contratar gente "de afuera". La mayoría quieren al candidato en el mismo lugar para poder entrevistarlo, hay que tratar que te acepten tener una primera entrevista via skype o similar. Luego hay que tratar de reducir el grupo de empresas a aquellas que esten dispuestas a ofrecer un plus por trasladarnos hasta allí a trabajar y vivir y negociar.
En mi caso particular tuve una sola propuesta en donde me ofrecían el alquiler temporal de un departamento y un plus por mudarme y fue en Belatrix, una de las principales empresas de servicios nearshore de latinoamerica. Todo el proceso lo hicimos via skype y me facilitaron todo lo necesario para ayudarme en la transición a mi nuevo trabajo y ciudad. Belatrix tiene oficinas en Chacras de Coria, con unos hermosos jardines y otras en plena Ciudad de Mendoza, mas parecidas a cualquiera de las que se pueden encontrar en BsAs.
Finalmente, una vez que conseguimos el trabajo, lo que hay que hacer es sacarse el miedo al cambio.
Tenes hijos? te lo van a agradecer, van a vivir mas tranquilos, conseguiles una casa con jardín (generalmente cuestan menos alquilar que en AMBA). Estas casado? habla mucho con tu pareja antes de empezar la búsqueda, pero mucho, y si pueden ir juntos a conocer la ciudad en donde quieren vivir, mejor. Vas a extrañar a tu familia? cuantas veces la ves al año? skype y 1 o 2 horas de avión hacen que las distancias sean cortas. Yo he visto a mi familia al menos una semana al año en estos 3 años.
Es fácil cambiar? y no, no lo es, pero si no probas nunca vas a saber que vale la pena. Hay que dejar de tenerle miedo al "interior" y ver las oportunidades que hay mas allá del Gran Buenos Aires.
Cada día hay más empresas dispuestas a contratar gente de Buenos Aires, por que, como en todos lados, la gente de sistemas escasea. Es cuestión de buscar y ser valiente.
Ojalá mi estadía en Buenos Aires sea lo mas corta posible y pueda volver a ver estos jardines.

Vista desde mi escritorio en Chacras de Coria

Nota aclaratoria: Aunque trabajo para Belatrix, este post lo hago por que quiero. No ha sido solicitado por nadie de la empresa y es mi opinión personal.

Disipando Conceptos Erróneos - "Vamos a automatizar todo y deshacernos de todos nuestros Testers"

Hoy les traigo un post de Dan Ashby, un Analista de Testing de Londres.
Este es el 5to post de una serie, y como se trata de automatización y me estoy metiendo de lleno en estos temas, me pareció muy interesante traducirlo. Espero que les guste.

Oigo esto todo el tiempo. Incluso de gente de muy alto rango. El último de ellos fue de un gerente de desarrollo, preguntando por qué estamos "todavía necesitando tener testers probando el software, si estamos apuntando a  automatizar el 100% de todo"...

En primer lugar, la verdad es muy simple: sólo se puede automatizar lo que sabe y esperas.

Cuando pensamos acerca de los "órdenes de ignorancia", entonces se hace más claro de por qué no es posible automatizar todo. Para aquellos que no están familiarizados con las órdenes de la ignorancia, permítanme explicarlos...

Hay 5 órdenes de ignorancia:

• El orden 0 de la ignorancia es la falta de ignorancia. Esto es esencialmente conocimiento. El conocimiento que se puede demostrar en una forma tangible. Por ejemplo, yo estoy bien informado sobre el hecho de que es imposible automatizar todo.

• El primer orden de la ignorancia es la falta de conocimiento. Esto es cuando no sabes algo y sabes que no sabes eso. Un ejemplo de esto sería que no sé cómo utilizar la herramienta  OWASP Zed Attack Proxy tool, en todo su potencial. Soy consciente de que yo no sé mucho acerca de esta herramienta específica y puedo elegir entre aprender o continuar el uso de diferentes herramientas como Fiddler o Burp Suite.

• El segundo orden de la ignorancia es la falta de conciencia. Esto es cuando no sabes que no sabes algo. Así que aquí es donde yo no soy más que un ignorante sobre algo, pero yo soy ignorante al hecho de que soy ignorante respecto a eso. Obviamente no se puede dar un buen ejemplo de esto, ya que eres ignorante de ello. :)

• El tercer orden de la ignorancia es la falta de proceso del descubrimiento. Así que aquí es donde no estás enterado de ninguna forma de obtener el conocimiento que no sabes que no sabes algo. Esto significa que no se puede aprender sobre las cosas que no sabes, por que no sabes (es decir no puedes tomar conciencia de las cosas que son del segundo orden ignorancia para convertirlas en cosas del primer para la ignorancia).

• El cuarto orden de la ignorancia es un poco descarado. Se trata básicamente de no estar al tanto de los 5 órdenes de la ignorancia. :)

Entonces, al relacionarse esto a la automatización... Puedes sólo automatizar realmente las cosas que están dentro de el orden 0 de ignorancia, donde se tiene el conocimiento y la expectativa de cómo debe funcionar la funcionalidad, por lo tanto, escribes una afirmación que comprueba la salida y devuelve un "pass" o "fail", en cuanto a si la salida cumple esa expectativa inicial.

Por otro lado, cualquier cosa que se ajuste dentro del resto de los órdenes de la ignorancia (en concreto el primer y segundo orden de la ignorancia), será imposible de automatizar, ya que no tienes conocimientos previos sobre cómo funcionará la funcionalidad o función. No tienes una expectativa o no eres consciente de ciertos escenarios o variables que rodean la funcionalidad con el fin de ser capaz de formar una expectativa que sea capaz de afirmar ese chequeo.

El Pensamiento Lateral y Testing Exploratorio ayudan en la transformación de los "desconocidos" en "conocidos", también ayudan en la transformación de los "desconocidos-desconocidos" en "incógnitas conocidas". Si bien no es posible hacerlo únicamente manteniendo conversaciones previas, las conversaciones ayudan. La mejor manera de aprender adecuadamente acerca de cómo funciona realmente un sistema, es de aprender del sistema a medida que investigamos. Por lo tanto estamos aprendiendo continuamente, diseñando nuestras pruebas (pensando nuevas preguntas para hacer al software) y haciendo nuestras pruebas a medida que aprendemos más.

Un segundo punto que me gustaría resaltar es que, incluso para las cosas de orden 0 (las cosas que usted sabe, ni pensar en las cosas que usted no sabe en este momento), es:  va a ser realmente de valor en la lucha para automatizar todo en lo que usted tiene una expectativa? Por ejemplo, ¿vale la pena la automatización de un escenario que sólo tenemos que ejecutar una vez?

Al pensar en lo que hay que automatizar, tenemos que pensar en VALOR... Yo soy un gran defensor de la automatización. Es muy valiosa en los entornos ágiles de hoy, con todo moviéndose mucho más rápido y fluido, con más agilidad. Nos da repetibilidad y feedback extremadamente rápido para nuestras tareas de comprobación, tales como pruebas de regresión o sanity/smoke testing. También es muy útil para ayudar a tus actividades de ensayo pensantes, usarlo para cosas como la creación de datos o la realización de acciones para llegar a lo profundo del flujo de trabajo a la parte del sistema que necesitas para poner a prueba... 

Sin embargo, tenemos que ser conscientes para qué la automatización es útil, y cuáles son las limitaciones, para que no caigamos en este concepto erróneo y cometer algunos errores graves.

Por lo tanto, la próxima vez que escuche a alguien decir "Vamos a automatizar todo", habla con ellos acerca de por qué eso en realidad no es posible y ayuda a hacer del mundo un mejor lugar :)

Dan Ashby

Testing es...

Ayer por la noche (de Argentina), Michael Bolton escribió una serie de tuits sobre qué es el Testing, en una especie de Manifiesto.
Hice un Storify para que los puedan leer, vale la pena aunque estén en inglés.

Por qué no sirve la ISO 29119 para el Software Testing - Parte 2

Continuando con la traducción del articulo de Michael Bolton. Pueden ver la primera parte aquí.
Nuevamente pido disculpas por anticipado por la traducción, no soy un profesional :P.

P: La norma ha estado en desarrollo durante los últimos siete años; ¿por qué has esperado tanto tiempo?

Algunos de nosotros no hemos estado esperando. Por ejemplo, he dado esta presentación en 2011. Algunos de nosotros hemos estado ocupados oponiéndose a los sistemas de certificación (Sólo ahi hay tanto buscador de rentas que uno puede oponer a la vez) Varios de nosotros hemos discutido largamente y en público con algunas de las figuras más prominentes que promueven la norma en las conferencias. A veces parecen no entender nuestras objeciones. Sin embargo, como dijo Upton Sinclair: "Es difícil conseguir que un hombre comprenda algo cuando su salario depende de que no lo entienda!"Ya sea a través de terribles argumentaciones o engaño deliberado, las respuestas en esas discusiones normalmente tenían la forma de no-sequiturs: "El estándar es opcional; algo es mejor que nada; muchas personas estuvieron involucradas; lo perfecto es enemigo de lo bueno; estamos tratando de ayudar a todas aquellas pobres personas que no saben qué hacer ". Los promotores de los estándares deberían (y probablemente lo hacen) saber que esas declaraciones se aplicarían a cualquier modelo de proceso que cualquier persona o grupo podría ofrecer. La construcción de la autoridad falsa en la ISO, y luego apelar a la autoridad, se ve muy parecido a la búsqueda de rentas para mí.
Por otra parte, la deformación de creer que la norma ha sido objeto de desarrollo serio cuando algunos de los modelos básicos (por ejemplo, el modelo de la 29119 para el proceso de planificación de las pruebas) ha pasado esencialmente sin cambios durante cuatro años, un período que incluyó el auge de los smartphones y la tecnología móvil, las secuelas de la crisis financiera, y el surgimiento de la Tablet PC. Agile Testing, según se informa, granjea poco más que unas pocas referencias.
No puedo decir que estoy sorprendido de que el testing y checking no aparecen tampoco en el radar de la 29119.

P: Por qué no se opone mediante el proceso formal establecido por la ISO?

Como James Bach señala, la verdadera pregunta aquí es: ¿por qué el oficio tiene que defenderse de un proceso de estandarización que se creó para favorecer a determinados grupos bien financiados?
ISO es una organización comercial; no es un órgano de las Naciones Unidas, que emana de los gobiernos representativos electos; no es una institución académica; no es un grupo representativo de los profesionales; no esta ordenado por ninguna deidad. La responsabilidad recae sobre ISO para mostrar la relevancia del estándar, incluso en sus propios términos. Simon Morley deconstruye eso.

P: No sería bueno tener un lenguaje común internacional para las pruebas de software?

Gran idea! De hecho, sería bueno tener un lenguaje común internacional para todo. Y con el fin de ser verdaderamente internacional y representar a la mayoría de la gente en el mundo, vamos a hacer que ese idioma sea el mandarín, o el hindi.
Hay muchos argumentos para demostrar que un lenguaje común para las pruebas de software no es ni deseable ni posible. He escrito en mi blog acerca de algunos de ellos, y lo he hecho más de una vez.

P: Por qué estás siempre en contra de las cosas? ¿No quieres estar a favor de algo?

Uno no tiene que estar a favor de algo para estar en contra de algo que es odioso. Pero como cuestión de hecho, yo estoy a favor de algo que es más importante que cualquier estándar: la libertad y la responsabilidad de la calidad de mi trabajo (como espero que todos los testers estén a favor de la libertad y la responsabilidad por la calidad de su propio trabajo).
Esto incluye la responsabilidad de hacer mi trabajo capaz, creíble, abierto al escrutinio, y tan rentable como sea posible. Debo ser responsable ante mis clientes, a mi oficio, y para la sociedad en su conjunto. En mi opinión, estas responsabilidades no lo hacen y no deben incluir, el cumplimiento de unas normas preestablecidas, poco representativas, innecesarias, que consumen tiempo y creadas por documentación auto-proclamada y entusiastas de los proceso-modelo.
Algunas cosas por las que estoy a favor: las premisas del Rapid Software Testing y su framework; el estudio de las estructuras del Testing Exploratorio; el modelo de estrategia de testing basado en la heurística; un conjunto de compromisos para que los testers le hagan a sus clientes; la práctica de la habilidad  en el marco del testing; la excelencia en la presentación de informes; y una serie de otras cosas. Esto no es representativo de la amplia comunidad del Testing... así que apuesto a que te alegras de que el cumplimiento de los estándares establecidos por James y yo es voluntaria. De hecho, el cumplimiento de nuestros estándares requiere que invente las pruebas por sí mismo; a adoptar las normas que ayudan; y resistir a las que no lo hacen, incluido la nuestra. Pero si usted encuentra algo que funcione para usted, dígalo. Dígale a todo el mundo.

P: Qué pasa con las pobres personas que necesitan orientación sobre cómo testear?

Mis ofrendas (gratis)  a esa pobre gente incluyen lo mencionado arriba. Esa pobre gente puede hacer uso de estas sugerencias e investigar las alternativas que alguien más pueda ofrecerle. Eso puede ser más difícil que hacer referencia a un estándar ISO y apelando a su autoridad (Puede ser considerablemente más fácil, también) Pero mi primera pieza de orientación sobre la forma de testear es esta: aprenda acerca de las pruebas, y aprenda cómo testear, a través del estudio y la práctica. Yo sostengo que la ISO 29119 no le ayudará con eso.

Si te convenció Michael Bolton, puedes firmar la petición en contra de la ISO 29119 aquí

Por qué no sirve la ISO 29119 para el Software Testing - Parte 1

En las ultimas semanas ha ido creciendo la voz en contra de la ISO 29119, un standard de la ISO para el software testing que no va ayudar en nada.
Muchos autores han hablado al respecto y pueden encontrar todos los links al respecto en la página de la International Society for Software Testing (ISST)
Tambien pueden firmar la petición en contra de la ISO 29119 aquí (no se si sirve de mucho pero yo ya la firmé)
Pero que es la ISO 29119 exactamente? Por que están en contra? Bueno , el tema es largo y complejo, por eso prefiero traducir este FAQ realizado por Michael Bolton en su blog.
Espero que les sea útil. Si ven algún error de traducción, sepan disculpar. Lo dividí en 2 partes porque es muy largo.

Preguntas Más Frecuentes Acerca de la Controversia sobre la 29119:

Este es un primer intento de una lista de preguntas más frecuentes sobre el movimiento para detener la ISO 29119. Aquí hablo por mí mismo, y no para la comunidad. Si usted ve un "nosotros", se refiere a mi percepción de la comunidad en general, pero no necesariamente a toda la comunidad; el tamaño puede variar. Hay un montón de discusiones en la comunidad; Huib Schoots está curando una colección de recursos sobre la controversia. Si tienes una percepción diferente o una opinión diferente, por favor compártela y hágamelo saber. Mientras tanto, me apresuro a señalar que absolutamente todos son bienvenidos y alentados a compartir mis opiniones.

P: ¿Por qué molestarse con un ataque de la comunidad a la norma ISO 29119? No es relevante para la mayoría de los probadores? ¿Y por qué ahora?

Para empezar, creemos que la ISO 29119 no es pertinente a todos los Testers, en el sentido de que parece ser un sobre estructurado modelo de procesos, centrado en una implacable y pesada burocracia derrochadora y de papeleo, con un contenido insignificante sobre las pruebas reales. Si su organización está en el negocio de producir documentación inútil, que así sea, pero eso no es lo que llamamos Testing. Los enfoques sugeridos por 29119 podrían ser útiles para las personas que están más interesados en cuidarse el culo que en la cobertura de pruebas.

Los originadores y los partidarios de la petición están tratando de establecer un patrón de oposición a la norma. Esto es importante cuando los abogados o auditores preguntan "¿Por qué no sigues 'un conjunto internacionalmente acordado de normas para las pruebas de software que se pueden utilizar dentro de cualquier ciclo de vida de desarrollo de software u organización'?"
Grandes voces de la oposición -no sólo a la norma, sino también al proceso por el cual fue creada y por el cual se comercializará- ayudarán a demostrar que la sugerencia de "acuerdo internacional" no tiene sentido; que la norma tergiversa las pruebas como muchos testers prominentes lo ven; que la norma es excesivamente compleja y opaca; que es a la vez demasiado vaga aquí y demasiado específica allí para ser útil en "cualquier" organización; y que los contextos radicalmente diferentes para el testing -muy apropiadamente- requieren enfoques radicalmente diferentes para testear.

En cuanto a la pregunta "¿por qué ahora", hay otra razón por esta oleada que, creo, que estamos descubriendo a medida que avanzamos: en los últimos años, a trancas y barrancas, la comunidad de Testing guiado por el Contexto (NdT: Context-Driven testing, no tengo una buena traducción para esto, je.) se ha convertido en mucho más grande y más capaz de actuar como una comunidad. Y eso a pesar del hecho de que las personas que aspiran a ser  pensadores ferozmente independientes, pueden ser un grupo bastante rebelde.  Una comunidad que acoge serios desacuerdos tendrá serios desacuerdos, y ha habido algunos. Sin embargo, parece que, de vez en cuando, hay algunas cosas que son lo bastante odiosa para unirnos. Personalmente, estoy tratando esto como una prueba y una experiencia de aprendizaje para prepararnos para algo en serio importante.

P: Los promotores de la norma insisten en que no es obligatoria, así que ¿cuál es el alboroto?

The promoters of the standard who say that the standard is not mandatory are being disingenuous. They are well aware of this idea:
"Otro esquema de clasificación distingue entre los estandares voluntarios, que por sí mismos no implican obligaciones relacionadas con su utilización, y los estándares obligatorios. Una estandar obligatorio se publica generalmente como parte de un código, norma o reglamento por un organismo gubernamental regulador y establece la obligación de las partes especificadas a ajustarse a la misma. Sin embargo, la distinción entre estas dos categorías se puede perder cuando los estándares de consenso voluntario se referencian en las regulaciones gubernamentales, haciendolos efectivamente en estándares obligatorios ". (fuente)
Los promotores de la 29119 comienzan usando la apelación a la autoridad (en este caso, la reputación de la ISO) para declarar una estandar. Si se da la circunstancia de que un regulador o burócrata, mal informado acerca del Testing, pasa sobre "un conjunto internacionalmente acordado de normas para las pruebas de software que se pueden utilizar dentro de cualquier ciclo de vida de desarrollo de software u organización" y se refiere a ellos en las regulaciones del gobierno, bueno, entonces, tanto mejor para los aspirantes a buscadores de ganancias que podrían haber estado involucrados en la redacción de la norma.

P: Si la ISO 29119 es tan terrible, no va a desaparecer por su propio peso?

Sí, probablemente lo hará en la mayoría de los lugares. Pero durante un tiempo, algunas organizaciones (incluidas las públicas; tus  impuestos en acción, recuerda) _ coquetearán con ella a un gran costo-incluyendo los costos fácilmente previsibles de inncesario cumplimiento , desplazamiento de objetivos, la tergiversación de las pruebas, y otra ronda de comercialización de certificaciones falsas, por lo que los buscadores de rentas consiguen una oportunidad para recoger de los bolsillos de los ingenuos y los cínicos.

P: ¿No está sólo quejándose porque usted está preocupado de que su enfoque no-estándar del Testing le pondrá fuera del negocio?

Así es como yo respondí esta pregunta en un blog (con un par de ediciones menores por los errores tipográficos y claridad):
"En un sentido, no hará ninguna diferencia para mi negocio si 29119-1, 29119-2 y 29119-3 se quedan, y si 29119-4 y 29119-5 pasan de borrador a aceptarse. Rapid Software Testing es acerca de las habilidades reales de testing (exploración, experimentación, pensamiento crítico, pensamiento científico, de información articulado, y así sucesivamente). Eso no compite con la 29119, en la misma  manera que un restaurante de pescado no compite con las compañías que hacen que las conservas de atún. Nos oponemos a las personas que manipulan el mercado, y el proceso de desarrollo de las normas ISO de sugerir a todo el mundo que el atún enlatado es el único alimento apto para comer para la gente. Discuto eso aquí.
"En otro sentido, la 29119 podría ser fantástica para mi negocio. Me ofrecería una manera de extender la marca: cómo hacer testing excelente y rentable que resista al escrutinio en contextos en los que algún burócrata, muy lejos fuera del proyecto de desarrollo, se dejó engañar en la creencia de que la 29119 era importante. Por el momento, estoy feliz de referir ese tipo de negocio a colegas míos, pero sospecho que sería algo así como una mina de oro para mí. Sin embargo, todavía me opongo a la 29119, porque lo que está en mi interés puede no estar en los intereses de mis clientes y de la sociedad en general.
"Permítanme ser específico: Hay normas existentes para dispositivos médicos, para la aviónica, y similares. Estas normas son importantes, y muchos de ellos son concisos y están bien escritos, y fueron creados por una verdadera colaboración entre las partes interesadas. Testers que están trabajando en dispositivos médicos o en el software de aviación tienen un número limitado de minutos en la jornada de trabajo. Como alguien que vuela mucho, y como alguien que es probable que requiera la ayuda de dispositivos médicos en un futuro próximo, yo preferiría que los testers pasen tantos minutos como sea humanamente posible realmente investigando el software, en lugar de cumplir (auténticamente, patéticamente , o maliciosamente) una norma innecesaria para el modelado de procesos, documentación, y la estrategia (un estándar para el desarrollo de una estrategia, imagine eso!) ".

P: A usted simplemente no le gusta las normas. ¿No es verdad?

Pues no. Me encantan las normas cuando se usan apropiadamente.
Como he subrayado en una presentación de PNSQC en 2011, denominada "Estándares y desviaciones", es posible y a menudo deseable para describir y normalizar los widgets (cosas tangibles y físicas que tienen atributos cuantitativamente medibles), y que deben interactuar, relacionarse, o encajar con otras cosas. Gracias a Dios por tornillos estandarizados y los destornilladores, CDs y discos duros SATA! Bravo a la UE por ordenar que las fuentes de alimentación para Smartphones se estandarice a USB! Sin embargo, incluso con los widgets, hay cuestiones relacionadas con la tensión entre los estándares y un estado de avance de la técnica. Aquí está uno de los mejores artículos de la historia sobre problemas con los estándares.
Es más difícil describir los procesos, ya que la descripción es, por necesidad, un modelo del proceso. Es difícil para muchas personas evitar cosificar el modelo, es decir, evitar tratar al modelo, la idea, como si fuera una cosa. Para un ejemplo de sobrecosificación del Testing, tómese un momento para reflexionar sobre la noción de lo que representa el trabajo de pruebas en términos de casos de prueba; lea luego "Los Casos de prueba no son Testing: Hacia una Cultura de Test Performance" por James Bach & Aaron Hodder.
Más en general, el enfoque de la 29119 en los artefactos y el modelo de proceso
desplaza y descentra de la parte más importante de cualquier esfuerzo de pruebas: el conjunto de habilidades y la mentalidad del tester individual.

P: De verdad creen que la norma ISO 29119 puede ser detenida?

No, claro que no lo creemos. Curtis Stuehrenberg lo pone perfectamente en una discusión en LinkedIn: "La petición no se trata de detener la publicación más de lo que una marcha contra la guerra es acerca de una expectativa razonable de poner fin a una guerra a través de un desfile. El punto de la petición y la charla general es para asegurarse de que al menos algunas personas escuchan que hay una parte importante de la comunidad del Testing que no estuvo representada y que defienden diferentes puntos de vista y prácticas para las pruebas de software como una disciplina profesional ". Si no podemos conseguir detener el estándar por los mecanismos de la ISO, por lo menos podemos demostrar que hay una ausencia de consenso fuera de los grupos de trabajo de la 29119.

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 :)