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:  

Proposito del nuevo año, aprender a programar!

On 3 enero, 2012, in Cursos, by twiindan

Como ya he comentado en algún articulo anterior, uno de los puntos que valoro generalmente en los testers son los conocimientos de programación. Siempre he sido defensor de que nuestra disciplina, es una disciplina no solo funcional si no también técnica por lo que valoro que estas personas tengan una base de programación.

Como ya comenté en el articulo “Han de saber programar los testers“, no es necesario que tengan unos conocimientos profundos sobre programación, pero si que tengan unos mínimos que le permitan leer código o analizar arquitecturas, al igual que realizar scripting o Bases de Datos.

Es por ese motivo, que hoy me gustaría compartir con vosotros una muy buena iniciativa que he encontrado y que podéis seguir de forma gratuita.

La iniciativa tiene el nombre de “Code Year” y consiste en un pequeño curso de programación online en el que nos podemos suscribir para que nos manden de forma semanal nuevas lecciones para poder aprender a programar desde el principio y poder así mejorar nuestras skills de programación.

El curso es totalmente gratuito, y el único dato necesario para el registro es la dirección de correo electrónico donde te mandaran posteriormente las lecciones y los ejercicios.

De momento ya hay más de 60.000 personas registradas, por lo que la iniciativa parece ser que ha tenido bastante éxito. Si aun no has realizado los propósitos para este año 2012, puede que esta iniciativa pueda ayudarte a definir uno de ellos!

Tagged with:  

Durante mi presentación en Valencia, expuse en una slide que era importante que los testers tuvieran programing o coding skills. Esta frase provoco una serie de murmuros, y note que decenas de ojos empezaban descuartizarme en su cabeza…

Efectivamente en cuanto acabe la presentación, todas las preguntas fueron hacia esa slide, ya que la mayoría de gente no estaba de acuerdo en que realmente un tester deba saber de programación. La pregunta abierta a debate es… Realmente un tester debe saber de programación? Porque existe tanto miedo a aprender a programar?

Aquí expongo mi opinión, pero no es más que eso, una opinión al respecto y por supuesto puede diferir de la de mucha gente:


PROGRAMAR O NO PROGRAMAR, ESA ES LA CUESTIÓN:

Parece ser que existe una gran reticencia de mucha gente que se dedica a la calidad de software y al testing (sobretodo estos últimos) a no tener que saber nada sobre programación. Esto en parte se debe a dos motivos (entre otros muchos): El primero de ellos es que mucha gente se ha dedicado al software testing por casualidad, y es gente reciclada de otros trabajos como soporte, o gente de la capa de negocio o más funcional. El segundo motivo es que otro gran porcentaje de testers son gente que se metieron en este sector porque justamente no querían programar y les pareció una alternativa sencilla para seguir dentro de las IT sin tener que saber programar.

Pero realmente sirve para algo saber de programación para ser tester?

 

Testing triangle

A mi siempre me ha gustado mostrar una pequeña figura como la siguiente donde localizo el testing entre dos mundos que casi están separados, la capa de negocio y la parte de desarrollo o parte técnica.

Para mi el tester ha de ser comunicador entre ambas partes (junto otros roles implicados en el desarrollo), ya que entre ellas la comunicación puede llegar a ser muy complicada.

Como podéis observar el tester toca tanto la parte de negocio como de desarrollo. Todo el mundo tiene muy claro que el tester ha de saber sobre la capa de negocio para hacer bien su trabajo, sin embargo poca gente tiene en cuenta que también es importante el trabajo con los programadores. Por lo tanto para mi un tester ha de tener parte de negocio, parte técnico y añadirle otras skills intermediaria.

Entonces, para que le puede servir programar a un tester? Principalmente por varios motivos:

  1. Para entender los problemas que puede tener una aplicación. Desde la capa de negocio se pueden encontrar muchos defectos, pero si realmente sabemos como esta construido el software, si sabemos como esta diseñado y creamos un modelo mental de este, sabremos como toma las decisiones, de donde obtiene los recursos, que partes del código son más susceptibles de tener más errores.  Obtenemos una gran fuente de información para mejorar en la realización de las pruebas!
  2. Automatización! Si lo se… existen maravillosas herramientas que haciendo clicks puedes automatizar… pero lo que realmente aporta valor es atacar sobre la lógica de la aplicación (a nivel funcional). Que seamos capaces de automatizar una API sin interfaz gráfica, capaces de regenerar datos mediante scripts, crear scripts para configurar la aplicación…
  3. La más importante para mi… para comunicarse con los programadores… aprendemos la capa de negocio para hablar con los clientes, para discutir con ellos, para proponerles cosas, informes etc. Sin embargo no somos capaces de comunicarnos con la gente técnica porque no hablamos su idioma… como queremos entonces que nos respeten??? Si queremos captar su atención tenemos que saber ayudarles, darles apoyo, hablar con ellos, mejorar su día a día, y esto solo lo podemos conseguir si sabemos como trabajan.

Gente que se dedica al testing y al QA, debemos recordar una cosa… nuestra disciplina se encuentra dentro de la Ingeniería de Software! Si queremos sacar todo el potencial de nuestra profesión tenemos que trabajar desde su base.

Con esto no quiero decir que tengas que tener un nivel de programación excelente, ni mucho menos, si yo soy tester y el de mi lado es programador es principalmente por dos motivos… el primero porque el trabaja 8 horas programando y yo no. El segundo es porque a el le motiva programar, a mi probar y hacer de QA. Pero si que es necesario que si me enseña un diagrama UML lo entienda, que si me muestra una arquitectura, podamos discutirla, que si me da un trozo de código (bien programado) pueda decirle que hace y proponer seguramente alguna mejora y si no lo entiendo pedirle que me lo explique. De esta forma, la otra persona ve que aporto valor a su trabajo, que realmente puedo serle de utilidad, en lugar de ser alguien que lo único que le dice es que ha hecho algo mal. A partir de ese momento, me podré integrar mejor con ellos e intentar internamente que mejoren la calidad de su código ayudandoles a hacerlo y ofrenciendoles todo el soporte necesario para ello ya que el objetivo de ambos es el mismo.

Esta condenado el tester funcional a desaparecer?

A mi parecer no. Hay una gran herencia en los últimos años, aunque creo que con la entrada del agilismo esta tendencia esta cambiando. Igualmente existe una gran cantidad de testers que son muy buenos realizando su trabajo, gracias al knowhow que tienen de la capa de negocio, y gracias a que se ha ido autoformando dentro del mundo del tester teniendo un gran background de heurisiticas que puede utilizar.

Conozco grandes testers exploratorios, y de testing manual, mucho mejor que algunos que sepan programar, gente a la que admiro, pero también creo que aprender un poco de programación no les hará daño. Insisto, ambas formaciones no son contradictorias, sino al contrario, son complementarias y nos ayudaran a realizar mejor nuestra profesión.

Al final nuestro objetivo es el mismo que el resto del equipo, entregar un software de calidad a nuestro cliente, por lo que hemos de aportar un valor diferencial respecto a nuestros clientes, y respecto a los programadores, ese es el status quo del tester.

Ahora ya podéis uniros al grupo de facebook de “quiero despellejar al que dice que los testers necesitan programar!”

Tagged with:  

Resumen Autumn Test BCN 2011 y VLC 2011

On 15 noviembre, 2011, in Eventos, by twiindan

Durante este último mes, la asociación TestQA no ha parado y ha montado dos ventos Season Test, en este caso en dos ciudades diferentes Barcelona y Valencia.

El Autumn Test de Barcelona se realizó el 26 de Octubre en el local Hyde con un público de casi 60 personas (de 85 apuntadas) donde se entrevisto a Lluís Serratosa, Jefe del departamento de User Acceptance Testing de Zurich, donde nos explico su experiencia en el departamente de UAT dentro de Zurich y como lo tenían organizado. La verdad que la charla fue muy amena y dio a conocer un mundo muchas veces desconocido como son los tests de aceptación junto con el cliente.

También se distribuyo información de las próximas conferencias a nivel nacional e internacional así como las principales revistas que existen sobre calidad de software y testing para difundirlo.

Una vez acabada la entrevista y la ronda de preguntas, se dejo a la gente que interactuara y realizará networking entre ellos para compartir experiencias y puntos de vista sobre el testing y la calidad de software.

El evento finalizó realizando una serie de sorteos de varios libros sobre calidad de software, para favorecer así la divulgación de esta disciplina.

Podéis ver las fotos en la web de TestQA

El Autumn Test de Valencia se englobo dentro de la conferencias VLC Testing que tuve el honor de asistir como ponente. Despues de una larga jornada de ponencias, las asistentes se dirigieron al local Birrar & Blues ubicado en la playa donde pudieron degustar de forma gratuita una cerveza casera junto con unas pizzas.

En esta ocasión se entrevisto a Javier Lopez Arana, Software QA Lead en Hewlett-Packard donde comentó como tenían montados los departamentos de calidad y de software dentro de HP y la complejidad que tenía probar algo como las impresoras. Destacar sobretodo el tema del outsorcing ya que javier comento que trabajaban con dos vendors uno local y otro Chino, y que la experiencia con el vendor Chino en los últimos años había sido muy satisfactoria.

Una vez acabada la entrevista y la ronda de preguntas a Javier, se procedió a realizar equipos de 5 personas para que realizan networking y hicieran un pequeño Quiz que les habiamos preparado para que interactuaran entre ellos. Sorprendentemente gano el equipo que menos testers tenia! El premio fueron unos libros sobre calidad de software y unas subscripciones a la revista Testing Experience.

Ya para finalizar se agradeció a los asistentes y a la organización por haber permitido realizar este evento en Valencia y comenzamos a arrasar con unas buenísimas pizzas que nos ofrecio el ITI.

Podéis seguir las novedades de la asociación TestQA y los nuevos eventos en su página oficial.

Tagged with:  

Resumen VLC Testing 2011

On 14 noviembre, 2011, in Conferencias, Eventos, by twiindan

Resumen VLC Testing 2011El día 10 de Noviembre tuvo lugar la jornada de calidad de software y testing VLC Testing 2011 en la ciudad de Valencia. La universidad de Valencia junto con el ITI ha querido recuperar estas jornadas despues de varias años sin realizarlas y la verdad que fueron todo un éxito.

Al final 120 asistentes pudieron asistir a las jornadas donde solo había un único tema entre los asistentes, el testing!

La jornada empezó con la presentación del director del Area de calidad del software del ITI (si, existe un area de calidad de software dentro de una universidad!) realizando una ponencia introductorio bastante divertida utilizando un juego de palabras sobre el testing (probado, reprobado, re-probado). Posteriormente Dario Ferrater hizo una ponencia sobre la experiencia del testing en los juegos olimpicos (Atos lo está realizando). A mi parecer una ponencia muy comercial, y que se tendría que haber enfocado más en el caso práctico de los JJOO ya que parecían muy interesantes.

Seguidamente tuve la ocasión de presentar mi ponencia sobre “skills” del tester, que podéis descargar en la sección de “Conferencias y articulos” y dar el feedback que queráis! Después vino mi compañero Javier Fernandez Pello que realizó también una gran ponencia sobre como tienen montado todo el departamento de QA dentro de su empresa, y explico todos los procesos que realizaban desde QA para intentar mejorar el proceso día a día. A mi parecer una gran ponencia que dió un toque diferencial a las conferencias ya que es un tema del que generalmente se habla poco.

Después de otra ponencia de caracter muy publicitaria a mi parecer de Jorge Castelló de Bull, llego otra gran ponencia de manos de Antonio Calero sobre métricas de software, donde explicaba las principales métricas que utilizaban con casos prácticos de análisis y números que dejaban mucho que desear sobre el software que se está produciendo actualmente.

Por la tarde destacar también la ponencia Maite Tamayo sobre un sistema metrológico, ya que mostraba que existían muchas complicaciones a la hora de testear software embedido y mostraba la solución que habían adaptado para solucionarlos. Posteriormente Jordi Sanchez hizo una ponencia sobre uno de los grandes “olvidados” en el software, la usabilidad.

Ya para acabar la jornada pudimos ver una presentación sobre sistemas críticos (que recuerdos!) y otra sobre testing combinatorio mostrando algunas herramientas que pueden ser de gran utilidad a la hora de realizar Data Driven Testing.

En general las jornadas han sido muy interesantes, y hubo variedad de ponencias, muchas de ellás con muchas cosas para aprender. Lo malo de las conferencias? Hubo alguna de ellas puramente comercial (como la de Atos o Bull) y por otra parte los tiempos eran excesivamente ajustados (11 conferencias en un día son muchas conferencias). Aún así el balance de las conferencias ha sido muy positivo. La organización cumplió con creces mis expectativas y hubo conferencias con mucha calidad por parte de los ponentes por lo recomiendo el próximo año asistir sin ninguna duda!

Felicidades a la organización por retomar este evento que ayudará a difundir la calidad del software y el testing por nuestro país!

Tagged with:  

VLCTESTING 2011

On 7 octubre, 2011, in Conferencias, by twiindan

Despues de dos años sin eventos sobre calidad de software y testing en Valencia, la universidad Politecnica de Valencia junto con el ITI (Instituto Tecnológico de Informatica) han lanzado el evento VLCTESTING 2011 para calentar motores y volver a realizar el año que viene las Jornadas de Testing que se hacían anteriormente.

El evento constará de una jornada sobre calidad y testeo de software dirigida a los profesionales del sector. Se realizará el 10 de Noviembre dentro del Instituto Tecnológico de Informática. Como ponentes habrá varios expertos españoles sobre calidad de software que nos explicarán temas sobre usabilidad, herramientas de gestión de calidad de software o estrategias de pruebas.

Como novedad se ha introducido dentro de las jornadas el evento Autumn Test organizado por la asociación TestQA donde se entrevistará a un Test Lead de HP y se realizarán actividades de networking entre profesionales del sector.

Podéis encontrar más información y el programa del evento en la página de VLCTESTING 2011.

Tagged with:  

Planning poker y Testing

On 5 agosto, 2011, in Agilismo, by twiindan

Seguimos con los conceptos de las metodologías ágiles, intentando aplicarlas a los sistemas de calidad y testing.

En el capitulo de hoy hablaremos de una técnica de estimación muy utilizada en las metodologías ágiles en las cuales el equipo de testing y calidad deben participar. Esta técnica es la llamada Planning Poker.

El planning Poker es una técnica de estimación por consenso utilizado par estimar el esfuerzo o complejidad de las tareas de un proyecto. Generalmente se utilizan para los proyectos de desarrollo de software, aunque puede ser aplicable a varios tipo de proyectos. En nuestro caso nos centraremos en su aplicación dentro del desarrollo de software.

Esta técnica suele utilizarse dentro de las reuniones de Planificación de Sprint para poder estimar el esfuerzo de cada una de las user stories que entraran en el sprint. Para ello después de que el Scrum master haya facilitado la user story y se hayan aclarado todas las dudas de la user story, todo el equipo debe votar el esfuerzo de estas tareas de forma simultanea.

Para ello se utilizan una baraja de cartas con diferentes valores, generalmente 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 y una tarjeta de ? (inseguro) y una taza de cafe (necesito un descanso). El motivo de ir incrementando los valores de forma exponencial es para reflejar la incertidumbre en la estimación.

Una vez vistos los resultados de la planificación se pregunta a las personas que tienen las estimaciones más altas y bajas que justifiquen sus motivos para esa estimación y generar una discusión dentro del grupo para intentar llegar a un consenso. El proceso termina cuando todos los integrantes del grupo llegan a un consenso sobre cual es el esfuerzo de la tarea a implementar.

