Ya se ha anunciado la nueva edición de las conferencias VLC Testing 2012 organizado por el ITI (Instituto Tecnológico de Informática).
En esta ocasión las conferencias tendrán lugar durante dos días, 14 y 15 de Noviembre en la ciudad de Valencia.
Las conferencias se centraran en esta ocasión en ponencias de caracter 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.
Junto con el anuncio de esta edición se ha abierto el plazo para el Call of Papers. Si estáis interesados en participar como ponentes aquí tenéis las fechas más relevantes para ello:
- 6/04 al 18/06 recepción de ponencias
- 31/07 Notificación de aceptación de las ponencias seleccionadas
- 06/08 Programa inicial
- 10/09 Programa completo
- 10/09 Inscripción anticipada al evento
- 05/11 Recepción de versiones finales de las ponencias
- 12/11 Cierre inscripción
Más información en la web de VLCTesting
Desde SoftQaTest hemos querido crear una nueva iniciativa para promover el contacto y el networking entre la gente de Barcelona que hemos denominado Beer Chat!
La idea ha sido de Mauri Edo (aunque el es más sano y lo hace con café :p) y me ha dado el permiso para replicarla en SoftQaTest. Así que ya sabes si eres de Barcelona o tienes pensado una visita a esta ciudad, podemos quedar para hace unas cervecitas (o lo que más te apetezca) mientras disfrutamos tranquilamente de una charla sobre testing!
Podéis ver más info aquí!
Ya se ha publicado el perfil básico de la norma ISO 29110. Este standard esta descrito para pequeñas y medianas empresas (lo que en España serian nuestras PYMES.
La guía de momento esta solo en inglés y se puede descargar de forma gratuita aquíLa norma se basa en estandares de CMMI, ISO 9001, ISO 12207, y ISO 15504 pero aplicada a pequeñas empresas. En ella se especifica todo el proceso de desarrollo de software, y puntos de mejora para las empresas, desde la perspectiva de Proyect Management y de Software Implementation.
La guía actualmente solo se encuentra en español, y puede descargarse de forma gratuita aquí.
Hace aproximadamente dos meses NexoQA (empresa que organiza ExpoQA) con SoftQaNetwork y ATI (Asociación de Técnicos Informáticos) lanzaron una encuesta sobre la situación salarial de los testers en España.
La encuesta estuvo abierta del 1 de Febrero al 15 de Marzo en la que participaron 86 personas del mundo de la calidad de software y el testing. Algunos datos curiosos, es que existe un buen porcentaje de mujeres en el mundo del testing (cosa no muy común en la ingeniería de software). También otro dato importante es la edad de los encuestados ya que todos los encuestados se encuentran entre los 20 y los 40 años por lo que se nota que es una disciplina muy joven y con mucho camino para madurar.
Unos números que me han gustado mucho, es que un 86 % de los encuestados tienen estudios superiores, por lo que se muestra que es una disciplina que necesita una base importante, y que no puede hacer cualquiera como piensan algunas personas. Si que es cierto que no es un requisito indispensable tener una carrera técnica o estudios superiores, pero si que ayuda bastante.
Sobre el tema de salarios prefiero no opinar… la mayoría de gente se siente peor pagado que la gente de desarrollo, aunque yo opino todo lo contrario. Hay muchos desarrolladores que están cobrando mucho menos que nosotros. En parte creo que es ratio oferta / demanda. Desarrolladores hay muchos, mientras que testers hay pocos, por lo que la cotización de un tester generalmente ha crecido mucho más en relación con el desarrollo.
Podéis ver el informe completo en la página de ExpoQA.
Esta mañana se ha creado la lista de distribución de correo de la asociación TestQA mediante Google Groups.
La lista es totalmente abierta y puede apuntarse cualquier persona que este interesado en el testing y en la calidad de software y que quiera estar enterado de todos los eventos que se realizan desde la asociación, al igual que seguir comentando y debatiendo sobre los diferentes temas.
Porque hemos utilizado Google Groups? Básicamente porque necesitábamos un sistema de comunicación que fuera rápido y pudiera llegar a todos el mundo. A parte nos interesaba un sistema en el que pudieramos debatir y hablar sobre temas de testing y calidad de software de forma flexible y accesible a todo el mundo. De esta manera podemos crear un espacio de comunicación que no sea dependiente de las plataformas como linkedin y que puede llegar directamente al correo de los miembros del grupo.
Esperemos que os guste la idea, y que se utilice de forma activa por todos los usuarios para seguir hablando sobre testing y seguir aprendiendo entre todos de esta disciplina.
Para apuntarse solo has de ir a la página del Google Groups de TestQA
Happy testing!
Hay una teoría que nacio en los años 1980 por parte de James Q. Wilson y George Kelling que se denomino la teoria de las ventanas rotas con un simple principio:
-
“Consideren un edificio con una ventana rota. Si la ventana no se repara, los vándalos tenderán a romper unas cuantas ventanas más. Finalmente, quizás hasta irrumpan en el edificio, y si está abandonado, es posible que sea ocupado por ellos o que prendan fuegos adentro.
-
O consideren una acera o banqueta. Se acumula algo de basura. Pronto, más basura se va acumulando. Eventualmente, la gente comienza a dejar bolsas de basura de restaurantes de comida rápida o a asaltar coches.
Esto responde a una curiosa conducta humana que dice que si algo esta mal ¿ Porque tengo que hacerla yo bien?
Esto es fácilmente aplicable al código de desarrollo y incluso a nuestros diseños de tests o los tests automáticos. Cuantas veces no habremos a alguien quejarse de que ha cogido legacy code que es un desastre y que es muy complicado lidiar con ello. O alguien que haya visto unos tests que de repente fallan y grita a los 4 vientos que están mal realizados o son un desastre?
Ahora preguntaros vosotros cuantas veces hemos hecho algo, hemos pensado que se podría hacer de otra forma mejor pero nos ha dado pereza realizarlo? En ese momento estamos dejando una ventana rota y que puede provocar lo que llamamos deuda técnica (tanto para desarrollo como para test). Cuantas ventanas rotas estamos creando que pueden tener una repercusión en el futuro? Y lo peor de todo cuantas las dejamos aun con la conciencia de que se podrían arreglar? No es más fácil arreglar las cosas cuando son pequeñas que cuando se han acumulado? Esta acumulación suele ser muy peligrosa, ya que después de mucho tiempo cuando se hace inmanejable es cuando alguien piensa cuanto tiempo se tardaría en arreglarlo y te das cuenta que es un tiempo inasumible.
El siguiente punto es… cuantas ventanas rotas hemos arreglado? Como hemos comentado antes es muy sencillo quejarse de que algo esta mal hecho y se pudiera hacer mejor, pero generalmente cuando te encuentras algo mal hecho (por ti o por quien sea), por algún extraño motivo se sigue realizando igual de mal o peor. No estoy diciendo de que digas “a partir de hoy durante 10 días solo voy a arreglar ventanas”, si no que cuando veamos algo que esta mal realizado, y debamos hacer una modificación en esa parte, la arreglemos. Alguien tiene que arreglarlo para que siga siendo mantenible… entonces hay que preguntarse… ¿Porque no yo? Seguro que a la larga, tu y tu equipo lo agradece… no hay nada mejor que predicar con el ejemplo.
Para este último caso hay que seguir la regla de los Boy Scouts, “Deje la zona del campamento, incluso más limpia que como la encontró” o la que solemos encontrar en muchos baños “Deje el baño como le hubiera gustado encontrarlo”. Es decir, si tenemos que tocar algo que hemos realizado anteriormente nosotros o otra persona, en lugar de quejarnos, mejoremoslo, ya que seguro que a largo plazo lo agradeceremos.
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 %!
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?
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?
ExpoQA 2012
Últimos comentarios