Pesadilla en la oficina

Ahora que tenía este post pensado, me comentan que ya existe una entrada en youtube que parodia la serie “Pesadilla en la cocina”, pero en el mundo del software, es decir: “pesadilla en la oficina”. Pues ale, os adjunto el enlace para que disfrutéis del vídeo:


¿Os imagináis algo así en vuestras empresas? ¿Aguantaríais que alguien criticara tan duramente vuestro trabajo? Y ojo, no me vale la típica respuesta de listillo en plan “sólo si sabe mucho más que yo”. Las cosas son como son, nos la diga Chicote, el tal Alvarote del vídeo, o Rita la Cantaora.

Anuncios

Eat your own dog food

dogfoodingHoy vamos a hablar de un término (dos en realidad), que están relacionados con prácticas de testing interno.

No te despistes al escuchar la frase ‘eat your own dog food’. En el mundo del desarrollo del software, nos referimos a una empresa que usa sus propios productos en el día a día, de forma interna, incluso mucho antes de salir al mercado. ¿Qué mejor demostración de confianza en tus productos y mejor forma de entregar un producto software pulido y plenamente operativo que usarlo tú mismo, de forma interna?.

Esta práctica, que también podremos oir como “dogfooding” (este es el segundo término), puede tener varios orígenes:

  • Queremos dar una imagen de confianza en nuestros productos. Es una manera de decir al público: “eh, fijaos si nos fiamos de nuestro software, que lo usamos día a día internamente”.
  • Qué mejor beta-testing que precisamente usar el producto de forma interna. Tendremos la garantía de que todos los defectos encontrados van a ser reportados, y resueltos de forma inmediata.
Hay muchas compañías que aplican este concepto. Apple usa internamente sus productos, Microsoft es otro habitual en el uso de esta práctica: usa sus lenguajes y entornos de desarrollo para crear sus…lenguajes y entornos de desarrollo, sistemas y aplicaciones. Incluso Microsoft usó Windows Server 2012 todavía sin terminar como plataforma para dar servicio a Bing a nivel mundial.  De hecho, Microsoft lleva toda su historia ligada al concepto de dogfooding con sus productos.
Pero son muchos los desarrolladores que lo hacen. Esto era muy típico por ejemplo hace algunos años con las típicas soluciones sectoriales de pequeñas compañías que desarrollaban software interno para su gestión (facturación, contabilidad, nóminas y gestión de…presupuestos, clientes, proveedores, etc.) y con el tiempo acababan vendiendo el software a empresas de su sector, o incluso a otros sectores.
¿Y tú? ¿Te atreverías a usar internamente en tu empresa el propio software que produces y confiar en él hasta el punto de dejar tus procesos de negocio críticos en sus manos?

Windows 10 y la gestión de pruebas beta

Hola a todos,
Supongo que muchos ya conoceréis el concepto de Alfa y Beta en el mundo del software. Pero es importante destacar, y en ello ISTQB lo diferencia claramente:

  • Pruebas Beta es un software que se da a probar al cliente en su casa. Vamos, que se lo lleva a su casa, o su oficina, y lo prueba.
  • Pruebas Alfa es un software por el contrario, que se prueba en un entorno controlado por el equipo fabricante, en las instalaciones del fabricante.

Y digo esto porque es muy típico confundir con el concepto de pruebas Alfa y Beta con la versión Beta y la versión Alfa (o pre-Beta) de un software.

Me acabo de acordar porque precisamente estos días, me he instalado Windows 10 en versión Beta, a través del Microsoft Insider Program.

Desde el punto de vista de la gestión de proyectos software, es muy interesante este concepto, ya que permitiría, bien llevado, a llevar el agilismo a extremos insospechados. Un cliente puede usar una aplicación (o en este caso, el sistema operativo), y a través del análisis de su uso del software, se podrían detectar funcionalidades mejorables, funcionalidades más usadas, etc. Por supuesto, en el caso de Windows 10, tenemos el caso del feedback tipo “esta aplicación no me ha funcionado”, o “esta página web no se ha visto bien”.

No digo que Microsoft esté haciendo Windows 10 añadiendo funcionalidades ad-hoc a nuestros gustos. Simplemente, que estamos cada vez más, ante una forma de trabajar adaptativa (ágil), permitiendo a posibles usuarios/clientes el ver prototipos tempranos, más o menos terminados.

Otro caso, también de Microsoft, es Windows 10 para móviles. Todos los usuarios de algunos modelos seleccionados, pueden instalarse una versión bastante avanzada (pero aún no terminada), para obtener feedback del uso, pulir defectos, detectar incompatibilidades, etc.

Por supuesto que todo esto ya existe, y tenemos aplicaciones web (recordemos que GMail ha sido una gran parte de su historia una versión Beta: más exactamente algo más de 5 años entre 2004 y 2009) que se ofrecen a los usuarios de manera muy temprana. Sin embargo, la aproximación que ha tomado este fabricante me parece valiente, y a la vez arriesgada, ya que una mala gestión del modelo de betas podría afectar gravemente a su imagen, si por ejemplo todos los ordenadores o todos los móviles dejasen de funcionar, o si los móviles comenzasen a hacer llamadas de forma autónoma y arbitraria.

Aquí desde el punto de vista de las pruebas y de la ingeniería del software, vemos como se presenta una disyuntiva, y hay que buscar un equilibrio entre la estabilidad del producto (por muy beta que sea), y la necesidad de hacerlo probar a un público lo mayor posible para obtener feedback. Desde luego, es necesario tener un gran control de las pruebas realizadas, y obtener métricas que nos permitan estimar (de forma aproximada, claro), el número de defectos y su gravedad en caso de liberar nuestro producto inacabado.

¿Y vosotros? ¿Os atreveríais a hacer público un software inacabado siguiendo un modelo de pruebas Beta? ¿Cómo gestionaríais los riesgos de hacer público un producto sin terminar?

La culpa no es del usuario

Hoy vamos a ver quién tiene la culpa de los fallos del software.
Me acabo de encontrar una referencia a mi antigua entrada “Cuando la culpa es del usuario“, en la que yo bromeaba sobre quién tiene la culpa de los fallos en el mundo del software. Yo pensaba contestar o comentar en aquél blog, pero al final, había que registrarse y he desistido. Sin embargo, al ver los argumentos a favor y en contra, he pensado que hay que darle otra oportunidad a mi antigua entrada, y recuperarla, esta vez de forma algo más seria.

¿Quién tiene la culpa de los fallos del software?

Vamos a verlo con un ejemplo. Supongamos que hacemos una casa: planos, diseño, ejecución de la obra…todo. Y el usuario entra en la casa a vivir. Hemos construido la casa en base a las funcionalidades habituales: comer, desayunar, ir a dormir, ir al baño, entradas de luz, etc. Además, hemos cumplido las normativas existentes: seguridad, anchura y altura de puertas y ventanas, acceso de luz, aislamiento térmico, etc.

Supongamos que el usuario hace algo imprevisto como intentar salir por la ventana (y es un 8º piso). Si se muere, ¿está claro que es su culpa, no? Pero si le dejamos abierta la puerta al cuarto de alta tensión y no ponemos ninguna medida de seguridad…si se electrocuta y muere…quizás la culpa SEA NUESTRA.

Ahora supongamos que hace otras cosas como entrar por el garage en vez de la puerta de entrada, o tiene la absurda (o no tan absurda?) idea de comprar un sofá o una cama y éstos no caben por la puerta. Puede también querer mirar por la ventana, y encontrarse conque ésta da a la pared del siguiente edificio al que el nuestro se encuentra pegado (vamos, que sólo va a ver y tocar pared). ¿Quién tiene la culpa de esto?

Volvamos al mundo del software y veamos unos pocos casos más tecnológicos:

  • El usuario entra en una parte no permitida del sistema. No podemos impedir que alguien obtenga una contraseña. Hasta ahí es cierto. Pero es nuestra responsabilidad como desarrolladores de software, que no sea posible acceder a partes del sistema restringidas, con una clave no autorizada. Esto me hace mucha gracia, porque tenemos la chulería de exigir que Windows sea super-mega-seguro…pero luego hacemos aplicaciones con más agujeros que un colador. Y entendemos que necesitamos un tiempo razonable para probar y corregir nuestros agujeros de seguridad (somos humanos, verdad?), pero no tenemos la misma tolerancia cuando en vez de desarrolladores, somos usuarios. Exigimos que el programa o sistema operativo que falla, se corrija DE INMEDIATO (los que lo programan no deben de ser humanos, sino robots). Y gratis. Y….vamos, que está claro que sabemos pedir…pero no dar. Exigimos derechos desproporcionados a los deberes que asumimos.
  • El usuario juega con el sistema. Pues que juegue. Es el usuario. ¿Que lo rompe o cuelga haciendo alguna tarea prohibida? Para eso están los logs. ¿Que mete datos estúpidos o incorrectos? Para eso están los logs y el sentido común. Por supuesto, también están las validaciones de datos. Si permitimos “XXX” como fecha de nacimiento, probablemente la función de cálculo de Edad fallará.
  • El usuario tiene que sacar su trabajo, que no es precisamente saber de la tecnología interna del programa. No tiene porqué saber si es puro Java, o JQuery…o lo que sea.

En fin, habría muchos más ejemplos que ahora mismo no tengo tiempo de abarcar. Pero sí me gustaría comentaros un caso real de un colega de profesión ha tenido, y que creo que va a ser representativo.

Caso real.

  • Se trata de una aplicación web.
  • En uno de los cambios de especificación, se añade soporte para iPad.
  • La aplicación se prueba, y funciona correctamente en varios navegadores, tanto en Windows como en dispositivos iPad (hasta en Android!)
  • Cuando llega el usuario, descubre que cierta funcionalidad, sólo está disponible con ratón: al pasar el ratón por encima de los elementos de la página, aparece una información específica de cada elemento. Esto, se introdujo por diseño para disminuir la información de pantalla. Y está genial. Pero un iPad no tiene ratón.
  • Resultado: enfado del usuario y rediseño de la aplicación.
  • ¿Quién tuvo la culpa?

Conclusiones:

Para acabar, resumamos las conclusiones de lo que hemos visto, y de lo que la experiencia me ha hecho ver en todos (y son muchos) estos años:

  • El usuario no tiene culpa alguna de los errores que se producen.
  • Es nuestra responsabilidad poner “paredes” y “puertas y ventanas” a la aplicación para permitir el acceso o no a las funcionalidades.
  • Es nuestra responsabilidad cumplir las normas y estándares existentes, así como adaptarlos no sólo al tipo de usuario, sino al entorno (hardware y sistemas software con los que interactúe).
  • Es nuestra responsabilidad identificar posibles interacciones del producto con otros productos, y ponerlo  como funcionalidades (si funciona) o restricciones (si no funciona).
  • Es nuestra responsabilidad probar. Y probar todo, o asumir los riesgos de lo que no se prueba. Leía recientemente un post donde un compañero de profesión decía que no se puede cubrir todo con las pruebas. Y es cierto. Pero eso no significa que nos tapemos los ojos e ignoremos los riesgos.
  • Automatizar es la clave: debemos hacer pruebas unitarias, y automatizar también las funcionales en la medida de lo posible. En el caso real que se ha mencionado, el problema no era del usuario, era de que no se hicieron todas las pruebas en todos los entornos. Si probar todo en tu PC cuesta 2 días…añadir un nuevo entorno (iPad), costará el doble (bueno, es una primera estimación).

Sobre Testing Quadrants

Hoy veremos un tema que no es nuevo, pero que me era desconocido hasta hace poco: los testing quadrants.