Estos puntos de esfuerzo luego pueden relacionarse con el sistema quantificable que cada equipo quiera (días, horas…).

Estos puntos de esfuerzo se utilizan también para medir la velocidad del equipo. Es decir, mediante la experiencia se puede saber aproximadamente cuantos puntos de esfuerzo puede asumir el equipo durante un sprint. Por ejemplo, si generalmente el equipo es capaz de producir 100 puntos de esfuerzo, no tiene sentido planificar más de estos (siempre dando un margen de maniobra).

El principal beneficio de utilizar esta técnica de estimación es la nula influencia de los miembros del equipo en la estimación inicial de la tarea. Al realizar una primera estimación de forma simultánea por parte de todos los integrantes del equipo, se elimina esa variable de influencia. Otra de las ventajas es que cada miembro del grupo puede justificar su puntuación por lo que general un sistema de debate abierto a todos los miembros del equipo que puede ayudar a despejar dudas. A parte también ayudará al equipo a saber hasta donde puede llegar para poder planificarse correctamente durante los días del sprint siguiente.

Porque es importante que el equipo de testing este dentro de el proceso de planning poker? Principalmente por dos motivos:

  1. Generalmente el equipo de desarrollo solo tiene en cuenta el esfuerzo que requerirá esta user story en su propio desarrollo o en su propio componente. Es decir si la user story requiere que algunos de estos componentes se integren con otros y así sucesivamente, posiblemente no lo tendrá en cuenta ya que no requiere esfuerzo por su parte. Sin embargo generalmente los equipos de calidad y testing al tener una visión más conceptual de la user story si que tendrá en cuenta estas integraciones y podrá ofrecer su justificación de forma más objetiva y de alto nivel al resto del equipo.
  2. Por otra parte, el equipo de desarrollo tampoco tendrá en cuenta las pruebas funcionales de la user story (si las pruebas unitarias). Esto implica que puede ser que una user story pueda parecer muy sencilla por la parte de desarrollo pero sin embargo sea muy compleja para la parte de testing o requiera de una gran cantidad de pruebas. Por ese motivo es muy importante que dentro de la user story y de la estimación de esta se tenga en cuenta también todo el esfuerzo de la parte de calidad para poder calcular el esfuerzo correctamente.

Si queréis aplicar esta técnica podéis obtener barajas virtuales en:

http://www.planningpoker.com/

De forma física en:

http://store.mountaingoatsoftware.com/products/planning-poker-cards

Si queréis también podéis imprimir una baraja muy divertida de Autentia:

http://www.autentia.com/zip/AutentiaPlanningPokerCardsCC.zip

 

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:  

El centro de formación permanente de la Universidad Politécnica de Valencia ha lanzado un nuevo curso de Software Testing.  El curso dirigido a personas con conocimiento de software (no require formación especifica de testing) intentará dar nociones de técnicas, metodologías y estrategias sobre testeo de software.

El curso empieza el día 13 de Junio del 2011 hasta el 21 de Junio y consta de 30 horas.  Será impartido por Tanja Vos.

El índice del curso es el siguiente:

1. Testeo estructurado: TMAP, Testframe, y ciclos de vida del testeo
2. El coste de la calidad y el ROI del testeo
3. El ciclo de vida del testeo (modelo V, testeo unitario, de integración de sistema, de aceptación)
4. Planificación del testeo (diferentes planes de testeo)
5. La organización y la estrategia del testeo
a. Las secciones de la estrategia de testeo
b. Informar sobre el progreso del proyecto de testeo (métricas simples)
c. Gestión de los defectos
6. Técnicas para el testeo
a. Análisis de riesgos
7. La infraestructura necesario para el testeo (tipos de entornos y herramientas para el testeo)
8. Automatización del testeo

El coste del curso es de 420 € para gente externa a la UPV y se aplicaran varios descuentos para los que pertenezcan a la universidad.

Para apuntaros al curso o solicitar más información podéis ir a la pagina de la UPV aquí.

Tagged with: