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?

Anuncios

Material para preparar ISTQB

Hola, aquí dejo un enlace bastante interesante con material que ayuda a la preparación de la certificación ISTQB:

ISTQB es una certificación que pretende cubrir en diversos niveles, las áreas de conocimiento relacionadas con la ingeniería de pruebas.

Si alguno más se anima a la certificación, mucho ánimo.

Se me olvidaba! El enlace: https://sites.google.com/site/softwaretestingbooks4u/manual-testing

Por cierto, este post es el número 200 en este blog. Vaya, ya tenemos unos cuantos.
Un saludo.

Próxima parada: ISTQB

Hola, tras tanta certificación de calidad para la empresa, y viendo el éxito que ha tenido la de ITIL a nivel personal, varios compañeros y yo nos estamos certificando en la ISTQB. El objetivo es pasar el examen a principios de año.

¿Qué es eso de la ISTQB? Es una certificación personal, que no caduca, y que tiene varios niveles. En el Foundations, certifica unos conocimientos básicos y suficientes. ISTQB está relacionada con el testing, con las pruebas en el desarrollo de software. Y no sólo está orientado a testers. Todo el mundo involucrado en el desarrollo y en especial testers y gestores deberían conocer al menos el nivel foundations.

Aprovecharé que me estoy preparando yo mismo, para ir comentando aquí algunos conceptos y mi experiencia en la certificación.

Hasta otra.

Cuando la culpa no es del usuario II

Recientemente he conocido a Martin, y me ha comentado que le ha gustado mi post “La culpa no es del usuario“.

Martin es un profesional en un sector difícil y cada día más competitivo. Conoce, aunque no es profesional del sector, la tecnología en sus diversos ámbitos. Le tocó sufrir la desidia y dejadez de las empresas de telefonía móvil en España, que muchas veces no se molestan en tener actualizado su software.

Recientemente, Martin quiso probar la disponibilidad y cobertura en su domicilio de una conocida empresa operadora de ADSL. Para saber si había cobertura, tenía que rellenar un formulario. En el mismo, se le solicitaba su dirección y número de teléfono. Nada fuera de lo normal hasta ahí. Sin embargo, cuál no sería su sorpresa al comprobar que no funcionaba. La respuesta fue que su número de teléfono estaba equivocado. Martin lo comprobó una y otra vez. Pero la respuesta fue la misma.

El software estaba equivocado, no su número de teléfono. En España, los teléfonos fijos empezaban en “9”. Sin embargo, algunas provincias, han ampliado su capacidad utilizando números que empiezan en “8”. ¿Resultado? Aunque ya hace bastante tiempo que existen números de teléfono que empiezan en “8”, el proveedor de ADSL seguía con un software obsoleto, incapaz de adaptarse a esta realidad.

¿Y ahora qué? Pues este conocido operador de ADSL ha perdido a un cliente. Ha hecho perder el tiempo a este señor (y seguramente a muchos más).

Como he dicho ya muchas veces en este blog, lo importante, la base de todo desarrollo son los requisitos. Y este caso es un claro ejemplo de requisitos mal tomados y mal implementados.

Además, fallaron las pruebas. No se definieron correctamente pruebas que recogieran las diversas posibilidades. Los casos de prueba no contemplaron las posibilidades.

Al final, por muy ágiles que seamos, por muy rápidos que queramos ser al poner un producto al mercado, no puede ser despreciando un mínimo de disciplina en estas áreas tan necesarias: requisitos y pruebas.

Gracias Martin por dejarme este comentario tan real como aleccionador.

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.