ExpoQA ha vuelto!

On 29 febrero, 2012, in Conferencias, by twiindan

 

 

 

 

 

 

Después de un año de parón, NexoQA ha lanzado el programa de EXPOQA 2012!

Este año el evento se realizará los días del 4-7 de Junio en el Hotel Auditorium (dentro del Centro de Congresos Principe Felipe).

Durante el primer día se realizará un taller “Hands On” pendiente aun de definir y esponsorizado por HP.

El segundo día se dedicará a tutoriales, donde podemos elegir entre cuatro posibles que durarán una jornada completa. Entre los tutoriales podemos encontrar el de “Testing ágil efectivo”, “Como utilizar historias de negocio en el testing de requisitos y sistemas”, “Pruebas de rendimiento” y “El testing como medio para conseguir el beneficio del negocio”.

Los días 5 6 y 7 se dedicarán a las conferencias que se han dividido en 3 tracks paralelos y por tematicas (Técnicas de pruebas, El futuro de nuestra profesión, Procesos y metodologías, Testing de moviles, Agile Testing, Herramientas y automatización y pruebas no funcionales).

Como conferenciantes destacar la participación de Fran O’Hara, experto en Agile Testing y en metodologías o Andy Glover (conocido como Cartoon Tester). A parte también podréis contar con mi participación en una conferencia sobre Agile Testing el día 7 de Junio!

Recordar que las conferencias son en ingles o español y que contaran siempre con traducción simultánea al otro idioma lo que facilitará las cosas a los oyentes que no dominen completamente el ingles.

Los precios varían entre los 280 € (un dia de conferencia) hasta los 950 € (Tutoriales y conferencias) aunque solo hasta el 4 de Abril! Igualmente ExpoQA ofrece descuentos para grupos, estudiantes, profesores y parados de hasta el 50 %!

 

 

Tagged with:  

Una de las excusas que ha utilizado mucha gente durante años para utilizar software propietario, era asumir que el código tenia una calidad superior a la del código Open Source. Parece ser que la gente tenia una percepción de que contra más cuesta un producto mejor era (aplicable a otras muchas cosas de la vida).

Este mito acaba de ser desmontado por un informe realizado por Coverity el cual es la tercera edición pero la primera con software propietario que se ha cedido de forma anónima.

El estudio se basa en el análisis de código estático (es decir no contempla pruebas de caja negra ni con la aplicación en ejecución) como son las variables no inicializadas, punteros no referenciados, corrupción de memoria o fugas de memoria. También indicar que solo contempla los errores catalogados como severidad “media” o “alta”, no se tienen en cuenta los errores de severidad “leve”.

Para el estudio se han tomado 37 millones de líneas de código abierto y 300 millones de código propietario.

En el código abierto se han examinado 45 de los mayores proyectos con una media de 820.000 líneas de código por proyecto y se ha encontrado una densidad media de defectos de 0.45 por cada 1000 líneas de código.

En el caso del código propietario se han analizado 41 proyectos con una media de código de 7,55 millones de líneas y con una densidad media de defectos de 0,64 por cada 1000 líneas de código.

Comentar que ambos análisis estan por debajo del indice que Coverity considera como aceptable que se localiza en una densidad de 1 defecto por cada 1000 líneas de código.

Los proyectos Open Source destacados con una cálidad de código “Excelente” han sido Kernel 2.6 de Linux, PHP 5.3 y PostgreSQL

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:  

Estos días ha habido mucho movimiento debido a dos grandes fallos que han provocado varios problemas en dos grandes compañias, Google y Coca Cola.

El primero de ellos ha sido debido a un error de seguridad en la aplicación Google Wallet (monedero virtual de Google) que permite en algunos telefonos obtener el PIN del monedero virtual y posteriormente realizar compras con las tarjetas de las que dispone.

El grupo de seguridad Zvelo ha realizado una pequeña aplicación para demostrar la facilidad para la obtención de PINs con un telefono rooteado. El PIN se guarda cifrado en la memoria del teléfono, pero como solo hay 4 cifras solo es necesario realizar 10.000 iteraciones para comprobar cual es el PIN correcto. En este caso solo afecta los telefonos con root por lo que Google ha salido del paso indicando que no se recomienda que se instale en estos terminales Google Wallet. La pregunta es… Que pasa si alguien me rootea el movil en algún momento?

Pero la historia no acaba aquí, si no que también se ha descubierto otro error grave y mucho más sencillo. Algo tan facil como borrar los datos de la aplicación y volverla a instalar… en ese momento nos pide un nuevo PIN y podremos utilizar de nuevo la tarjeta! Este caso se puede dar fácilmente en el caso de que nos robaran el móvil. La respuesta de Google en este caso ha sido a mi parecer un poco más débil, utilizar un PIN para el teléfono y un borrado de datos en caso de robo. A mi parecer una solución muy pobre para tapar errores de seguridad de este calibre… Debilidades que harán que mucha gente se lo piense antes de utilizar en Google Wallet!

La otra gran protagonista es Coca Cola, ya que después de hacer un despliegue impresionante en la web para promocionarse en la Super Bowl tuvo problemas de rendimiento. Parece ser que el anuncio a bombo y platillo de su nueva página web durante la Superbowl supero todas las expectativas y desbordo los servidores de Coca Cola mostrando un bonito mensaje de error durante un buen rato…

Después de haber trabajado durante semanas en la publicidad del evento, de todo el coste que pudo suponer el anuncio en la Superbowl, imaginaos el impacto que puede tener que los usuarios solo vean una página de error… Coca Cola no ha comentado en ningún momento el coste de esta caida, pero seguro que ha provocado perdidas muy abultadas, no solo por el coste de la web si no por la perdida de la oportunidad (recordar que la Superbowl es el evento más visto por los americanos en todo el año) y por la mala visibilidad de la marca de cara a los usuarios.

Vosotros tenéis en cuenta las pruebas de rendimiento y seguridad durante vuestra fases de testing? Hasta que punto? Realmente creéis que son suficientes?

Tagged with:  

DebaTEST sobre Seguridad

On 8 febrero, 2012, in Eventos, by twiindan

 

Después de un pequeño paron navideño, la asociación TestQA vuelve con los eventos DebaTEST.

En esta ocasión el tema escogido por los asistentes y seguidores de la asociación ha sido sobre Seguridad!!!

Como siempre contaremos con algunas personas invitadas con varios años de experiencia en temas de seguridad y penetration testing.

El evento se realizará en el centro cívico Golferichs en la calle Gran Vía el dia 29 de febrero de 19.00 a 21.00 aproximadamente. Como siempre la entrada al evento será totalmente gratuita!

Para apuntarse puedes hacerlo desde la pagina de la asociación TestQA

Esperamos vuestra asistencia para poder debatir sobre como hackear nuestros sistemas!

Tagged with: