Resumen QA&TEST 2010 (first day)

On 31 octubre, 2010, in Certificación, tutoriales, by twiindan

Ya han acabado las conferencias QA&TEST 2010, la novena edición de estas conferencias sobre Calidad y Testing en Sistemas empotrados.  Han sido 3 días llenos de grandes ponencias y muy interesantes temas de debate dentro y fuera del programa.

Las conferencias comenzaron con dos tutoriales, uno de ellos sobre testing en sistemas operativos en tiempo real por parte de Martin Timmerman y otro sobre entornos ágiles por Tim Korson. Por desgracia no pude dividirme, y solo pude asistir al tutorial de entornos ágiles dodnde Tim Korson intento indicar una seria de pasos y de consejos para integrar un entorno ágil en empresas tradicionales o empresas que estan bajo reguladoras y que necessitán una serie de procesos y documentación para mantener sus certificaciones en CMMI o ISO 9000 aunque también aplicable a otros reguladores como FDA. La verdad muy buenas ideas y comentarios para problemas que generalmente nos encontramos a diario en este tipo de entornos.

Despues de los tutoriales pudimos disfrutar de una gran comida en el propio palacio Euskalduna, excelente menu!

Ya despues de la gran comida vino una de las mejores y más esperadas Keynotes protagonizada por Ross Smith de Microsoft. En esta keynote Ross Smith nos indico una revolucionara forma aumentar la productividad medinte juegos en el trabajo que involucren a varios testers, para ellos explico varios ejemplos que se pusieron en marcha dentro de Microsoft con un gran éxito.

Ya por último asistimos a un par de conferencias, una sobre SCRUM en departamentos de calidad  por Benjamin Jurg y seguidamente otra sobre diferentes  tipos de métricas “optimizadas” por Cenkler Yakin indicando un caso práctico en M&A corporation.

Por último y para acabar la tarde, se realizó una lectura especial realizada por Tom Stokes sobre el lenguaje del “Risk Managegment”. Una controvertida lectura que dio paso a un pequeño debate al finalizar esta sobre los diferentes tipos de riesgo y las diferentes palabras para definirlos.

Un duro día pero lleno de nuevas ideas para estudiar y desarrollar! Mañana explicaremos como fue el segundo día de QA&TEST 2010, tan interesante como el primero!

Tagged with:  

SQL injection cartoon

On 22 octubre, 2010, in Jokes, by twiindan

Os dejo hoy con una divertida viñeta que he encontrado hoy en la página “Quick testing tips” sobre errores de SQL.

Espero que lo disfrutéis!

El próximo día explicare un poco sobre este tipo de vulnerabilidad para que podáis aplicarlo y añadirlo en vuestros tests.

Tagged with:  

Muy interesante el estudio que ha realizado la consultoría Pierre Audoin Consultants (PAC) donde indica un rápido crecimiento en el ámbito del testing de software dentro del mercado de las IT.

Según la consulta, el gasto mundial en calidad y testing actualmente se cifra en unos 79.000 millones de euros, y preveen que crecerá hasta pasar el liston de los 100.000 millones de euros en los próximos 4 años. Esto implicaria un crecimiento en nuestro sector de 26,58 % en los próximos cuatro años.

Para ellos el ámbito del testing se está convirtiendo en uno de los sectores más sólidos de contratación de personal en el sector de las IT durante los últimos años, y preveen que siga siendo asi durante los siguientes años.

Realmente creo que el testing es una disciplina joven, y que aun no ha evolucionado del todo, pero que poco a poco se va desarrollando y se va teniendo más en cuenta en todos los sectores hasta que en muchos de ellos se perciban como algo imprescindible.

Realmente creeis que evolucionará el testing durante estos años, siendo uno de los sectores con mayor crecimiento dentro de las IT? Que creeis que haría falta para que esta evolución se lleve a cabo?

Tagged with:  

Porque existen los errores?

On 12 octubre, 2010, in Articulos, Prácticas desarrollo, by twiindan

Una tarde de viernes, despues de una semana de trabajo y de vispera de puente, con una cerveza, unos cacahuetes y los compañeros del trabajo, que mejor escenario para tener una típica discusión entre developers y testers!

Aunque esta vez de la discusión aprendi un par de cosas que me han hecho reflexionar durante estos dias. En la discusión me comentaba un compañero de desarrollo que efectivamente a medida que un developer va ganando experiencia y aprendiendo, seguramente no necesite un tester para encontrar errores porque casi no los cometera. Como no, a mi me parece un razonamiento imposible ya que un developer como persona humana que es (al igual que un tester) siempre comenterá algún error en su código por muy bueno que sea.

Pero esto me hizo pensar en algo curioso… realmente el único motivo por el cual existimos los testers es porque el departamento de desarrollo hace mal ( o no óptimo)  su trabajo? Es culpable el departamento de desarrollo de todos los errores que encontramos?

