Softqanetwork.com » Artículos de Opinión

La calidad es asunto de todos

Javierpello — Fri, 30 Jul 2010 05:27:35 +0000

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.

Por tanto es muy importante que en las empresas divulguen la importancia de la calidad en la forma de trabajar de sus empleados. La calidad no es solo cosa de una o varias personas, sino de cada uno de los miembros de la organización. Es por ello que muchas empresas implanta por ejemplo la ISO9000, donde desarrollan un “Manual de calidad” que debe ser leído y conocido por toda los trabajadores de la empresa. Quedaros con la frase, “la calidad está dentro de cada uno de vosotros”.

Teoría del “Defect Clustering” y las cucarachas

Javierpello — Fri, 09 Jul 2010 10:56:06 +0000

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”.

Por otro lado es importante mencionar otra similitud que tiene los defectos en cluster con las cucarachas, su resistencia a los pesticidas. Mucha gente habla de la “paradoja de los pesticidas”, la cual dice que las cucarachas se pueden hacer inmunes a los insecticidas si siempre usamos la misma marca. Esta teoría aplicada al desarrollo de software y al testing nos quiere decir que como tester o expertos en calidad debemos de estar continuamente actualizando y mejorando nuestros test cases, creando nuevos casos de pruebas. El uso continuo del mismo conjunto de pruebas nos llevará a un punto en el cual no entraremos más defecto, porque nuestros test se focalizan siempre en las mismas areas. Se creativo y no dejes que las plagas de cucarachas se extiendan en su software.

Philip Crosby y la calidad del Software.

Javierpello — Sat, 03 Jul 2010 14:33:52 +0000

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”).

Crosby afirma que la calidad está basada en 4 principios absolutos:
• Calidad es cumplir con los requisitos.
• El sistema de calidad es la prevención.
• El estándar de realización es cero defectos.
• La medida de la calidad es el precio del incumplimiento.

Creo que los pilares de la calidad establecidos por Gurus como Crosby, Deming o Juran, hacia finales de los 1970s y entrados los 1980s, siguen siendo los mismos que usamos hoy en día. Sin ir más lejos el CMM (Capability Maturity Model) desarrollado por el “Software Engineering Intitute” de la Universidad de Carnegie-Mellon, se basó en el modelo de madurez de Phillip Crosby . Es cierto que no podemos comparar un producto manufacturado con un producto Software, son productos con características distintas (objeto material versus inmaterial, objeto que se desgasta con el uso versus mantenimiento…), pero ambos deben de ser entregados con la calidad que espera el cliente. Al mundo de la ingeniería de software todavía le queda mucho camino por recorrer, y poco a poco las empresas se van concienciando más de la necesidad de establecer medidas de calidad en sus desarrollos de Software.

Como dijo Crosby en su día, las empresas deben crear mecanismos de mejora continua. Mecanismos que identifiquen y cubran las expectativas del cliente. Es decir, primero tenemos que conocer bien el sector en que trabajamos y establecer medidas en función del producto que desarrollamos. No es lo mismo el desarrollo de software crítico que el desarrollo de una aplicación de gestión de contenidos. Ambas aplicaciones necesitan calidad, pero en distinta medida. Una organización que no establezca estos mecanismos y no sea capaz de ofrecer la calidad esperada por sus clientes está destinada a entrar en un período de incertidumbre que le puede llevar al fracaso. Y sobre todo hoy en día, donde la competitividad entre empresas es cada vez mayor.

Es dicifil probar los beneficios de la calidad a corto plazo, por eso la calidad tiene mucho enemigos o debilidades, como la fatal de apoyo institucional dentro de la organización (stakeholders), falta de conocimientos, la impaciencia en conseguir resultados, la falta de disciplina de los equipos, el coste (aunque Crosby dijo que la calidad no cuesta)…

Referencia sobre Philip Crosby: wikedia.com

El concepto es el concepto!!!!

Javierpello — Thu, 13 May 2010 23:40:34 +0000

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!!!!!

La importancia del modelado

Javierpello — Mon, 12 Apr 2010 12:53:24 +0000

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? Hay cuatro razones principales:

Ayudar a comprender el sistema actual.
Ayudarnos a conceptualizar la solución.
Ayudar a la mejora de la comunicación.
Evita ambigüedades e interpretaciones erróneas.

¿Que necesitamos para modelar? todo depende de la organización, pero tampoco es necesario gastarse un dineral en sofisticadas herramientas, con una simple herramienta de dibujo se pueden hacer diagramas de forma barata y eficaz sin la necesidad de invertir en algo caro y complejo. Por tanto, sólo necesitamos de una herramienta que nos permita dibujar “Use Cases”, “sequence diagrams” o “BPMN (Business process Management Notation)”. Una herramienta para ello es el “StarUML”. La potencia de estos modelados es que cada diagrama tiene sus propias reglas con significados específicos y estándar, los cuales dejan poco margen a interpretaciones erróneas. Si esto lo trasladamos al mundo del testing, el modelado es fundamental a la hora de diseñar test cases…pero creo que las empresas siguen sin comprender su importancia. En fin, creo que todavía nos queda un largo camino por recorrer.

FiascoAwards 2010 – ¿Porque fracasan los proyectos?

Javierpello — Fri, 12 Mar 2010 19:36:55 +0000

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

Now Hiring????

Javierpello — Thu, 21 Jan 2010 19:30:54 +0000

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.

Google, “Testing in the toilet”

Javierpello — Fri, 11 Dec 2009 10:09:20 +0000

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.