viernes, 18 de marzo de 2016

Técnicas de Estimación de Pruebas - Test Case Point Analysis

Uno de los primeros retos a los que se enfrenta un Test Manager al inicio de un proyecto es realizar una buena estimación de tiempos.

Existen multitud de técnicas de estimación de pruebas, pero su precisión depende siempre (en mayor o menor medida) de la experiencia previa y de la capacidad y conocimientos del equipo.

ISTQB, por ejemplo, propone 3 técnicas de estimación:


  1. Estimación experta. Esta técnica consiste en:
    • Identificar todas las tareas a ejecutar (normalmente utilizando un enfoque descendente (“top down”)).
    • Obtener estimaciones para cada tarea por los responsables (de su ejecución) o por expertos.
    • Sumar todos los valores de las tareas. Incluir los factores de corrección (si hay experiencias respecto de la exactitud de ciertos estimadores).
    • Incluir elementos amortiguadores (buffers)/elementos adicionales, con el objeto de cubrir tareas omitidas o subestimadas.

  2. Estimación basada en analogías. Esta técnica consiste en:
    • Clasificar las tareas de pruebas requeridas.
    • Buscar un proyecto que se haya desarrollado en el pasado que contenga una tarea similar a una específica .
    • Utilizar el esfuerzo real de esta tarea como base de la estimación.
    • A través del uso de métricas (líneas de código, número de módulos, número de casos de prueba, etc.) como base, calcular el valor de la estimación total.
    • Considerar factores de corrección.

  3. Estimación basada en porcentajes. Esta técnica consiste en:
    • El esfuerzo para las actividades de pruebas se estiman sobre la base de la totalidad de las actividades del proyecto.
    • El valor del porcentaje requiere ser determinado basándose en la experiencia.
    • La estimación basada en porcentajes no tiene en cuenta el esfuerzo de las pruebas de regresión, que pueden ser una parte sustancial de las pruebas de mantenimiento y asociadas a cambios.
Actualmente, existen otras técnicas de estimación que encajan mejor con las metodologías ágiles como SCRUM, por ejemplo el Planning Poker.

También hay técnicas muy elaboradas que tienen en cuenta multitud de factores, como el TPA (Test Point Analysis) de Sogeti.

En la línea del TPA se encuentra la técnica de TCPA (Test Case Point Analysis). En internet disponéis de múltiples propuestas de aplicación de esta técnica, como por ejemplo las de:
  1. QA Symphony
  2. Cognizant
  3. Priya Chaudhary y C.S. Yadav
Evidentemente, todas estas aplicaciones cuentan con muchas similitudes, pero también tienen diferencias, como los factores a considerar, los pesos de dichos factores, las actividades de pruebas contempladas, etc.

A continuación, propongo un modelo de aplicación del TCPA que aglutina elementos de las referencias anteriores.

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

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:


Compartir