Si para ti la respuesta es NO, entonces coincidimos perfectamente y por ese motivo me gustaria hacer una pequeña lista de las razones por las que pueden haber errores en el sistema:

  1. Errores al programar: Es el primero que nos viene a la cabeza y el inicio de la discusión con mis compañeros. Los humanos no somos perfectos y por lo tanto cualquier persona (developers o testers) cometeremos errores dentro del ciclo de vida del software.
  2. Cambios de última hora: Siempre existen, son como una lacra que sabes que tarde o temprano llegarán, son los temidos cambios a dos semanas de entregar una aplicación, unos cambios que en principio no afectan a “nada” y al final afectan a “todo”.  En todos los proyectos existen cambios, y generalmente no se le dan la importancia que merecen ya que muchos de ellos ni siquiera estan planificados.
  3. Errores de terceros: Siempre que utilicemos software de terceras partes como los entornos de desarollo o librerias externas a nuestro proyecto existe la posibilidad de que existan errores no contemplados. Estos errores son heredados por nuestro software y generalmente son dificiles de detectar en las fases de desarrollo.
  4. Errores de comunicación: Para mi la principal fuente de errores ya que esto conduce en parte al punto 2 (cambios de última hora). La comunicación es una de las partes más imporantes dentro del desarrollo del producto y de ella deriivan los requisitos, especificaciones, diseño… Por lo tanto un error de comunicación en algunas fases de proyecto pueden resultar fatales derivando en especificaciones incompletas o erroneas.
  5. Control de versiones: Generalmente otra fuente de problemas provienen del control de versiones de cada uno de los módulos de desarrollo. Aunque existen una gran variedad de aplicaciones o herramientas para realizar esta tarea es fácil que las malas prácticas dentro de desarrollo acaben con una versión antigua de algún módulo o algún componente erróneo.
  6. Malas prácticas de diseño: Otro de los grandes focos de errores, sobretodo en sistemas que son muy complejos o donde se utilizan nuevas tecnologías o nuevas arquitecturas. Generalmente se designa a un solo analista o arquitecto para realizar el diseño de los componentes de software, en lugar de realizar un brainstorming o realizar revisiones de diseño entre arquitectos para detectar errores tempranos.
  7. Malas practicas de codificación: Aun recuerdo el dia que se instauraron en los departamento de desarrollo las guias de buenas prácticas, un poco más y nos cortan el cuello!!! Pero un tiempo despues se ha comprabado que los errores detectados por las malas practicas han disminuido considerablemente, y ahora la gente de desarrollo se han acostumbrado llegando incluso dejar de lado todas sus manias a la hora de codificar o utilizar herramientas de debugging, analizadores, validarores… un buen programador no solo escribe líneas de código si no que las realiza de las mejor manera posible!
  8. Tiempo de desarrollo imposible: He querido dejar este para el último ya que creo que es de los pocos que estamos de acuerdo todos los departamentos. Cuando se planifica un proyecto de software, nunca he visto que se tenga en cuenta realmente el esfuerzo de este ya que generalmente quien lo planifica no sabe lo dificil que es realizar software. Esto se traduce en presión y stress sobre los departamentos de desarrollo, que incomodan a los programadores y les inducen a producir más errores. A parte como hemos comentado anteriormente (en el punto 2) los cambios que se piden desde el cliente en cualquier punto del proyecto muchas veces no se contemplan en la planificación al igual que la resolución de errores.

He nombrado ocho posibles factores a la hora de introducir errores, pero existen una infinidad más ya que miles de factores influyen en el ciclo de vida del software, aun así remarcar que no toda la responsabilidad de la introducción de errores es por parte de desarrollo ni mucho menos, si no que los errores se introducen en todas las fases desde los requerimientos, diseño… hasta los propios testers que como el resto del mundo, tambien somos humanos!(con nuestro corazoncito, y nuestra alma)

Conoceís algunos factores más que puedan influir en la introducción de errores¿?

Cartoon Tester

On 8 octubre, 2010, in Jokes, by twiindan

Hace ya tiempo que sigo un blog de testing bastante curioso la verdad, ya que no es el típico blog con articulos sobre testing unicamente si no que el creador Andy Glover intenta darle un poco de humor a nuestro día a día con chistes o viñetas, que va realizando para endulzar un poco esta disciplina.

Aquí os dejo una de las que más me ha gustado y que justamente tuve la suerte de poder corroborar ayer mismo en mi trabajo (un bug muy grande atrajo a una marabunta de developers curiosos y escepticos). Espero que os guste, y no dejéis de seguir el blog de Andy Glover para sonreir de vez en cuando!

Podéis ver el resto de las viñetas creadas por Andy aquí.

Tagged with:  

QA&TEST 2010

On 7 octubre, 2010, in Conferencias, by twiindan

A finales de este mes se celebran las 9ª conferencias internacionales sobre Testing y Calidad de Software de QA&TEST 2010 en el “Palacio de Congresos y de la Música Euskalduna Jauregia, exactamente los días 27-29 de Octubre.

La conferencias existe con la intención de difundir los últimos avances y desarrollos tecnológicos en Testing y Calidad de Software en los sistemas embedidos y mostrar las prácticas exitosas para ayudar a las empresas a tomar parte en los mercados de forma más conpetitva. Las conferencias estan dirigidas a directores o jefes de proyecto, profesionales del testing o ingenieros de Calidad.

Entre los conferenciantes podemos encontrar gente como Paul Baker de Motorola, Ross Smith deMicrosoft o Micael Stahl en Intel. A parte tambien podrán contar con un servidor que realizará la conferencia el día 28  a las 16:00 “Creating VV&T and QA software departments in a medical company

Espero veros por allí!

Podéis encontar el programa completo aquí.

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: