Muchas veces dudamos si automatizar o no automatizar unas pruebas ya que no sabemos si el coste de la automatización va a ser mayor que las pruebas manuales, es aquí donde nace el dilema de la automatización de pruebas.

He asistido a varias ponencias respecto a este tema y casi todas están enfocadas a temas como el retorno (ROI), pero muchas veces no disponemos de tiempo o de datos suficientes para poder realizar una estimación profunda para saber si será rentable económicamente hablando (recordad que el tiempo es dinero!).

Normalmente cuando intento decidir si merece la pena automatizar o no y no tengo tiempo suficiente para poder analizarlo en profundidad utilizo la siguiente checklist para tener una aproximación:

  1. Cuantas veces debe ejecutarse el caso de prueba (cada cuanto hay una versión, cuantos test de regresión o de sistema se realizan anualmente…)
  2. Es un módulo muy variable? Hay cambios en esa parte del componente en el corto/medio plazo?
  3. Cual es el coste de ejecucción manual (preparación y ejecucción).
  4. Que precisión necesita la prueba.
  5. Coste de la automatización (tiempo, herramienta y persona).
  6. En que mejora la automatización de la prueba (se pueden realizar más verificaciones simultaneamente?)
  7. Que resultados me genera la prueba automática? Son importantes?
  8. Que complejidad tendrá la prueba automatica? Será mantenible?

A mi personalmente me ayuda bastante realizarme la mayoria de estas preguntas cada vez que dudo en automatizar o no realizarlo, sobretodo las 5 primeras. Lo importantes siempre es tener en cuenta hasta que punto interesa automatizar o no las pruebas para no realizar esfuerzos innecesarios!

Y tu? Eres de lo que automatiza cualquier tipo de prueba? O eres de los que prefiere un test manual?

Tagged with:  

Logging para Junit

On 22 junio, 2010, in Consejos, by twiindan

El otro día vi como se estaban peleando los desarrolladores con unos Test Unitarios hechos en Junit que no entiendian porque fallaban y se excusaban en que no tenían ningún log cuando los desarrollaban.

Empece a pensar un poco, y llegue a la conclusión que al fin y al cabo Junit no deja de ser código java puramente y que por lo tanto se podría utilizar igualmente la librería que utilizamos para el desarrollo de la aplicación log4j.

Dentro del frameework de Log4j está el concepto de “Appenders” donde se le indica el destino en el que se escribirán las trazas de log (consola, fichero de texto…). En nuestro caso, estos Appenders se configuran durante la inicialización de la aplicación, por lo que en los tests unitarios se debería inicializar en algo parecido.

Para ello dependiendo de nuestra arquitectura de Test Unitarios de Junit podemos optar por varias opciones:

  • Si queremos inicializar el log para un test o varios en particular hay que realizar la llamada desde los métodos “setUp” y realizar un logging shutdown en el método “tearDown”:

public void setUp() {
BasicConfigurator.configure();
}

public void tearDown() {
LogManager.shutdown();
}

  • Si tenemos los tests en Test Suites lo mejor será que inicialicemos los logs en un método de inicialización @beforeclass:
public class AllTests {
    @BeforeClass
    public static void startup() {
        BasicConfigurator.configure();
    }
}

Yo personalmente prefiero la segunda opción ya que de esta manera podemos ejecutaremos la inicialización de los logs una única vez y siempre antes de la ejecucción de los tests, por lo que no tendremos problemas de encontrarnos código duplicado.

Tagged with:  

EuroStar 2010 invita a tu grupo de Test

On 18 junio, 2010, in Conferencias, by twiindan

Os gustaría a ti y al resto de tu equipo ir al EuroStar 2010 pero no tenéis entrada?

Para todos aquellos que realmente sientan pasion por el testing Eurostar ha lanzado un pequeño concurso para que puedan acceder a las mayores conferencias de Calidad y Testing de Europa.

Para ello solo tenés que realizar un video tu y tu equipo de dos minutos como mínimo en el que debéis indicar porque os gustaría ir y demostrar vuestra pasión y talento por la calidad y el testing de sotware.

Una vez realizado el vídeo debes subirlo a Youtube y envíar un correo a Kevin@eurostarconferences.com indicando el video que habéis subido.

Los ganadores del concurso recibirán 4 entradas para acceder a las conferéncias EuroStar de Cophenague de este año y el video será publicado en la página principal de las conferéncias.

Tagged with:  

Requisitos SMART

On 17 junio, 2010, in Definiciones, requerimientos, by twiindan

Ya comentamos hace unos días que una parte muy importante del desarrollo de un producto de sofware son los requerimientos.

En esta primera fase es donde se define que es lo que el cliente quiere exactamente, y a partir de estos se realizará el análisis, diseño, codificación y pruebas. Por este motivo es tan importante tener unos requisitos muy bien especificados y sin ambiguedades.

Es por ese motivo que se definió la metodología SMART para los requisitos. SMART son las siglas de las características que debe de tener un requerimiento:

  • Specific: Los requerimientos deben de de ser lo más claros posibles, sin ningún tipo de ambigüedad y sin posibilidad de libre interpretación.
  • Measurable: Debe poder ser medido o verificado. Se han de poder definir pruebas para verificarlo.
  • Attainable: El requisito debe ser accesible y realista, debe tener unos objetivos técnicos alcanzables.
  • Realisable: Cada uno de los requerimientos debe ser realizable con los recursos disponibles.
  • Traceable: El requerimiento debe poder trazarse con todo el proceso de desarrollo (análisis, diseño, codificación i pruebas).

Generalmente la mayoría de errores se introducen durante el diseño de los requerimientos, por ese motivo es muy importante crear unos requisitos de calidad.

Tagged with:  

Generar Datos para pruebas

On 17 junio, 2010, in Herramientas, by twiindan

El otro día para realizar unas pruebas necesitaba una gran cantidad de datos que debia generar y que logicamente no tenia.

Estube buscando con el dios Google algún listado o Base de Datos que pudiera cargar para poder realizar las pruebas, pero finalmente no encontre nada de mi interés, aunque encontre algo mucho mejor, la página “Generate Data“.

La página nos ofrece cerar una cantidad de datos aleatorios (hasta 5000) en varios formatos: HTML, EXCEL, XML, CSV o SQL.

Entre los datos que podemos generar se encuentran los más comunes como Nombres, telefonos, mails, ciudades, códigos postales… a parte también nos permite generar datos con un número fijado o aleatorio de palabras o personalizar la la generación de datos para generar datos incrementales, dentro de unos rangos o algunas listas.

Una de las grandes funciones que tiene es crearte la query para crear y realizar los inserts necesarios en una BBDD y facilitar de esta manera la introducción de datos en una BBDD.

El script se puede descargar y esta bajo licencia GNU open source.

Espero que os sirva de ayuda!

Tagged with:  

Matriz de Trazabilidad

On 15 junio, 2010, in Definiciones, requerimientos, by twiindan

Durante el ciclo de vida del desarrollo de software de un proyecto existen dos fases muy importates como son la definición de requisitos o especificaciones y el diseño y ejecucción de pruebas.

Cuando el proyecto es muy grande o complejo es difícil poder saber que test ejecutados o diseñados cubren cada una de las especificaciones o requerimientos del proyecto.

Es por este motivo que existe lo que se conoce como la matriz de trazabilidad.

La matriz de trazabilidad es una herramienta que se utiliza para saber que requerimientos quedan cubiertos por una prueba. Veamoslo con un secillo ejemplo.

Imaginemos que tenemos un proyecto con 5 requerimientos (R1-R5) y hemos diseñado tres casos de prueba (T1-T3).

  • El caso de prueba T1 cubre los requerimientos R1 y R4
  • El caso de prueba T2 cubre los requerimientos R3 y R5
  • El caso de prueba T3 cubre el requerimiento R3

En este caso la matriz resultante será:

T1 T2 T3
R1 X
R2
R3 X X
R4 X
R5 X

Viendo la matriz podemos ver claramente dos cosas:

  1. El requerimiento R3 está probado en 2 casos de prueba.
  2. El requerimiento R2 no está cubierto.

Gracias a estos datos podemos ver que partes o módulos del software no están cubiertos y deberían probarse por otras pruebas o identificar los requerimientos más críticos para saber si están suficientemente cubiertos (más de un caso de prueba es diseñado y ejecutado para ese requerimiento).

También podemos identificar los casos de prueba que han fallado y a partir de ahí ver que requerimiento esta en riesgo para poder evaluar la criticidad y el riesgo de este.

Preparado para aprobar el ISTQB?

On 15 junio, 2010, in Certificación, by twiindan

Tienes pensado realizar la certificación ISTQB Foundations?

Quieres practicar con preguntas reales del examen?

No estas seguro si aprovarías el examen en caso de hacerlo?

Si has respuesto con una afirmación a algunas de las tres preguntas anteriores, puedes realizar examenes de prueba en la web de Quality Testing.

Quality testing es una red social para la comunidad internacional de testing. Nacio en el 2008 y ha conseguido reunir a más de 2000 personas.

Cuenta con varios foros, blogs, trabajos, noticias y eventos que proporcionan a los testers una gran fuente de información para su profesión.

A parte cuenta con 10 tests del ISTQB para que puedas practicar antes de presentarte a la certificación oficial.

Accede a los tests aquí.

Tagged with:  

Automated Software Testing Magazine

On 14 junio, 2010, in Revistas, Sin categoría, by twiindan

El Automated Testing Institute ha publicado el segundo número la revista “Automated Software Testing”.

Esta revista,esta dedicada completamente a temas de automatización de test, tanto a nivel de creación de un framework o automatización de pruebas con software Open Source.

Muy interesante el articulo sobre testeo de aplicaciones de voz “The sound of automation”.

La revista es totalmente gratuita de forma online y podéis descargarla de aquí.

Tagged with:  

Un grupo de hackers de Goatse Security han informado de un problema descubierto en las redes de AT&T que ha permitido acceder a las cuentas de correo electrónico de los poseedores de un iPad 3G de Apple. AppleAt&T

En concreto se trata 114.000 usuarios de los cuales han podido acceder a la dirección de correo electrónico aunque no han podido entrar en las cuentas de estos.

Entre los afectados se encuentran celebridades militares y políticas como el Alcalde de Nueva York o el CEO de New York Times.

Fallos de seguridad como este que ponen en compromiso datos importantes de los usuarios, han de ser considerados como muy graves ya que daña potencialmente al nombre de las empresas, en este caso Apple y AT&T y las pérdidas pueden llegar a ser millonarias.

Esperemos que todo se haya quedado en un susto y la próxima vez se realicen pruebas de seguridad mucho más exhaustivas.

Mas información aquí.

Tagged with:  

El Test Driven Development es una práctica de programación con una filosofía muy diferente al desarrollo de software de toda la vida.

En el Test Driven Development lo que se realiza primero de todo no es el diseño del código sino las pruebas basadas en las especificaciones y requisitos. Una vez implementada la prueba, se realiza el código necesario para que esta prueba funcione correctamente realizando los refactorings necesarios para ello.

El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione. La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.

De esta manera conseguiremos un código enfocado a éxito, mucho más robusto y mantenible debido a que las pruebas obligan a desarrollo a reflexionar sobre el comportamiento del código y ha garantizar que el código funcione sobre pruebas diseñadas anteriormente.

Una de las ventajas que se obtienen directamente es la temprana detección de introducción de código que genera errores en otras partes de código, facilitando de esta manera la integración de los diversos módulos del software.

El ciclo de desarrollo con TDD quedaría de la siguiente manera:

  1. Definir especificaciones y requisitos
  2. Escribir la prueba: Escribir el caso de prueba según las especificaciones creadas en el paso anterior. El diseño de la prueba debe contemplar y cubrir todos los escenarios y condiciones posibles.
  3. Escribir el código para la prueba: Se debe escribir el código necesario para todos los casos de prueba que se han definido anteriormente. De esta manera nos aseguramos que el código se realice para las especificaciones definidas anteriormente
  4. Ejecucción de las pruebas: Se realiza la ejecucción de las pruebas diseñadas sobre el código. En caso fallo o que no se cumplan todas las condiciones de prueba se debe reescribir el código para que se cumplan las pruebas y especificaciones.
  5. Refactorización: Una vez han pasado todas las pruebas se realiza un proceso de refactorización para poder optimizar las pruebas y el código. Normalmente a medida que realizas las pruebas se ocurre nuevo código y viceversa. Se han de realizar varias iteraciones para optimizar el desarrollo al máximo.

Gracias a todo este proceso podemos asegurar un sistema robusto y con un mínimo número de fallos en nuestra aplicación.

Tagged with: