domingo, 30 de noviembre de 2014

II Jornadas sobre Calidad del Producto Software & QA Open Space - Día 2 (2/2)

http://calidaddelproductosoftware.com/2014/


(Puedes encontrar la primera parte de este artículo aquí)

La cuarta charla, titulada "Evolución de un Modelo de Pruebas tradicional a un Modelo de Calidad Total", fue presentada por Alfonso R. López Rivero, de Vodafone. En ella se explicó como Vodafone ha transformado por completo su modelo de la calidad para grandes aplicaciones corporativas de la mano de MTP.

Las ponencias en las que una empresa explica su "caso de éxito" siempre me resultan muy interesantes. Alfonso comentó que Vodafone había apostado por la calidad por encima de time to market (aunque sin olvidarse de él por completo, claro).

Para implantar todos estos cambios, realizaron en primer lugar pruebas de concepto y agruparon dichos cambios en 2 grandes grupos:
  1. Cambios Organizacionales
  2. Cambios Culturales
En el primero se encuadran los cambios que implican un cambio en la estructura jerárquica y organizativa de los equipos:
  • RM - Release Management
  • C&DM - Configuration & Data Management
  • SQA - Software Quality Assurance
    • Ejecución de pruebas
    • Automatización de pruebas y tareas
    • Provisión de datos de prueba
    • Calidad de código: cuando hay tiempo, tratan de "limpiar" código legacy para mejorar su calidad.
    • Calidad de requisitos
    • Pruebas de rendimiento: utilizan una línea base de rendimiento para determinar si el rendimiento de un software es o no aceptable
    • Pruebas funcionales

Los cambios culturales son los más difíciles de llevar a cabo:
  1. En primer lugar hay que pensar si realmente se desea cambiar
  2. Posteriormente hay que planificar la ejecución de los cambios
  3. Superar las barreras que se vayan encontrando y
  4. Por último decidir cómo se medirá el éxito (el valor creado)

En este proceso de cambio se lograron mejoras aplicando acciones proactivas, pero también se aprendió mucho a partir de los errores cometidos.

Por último, Alfonso nos comentó algo que realmente me pareció una gran idea y es que cuando hacen un cambio importante de software, hay gente que se desplaza físicamente a las tiendas para obtener el feedback del cliente.

II Jornadas sobre Calidad del Producto Software & QA Open Space - Día 2 (1/2)

http://calidaddelproductosoftware.com/2014/


Los días 26 y 27 de noviembre se han celebrado las II Jornadas sobre Calidad del Producto Software & QA Open Space. Como el año pasado, este evento ha estado organizado por El Corte Inglés, la Universidad Rey Juan Carlos, la Universidad Carlos III y la UNED.

En esta ocasión, las jornadas se han celebrado en el Campus de Móstoles de la Universidad Rey Juan Carlos.

Si las primeras jornadas estuvieron centradas en el "QUÉ", éstas segundas han estado centradas en el "CÓMO". Otra de las novedades han sido los Open Space: los asistentes dejaban notas en un tablón con las ideas, preguntas o sugerencias relacionadas con el tema del Open Space. Posteriormente, los organizadores, a partir de esas notas planteaban 3 líneas argumentales diferentes y los asistentes podían unirse libremente a cualquiera de ellas. De esta forma se crearon debates abiertos y colaborativos en los que cualquiera podía expresar sus opiniones. Los 3 debates finalizaron con la exposición de las principales conclusiones alcanzadas en los debates.



Lamentablemente, sólo pude asistir al segundo día del evento. Tenía muchas ganas de asistir a algunas charlas del primer día pero por imprevistos en mi trabajo, no pudo ser.

La primera charla del segundo día fue "¿Y qué pinta la Integración Continua en un sitio como éste?", presentada por Ana María del Carmen García y Mariano Minoli, de 233gradosdeTI.

Los ponentes explicaron las 6 razones para utilizar integración continua son:

  1. Reducir riesgos y tiempos:
    Con la integración continua se introducen cambios pequeños y frecuentes en el código. Con el sistema tradicional de entrega de software tradicional se realizan grandes modificaciones cada muchos meses o incluso años.
    Una frase de Martin Fowler resume esta idea:
    "Si algo duele, hazlo más a menudo"
  2. Reducir procesos repetitivos manuales: los procesos manuales son propensos a errores.
  3. Crear una versión de software mediante un proceso conocido, confiable, probado, versionado y repetible
  4. Mejorar la visibilidad del estado del proyecto
  5. Lograr una mayor auto-confianza y seguridad en el equipo de desarrollo
  6. Obtener feedback rápido de los usuarios

martes, 4 de noviembre de 2014

Traducción de TestLink 1.9.12 al español (de España)

  


Hace casi 2 años publiqué en este blog la traducción al español de TestLink 1.9.5

Hoy, tras varias versiones sin actualizar, publico la traducción al español (de España) de TestLink 1.9.12 (última versión estable):

https://mega.co.nz/#!RpYWUYgL!GigI3_xE13lygaZvarNGXjEDkU0hwNSImASZGwRKEIE

Este fichero .zip contiene los siguientes ficheros:
  • /locale/es_ES/strings.txt
  • /locale/es_ES/description.php
  • /locale/es_ES/texts.php
  • /locale/es_ES/custom_strings.txt.example

Adicionalmente, he añadido algunas cadenas de texto que sólo aparecen en la versión en desarrollo al fichero strings.txt para que la actualización sea lo más completa posible a fecha de hoy.

También es importante destacar que no he eliminado cadenas de caracteres antiguas (en desuso en la última versión), por lo que podéis utilizar esta traducción con versiones anteriores de TestLink sin ningún problema.