Fuente: libro “Agile Testing: the book”
Esto de los testing quadrants parece estar originalmente basado en la visión de Brian Marick en su blog (http://www.exampler.com/old-blog/2003/08/22/), y consiste en clasificar los diferentes tipos de tests desde dos puntos de vista:
  • Orientación: los tests varían entre los más orientados al negocio (Business Facing), y los más orientados a la tecnología (Technology Facing).
  • Tipo de test: a la izquierda, los de soporte al equipo (Supporting the team). A la derecha, los que critican al producto (Critique Product).
A partir de las ideas originales de Brian Marick, esta idea de los testing quadrants se desarrolló en el ya famoso “Agile Testing: the book” (http://agiletester.ca/), de donde está sacada la imagen que preside este post.
Tal y como se habla en algunos blogs, la numeración Q1, Q2, Q3, Q4 y el uso que se les suele dar a los tests, no pretenden indicar que estemos hablando de la nueva metodología “Cascada” para los tests. De hecho, la numeración es arbitraria. A continuación, veremos que no están desencaminados.
Sí es cierto que en diversas fases del proyecto, es habitual que se utilicen tests ubicados en distintos cuadrantes. Esto es por la forma en que están diseñados los cuadrantes.
Los cuadrantes 3 y 4 suelen exigir que ya exista un conjunto bastante bien definido de código instalable. Los cuadrantes 1 y 2, suelen utilizarse en las primeras fases, por su naturaleza automática (Q1) y facilidad para el prototipado (Q2).
La idea de los cuadrantes es clasificar las técnicas de text, no proporcionar una secuencia natural  y férrea (como el ya manido método de desarrollo en cascada).
Os recomiendo explorar los enlaces para ampliar este interesantísimo tema.

Certificaciones Profesionales

Esta entrada la he creado a raíz de un comentario que he recibido en otra entrada anterior. Allí, un lector me preguntaba sobre las certificaciones de software. En concreto, me preguntaba además por la certificación ISQTB.

Un excelente estudio sobre las distintas certificaciones y su utilidad o necesidad, puede encontrarse en este post del blog de Javier Garzás.

He de decir que aunque este estudio me ha parecido un buen trabajo, los resultados desde mi punto de vista se desmerecen porque faltan datos. Es una buena idea tratar de obtener tendencias, pero con tan sólo dos valores es muy complejo tratar de analizar la verdadera situación del mercado en cuanto a estas certificaciones. Animo al autor a continuar con el estudio para ver la evolución de esas certificaciones a largo plazo.

Hay que considerar, que las certificaciones son muy específicas del perfil o rol del profesional. Por ejemplo, no son significativas las certificaciones en gestión para un tester o programador, lo mismo que la certificación ISQTB puede aportar escaso valor a un jefe de proyecto. Es por eso que las certificaciones están asociadas a los roles:

Otro punto a destacar es que las certificaciones no siempre terminan de cuajar. Por muy bueno que sea el nivel exigido, es más importante el prestigio o grado de aceptación en el mercado (número de empresas que los solicitan). Por desgracia, hay acreditaciones muy buenas como TMAP que no terminan de cuajar en su ámbito.

Esto me recuerda al típico problema del mercado: VHS vs BETAMAX; HD DVD vs BlueRay… y así unos cuantos. Al final, es posible que te gastes un dinero en una certificación, y que luego ésta no termine de tener el prestigio de otra cualquiera. Y se trata de una importante inversión en tiempo y dinero.

Hay otra consideración, y es que las certificaciones o bien “caducan”, o bien son reemplazadas por otras versiones que las convierten en obsoletas. Es el caso de CMM, que se vio reemplazado por CMMi.

Para terminar de complicar la cosa, en algunos países se crean certificaciones o acreditaciones profesionales de ámbito local (como es el caso de CFCP en Mexico). Eso dificulta la decisión de las personas, que se encuentran entre la duda de certificarse en una cosa u otra. Además, las certificaciones que se presentan al mercado, no suelen cubrir de forma unívoca una acreditación existente, sino que suelen añadir o eliminar elementos de forma que una, no cubre el 100% de otra. Esto no quiere decir que las certificaciones estén mal pensadas o diseñadas, no quiero decir eso. Simplemente, no todas tienen el mismo marco de referencia (áreas de conocimiento o experiencia acreditadas), no tienen el mismo alcance (nacional, internacional), y tampoco tienen el mismo prestigio. Hasta aquí, ya tenemos 3 dimensiones a considerar.

Si a todo esto, añadimos lo que Javier Garzás trataba de identificar en su estudio (la evolución del prestigio o necesidad del mercado de esas acreditaciones a lo largo del tiempo), vemos que la decisión es complicada: ¡4 dimensiones!

  • Ámbito
  • Alcance
  • Prestigio
  • Evolución temporal

En concreto, y ya terminando de responder a mi lector en su comentario, diré que la ISQTB me parece una excelente certificación. Yo personalmente la veo solicitada en múltiples ofertas, y particularmente creo necesario que la gente dedicada al testing, tenga una formación específica. No por programar mejor o peor, se tienen porqué adquirir los skills relacionados con las pruebas. La de TMAP, apenas la veo en ofertas a día de hoy, por ejemplo (y quizás es tan exigente o más que la de ISQTB, lo ignoro).

En una entrada anterior (“¿Hace falta que un tester sepa programar?”), comentaba esto mismo.

Además, hemos de notar que nuestro lector se identifica como “Senior QA”, de lo que deduzco que tiene experiencia más que suficiente en el ámbito de las pruebas. ¿Qué valor le puede aportar tener una acreditación en esa área para la que ya tiene experiencia? ¿Le aportaría más valor otra acreditación relacionada con el siguiente escalón en su carrera profesional? Este es otro punto a valorar, ya que me suelo encontrar con situaciones en las que tengo dos tipos de profesionales:

  • Amplísima experiencia, pero ninguna acreditación concreta para el área profesional.
  • Una o varias acreditaciones / certificaciones, pero escasa experiencia.

¿A quién contratarían ustedes? ¿En quién confiarían más? En concreto la ISQTB me parece estupenda, pero un señor con 3 o 4 años de experiencia en pruebas usando prestigiosas herramientas como HP Quality Center o cualquier otra marca, me merece también muchísima confianza (¿quizá más?).

Por hoy, creo que hemos dado suficientes vueltas a un tema, que veo que tiene muchas ramificaciones. Ya seguiremos otro día.

Testing (III) – Análisis y resultados de las pruebas

Este es el tercero de una serie de artículos sobre el testing y el cmmi:

Vamos a retomar esta serie de posts dedicados al testing.

Nos habíamos quedado en el post anterior en la planificación de las pruebas. Por supuesto, faltaría la realización de las pruebas según lo planificado. Pero para ello, me gustaría dedicar un exhaustivo análisis de la herramienta HP Quality Center que he tenido el placer de probar.

Vayamos pues a la etapa de análisis y resultados.

Recopilación de resultados

En primer lugar, hay que recopilar los resultados. Es decir, para poder hacer cualquier tipo de análisis, no basta con probar. Ni siquiera basta con apuntar los resultados. Hace falta que esos resultados estén consolidados en un repositorio.

¿Acaso no desarrollas tu código y después recopilas y unificas todo en un repositorio? Pues con las pruebas igual. Hay varias formas de hacerlo:

  • Con herramientas como HP Quality Center que centralizan todo el proceso y se responsabilizan de las distintas fases y su integración.
  • De forma manual con simples ficheros Excel, por ejemplo.

Análisis de los resultados de las pruebas

  • Con los resultados de las pruebas y el informe de pruebas presentes, se analizan los resultados para comprobar si se han cumplido los criterios que se especificaron para asegurar que la prueba ha sido exitosa. Los resultados de las pruebas de cada producto de trabajo tienen que figurar en los informes y éstos se tienen que analizar incrementalmente para poder darlos como correctos.
  • Cuando el resultado de las pruebas no es el esperado y no está claro que el defecto resida en el producto, es útil estudiar el “cómo se hizo”, para descartar que los errores se deban a problemas de métodos, de criterios o del entorno de pruebas. De nuevo, las herramientas nos ayudarán a buscar el “porqué” de los resultados.

Hay que aclarar que en ocasiones esta fase de análisis no tiene porqué llevarla a cabo la misma persona que se encarga de las pruebas, ni tampoco los programadores. Aquí un buen rol de QA, o incluso el jefe de proyecto, puede aprovechar su experiencia para arrojar luz sobre los resultados. En entornos ágiles, el scrum master podría encargarse de esta tarea.

Comunicación de resultados de pruebas

Una vez se han analizado los resultados de las pruebas, llega la parte más desagradable para el personal técnico: la comunicación de resultados. La comunicación se hace a varios destinatarios:

  • Al equipo de desarrollo. Es importante que sepan el estado del producto en cuanto a defectos encontrados, y una comparación respecto a fases anteriores o si es posible, respecto a otros proyectos más o menos similares. No se trata nunca de decir “lo hacemos mejor” o “lo hacemos peor”. Este tipo de actitud es la mejor forma de cargarse las métricas.
  • Al gerente y otros responsables del proyecto. Aquí es crucial dar un sentido de “vamos bien” o “hay que mejorar”. Tratar de engañarse con un “no es tan malo como parece”, es la mejor forma de llevar un proyecto al fracaso. Si los resultados son buenos, hay que ser realistas y no dejarse llevar por un falso entusiasmo, acortando plazos (por ejemplo).
  • Al cliente. En numerosas situaciones, sobre todo en los entornos de testing y preproducción, el cliente estará al tanto del estado de defectos, y de los resultados de las pruebas. Es importante transmitir seguridad, y sobre todo, franqueza.

El próximo post debería ser por fin el que estoy preparando de automatización y gestión de pruebas con HP Quality Center como ejemplo.