El año pasado cuando estuve en expoQA tuve la oportunidad de escuchar a “Jan Fish”, una mujer americana con aspecto extravagante con más de 34 años de experiencia en el testing y actualmente gerente de pruebas y mejora de procesos en Philips Lifeline. Casi nada!!!!…pues bien, esta mujer hizo una de las presentaciones más interesantes que he visto sobre testing, sobre todo por la forma de expresarse y la pasión que ponía. De aquella presentación no olvidaré un comentario: “la calidad está dentro de cada uno de vosotros” y comentaba a manera de broma: “estoy segura que todo el mundo cuando se levanta por las mañanas se levanta pensado, hoy voy hacer un buen trabajo”, parece obvio, pero añadía: “no creo que nadie se levante por la mañanas pensando…voy a ir a trabajar y voy hacer un trabajo de mierda“. Y es verdad, tiene toda la razón, todo el mundo (o casi todo el mundo) por defecto tiene la intención de mejorar y hacer un buen trabajo, un trabajo con calidad. Esa forma de pensar es lo que hace grande a una organización, gente que busque la calidad en su trabajo y la excelencia. Read more

El “defect clustering” no es un concepto nuevo en la ingeniería de software y el testing. Todo tester conoce esta teoría que se resumen en una frase: “si encuentras un defecto crítico sigue buscando, es muy probable que haya muchos más”. Y básicamente en esto se basa esta teoría, ya que los defectos de software son como las cucarachas, si encuentras una cucaracha en tu cocina estate seguro que no está sola, aparecerán muchas más. Esto es lo que nos dice el Defect Clustering, encuentra un defecto importante y sigue buscando, sigue tirando del hilo…porque donde hay un defecto gordo habrá muchos defectos más. Analiza el defecto y busca patrones similares…esto te llevará a nuevos defectos. Exactamente lo mismo ocurre con las cucarachas.

Hay muchas hipótesis sobre este tema. Investigando he encontrado datos que sostienen que los defectos están normalmente localizados en un mismo área, incluso indicando que el 80% de los defectos se encontrado en un 20% del todo el código. Formando lo que llaman los expertos “cluster of defects”. Read more

Philip Crosby es uno de los más destacados gurús de la calidad que ha tenido Estados Unidos. Su nombre es bien conocido por la introducción en las empresa de los conceptos “Do it Right First Time” y “Zero Defects”. Philip Crosby ha publicado más de diez libros en su carrera, el primero (best seller) fue “Quality is Free” o “La Calidad No Cuesta”, y luego destacaron “The absolutes of Leadership” o “Los Absolutos de la Calidad”. Crosby define la calidad como “la conformidad con los requisitos que la propia compañía ha establecido para sus productos basados directamente en las necesidades de sus clientes“. Él creía que dado que la mayoría de las empresas cuentan con sistemas que permiten calcular la desviación de lo que realmente se necesita, las empresas manufacturadoras gastan alrededor del 20% de sus ingresos haciendo las cosas mal y haciéndolas de nuevo. De acuerdo con Crosby esto puede ser un 35% de los gastos de funcionamiento del servicio. Para él cero defectos significaba hacer las cosas bien la primera vez, para ello animaba a todos los trabajadores a realizar mejoras continuas de su trabajo. El objetivo final era entrenar a los trabajadores y dales las herramientas necesarias para realizar las tareas y mejorar así la calidad. La creencia de Crosby era que si una compañía establecía un programa de gestión de la calidad tendría más ahorros que lo que pagaría por los costos de dicho programa (“quality is free”). Read more

No es la primera vez que tengo conversaciones con compañero del mundo del testing en la que una definión significa una cosa para unos y otra diferente para otros. Si esto ocurre entre personas con años de experiencia en testing ¿Qué ocurre cuando un tester habla con un desarrollador? Buffff, la situación se complica todavía más. Podríamos pensar que todos somos ingenieros de Software y que hablamos el mismo lenguage, pero la realidad es que con el tiempo está habiendo una diferencia cada vez mayor entre unos y otros.

Hay muchos ejemplos de fases de testing, técnicas y conceptos que son bien conocidos entre testers y que son completamente desconocidos por los desarrolladores. Conceptos básicos como “smoke test” o “sanity test” no suelen ser comprendidos en primer terminos por los desarrolladores, hasta que les explicas de que estás hablando y recibes un “aaah, te refieres a eso!!!!”.

Una técnica que muchas veces suele sonar extraña es el “exploratory testing”. La idea del exploratory testing (a grandes rasgos) es que un usuario realice pruebas aleatorias de forma inesperada (sin seguir unos test cases previamente diseñados) basándose en su experiencia en la aplicación. Pues bien, es probable que si habláis del exploratory testing con un desarrollador se os quedará mirando con una cara como “de que demonios me estás hablando”.

