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();
         }
    }
}

Compartir