Debido a que en estos momentos el gestor de defectos de TestLink está caído (* ver actualización a continuación), no he podido subir estos ficheros de forma oficial al repositorio de la herramienta. Lo subiré en cuanto el problema esté solucionado.

Por supuesto, agradezco que me informéis de cualquier error que veáis.

**** ACTUALIZACIÓN 05/11/2014 ****
He abierto una nueva incidencia en el gestor de defectos de TestLink adjuntando esta nueva traducción:
http://mantis.testlink.org/view.php?id=6730

Volveré a actualizar el artículo cuando los ficheros pasen a formar parte de la versión en desarrollo de TestLink.


**** ACTUALIZACIÓN 07/11/2014 ****
La traducción ya forma parte de TestLink. El siguiente commit lo demuestra:
https://gitorious.org/testlink-ga/testlink-code/commits/4836668d820e490cc4557ee59ef94ec050e74fa3

lunes, 22 de septiembre de 2014

Hexawise: Generación de casos de prueba aplicando Combinación de Datos

La Combinación de Datos es una de las técnicas de prueba más utilizadas. En todas las aplicaciones en las que el usuario pueda introducir datos para generar una determinada respuesta del sistema, podría aplicarse esta técnica.

Cem Kaner [1] [2] explica la técnica en el siguiente vídeo (en inglés):


El problema es que cuando el número de datos de entrada es elevado y además cada uno de ellos puede tomar diferentes tipos de valores (valores en distintas clases de equivalencia), aplicar la técnica de forma manual puede se muy complicado.

Afortunadamente, existen múltiples opciones para realizar pairwise testing:

Una de las herramientas más completas para realizar Combinación de Datos es Hexawise:


Hexawise es una herramienta online que ofrece un periodo de prueba gratuito de 30 días siempre y cuando te registres usando una dirección de correo profesional:


Creo que hace unos años esta herramienta era gratuita para los 5 primeros usuarios registrados de cada dominio de correo electrónico empresarial. Esto permitía que una empresa pequeña pudiera utilizar la aplicación de forma gratuita durante un tiempo ilimitado.

Actualmente no abundan las opciones gratuitas de calidad. CombTest, de la Universidad de Castilla La Mancha es una de ellas: http://alarcosj.esi.uclm.es/CombTestWeb/ 

Hasta hace pocos años, la herramienta CTE XL de Berner & Mattner ofrecía una versión gratuita de su programa que permitía aplicar pairwise y threewise para generar casos de prueba. También permitía aplicar reglas de negocio basadas en operadores lógicos para determinar relaciones obligatorias, condicionadas o prohibidas. Sin embargo, actualmente, sólo la versión de pago ofrece la posibilidad de generar casos de prueba.

viernes, 5 de septiembre de 2014

Alternativas para realizar testing multi-navegador

Es indiscutible que hoy en día, los usuarios podemos acceder a nuestras webs favoritas desde múltiples dispositivos: PCs, smartphones, tablets, smart TVs, etc.

Para ello, también podemos usar múltiples navegadores web: IE, Mozilla Firefox, Chrome, Ópera, Safari, Dolphin, Epiphany, etc.

Esta variedad supone un verdadero quebradero de cabeza para los diseñadores y desarrolladores de webs y aplicaciones y por supuesto, también para los testers de software.

¿Cómo podemos probar en múltiples navegadores / múltiples sistemas operativos?
Existen muchas alternativas:
  1. Múltiples dispositivos físicos: Tener todos los dispositivos físicos con los diferentes navegadores que se quiere probar, es la opción con la que se obtienen los resultados más fiables (lógicamente) pero eso supone un elevado coste económico. También supone un esfuerzo muy alto a la hora de probar. Como no se pueden tener todos los dispositivos físicos existentes, puede analizarse el tráfico de la web y comprobar los dispositivos más utilizados por los usuarios; es decir, los dispositivos más representativos.

  2. Máquinas virtuales: Cuando se trata de probar varios navegadores en diferentes sistemas operativos de ordenador, tener en un mismo equipo diferentes máquinas virtuales con las configuraciones a testear es una opción muy buena. Una herramienta gratuita y libre para virtualizar sistemas operativos en ordenadores con arquitectura x86 es VirtualBox.

  3. Dispositivos físicos remotos: Existen algunas páginas que permiten probar tu página web en dispositvos físicos reales a través de una conexión remota. Por ejemplo, en la web de Samsung Developers es posible probar gratuitamente (con un límite de minutos diarios) diferentes dispositivos móviles de Samsung.

  4. Emuladores: Si se quiere probar una web en Android, también puede utilizarse un emulador. Por ejemplo, Android-x86. Los resultados de los emuladores no son 100% fiables pero pueden ser útiles para realizar una prueba rápida.

  5. Múltiples versiones de navegadores en el mismo equipo: En algunas ocasiones, lo que se desea es probar una web en diferentes versiones del mismo o de varios navegadores. Google Chrome y Ópera, por ejemplo, permiten instalar varias versiones en el mismo equipo sin ningún problema. Sin embargo, hay más dificultades para instalar varias versiones de IE o de Firefox en el mismo ordenador. Los siguientes herramientas facilitan esta labor:
    • IE Tester: Es una herramienta para Windows que permite abrir pestañas de IE 5.5, 6.0, 7.0, 8.0, 9.0 y 10.0 (con ciertas resricciones dependiendo de tu vwersión de Windows y del IE que tengas instalado). Esta herramienta, aunque es interesante, es bastante inestable, no permite popups y su desarrollo parece que está descontinuado.



    • Utilu IE Collection: Este programa instala en el equipo las siguientes versiones de IE de forma independiente, desde IE 1.0 hasta IE 8.0.
    • Utilu MFC: De forma análogo a Utilu IE Collection, Utilu MFC instala de forma independiente múltiples versiones de Firefox, desde Firefox 2.0 hasta Firefox 34.
    • Multifirefox: Herramienta para Mac OS que permite ejecutar varias versiones de Firefox.

  6. Herramientas online: Hay muchas páginas web que te permite visualizar el aspecto de tu página web en diferentes navegadores de Windows, Mac OS y GNU/Linux de forma rápida. Una de las más conocidas es BrowserShots:

Aquí comienzan a aparecer los primeros resultados para http://jesus.hernandez.abeleira.com/:


Como véis, hay muchas opciones para probar con diferentes sistemas operativos y navegadores pero ninguna es perfecta. Todas tienen ventajas y desventajas y deberás seleccionar en cada ocasión aquella que mejor se adapte a tus necesidades.

martes, 19 de agosto de 2014

Perla de twitter #4: El Precio de la Calidad de SW

Para esta esta nueva entrega de la sección de "Perlas de Twitter" he elegido una imagen clásica (muy conocida en twitter) con un mensaje claro y directo:
"The bitterness of poor quality remains long after the sweetness of low price is forgotten"

(Traducción: La amargura de la baja calidad permanece mucho después de que la dulzura del bajo precio se ha olvidado)



Fuente: @vgaltes: https://twitter.com/vgaltes/status/466888159083913217

Esta imagen me recuerda esta otra que vi hace tiempo:


 "Puedes elegir algo bueno y barato, pero no será rápido.  Puedes elegir algo bueno y rápido, pero no será barato. Puedes elegir algo rápido y barato pero... NO SERÁ BUENO."

En un artículo anterior ya hablé de los Costes de la Calidad y la No Calidad. Apostar por la calidad es una inversión que da beneficios a medio y largo plazo.

sábado, 16 de agosto de 2014

Ciclos de Procesos

La técnica de Ciclos de Procesos es una de mis preferidas. En todos los proyectos en los que he participado he terminado aplicándola de una u otra manera. Para poder aplicarla correctamente es necesario contar con la base de pruebas adecuada: Procesos de Negocio.

Cuando en una organización no existe documentación de este tipo, a mi me resulta muy útil realizar yo mismo un grafo de los procesos (posteriormente solicito al cliente que verifique la corrección del mismo). Este ejercicio me permite comprender mejor la necesidad de negocio que se desea satisfacer con el programa a testear.

Como comenté en el artículo de Selección de Técnicas de Diseño de Pruebas, cada técnica de diseño de prueba sirve para probar una o varias características de calidad. La técnica de Ciclos de Procesos (técnica de diseño de pruebas formal y de caja negra), permite testear:
  • Usabilidad
  • Efectividad
  • Adecuación funcional
  • Seguridad
Además, permite encontrar inconsistencias entre las funcionalidades desarrolladas y los procesos de negocio. También permite comprobar si la manera elegida para dar respuesta a la necesidad de negocio es la más efectiva y la más idónea desde el punto de vista de la usabilidad y la seguridad. 

Otra de las ventajas de esta técnica es que puede ser utilizada con diferentes grados de cobertura y profundidad.

Voy a explicar con un ejemplo como aplicar esta técnica. El siguiente diagrama de flujo o proceso de negocio es el que se quiere probar:


lunes, 30 de junio de 2014

Esa delgada línea que separa el Testing del Desarrollo

Algunas metodologías o marcos de prueba tradicionales como puede ser ISTQB, indican que hay diferentes grados de independencia del testing frente al desarrollo:
  • Pruebas de desarrollador: la misma persona que escribe el código se encarga de realizar las pruebas.
  • Equipos de desarrollo: las pruebas de una determinada parte del código las realizar un desarrollador distinto al que escribió dicho código.
  • Equipos de prueba: las pruebas las realiza un equipo independiente del equipo de desarrollo pero con personal de la misma empresa u organización.
  • Organización de pruebas: el testing lo realiza un equipo externo a la empresa (subcontratación o externalización de las pruebas).
En ISTQB, aunque se reconoce el hecho de que un desarrollador es quien mejor conoce el código, se indica que los desarrolladores no tienen ni la mentalidad, ni la preparación adecuada para asumir el rol del tester. Además, se hace énfasis en que los desarrolladores tienen un "apego" a su propio código que no les hace ser objetivos a la hora de realizar pruebas.

Por tanto, parece que de alguna manera se aboga por mantener los roles de desarrollador y tester perfectamente separados, con tareas y responsabilidades no solapadas.

Sin embargo, por otro lado tenemos las metodologías Ágiles, como Scrum, en el que sólo se contemplan 3 roles dentro de un equipo:
  • Scrum Master
  • Product Owner
  • Development Team

jueves, 29 de mayo de 2014

La Estrategia de Pruebas

¿Qué es la estrategia de pruebas? ¿Qué diferencia hay con el enfoque de pruebas?
Cada metodología de pruebas tiene su propia definición para la estrategia y para el enfoque de pruebas. Según ISTQB, la estrategia de pruebas es la descripción de los diferentes niveles de pruebas y las pruebas que deben realizarse en cada uno de ellos en una organización o conjunto de proyectos. El enfoque de pruebas es la concreción de la estrategia de pruebas en un proyecto concreto. Este enfoque incluye las decisiones de prueba tomadas para alcanzar los objetivos del proyecto, el análisis de riesgos del producto, los criterios de entrada y salida, las técnicas de prueba seleccionadas, etc.
Sin embargo, para TMap, la estrategia de pruebas es similar a lo que ISTQB llama enfoque de pruebas. En este artículo utilizaré la terminología de TMap.

¿Por qué es necesario aplicar una estrategia de pruebas?
El tiempo disponible para probar es limitado. No se puede dedicar a todo el mismo esfuerzo de pruebas. Esto significa que hay que tomar decisiones (argumentadas) relacionadas con la profundidad de pruebas. La estrategia de pruebas también nos ayudará a utilizar nuestros recursos de pruebas de la forma más efectiva y eficiente posible a lo largo de todo el proyecto.
La estrategia de pruebas se basa en los riesgos. Si el software entregado es muy crítico para el negocio, será necesario realizar pruebas intensivas. Por el contrario, si el sistema no desempeña un papel importante en el negocio, no será necesario realizar pruebas con demasiada profundidad ni cobertura.
El objetivo de la estrategia de pruebas es determinar qué, cómo y cuándo (en qué nivel de pruebas) hay que probar para encontrar el mayor número de defectos posible con el mínimo coste y reduciendo al máximo el nivel de riesgo del producto.

¿En qué momento del proyecto debe realizarse la estrategia de pruebas? ¿Quién la realiza?
Como comenté en un artículo anterior (Selección de Técnicas de Diseño de Prueba), la estrategia de pruebas debe diseñarse teniendo en cuenta lo siguiente:

Por tanto, la estrategia de pruebas debe realizarse tras obtenerse esta información, y antes de comenzar a diseñar los casos de prueba, por supuesto.
Visto en términos de ciclo de vida del proyecto, la estrategia de pruebas debería encuadrarse dentro de la fase de planificación. Posteriormente, la estrategia debe revisarse durante todo el proyecto para adaptarse a los cambios que puedan producirse:
  • Cambio de objetivos
  • Modificación de los riesgos/prioridades
  • Cambios en los recursos (tiempo, tamaño del equipo, presupuesto, etc.)

martes, 20 de mayo de 2014

La matriz RACI

Una de las principales dificultades que me he encontrado en los proyectos de testing en los que he participado es la falta de colaboración del cliente.

Algunos clientes consideran que toda la información que necesita el proveedor se encuentra en el pliego de condiciones. Otros piensan que si contratan a un equipo especializado en testing es precisamente para olvidarse completamente de ese tema y no entienden por qué tienen que dedicar tiempo a responder preguntas o realizar tareas como un Análisis de Riesgos del Producto.

Considero que para que un proyecto tenga éxito es necesaria la colaboración estrecha de proveedor y cliente. Tanto en las metodologías más tradicionales como TMap NEXT como en las nuevas metodologías ágiles (digo "nuevas" metodologías pero el manifiesto ágil tiene más de 14 años...) se hace hincapié en esta colaboración. TMap así lo indica cuando explica en qué consiste el BDTM (Business Driven Test Management) y las metodologías ágiles como Scrum incluyen al cliente/usuario final como parte del equipo (Product Owner). El cliente no debe ser un mero "aceptador" del producto final.

lunes, 28 de abril de 2014

Cálculo de Creditor ID para emisión de recibos SEPA


Hace unas semanas publiqué un artículo en el que compartía el código JAVA necesario para validar un XML contra un esquema XSD. Ese código, que puede ser útil en muchas circunstancias, encuentra en SEPA una aplicación inmediata.

Hoy publico el código de otro programa JAVA útil en la migración a SEPA: Una Calculadora de Creditor ID (identificador del acreedor/emisor de recibos SEPA):

import java.util.Scanner;

public class creditorid
{
    public static void main(String [] args) throws Exception
    {
        try {
            Scanner sc = new Scanner(System.in);
            final StringBuffer transformado = new StringBuffer();
            String pais;
            String sufijo;
            String cif;
            String inicial;
            
            System.out.print("\n**** CALCULADORA DE CREDITOR ID ****\n");
            System.out.print("\n");
            System.out.print("DATOS DE ENTRADA: \n");
            
            //Se solicitan los datos de entrada (País, Sufijo y CIF)
            System.out.print("Introduce el codigo de pais (ej: ES para Espana): ");       
            pais = sc.nextLine();

            System.out.print("Introduce el sufijo (ej: 000): ");       
            sufijo = sc.nextLine();
            
            System.out.print("Introduce el CIF (ej: 12345678A): ");       
            cif = sc.nextLine();
            
            //Punto de partida
            inicial = cif + pais + "00";
            
            //Eliminar caracteres raros y pasar letras a números          
            for (int i=0;i<inicial.length();i++) {
       char c = inicial.charAt(i);
       if (Character.isLetter(c)) {
        transformado.append(Character.getNumericValue(c));
       }
       if (Character.isDigit(c) ) {
        transformado.append((char)c);
       }
      }
            
            //Paso el stringbuffer a string
            String stringtransformado = transformado.toString();
            
            //Paso el string a long
            long numerotransformado = Long.parseLong(stringtransformado);
            
            //Cálculo de módulo
            long modulo97 = numerotransformado%97;
            
            //Obtención del dígito de control
            long checkdouble = 98-modulo97;
            String check = Integer.toString((int)checkdouble);
            
            //Si el dígito de control es de una única cifra se añade un cero a la izquierda
            if (check.length()==1) check=0+check;
            
            //Resultado final (CREDITOR ID COMPLETO)
            System.out.print("\nRESULTADO: ");  
            System.out.println(pais+check+sufijo+cif); 
            
          } catch (Exception e) {
          e.printStackTrace();
         }
    }
}

viernes, 18 de abril de 2014

Perla de twitter #3: Curiosity is king

Cuando se mencionan las cualidades que debe tener un buen tester, la curiosidad es una de las que más se repiten.

Estos dos tweets hacen referencia precisamente a la importancia de ser curioso en el mundo del testing.

El primero de ellos es de Benjamin Yaroch (@dynamoben)

https://twitter.com/dynamoben/status/439077667879399424

https://twitter.com/dynamoben/status/439077667879399424

Traducción libre: Estar interesado en aprender cómo funciona algo y no en cómo dice alguien que funciona, es importante en la prueba. La curiosidad es fundamental.


domingo, 30 de marzo de 2014

Así fue el Accenture EMEA Testing Client Symposium 2014 (2/2)

El segundo día del Accenture EMEA Testing Client Symposium 2014 comenzó con una conferencia de Daniel Meusburger de Accenture titulada Gamification for testing.

La gamificación se queda con la esencia que hace que los juegos sean tan atrayentes y absorbentes y la aplica al mundo de los negocios con el objetivo de obtener mejores resultados.

Daniel nos explicó que dependiendo de si se hace foco en el contenido o en el realismo o si se pretende aprender o modificar el comportamiento, la gamificación puede dividirse según la imagen siguiente:



Para conseguir que los trabajadores modifiquen su comportamiento se pueden utilizar motivaciones extrínsecas (una recompensa económica, por ejemplo) o una motivación intrínseca (comprometerse en las actividades porque resultan atractivas por sí misma). Utilizar recompensas externas puede ser útil pero hay que tener cuidado porque es posible que en el momento de retirar el estímulo externo, el trabajador podría volver a comportamientos anteriores.

Es útil premiar los buenos comportamientos para modificar la actitud de los trabajadores frente al trabajo. Lo que no es útil en ningún caso es castigar.

Como ejemplo de que la diversión puede modificar el comportamiento, Daniel nos mostró el siguiente video:



Otro ejemplo de gamificación, es el plugin de Jenkins que premia los builds correctos y la ejecución de casos de prueba unitarios.

La gamificación puede aplicarse en las siguientes áreas:
  • Gestión del rendimiento.
  • Recompensas y reconocimiento.
  • Colaboración.
  • Gestión del conocimiento.
  • Crowd sourcing.

La aplicación de trabajo colaborativo de Accenture, A3, o la plataforma uTest, ponen en práctica muchas teorías de la gamificación para fomentar la colaboración e incrementar la diversión en el trabajo para mejorar el rendimiento.


sábado, 29 de marzo de 2014

Así fue el Accenture EMEA Testing Client Symposium 2014 (1/2)

Durante los días 27 y 28 de marzo, se ha celebrado en Madrid el Accenture EMEA Testing Client Symposium 2014.

En este evento se han dado cita responsables de testing, desarrollo o proyectos de empresas clientes de Accenture de todo el mundo (Francia, Inglaterra, Alemania, Italia, India, Filipinas, EEUU, España, etc.) así como expertos de esta empresa de consultoría.

El simposio se ha compuesto de 7 ponencias y 2 mesas de debate de diferentes temas relacionados con el presente y el futuro del testing.



Abrió el evento Nick Mayes, de Pierre Audoin Consultans, con una ponencia titulada Trends in testing. Nick destacó el hecho de que la tecnología es una palanca de cambio para el mundo empresarial. Actualmente, gracias a la tecnología, se están reinventando negocios tradicionales. Uno de los ejemplos que puso fue el de esta tienda de comestibles virtual situada en Gatwick:



Durante esta conferencia se mostraron datos que evidencian un aumento progresivo en el gasto que realizan las empresas en calidad de software. Las áreas de mayor crecimiento están en la nube y en SaaS (Software as a Service).

Uno de los mayores retos a los que se enfrentan hoy en día las empresas es el de la movilidad. Todas las aplicaciones y portales deben optimizarse para los múltiples dispositivos móviles existentes (diferentes tamaños de pantalla, sistemas operativos, capacidad de procesamiento, etc.). Además, el time to market de las aplicaciones debe reducirse al mínimo (sin perder calidad ni recortar funcionalidades) para no perder oportunidades de mercado, no quedarse rezagado respecto a la competencia y no perder clientes. Para conseguir acortar estos tiempos se está incrementando el uso de las metodologías ágiles, o al menos de algunas de sus prácticas como la integración continua y la entrega continua de software.

Las empresas tienen diferentes técnicas para aumentar la eficiencia del testing como por ejemplo, la centralización de recursos, la externalización, la racionalización de proveedores y la inversión en herramientas de prueba.

En esta conferencia, por supuesto también se habló de seguridad (muy en boga por los recientes escándalos de espionaje en internet, robo de contraseñas, etc.) y el Big Data.

También hubo un apartado para las nuevas herramientas de prueba que están surgiendo para dar respuesta a todas estas nuevas necesidades. Las suites de HP, IBM y Microsoft se complementan con herramientas como SOASTA, Perfecto Mobile, Wipro, Load Storm, Veracode, Neotys, Coverity, Janova, etc.

Otro dato interesante fue que a pesar de que en el mercado del testing cada vez hay más pequeñas consultoras, el 65% sigue en mano de las grandes consultoras tradicionales.

miércoles, 26 de marzo de 2014

Puntos a considerar en la definición de métricas e indicadores de calidad




Hay una célebre frase de William Thomson que dice:

"Lo que no se define no se puede medir. Lo que no se mide , no se puede mejorar. Lo que no se mejora, se degrada siempre."

Por tanto, medir es necesario. En todo proyecto, en mayor o menor medida, se utilizan métricas para construir indicadores que ayuden a determinar el grado de avance del proyecto, el porcentaje de objetivos alcanzados o la calidad de un determinado producto software.

Definir un buen conjunto de métricas/indicadores para un proyecto no es una tarea sencilla. Algunas de las consideraciones que hay que tener en cuenta a la hora de afrontar esta tarea son:
  • El conjunto de indicadores no debe ser demasiado extenso: Tener muchas métricas puede dificultar su gestión y causar confusión.
  • Los indicadores deben definirse de forma que no den lugar a interpretaciones. Para ello, deberían definirse estos atributos (entre otros) para cada uno de ellos:
    • Código: Abreviatura o identificador asociado al indicador.
    • Denominación: Nombre completo de la métrica.
    • Objetivo: Muy importante. Indica qué objetivo se persigue con esta métrica. Las métricas deben definirse buscando obtener visibilidad del grado de consecución de los objetivos del proyecto.
    • Descripción: Breve descripción de la métrica.
    • Valor objetivo: Valor mínimo que debe alcanzar la métrica para considerar.
    • Hito de cálculo: Momento y frecuencia de cálculo de la métrica.
    • Tamaño de la muestra: Periodo de tiempo o número de elementos que se considerarán a la hora de realizar el cálculo.
    • Origen de datos: Herramientas o bases de datos que se utilzarán como fuente de datos para realizar el cálculo de la métrica.
    • Regla de cálculo: Fórmula utilizada para obtener el valor del indicador. 
    • Formato: Formato y precisión con la que se informará el resultado de la métrica: número de decimales, valor absoluto/porcentaje, etc.
  • Debe definirse un conjunto de indicadores diferente para cada grupo de stakeholders porque cada uno de ellos tiene necesidades de información diferentes.
  • Es útil establecer rangos de valores aceptables/inaceptables para comprender más fácilmente si se están alcanzando los objetivos del proyecto o no.
  • Tan útil como proporcionar un indicador es analizar su evolución en el tiempo porque puede ayudarnos a adivinar tendencias y anticiparnos a posibles desviaciones.

viernes, 14 de marzo de 2014

La respuesta emocional al cambio y los quick wins


La necesidad de cambio nace de la insatisfacción. Todos los proyectos tienen como objetivo dar respuesta a una insatisfacción.

Sin embargo, no todos los estamentos de la empresa afrontarán de la misma forma los cambios, bien por falta de información (no conocer), por falta de formación (no poder) o por falta de interés, voluntad o motivación (no querer). Los cambios siempre cuentan con la oposición de los que se sienten beneficiados o cómodos en la situación actual y abogan por mantener el statu quo en la empresa. También suelen contar con las reticencias de aquellos que han tenido malas experiencias con proyectos de cambio en el pasado.

Cuando los cambios que introduce un proyecto en una empresa son muy grandes, pueden generar confusión, ansiedad o miedo; es decir, un respuesta emocional negativa al cambio (el cambio genera frustración, añoranza de la situación anterior y sentimiento de pérdida). Saber explicar y comunicar bien estos cambios es vital para que no se produzca el rechazo.

Para que el proyecto triunfe es necesario el apoyo de los actores principales:
  1. Sponsor: el patrocinador del proyecto debe ser el principal insatisfecho e impulsor del cambio en la empresa y debe influir durante todo el proyecto. El sponsor siempre debe ser una persona con poder dentro de la empresa.
  2. Evangelizadores o defensores del cambio: los evangelizadores son otros grandes impulsores del proyecto porque también son grandes "insatisfechos" con la situación actual, pero no cuentan con el poder del patrocinador.
  3. Agentes del cambio: los mandos intermedios son esenciales para comunicar a sus empleados de forma correcta cómo influirán los cambios en su trabajo diario.
  4. Objetivo: son las personas que realmente se verán afectadas por el cambio. Es imprescindible contar con su apoyo y colaboración y para ello deben comprender que el cambio les aportará beneficios que compensarán las dificultades o molestias iniciales que puedan sufrir inicialmente.

viernes, 7 de marzo de 2014

El artículo de las 1000 visitas y otras estadísticas del blog

Hace aproximadamente 16 meses comencé a escribir en este blog. En ese tiempo he publicado un total de 30 artículos incluyendo éste.

En total, este humilde blog ha recibido casi 7800 visitas que se reparten de forma desigual. Uno de los posts acapara más de 1000 de esas visitas (un 13% del total) y tiene un 60% más de lectores que el segundo:



En la siguiente imagen se pueden ver las 10 entradas más leídas del blog:


Es fácil ver que la temática con más éxito es la de las herramientas de prueba en general (6/10 artículos) y TestLink en particular (3/10 artículos que aglutinan más de 1600 visitas). Tengo que decir que coincido en gustos con vosotros porque también es mi tema favorito.

miércoles, 5 de marzo de 2014

Validación de ficheros XML usando un esquema XSD (JAVA)


A continuación comparto con vosotros un breve código JAVA que permite validar sintácticamente un fichero XML tomando como referencia un esquema XSD:

import javax.xml.XMLConstants;
import javax.xml.transform.Source;
import javax.xml.transform.stream.StreamSource;
import javax.xml.validation.*;
import org.xml.sax.ErrorHandler;
import org.xml.sax.SAXException;
import org.xml.sax.SAXParseException;
import java.util.List;
import java.io.*;
import java.util.LinkedList;

public class validador
{
    public static void main(String [] args) throws Exception
    {
        try {
         //XML a validar
         Source xmlFile = new StreamSource(new File("C:/Users/Desktop/file.xml"));
        
         //Esquema con el que comparar
         Source schemaFile = new StreamSource(new File("C:/Users/Desktop/schema.xsd"));

         //Preparación del esquema
         SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
         Schema schema = schemaFactory.newSchema(schemaFile);
         
         //Creación del validador
         Validator validator = schema.newValidator();

         //Definición del manejador de excepciones del validador
         final List exceptions = new LinkedList();
         validator.setErrorHandler(new ErrorHandler()
          {
          @Override
          public void warning(SAXParseException exception) throws SAXException
          {
           exceptions.add(exception);
          }

          @Override
          public void fatalError(SAXParseException exception) throws SAXException
          {
           exceptions.add(exception);
          }

          @Override
          public void error(SAXParseException exception) throws SAXException
          {
           exceptions.add(exception);
          }
          });

         //Validación del XML
         validator.validate(xmlFile);
         
         //Resultado de la validación. Si hay errores se detalla el error y la posición exacta en el XML
         if (exceptions.size()==0) {
          System.out.println("FILE " + xmlFile.getSystemId() + " IS VALID");
         } else {
          System.out.println("FILE " + xmlFile.getSystemId() + " IS INVALID");
          System.out.println("NUMBER OF ERRORS: "+exceptions.size());
              for(int i = 0; i < exceptions.size(); i++) {
               i=i+1;
               System.out.println("Error # "+i+":");
               i=i-1;
               System.out.println("    - Line: "+exceptions.get(i).getLineNumber());
               System.out.println("    - Column: "+exceptions.get(i).getColumnNumber());
               System.out.println("    - Error message: "+exceptions.get(i).getLocalizedMessage());
               System.out.println("------------------------------");
                         }
                 }
          } catch (SAXException e) {
           e.printStackTrace();
          } catch (IOException e) {
          e.printStackTrace();
         }
    }
}

viernes, 7 de febrero de 2014

Perla de twitter #1: Michael Bolton, la calidad del software y las expectativas del usuario

Inauguro esta sección de perlas encontradas en twitter con un comentario en tono de humor de Michael Bolton relacionado con la calidad del software y las expectativas del usuario:

 Michael Bolton

Traducción libre: "La conformidad con las expectativas" no es una garantía de calidad. Ejemplo: Yo esperaba que Windows Vista fuese malo; es malo. Expectativa cumplida. #testing

@michaelbolton
https://twitter.com/michaelbolton/status/274974942372691970

sábado, 1 de febrero de 2014

Instalación completa y portable de TestLink 1.9.9 + Mantis 1.2.15

TestLink y Mantis son 2 herramientas libres ampliamente utilizadas de forma independiente y conjunta. La primera es un Gestor de Pruebas y la segunda un Gestor de Defectos.

Ambas son fácilmente instalables mediante el uso de Bitnami:

También pueden ser descargadas individualmente e instaladas en un entorno compuesto por un Servidor Web Apache, base de datos MySQL y PHP:

Sin embargo, sería necesario realizar la integración de ambas herramientas de forma manual y aunque es sencillo, en ocasiones puede presentarse algún problema, como ya comenté en otro artículo.

En el siguiente enlace podéis descargar gratuitamente una instalación completa y portable de TestLink 1.9.9 + Mantis 1.2.15 integradas mediante la interfaz SOAP. También está configurada la interfaz de base de datos por si alguien prefiere esta forma de integración:
https://mega.co.nz/#!M1AGTAgR!oY0PNoeltKIUWJo_z7qoow0zGopwX_bpxx58KxnJdd8

Nota 1: El tamaño del fichero es de aproximadamente 104,1 MB.
Nota 2Se recomienda NO usar esta instalación en un entorno productivo.

El servidor WAMP (Windows + Apache 2.4.7 + MySQL 5.6.15 + PHP 5.4.24) lo proporciona la versión portable 14.1VC9 de la aplicación EasyPHP  DevServer.

La instalación por supuesto, es completamente modificable y configurable para que podáis personalizarla a vuestro gusto.

Para comenzar a utilizar esta instalación sigue los siguientes pasos:
  1. Descarga el fichero .zip
  2. Descomprime el fichero en cualquier carpeta de tu disco duro (o en una memoria USB si lo prefieres)
  3. Ejecuta EasyPHP-DevServer-14.1VC9.exe
  4. Consulta los ficheros "0 - RUTAS.txt" y "0 - USUARIOS y CONTRASEÑAS.txt" para conocer qué debes teclear en tu navegador para acceder a cada una de las aplicaciones y para consultar los datos de los usuarios dados de alta.

Consideraciones a tener en cuenta:
  • El servidor Apache arranca en el puerto 80 pero puedes cambiarlo por otro si lo prefieres.
  • No está configurado el protocolo SMTP de ninguna de las aplicaciones por lo que las alertas o notificaciones por correo electrónico no funcionan por defecto.
  • Si al ejecutar por primera vez EasyPHP-DevServer-14.1VC9.exe aparece un popup preguntándote si quieres regenerar los ficheros de configuración, pulsa "". Al hacer esto se sobreescribe un pequeño cambio en el fichero \binaries\php\php_runningversion\php.ini que es indispensable para que funcione la interfaz SOAP. El cambio consiste en eliminar el ";" situado al comienzo de la línea ";extension=php_soap.dll" para activar la extensión php_soap.
Si os encontráis algún problema para descargar o utilizar estas aplicaciones, no dudéis en preguntarme en los comentarios.

miércoles, 29 de enero de 2014

Características de un buen informe de defecto

Cuando se ejecuta un caso de prueba, si el resultado obtenido no coincide con el resultado esperado, decimos que existe un defecto en el software. Este defecto debe ser descrito en un informe de defecto para que pueda ser corregido por un desarrollador.
Un informe de defecto debe tener (entre otros), los siguientes datos:
  • Un ID único para identificarlo inequívocamente.
  • Un breve resumen del defecto.
  • Una descripción del entorno de pruebas en el que se ha realizado la prueba y su configuración.
  • Versión del software objeto de pruebas.
  • El o los casos de prueba afectados por el defecto.
  • Una descripción de los pasos seguidos hasta llegar al defecto (si es reproducible) y de los datos utilizados. Es importante incluir evidencias (capturas de pantalla, vídeos, sonido, etc.) de cada paso.
  • Su severidad: La severidad está relacionada con el riesgo de negocio que supondría no resolver el defecto. En ocasiones también se relaciona con el impacto que tiene en la continuidad del ciclo de pruebas. Normalmente se establecen 3 ó 4 niveles de severidad. Por ejemplo: Bloqueante, Alta, Media, Baja. Es muy importante que todos los interesados del proyecto tengan muy claros los criterios de asignación de severidades para favorecer la comunicación entre equipos y evitar malentendidos.
  • Su prioridad: La prioridad, que en ocasiones se confunde con la severidad, está relacionada con el riesgo del proyecto; es decir, que la prioridad está muy ligada a la urgencia de resolución del defecto.
  • La descripción de un único defecto: En un informe de defecto no se pueden explicar varios defectos, sólo 1.
  • El resultado esperado: Para evidenciar por qué esperábamos un determinado resultado se pueden utilizar referencias a la base de pruebas
  • El resultado obtenido (incorporando evidencias).
  • La fecha de detección.
  • El tester que lo ha detectado.
  • El desarrollador al que se asigna el defecto.
  • Estado de la incidencia (abierta, asignada, cerrada, etc.).
  • Un registro histórico de los cambios y actualizaciones que sufra hasta su cierre.
  • Cualquier otro dato que ayude al desarrollador a solucionar el defecto. Piensa que cuanto más claro y completo sea el informe, más probable será que el defecto sea resuelto con rapidez.


sábado, 18 de enero de 2014

Técnicas de prueba para Puntos de Decisión

Entre las muchas técnicas básicas de prueba podemos encontrar 5 relacionadas con los puntos de decisión.


Una decisión es un conjunto de condiciones relacionadas mediante operadores matemáticos.

Veamos un ejemplo:
S = (A and B) or (C and D)

  • S es la decisión
  • A, B, C y D son condiciones que pueden tomar 2 valores: 0 y 1
  • and y or son los operadores matemáticos

Las 5 técnicas básicas para probar la decisión S son:

Cobertura de decisión
El objetivo es encontrar el mínimo número de casos de prueba que permita que la decisión tome todos los posibles valores (0 y 1)

En este caso, con 2 casos de prueba (cada fila es un caso de prueba) se puede obtener El 100% de cobertura de condición:

A B C D S
0 0 0 0 0
0 0 0 1 1

Como se puede ver en la tabla anterior, esta cobertura es muy pobre porque apenas se prueba el funcionamiento de cada condición.

El número de casos de prueba necesarios para obtener el 100% de cobertura es n, siendo n el número de posibles salidas.

sábado, 11 de enero de 2014

Los oráculos de prueba y la evaluación heurística

Un oráculo de prueba podría definirse como toda fuente de información que puede utilizarse para determinar el resultado esperado de un caso de prueba.

Una vez que se conoce cuál es el resultado esperado, podemos comparar con él el resultado obtenido para así determinar si el caso de prueba está pasado o fallado.

Un oráculo de pruebas puede ser documentación formal como un catálogo de requisitos, especificaciones funcionales o casos de uso. También puede ser el actual sistema software que va a ser sustituido por el nuevo software a probar, un manual de usuario o el conocimiento de expertos o usuarios del sistema.

Evidentemente, el propio código fuente a probar no puede ser en ningún caso el oráculo de prueba.

En muchos proyectos la documentación es escasa, no contiene el detalle suficiente, está desactualizada, no está disponible en fases tempranas del proyecto o directamente, no existe. Todos estos problemas existen en la documentación relacionada con la funcionalidad del software pero aún más en la documentación de otros atributos de calidad como el rendimiento, la usabilidad o la seguridad.

En estos casos, como ya mencioné en un artículo anterior, el testing exploratorio es fundamental, en concreto, la evaluación heurística.

Los métodos de evaluación heurísticos son útiles pero no pueden aplicarse siempre. Hay que tener en cuenta el contexto del proyecto en el que se aplican y deben utilizarse como una ayuda para encaminar las pruebas no como una guía a seguir de forma estricta paso a paso.

Para realizar una evaluación heurística, al igual que para diseñar casos de prueba a partir de documentación y técnicas de prueba más formales, hay que tener siempre claro que el objetivo final es encontrar defectos y vulnerabilidades en el software a probar.

Para realizar una evaluación de este tipo puede ser útil construir una lista de verificación con puntos a analizar para encontrar problemas en el software. Quizás la lista más conocida es la creada por Michael Bolton y James Bach: FEW HICCUPPS.


Las siglas de este acrónimo significan lo siguiente:
  • Familiarity: Puede resultar muy útil buscar en un software problemas detectados anteriormente en programas similares.
  • Explainability: Si no podemos explicar a otra persona cómo funciona el software o no somos capaces de entender bien una funcionalidad podemos encontrarnos ante un problema de diseño del software.
  • World: El software debería ser consistente con aquello que ya conocemos o con lo que esperamos de él.
  • History: El software debe ser consistente con anteriores versiones de él mismo.
  • Image: El software debe estar en consonancia con la imagen de marca y con el mensaje que desea transmitir.
  • Comparable products: El software debe ser consistente con otros programas del mismo tipo, incluidos los de la competencia.
  • Claims: Los consejos, peticiones, quejas, ideas, etc. de los interesados de un proyecto deben ser tenidos en cuenta en el desarrollo del software.
  • User's expectations: El software debe ser consistente con lo que un usuario puede esperar de él.
  • Product: El software debe ser consistente con otras partes de software del mismo sistema.
  • Purpose: El sistema debe servir para dar respuesta a aquello para lo que se diseñó.
  • Statutes & Standars: El sistema debe cumplir con las leyes, estándares y regulaciones que puedan ser aplicables en cada caso (por ejemplo, la LOPD).

Si se detectan desviaciones al evaluar los puntos anteriores es muy posible que exista un defecto en el software pero no es algo seguro, sólo plausible, porque se ha utilizado una evaluación heurística.

Compartir