En resumen ¿hablamos un lenguaje diferente? Para mi la respuesta es sencilla, si, hablamos un lenguaje diferente. El mundo del testing ha evolucionado, evoluciona y evolucionará cada vez. Saldrán nuevas técnicas y nuevo conceptos que tendremos que aprender tanto nosotros como los desarrolladores. Creo que esa es también la gracia del testing, que no es sólo testear y encontrar defectos…que hay todo un mundo de técnicas, conceptos, frameworks, certificaciones, buenas prácticas…así como miles de libros que hablan del tema…pero al final, el concepto es el concepto!!!!!

Leyendo un articulillo sobre los roles y las responsabilidades de un BA (Business Analyst), apareció la pregunta: “What’s the best tool for modelling?”. Herramientas en el mercado hay muchas, pero transladando esta cuestión al mercado español ¿entienden las empresas españolas de la importancia del modelado? son pocas las empresas que conozco que realmente hagan un modelado antes de empezar sus desarrollos. Me imagino que mucha gente estará en desacuerdo en esta afirmación, pero creo que esto se debe a la falta de madurez de las empresas de desarrollo de software. Lo primero que deberíamos preguntarnos ¿porqué necesitamos modelar? Read more

Ayer estuve en los “FiascoAwards 2010“, un evento que quiere premiar cada año a proyectos, ideas, productos o servicios que hayan acabado en fracaso…en este caso, en fiasco. Este año el premio se lo ha llevado el “ipad”, producto que aún no ha salido al mercado en muchos países. Pero bueno, dejando al margen este pequeño detalle existen miles de webs y libros que hablan de porque fracasan los proyectos: mala planificación, cambio de objetivos en medio del proyecto, mal gestón, selección incorrecta del equipo de trabajo…y mil historias más. Lo que no es frecuente ver son empresas que achaquen el fiasco de un proyecto por una mala gestión de la calidad.

Creo que es insdiscutible que la mala calidad del software es una de las principales causas de fiasco en proyectos de software. Me gustaría saber si conocéis de proyectos en los que hayáis participado o que conozcáis que hayan acabado en Fiasco por baja calidad.

Link: http://www.fiascoawards.com

Es curioso ver la ofertas de empleo que van apareción en la red. Está claro que en estos momento de crisis se encuentran muchas menos ofertas, y se empieza a ver más empresas que contratan a menos gente para hacerlo todo. Cuando el mercado goza de buena salud se contratan Test engineers para hacer automatización, expertos en rendimiento, seguridad, etc. Hoy en día, las descripciones de trabajos en el mundo de la calidad son muy extensas y buscan un persona que haga todo. Se quiere contratar a una persona que tenga una lista interminable de aptitudes.

¿Que conlleva todo esto? Más presión sobre los testers, lo que puede conducir a más errores, es decir…a no encontrar errores importantes. La mayoría de las veces la gente no piensa en las pruebas de software hasta que le enseñan la aplicación al cliente y encuentra errores importantes. La economía puede estar pasando momentos dificiles, pero las pruebas de software son siempre necesarias.

Todo proyecto maneja tres parámetros, basándonos en el PMI (Project Management Institute): alcance, tiempo, y presupuesto. Pero, ¿Que pasa con la calidad? claro, el PMI no entra en estos temas. Podemos reducir el tiempo…podemos reducir el alcance, pero nunca deberíamos reducir la calidad de nuestro producto.

Aunque no es una noticia reciente, creo que es interesante compartir este tipo de iniciativas, sobre todo si son constructivas. Google, una empresa mundialmente conocida por muchas de sus iniciativas o excentricidades, introduce “testing in the toilet”. Algo realmente curioso y asombroso que sólo google es capaz de proponer. “Testing in the toilet” trata de inspirar a sus trabajadores, no sólo con la lectura de libros, asistiendo a conferencias, o escribiendo artículos en revistas…google va un poco más allá y pone consejos, buenas práctica, metodologías, noticias, bromas…en un sitio que, cuando lo ves, no puedes ignorarlo…el baño.

Parece ser que a ellos le ha funcionado, así que han querido compartir con el mundo su arma secreta que os ayudará a difundir vuestra pasión por el test y la calidad, y ofrecer una manera divertida y fácil para educarte a ti mismo y al resto de su empresa acerca de estos trucos y técnicas.

¿Como podríais hacerlo? poner todas vuestras propuestas de mejora en el cuarto de baño, pasillos, cocina, o incluso en el ascensor. Y si queréis, podéis enviar el feedback a google explicándoles como ha ido la propuesta en vuestra empresa.