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:  

Principios Generales de Testing

On 6 julio, 2010, in Consejos, Definiciones, by twiindan

Actualmente estoy estudiando para realizar la certificación del ISTQB Foundation y en el primer tema existe un apartado donde se indican muy bien los principales principios del testing.

  1. Testing shows presence of defects: El testing puede mostrar que existen defectos, pero no puede provar que no los haya si no que unicamente reduce la probabilidad de que queden defectos sin descubrir.
  2. Exhaustive testing is impossible: Testear todas las combinaciones y posibilidades es imposible, por ello se debe priorizar y realizar análisis de riesgos para enfocar los esfuerzos del equipo de test.
  3. Early testing: Las actividades de test deben lo antes posible en el ciclo de vida de desarrollo de software, enfocandolo en objetivos definidos.
  4. Defect clustering: Un pequeño número de módulos son los que contienen la mayor parte de los defectos descubiertos antes de realizar una release.
  5. Pesticide Paradox: Por mucho que se repitan los mismos tests, no se van a encontrar más errores. Por ese motivo los test cases necesitan ser regularmente revisados y se deben ir añadiendo nuevos para probar las diferentes partes del software.
  6. Testing is context dependent: Los procesos y las metodologías de test aplicadas deben ser diferentes según el contexto.
  7. Absence  of errors fallacy: Encontrar y arreglar defectos no ayuda si el sistema no es usable o no concuerda con las necesidades y expectativas del testing.

Estáis de acuerdo con todos los principios? La verdad que es un buen resumen de las características principales del testing, unos principios que todos deberíamos aplicar siempre que podamos.

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:  

Caja blanca, caja negra

On 7 junio, 2010, in Definiciones, Técnicas, by twiindan

Hoy vamos a hablar de dos conceptos básicos en el arte del testing de software, dos conceptos que seguramente todo el mundo conoce, la caja blanca y la caja negra.

Para explicar estos conceptos utilizaremos la propia caja como ejemplo.

Imaginad que váis a una tienda y el vendedor te quiere vender una caja negra en la que te asegura que si pones dentro X euros salen 2·X €, la condición es que no puedes saber que hay dentro de la caja.  Sin pensarnos la compraríamos, pero antes deberíamos comprobar que no es un timo y por eso probaríamos la caja.

Las pruebas que podríamos realizar son:

  1. insertar 5 euros y comprobar que salen 10
  2. insertar 10 euros y comprobar que salen 20
  3. Y así sucesivamente…

De esta manera comprobaríamos la funcionalidad de la caja sin saber como funciona. Este es lo que se conoce como pruebas de caja negra.

Por otro lado imaginaros ahora que el vendedor os dice que podéis ver como funciona la caja, como somos testers muy curiosos vemos todos los mecanismos que hay dentro de la caja y vemos que tiene una sofisticada máquina de fabricar billetes con muchos conductos (uno para cada tipo de billete), es decir vemos todas las entradas, las salidas y los pasos intermedios (los conductos de los billetes). Para asegurarnos que funciona perfectamente la máquina (ya que el precio ha subido desde que podemos ver como funciona) decidimos probar todos los caminos posibles intermedios que podemos ver. En este caso estaríamos realizando pruebas de caja blanca ya que sabemos el contenido de la caja.

Si trasladamos la analogía al mundo real, las pruebas de caja negra sería aquellas en las que no tenemos acceso al código fuente, solo podemos probar la funcionalidad mediante entradas y salidas mientras que las pruebas de caja blanca serían probando cada una de las condiciones o caminos del código teniendo acceso a él.

Cual de las dos técnicas es mejor? Cada una tiene sus pros y sus contras, algo que iremos viendo a medida que profundicemos en el tema, pero generalmente lo ideal es mezclar ambas metodologías para conseguir una mayor área testeada.

Tagged with: