VLC Testing 2014

On 20 octubre, 2014, in Conferencias, by twiindan

Ya se ha anunciado la programación de la edición anual de las conferencias VLC Testing 2014 organizado por el ITI (Instituto Tecnológico de Informática) y hay que reconocer que este año ha vuelto con mucha energía y con un gran programa donde se podrán ver conferencias de varios temas sobre la calidad de software.

En esta ocasión las conferencias tendrán lugar durante dos días, 12 y 13 de Noviembre en la ciudad de Valencia.

Las conferencias se centraran en esta ocasión en ponencias de carácter práctico relacionados con la calidad del software y el testing incluyendo testimonios, ejemplos, demostraciones, lecciones aprendidas, aplicación de técnicas, uso de herramientas, buenas prácticas, entre otras.

Este año han cambiado los horarios y el primer día estará dedicado a los seminarios mientras que el segundo se centrara en las conferencias y en el evento de networking TrobaTest.

Los seminarios estarán enfocados en varios temas de interes, como son BDD, prototipado, automatización, calidad interna o testing en mobiles. Los seminarios son sesiones de 1h y 30 minutos donde se profundizará mucho más en estos temas, y están pensados para que sean mucho más prácticos y participativos que las conferencias.

Durante el segundo día se realizaran las conferencias, donde me gustaría destacar temas como la gamificación que presentará Antonio Calero, varias conferencias sobre automatización y sobre testing de seguridad.

El precio es de 100 euros solo el día de conferencias y de 180 los dos días. SoftQATest dispone de cupones de descuentos del 25 % para todos los interesados en asistir!

Más información en la web de VLCTesting

Tagged with:  

Muchas veces la gente de QA y de Testing juegan al poli malo y mediante metricas, numeros y KPIs “echamos la bronca” (en sentido figurativo) a la gente de desarrollo por realizar más las cosas. Somos especialistas en obtener numeros del Sonar y indicar a la gente de desarrollo que tiene mucho codigo duplicado, que no cumple las reglas del Checkstyle o que no ha documentado suficientemente bien el código.

Nos encanta dar consejos de como deberían programar para ser más efectivos y sacar un software de mejor calidad, nos encanta recomendar algunas buenas prácticas que hemos leido o hemos visto que han funcionado en otros proyectos y por supuesto nos hace felices saber que estamos ayudando cada día a que la gente de desarrollo programe mejor y con más calidad.

Esto creo que es una práctica muy útil que debemos seguir haciendo, ya que ofrecemos un punto de objetividad que quizás dentro del equipo de desarrollo es más complicado de ver. Pero la pregunta es… ¿Porque no nos aplicamos a nosotros mismos las mismas practicas?

Personalmente creo que es muy importante que tratemos nuestro trabajo como si se tratara del de desarrollo. Que quiero decir con esto? Pues principalmente dos puntos:

  • Tratar nuestros diseños o nuestros tests cases como si de código se tratara. Es decir, si vamos a realizar un mismo procedimiento de test con varios juegos de datos, porque no utilizamos una estrategia de DataDriven en lugar de replicar todo el procedimiento? Si como prerequisito dentro de un test case tenemos un procedimiento de un Test Case anterior, porque no lo referenciamos o lo linkamos directamente en lugar de reescribirlo? Realmente es necesario tener TCs de varias hojas o Prerequisitos de más de media página?
  • Tratar los tests automáticos como si se tratara de código fuente. Porque nos resistimos tanto en subirlos a un sistema de versionado? En el caso de que esten automatizados en un lenguaje de programación, también deberíamos pasarles exactamente los mismos procesos de métricas que el código fuente y actuar al respecto. Otro buen ejemplo puede ser crear objetos reutilizables para no crear código duplicado dentro de la automatización.

Que ganamos realmente jugando con otras reglas? Primero de todo, desconfianza de la gente de desarrollo, ya que si algo es bueno, debe ser bueno para todos no solo para algunos. Segundo más trabajo de mantenimiento y tercero provocar que seguir haciendo las cosas mal por nuestro lado.

En mi caso, hace unos 4 mes aproximadamente tuve que realizar cambios en casi todos mis tests automaticos por no haber utilizado elementos reutilizables… por lo que tenia el código duplicado una cantidad innombrable. El resultado, me costo 1 semana entera adaptar los tests automáticos. Eso si aprendi la lección y aproveche que tenía que rehacer más del 60 % de los tests para construir elementos reutilizables para no tener tanto código duplicado. Hace 15 días me volvieron a cambiar una estructura que me hacía fallar el 60 % de los tests aproximadamente. Me costo adaptarlo 4 horas, por lo que tarde un 10 % de la primera vez.

Otro ejemplo práctico, en el tiempo que mi equipo de desarrollo ha realizado tres mini periodos de refactoring (aproximadamente 3 días cada uno de ellos), yo solo he realizado uno a mis tests que no supero un día! Lo que me hace pensar… realmente soy tan bueno que no necesito refactorings? O es que realmente no le doy la suficiente importancia en mis tests a la refactorización?

Esto son solo unos pequeños ejemplos al respecto, ahora también obligo al equipo de desarrollo a que para cerrarme la tarea de la implementación de los tests se asegure que los he subido al sistema de versionado y que tenga una etiqueta, de esta manera tenemos todo un poquito más controlado.

Y vosotros, aplicáis las mismas reglas a la gente de desarrollo que a vosotros mismos? Utilizáis los mismos criterios? Que procedimientos seguis para comprobar la calidad de vuestros tests?

Tagged with:  

Cronica DebaTEST

On 5 julio, 2011, in Eventos, by twiindan


El pasado día 30 de Junio la Asociación TestQA organizo el primer evento DebaTEST orientado a debatir sobre un tema en particular dentro de la calidad y el testing y simultanamente hacer networking.

El evento transcurrio de 19.00 a 21.30 de la tarde aproximadamente en el bar “El gran Foc” y se hablaron de varios temas relacionados con la automatización de testing y todo lo que le rodea. EL debate fue dirigido por uno de los miembros de la asociación y contaba con varios expertos sobre automatización en diferentes niveles.

Podéis leer una crónica completa y ver las fotos del evento en la página de la asociación TestQA:

 

 

Tagged with:  

DebaTEST sobre automatización

On 15 junio, 2011, in Eventos, Herramientas, by twiindan

Desde la asociación TestQA se ha iniciado un nuevo evento llamado DebaTEST, creado para realizar debates sobre un tema en particular.

En esta primera ocasión el tema que se tratará será Automatización de Tests. Para ello se contará con la colaboración de varias personas del mundo de la calidad y del testing con experiencia en varios campos de la automatización como la implantación de herramientas, la automatización funcional o las pruebas de carga.

El evento se realizará el día 30 de Junio en el bar “El gran foc” a las 19.00 de la tarde y es totalmente gratuito.

Si queréis asistir solo tenéis que apuntaros en la página oficial de TestQA de forma limitada.

 

Tagged with:  

Resumen QA&TEST 2010 (second day)

On 1 noviembre, 2010, in Conferencias, by twiindan

Despues de un muy buen comienzo de las jornadas, llego el segundo día con unos contenidos igual de interesantes que el primer día.

El día empezo con la Keynote de Tammy Noergaard donde explico los principales errores que cometemos dividido en varios niveles, desde errores que se producen por parte de planificación o dirección (como no tener en cuenta los deadlines a la hora de planificar, o escoger el lenguaje de programación correcto a la hora de diseñar y programar la aplicación, o no definir la estrategia de testing desde el primer día). Una keynote muy instructiva donde se nos recordaba errores que siempre cometemos y que conviene siempre tener presentes (creo que me haré una lista y la colgaré en mi sitio para no volverlos a cometer).

Seguidamente se realizaron varias presentaciones dentro de dos tracks (Testing Safety Critical Systems y Requirment Management). Dentro del primero destacar la conferencia sobre análisis estático, y varios problemas o errores que pueden surgir si este no se realiza.  También una gran presentación por parte de Bryan Bakker sobre diseño de tests automáticos emfatizando sobretodo la parte de test de integración, generalmente otro tipo de testing un poco olvidado (por lo menos en mi organización).

Despues de todo esto un descanso bien merecido y una gran comida a base de varios pescados en el restaurante del Palacio de Euskalduna.

Ya con el estomago lleno, volvian las conferencias de nuevo con dos tracks diferentes (People in Software Testing y Testing Techniques & Testing Proccess). Yo me tuve que quedar en la primera de ellas ya que mi conferencia estaba en este track.  Muy destacable el toque de humor de Tony Simms a la hora de narrar los diferentes problemas que podia tener un project manager y que generalmente no tenemos en cuentaa. Seguidamente una descafeinada presentación en la que estaba totalmente de los nervios! Despues de todo este tiempo, fue el momento, 40 intensos minutos donde explique las funciones que se realizan dentro de Diagnostic Grifols, por suerte los nervios se fueron poco a poco y en general la gente por lo menos no se dormia. Una vez ya finalizado, 2 preguntas (una de ellas con un poco de mala leche) y un gran aplauso por la presentación!

Para acabar la jornada se realizó un interesante debate donde hubo varios temas centrales como las metodologias ágiles o las certificaciones, dos temas muy candentes actualmente.

ya acabada la jornada, muchas preguntas sobre varios procesos de mi presentación por parte de varias personas y a descansar al hotel.

Ya por la noche una interesante cena de gala donde los organizadores nos regalarón un buen menu y unas cuantas copichuelas en un bar de copas, lo ideal para soltarse un poco más la lengua y acabar de perfeccionar el ingles! Eso si, no muy tarde a dormir que aun faltaba el tercer día!

Despues de un merecido descanso volvemos a la carga!

Hoy vamos a realizar un pequeño tutorial sobre como habilitar aplicaciones Flex para que puedas ser testeadas mediante la herramienta IBM Rational Functional Tester 8.1.1 (RFT).

Para poder testear aplicaciones realizadas en Flex mediante la herramienta se pueden realizar dos métodos:

  • Compilando la aplicación con las librerias de automatización de Adobe Flex y las librerias de RFT.
  • Mediante un cargador en el tiempo de ejecucción

En este caso me voy a centrar en la solución que he adoptado en mi trabajo que es mediante la compilación con las librerias necesarias.

Para poder habilitar Flex debemos seguir los siguientes pasos:

1. Compilación del software por parte de desarrollo con las librerias de automatización de adobe flex y de rational functional tester:

  • automation.swc
  • automation_agent.swc
  • automation_charts.swc
  • rftFlex3.0.swc
  • rftProp_Flex3.0.swc

2. Para ello se puede pediar a desarrollo que lo haga por uno de los siguientes métodos (o por los dos conjuntamente)

  • Mediante el archivo flex-config.xml que deberia quedar así:

</include-libraries>

<library>/libs/automation.swc</library>
<library>/libs/automation_charts.swc</library>

<library>/libs/automation_agent.swc</library>
<library>/libs/ rftFlex3.0.swc </library>

<library>/libs/ rftProp_Flex3.0.swc </library>
</include-libraries>

  • Mediante los argumentos opcionales del compilador, donde la linea de argumentos será:

-Include-libraries “<flex builder install dir>\libs\automation.swc” “<flex builder install dir>\libs\automation_agent.swc” “<flex builder install dir>\libs\automation_charts.swc” “<flex builder install dir>\libs\rftFlex3.0.swc” “<flex builder install dir>\libs\libs\rftProp_Flex3.0.swc”

3. Una vez finalizada la compilación por cualquiera de los métodos mencionados estarán disponibles para testing el archivo flash (swf) y un wrapper html que apuntará al archivo flash (por ejemplo index.swf y index.html)

4. Habilitamos los navegadores (Internet Explorer o Mozilla Firefox)

1. Internet Explorer

i. Menu Herramientas à Opciones de Internet

ii. Pestaña seguridad

iii. Elegimos la zona de contenido (internet o intranet dependiendo donde tengamos nuestra aplicación de pruebas)

1. Intranet local

a. Añadimos nuestra web en sitios de confianza (por ejemplo localhost:8080)

b. Pulsar en nivel personalizado y poner en nivel Medio-bajo.

c. En el panel de valores pulsar sobre Habilitar para Inicializar y crear scripts de controles ActiveX no seguros

d. Aceptar

2. Mozilla Firefox

i. Menu Herramientas à Opciones à Contenido

ii. Quitar el recuadro de selección de Bloquear ventanas Emergentes

iii. Menu Herramientas à Opciones à Seguridad

iv. Quite el checkbox del recuadro de selección Avisarme cuando los sitios intenten instalar complementos.

5. Añadir la aplicación flex como fiable para poder ejecutarla:

1. Cree una carpeta FlashPlayerTrust en C:\WINDOWS\system32\Macromed\Flash.

2. Cree un archivo denominado Flex sin ninguna extensión de archivo en la carpeta FlashPlayerTrust.

3. Especifique la vía de acceso al directorio de la aplicación Flex en el archivo Flex. Por ejemplo, si la aplicación Flex está en el directorio C:\Test, escriba la vía de acceso en el archivo Flex como C:\Test.

4. Guarde el archivo.

6. Configurar dentro de IBM RFT los entornos y la aplicación:

1. Configurar à Habilitar entornos para prueba

2. Habilitar el JRE necesario y el navegador que se va a utilizar.

3. Configurar à Configurar aplicaciones para prueba

4. Añadir

5. Seleccione aplicación Flex

6. Introducir la URL que se quiere probar (http:localhost:8080/index.html)

Una vez realizados todos estos pasos ya podremos lanzar nuestra aplicación desde RFT y empezar a grabar los scripts necesarios para ejecutarlos posteriormente.

Espero que os haya sido de ayuda!

  1. Para ello se puede pediar a desarrollo que lo haga por uno de los siguientes métodos (o por los dos conjuntamente)
                                                          i.      Mediante el archivo flex-config.xml que deberia quedar así:

<include-libraries>
<library>/libs/automation.swc</library>
<library>/libs/automation_charts.swc</library>

<library>/libs/automation_agent.swc</library>
<library>/libs/ rftFlex3.0.swc </library>

<library>/libs/ rftProp_Flex3.0.swc </library>
</include-libraries>

   
  1. Compilación del software por parte de desarrollo con las librerias de automatización de adobe flex y de rational functional tester:
1.    automation.swc
2.    automation_agent.swc
3.    automation_charts.swc
4.    rftFlex3.0.swc
5.    rftProp_Flex3.0.swc

  1. Para ello se puede pediar a desarrollo que lo haga por uno de los siguientes métodos (o por los dos conjuntamente)
                                                          i.      Mediante el archivo flex-config.xml que deberia quedar así:

<include-libraries>
<library>/libs/automation.swc</library>
<library>/libs/automation_charts.swc</library>

<library>/libs/automation_agent.swc</library>
<library>/libs/ rftFlex3.0.swc </library>

<library>/libs/ rftProp_Flex3.0.swc </library>
</include-libraries>

                                                      ii.      Mediante los argumentos del compilador. La linea de argumentos seria en este caso:
-Include-libraries "<flex builder install dir>\libs\automation.swc" "<flex builder install dir>\libs\automation_agent.swc" "<flex builder install dir>\libs\automation_charts.swc" "<flex builder install dir>\libs\rftFlex3.0.swc" "<flex builder install dir>\libs\libs\rftProp_Flex3.0.swc"

  1. Desarrollo nos proporcionara el archivo swf compilado y el wrapper html que apunta al archivo flash (por ejemplo index.swf y index.html)
  2. Habilitar el entorno de prueba

i.      Valores del navegador

1.      Internet Explorer

a.       Menu Herramientas à Opciones de Internet

b.      Pestaña seguridad

c.       Elegimos la zona de contenido (internet o intranet dependiendo donde tengamos nuestra aplicación de pruebas)

i.      Intranet local

1.      Añadimos nuestra web en sitios de confianza (por ejemplo localhost:8080)

2.      Pulsar en nivel personalizado y poner en nivel Medio-bajo.

3.      En el panel de valores pulsar sobre Habilitar para Inicializar y crear scripts de controles ActiveX no seguros

4.      Aceptar

2.      Mozilla Firefox

a.       Menu Herramientas à Opciones à Contenido

b.      Quitar el recuadro de selección de Bloquear ventanas Emergentes

c.       Menu Herramientas à Opciones à Seguridad

d.      Quite la marca del recuadro de selección Avisarme cuando los sitios intenten instalar complementos.

ii.      Añadir la aplicación como fiable para ejecuatarla

1.      Cree una carpeta FlashPlayerTrust en C:\WINDOWS\system32\Macromed\Flash.

2.      Cree un archivo denominado Flex sin ninguna extensión de archivo en la carpeta FlashPlayerTrust.

3.      Especifique la vía de acceso al directorio de la aplicación Flex en el archivo Flex. Por ejemplo, si la aplicación Flex está en el directorio C:\Test, escriba la vía de acceso en el archivo Flex como C:\Test.

4.      Guarde el archivo.

iii.      Dentro de IBM RFT

1.      Configurar à Habilitar entornos para prueba

2.      Habilitar el JRE necesario y el navegador que se va a utilizar.

3.      Configurar à Configurar aplicaciones para prueba

4.      Añadir

5.      Seleccione aplicación Flex

6.      Introducir la URL que se quiere probar (http:localhost:8080/index.html)

ii. Mediante los argumentos del compilador. La linea de argumentos seria en este caso:

-Include-libraries "<flex builder install dir>\libs\automation.swc" "<flex builder install dir>\libs\automation_agent.swc" "<flex builder install dir>\libs\automation_charts.swc" "<flex builder install dir>\libs\rftFlex3.0.swc" "<flex builder install dir>\libs\libs\rftProp_Flex3.0.swc" 
 

Tagged with:  

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:  

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: