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?

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.

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:

• Gestión (PMP, CAMP, ITIL,...)
• Auditoría (CISA, SCAMPI Lead Appraiser...)
• Seguridad (CISM...)
• Pruebas (TMAP, ISQTB...)
• Análisis (CPRE,...)
• Desarrollo

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:

• Testing (I) - Las pruebas según el CMMi
• Testing (II) - Planificación de las pruebas
• Testing (III) - Analizar los resultados de las pruebas

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.

El coste de la calidad

La calidad cuesta. Y aquí es donde vais a empezar a pagar. Con horas extras. Uy no. No parece muy buena idea empezar este post parafraseando la frase de aquella serie de los 80 que se llamaba "Fama".

Y sin embargo es cierto: la calidad tiene un coste. Pero no hay que dramatizarlo. Como un compañero de trabajo cuyo nombre mantendremos en el anonimato me decía no hace mucho: "Pero esto de la calidad, ¿cuántas horas extra me va a costar a la semana?". Es curioso. Si se tratara de introducir en el proyecto una tecnología novedosa (aun cuando fuera totalmente irrelevante para el éxito del proyecto), no le importaría dejarse la piel en ello. Pero si se trata de aportar visiblidad, mejorar el número de defectos, introducir buenas prácticas, obtener un repositorio de componentes reutilizables....en ese caso, todo nos cuesta.

Esto me recuerda a cuando éramos niños pequeños: hay que ver cuánto nos costaba lavarnos los dientes. Y sin embargo, es una tarea que supone realmente un esfuerzo y tiempo ínfimos, y mucho más comparado con los beneficios que da. Pero claro, cuando tenemos 4 o 5 años no pensamos en los beneficios. Nos da todo igual.

El motivo de este post ha sido mi lectura reciente de un curso ofrecido por INTECO, en el que he aprovechado para ver si encontraba algo que o no conociera, o que al menos hacía tiempo de lo que no me acordaba. Y me he llevado la agradable sorpresa de un gráfico en el que se analiza el coste del proyecto. Vamos a recordar un poco estos conceptos:

1. Coste del Proyecto

Los costes del proyecto se dividen en Costes de Ejecución (lo que cuesta hacer las tareas productivas), y el Coste de la Calidad (básicamente, el resto)

1.1. Coste de Ejecución

Básicamente serían: la preventa, la planificación y el desarrollo.

1.2. Coste de la calidad

Se dividiría en:

• Coste de la Conformidad
• Coste de la No Conformidad

1.2.1. Coste de la Conformidad

• Evaluación: Son las revisiones, pruebas y auditorías que se hacen para ver que todo está conforme planificado en cuanto a funcionalidad y calidad.
• Prevención: Son las tareas adicionales de formación, documentación, toma y análisis de datos, etc., que permiten ayudar a que todo esté conforme en cuanto a funcionalidad y calidad.

1.2.2. Coste de la No Conformidad

• Internos: es el coste de volver a escribir requisitos, rehacer el diseño funcional y técnico, reescribir el código, etc.
• Externos: soporte técnico, gestión de quejas e incidencias, pérdidas de proyectos, reclamaciones, etc.

El coste de la calidad suele presentarse de forma gráfica de la siguiente forma (clic para ver más grande):

En esta gráfica se muestran los costes totales de la calidad como la suma de los costos de los fallos (lo que hemos llamado "Coste de la No Conformidad"), y los costes de prevención y evaluación (lo que hemos llamado "Coste de la Conformidad"). Vemos que existe un nivel óptimo en el que conseguimos mantener una cuota de fallos razonablemente baja, con un coste total mínimo.

Testing (II) - Planificación de las pruebas

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

• Testing (I) - Las pruebas según el CMMi
• Testing (II) - Planificación de las pruebas
• Testing (III) - Analizar los resultados de las pruebas

En las pruebas, se suele dejar de lado aspectos fundamentales como son:

• Preparación/planificación
• Análisis
• Reporting de los resultados de las pruebas

Hoy voy a intentar dar un repaso al primero de ellos.

Preparación de las pruebas.

Como cualquier tarea de verificación, las pruebas de software no pueden pasar por alto estas prácticas, que se encuentran por otro lado perfectamente identificadas en el modelo CMMI. Antes de empezar con las pruebas, tiene que haber una etapa de preparación en la cual se seleccionan los productos de trabajo a probar, se establece el entorno de pruebas y se disponen los  procedimientos y los criterios a aplicar en las pruebas. Para los fanáticos anti-burocracia, esta etapa puede ser mucho más simple de lo que estáis pensando. En un proyecto pequeño puede ser unas frases y listas de requisitos. Si siempre hacemos igual las pruebas, puede bastar hacer referencia a nuestro estándar o a un proyecto anterior.

En esta etapa para cada producto a probar se tienen que identificar los requisitos que tiene que satisfacer, y se tiene que buscar la estrategia de pruebas adecuada.

Se tienen que seleccionar los métodos de pruebas que se van a usar, por ejemplo decidir si es adecuado incluir  pruebas de cobertura de caminos, de carga, de esfuerzo, de rendimiento, pruebas basadas en tablas de decisión, y en descomposición funcional, y si se van a reutilizar casos de prueba.

Otro aspecto dentro de la preparación de las pruebas es el establecimiento del entorno de pruebas. Una prueba de producto puede requerir simuladores, emuladores, generadores de escenarios, herramientas de reducción de datos, controles ambientales e interfaces con otros sistemas. De las características del entorno de pruebas se derivan las tareas necesarias para su preparación, que deberán incorporarse al calendario del proyecto.

También se tienen que establecer los criterios que se van a seguir en las pruebas. Para especificarlos es preciso consultar los requisitos del producto y de componentes de producto, estándares, políticas de la organización, tipo de prueba, parámetros de compromiso entre la calidad y el coste de las pruebas, propuestas y acuerdos. Dos de los criterios que tienen que estar fijados especialmente y con objetividad es el de finalización de las pruebas, y el de aceptación del producto. En qué momento se puede dejar  de probar y qué se tiene que cumplir para que se acepte el producto, estos criterios no tienen que ser subjetivos, deben referirse a condiciones susceptibles de ser medidas (por ejemplo: las pruebas terminarán cuando la detección del siguiente error tenga un coste superior a …)

Las pruebas se desarrollan en el entorno establecido e incrementalmente durante todo el ciclo de vida del proyecto. Una organización y realización adecuada de las pruebas contribuye desde un principio a conseguir productos con la calidad acordada.

Como producto de las pruebas no solamente está el resultado de las mismas sino que también se tiene que preparar un informe sobre esos resultados, constatar las acciones a emprender seguidamente y algo que no es frecuente: un registro del método seguido, “cómo se hizo”, para asegurar que las pruebas se pueden repetir exactamente igual. Esto último es importante en labores de mantenimiento,  cuando se hacen pruebas de regresión, para evitar que una alteración en el método confunda el resultado de las pruebas.

Algo importante a tener en cuenta: es posible que por contrato, legislación, normas del cliente, etc., se nos exijan documentos y pruebas específicas que no hayamos inicialmente considerado. Por ejemplo, un cliente en la Administración Pública que use la metodología "X", si por contrato, hemos dicho que vamos a usar dicha metodología, deberemos revisar a qué documentos, tipos y ciclos de pruebas nos hemos de someter. También puede ser típico que no sea directamente el cliente, sino una empresa certificadora de aplicaciones (un proveedor externo), quien en su nombre verifique la calidad de nuestro desarrollo. Por supuesto, que deberemos recoger como requisitos, las pruebas a las que van a someter a nuestro producto.
Vamos a ver en resumen, cual podría ser (en un proyecto grande, y siempre que se estime necesario), la información a recopilar en esta fase de preparación/planificación de las pruebas:

• Tipos de pruebas. Identificar qué pruebas vamos a realizar a nuestro desarrollo.
• Ciclos de pruebas
• Recursos físicos: principalmente, equipos y entornos, software. Al menos, habrá que identificar qué pruebas se realizan en cada entorno (desarrollo, pruebas, pre-producción, producción, formación...). Los recursos también pueden ser los datos de pruebas. Habrá que tener en cuenta si son necesarios, quién es el responsable de proporcionarlos, etc.
• Recursos humanos: personal del cliente responsable o participante en las pruebas, miembros de nuestro equipo y su rol en la prueba a realizar, otras personas (proveedores externos, etc.)
• Calendario de pruebas: tratar de ajustar a nuestro plan de trabajo, las pruebas a realizar. Con ello, no sólo tendremos un calendario orientativo de cuándo tenemos que estar disponibles para hacer las pruebas, sino que además podremos avisar con tiempo de que ciertas personas estén disponibles (por ejemplo, el responsable de sistemas del cliente), o de que se haya comprado e instalado ese servidor Unix que tenemos planificado.
• Restricciones/limitaciones: las que se nos ocurran. Son notas a tener en cuenta para "no meter la pata".
• Dependencias: ¿dependemos de servicios/funcionalidades que proporcionan otros proveedores? ¿Proporcionamos nosotros servicios o funcionalidades que van a requerir otros proyectos?

¿Pero tú estás loco?¿Todo esto es necesario?

La respuesta es sí y no. Es necesario tener en cuenta estas cosas, y es algo que de forma natural, los que hemos estado metidos en muchos proyectos solemos recopilar en mayor o menor grado. Para evitar que se olviden estas cosas, el CMMi (y casi todas las metodologías), nos recomiendan usar una Checklist. Por supuesto, los que nunca lo han hecho, les parecerá la primera vez un gran esfuerzo. Luego, conforme lo usas en varios proyectos, te das cuenta que normalmente sólo haces realmente una parte de lo aquí comentado (¡claro, sólo lo que aplica a tu proyecto, nunca hay que trabajar por trabajar!)

Normalmente, todas estas cosas sólo serán necesarias en proyectos grandes, complejos o con riesgos tecnológicos y/o de integración.

Aquí va una típica conversación entre programador y jefe de proyecto:

• Jefe de Proyecto: venga, lo instalas en pruebas y le das un par de vueltas hasta que estés seguro de que funcione. (notar aquí que el Jefe de Proyecto echa la responsabilidad al programador, pero no le guía en qué, cómo, cuándo ni porqué...)
• Programador: ¿Oye, y que pruebo?
• Jefe de Proyecto: bah, tú simplemente revisa que todo lo que hemos tocado funciona.

Bueno, seguro que vosotros os habéis visto en situaciones similares. La realidad supera como siempre, a la peor de las ficciones.

Testing (I) - Las pruebas según el CMMi

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

• Testing (I) - Las pruebas según el CMMi
• Testing (II) - Planificación de las pruebas
• Testing (III) - Analizar los resultados de las pruebas

Las pruebas en el modelo CMMI DEV están tratadas principalmente en las áreas de proceso "Verificación" y "Validación".

La verificación tiene como objetivo demostrar que el producto de trabajo cumple los requisitos que se especificaron para ese producto de trabajo, la validación asegura que el producto que se proporciona es adecuado para su uso previsto y en el entorno operativo previsto. Con la oportunidad que da el sintético idioma inglés, los americanos dicen que la pregunta para la verificación es Did you build the product right?, mientras que la pregunta para la validación es Did you build the right product?

La verificación se hace sobre productos de trabajo y sobre el producto final, entendiendo que los productos de trabajo son resultado de actividades diversas y no solamente de la codificación. Se tienen que verificar los documentos que se generan respecto a los requisitos que se acordaron al inicio y durante el desarrollo del proyecto. Por ejemplo, el manual de usuario deberá cumplir con algún tipo de requisito o normativa, especificado por el cliente o por la organización que hace el desarrollo. Se tendrá que comprobar que se haya escrito en el idioma o idiomas pedidos, que sigue una estructura adecuada y que está completo, que figuran los logos del cliente si así se ha especificado. Como éstos puede haber otros requisitos para este producto o para otros.

En la validación intervienen los usuarios finales u otros involucrados en el proyecto, que tienen autoridad para revisar los productos obtenidos y rechazarlos si no satisfacen las necesidades del usuario cuando se encuentran en el entorno en el que van a operar. Siguiendo con el ejemplo del Manual de Usuario, la persona que tiene que validarlo, comprobará que los resultados de las consultas le son útiles en el entorno y la función de la aplicación para las que las hace. Por ejemplo, puede encontrarse que entre los parámetros de configuración no figuran los necesarios para su sistema operativo.

El modelo CMMi considera especialmente la utilización de las revisiones entre pares como instrumento de verificación, tanto es así que la utilización de las mismas es una de las metas del área de proceso “Verificación”. Para decirlo más claramente, si una organización quiere alcanzar el nivel 3 está obligada a utilizar este método.

Las revisión entre pares es una técnica en la que el producto del trabajo de una persona se expone a la consideración de otras personas con las que no tiene relación de dependencia, es decir, son sus iguales, sus compañeros. El producto generado se revisa utilizando listas de comprobación ("checklists") en las cuales se pueden encontrar cuestiones sobre reglas de construcción, guías de diseño, facilidad de mantenimiento, tipos de defectos comunes, etc, que se van a comprobar en elementos  entre los que pueden estar los productos de trabajo claves de las actividades de especificación, de diseño, de prueba y de implementación, y sobre los productos de trabajo específicos de planificación.

Verificar es más que probar.

Solamente probar código no es verificar, las pruebas del software son una parte del concepto de verificación tal y cómo lo entiende el modelo. Todos lo productos de  trabajo del proyecto, no solamente el código, deben considerarse para decidir si se incorporan entre los que van a ser verificados, y entre ellos están los documentos técnicos, los planes, los productos COTS (*), herramientas a utilizar, e incluso elementos de formación.

Validación.

En las actividades de validación, interviene el usuario para comprobar que el producto le presta las funcionalidades pedidas en el entorno de producción. Se han llamado normalmente “pruebas de aceptación” y tradicionalmente se hacen cuando el producto está terminado y sólo sobre el software. Para evitar sustos a última hora, deberían seleccionarse productos de trabajo intermedios, susceptibles de ser validados, que puedan predecir si el producto final cumplirá las expectativas del usuario y de este modo ir validando pronto, paulatina e incrementalmente durante todo el proyecto.
Ejemplo de los productos que se pueden validar son: los requisitos, diseños, componentes de producto, interfaces de usuario, manuales de usuario, materiales de formación y documentación del proceso.
El modelo exige las mismas prácticas para validar que para verificar, excepto la revisión entre pares.

 (*) COTS: Commercial Off The Shelf; paquetes o productos comerciales, que hay que probar (al menos su integración con el resto de nuestro producto).

Por fin un estándar para las pruebas: ISO 29119

Se está haciendo un importante esfuerzo desde hace ya algún tiempo para estandarizar las pruebas de software. El resultado de esto es el estándar ISO/IEC 29119 Software Testing, que todavía no está terminado, sino que se encuentra en revisión pública de la versión borrador. El portal de trabajo se encuentra en: http://softwaretestingstandard.org/, donde encontraréis información actualizada del estado y contenido.

¿Qué pretende este estándar?
Su objetivo es recopilar la terminología, procesos, documentación y técnicas para todo el ciclo de vida de pruebas del software.

¿Cuál es su contenido?
El contenido está estructurado (actualmente a fecha 12-12-2011) en cuatro partes:

• Parte 1: Definiciones y Vocabulario
• Parte 2: Proceso de Pruebas
• Parte 3: Documentación de Pruebas
• Parte 4: Técnicas de Pruebas

¿En qué se basa?
Se basa en las principales normas que actualmente son los referentes de esta área:

• BSI (British Standards Institution): BS 7925-1, Software Testing: Part 1-Vocabulary y BS 7925-2, Software Testing: Part 2-Software Component Testing.
• IEEE Std. 829, Software Test Documentation y IEEE Std 1008, Software Unit Testing, IEEE Std 1012-1998 Software Verification and Validation y IEEE Std 1028-1997 Software Reviews.
• ISO/IEC 12207, Software Life Cycle Processes, ISO/IEC 15289, System and Software Life Cycle Process Information Products y ISO/IEC TR 19759, Guide to the Software Engineering Body of Knowledge

¿Hace falta que un Tester sepa programar?

Esta es otra afirmación que me ha sorprendido y mucho, y que he oido mucho hablar de ella durante mis muchos años de práctica. A ver. La técnica que suelen usar los bloggers normalmente es plantearlo como una pregunta. Pero en realidad, muchas veces ya se tiene la respuesta, y el post se limita a dar una avalancha de argumentos a favor de su postura. Vamos a intentar dar una vuelta a los argumentos a favor y en contra. Pero ¿porqué programar? ¿porqué no hablamos de otros conocimientos como: UML, arquitectura, lenguajes de programación, herramientas de desarrollo,  herramientas de testing, sistemas, análisis...? Me da la sensación de que esta afirmación viene siempre de gente con un fondo importante en programación, y que por  tanto da mucho valor a este rol (y no digo que no lo tenga), y que sin querer desprecia el resto de roles en el ámbito del desarrollo software.

Dando una vuelta por internet, me encuentro con argumentos a favor y en contra. Pero sorprendentemente, muchos más a favor. Vayamos viéndolos:

A favor:

• ¿Porqué no? He encontrado este argumento, y bueno...no se han roto la cabeza.
• Depende. Vale. Otro argumento bien fundamentado. No en serio, vamos a intentar profundizar sobre éste, ya que soy partidario de él parcialmente. Lo haremos durante el post.
• Todo ayuda. Ahí estoy de acuerdo. Cuanta más formación, mejor. Pero más bien la duda sería: ¿qué es mejor? ¿Que esté formado en programación y desarrollo (específico en lenguaje, en plataforma, en arquitectura...)? ¿O que esté formado en el negocio del cliente, que conozca su forma de trabajo, sus necesidades, su lenguaje específico? ¿Qué debe hacer realmente un tester?
• Para poderle explicar al programador dónde está el fallo, ya que el conocimiento de programación le puede hacer inferir qué problema tiene, y así le ayuda a corregirlos antes. Este argumento me sorprende y mucho. Salvo que el tester sea uno de los programadores, y conozca la arquitectura en detalle, es difícil (por no decir imposible), que el tester sepa qué y porqué falla algo. Estoy de acuerdo, que cuando con nuestra experiencia, los que hemos programado hacemos pruebas, podemos tener sospechas de porqué falla algo. Pero de ahí, a que realmente sea útil esa sospecha, es concedernos un criterio excesivo.
• Para poderle aportar al programador experiencia sobre cómo corregir sus fallos, de forma que su código sea más seguro y fiable. Esta también me ha sorprendido. Entonces qué queremos ¿testers o formadores? Esta es la visión típica de la persona que ha probado mucho, pero también ha programado mucho. Pues claro que tendrás experiencia en fallos/soluciones típicas. Pero es mucho más complicado que eso. Si estamos en un mantenimiento, no vamos a tener tiempo de tonterías: hay que resolver la incidencia para cumplir el ANS (Acuerdo de Nivel de Servicio). Y si no es un mantenimiento, si de verdad tenemos tiempo de ponernos a hablar y discutir con el programador todos y cada uno de los fallos encontrados....yo quiero trabajar en ese proyecto, y lo quiero YA. Aquí se mezclan churras con merinas. De acuerdo que programadores que han hecho mucho testing, son los más adecuados para transferir ese conocimiento. Pero eso no significa que el tester deba hacerlo, porque la forma de corregir los defectos puede depender de la arquitectura específica, y el tester no tiene porqué conocerla. De hecho, en la mayoría de los casos, lo que interesa es presentar un informe de resultados de defectos al cliente y/o al jefe de proyecto. La solución de los problemas, su prioridad, etc., dependerá de muchos factores (y no tiene porqué ser el criterio del tester, y mucho menos del programador).

En contra:

• No debe condicionarse al tester con el conocimiento interno de la aplicación. Las pruebas deben realizarse siguiendo las indicaciones del plan de pruebas. Ahora bien, si no hay plan de pruebas, no hay casos de pruebas, ni datos de prueba, ni resultados esperados…no necesitamos un tester que sepa programar. Necesitamos a Dios.
• El conocimiento de la aplicación (léase documentación, arquitectura, análisis, etc), puede estar obsoleto. Si defendemos las metodologías ágiles, es posible que el tester no cuente con documentación actualizada de “qué hay dentro”. Si aceptamos que esto sea así, ¿cómo vamos a exigirle que entienda algo que seguramente no le sirve? Dejémosle que pruebe lo que debe probar, y que no esté pensando en "lo que hay detrás".
• ¿Debe alguien que se prueba la ropa saber coser? ¿o hacer pantalones, o cortar telas…? ¿Deben los inspectores de calidad de un edificio saber poner ladrillos, etc? ¿Debe un técnico de ITV saber construir un coche? (puede que ni siquiera le haga falta saber conducir)
• Un tester debe ser objetivo. Su resultado es un informe de pruebas. Si su resultado son consejos a los programadores, tendremos a un arquitecto, analista o programador “power”, cuyo tiempo estaría mucho más aprovechado revisando la arquitectura y el código (o formando al equipo), que probando.
• A un programador difícilmente le puede aportar un resultado de pruebas del estilo: "yo creo que te falla la punta de la trócola cuando el cimborrio izquierdo recibe un valor trambostático". Si la conclusión del tester no es objetiva, acabaremos creando una cadena de opiniones que finalmente perviertan el resultado de la prueba, y por tanto, la invaliden. Al programador hay que darle algo objetivo: se da el fallo x cuando en la situación y meto el valor z. Esto es algo repetible y objetivo. Por ejemplo: no le puedo decir: "me parece que en algunos ordenadores el color de fondo es más claro". Sino que si soy un tester debo decir: "en las pruebas X, en el ordenador Z, el color de fondo se ve más claro".  

Yo creo que la conclusión sería ésta:

• Si el equipo y el proyecto son pequeños, no te queda otra: no es operativo tener un señor sólo para probar, a no ser que sea un recurso compartido entre proyectos. Aquí normalmente no es que haga falta, es que simplemente este tester tiene también otros roles.
• Si el proyecto es mediano o grande, se hace necesario un tester especializado en esa tarea. Y aquí es cuando es menos significativo que el tester sepa hacer otras tareas.
• Si sólo llevamos un proyecto en la empresa: aquí la visión es otra: necesitas alguien que haga el testing, pero que también te de soporte a más tareas. Además, es más fácil que el tester esté versado en el negocio del cliente, la arquitectura, etc, porque sólo hay 1.
• Si llevamos varios proyectos en la empresa: si el tester se comparte entre varios proyectos, es más difícil que esté puesto en el negocio, en la programación, la arquitectura...ya que pueden ser muy diferentes. Si el tester no se comparte entre varios proyectos, sino que hay uno por proyecto, entonces sí que es posible que aporte algo más.