Blog de Miguel Llopis

Serie ECDB: ¿Qué cualidades debe tener un buen tester?

A primera vista, podría dar la sensación de que es más sencillo romper que crear. Reventar códigos fuente debe ser, sin duda, mucho más sencillo que crearlos. Sin embargo, no es así.

¿Por qué?

Si consideramos el Software Testing como un proceso metódico y disciplinado (como deberíamos hacer), dicho proceso requerirá el mismo esfuerzo y dedicación que el desarrollo de dicho software. En realidad, el Software Testing implica una serie de habilidades similares a las del developer, pero con algunos matices diferenciadores.

Como habréis deducido a estas alturas de la serie, la mayoría de compañías actuales con un cierto grado de madurez consideran el Software Testing como un rol imprescindible y necesario como complemento del rol de developer. Por desgracia, aún existen muchas compañías en las que esto no es así. Compañías en las que la filosofía coincide con la expuesta en una de las anteriores entregas:

Soy mejor cuanto menos tardo en generar artefactos, y una vez los haya generado realizaré una serie de pruebas con las que quedaré satisfecho si no encuentro fallos: ¡Qué gran developer estoy hecho!

En el sistema competitivo del mercado actual, este segundo tipo de compañías no permanecen en escena durante mucho tiempo: Los clientes deciden no comprar esos productos plagados de bugs!!

Una buena o mala planificación de tests puede llevar una compañía al éxito o reducirla a cenizas!

Con esta perspectiva, deberíamos considerar una decisión crítica la buena elección de profesionales dedicados al proceso de pruebas. Pero...

¿Qué características debemos considerar vitales en un tester?

- Capacidad para "imaginar" soluciones a problemas existentes. Un tester debe ser capaz de poder realizar hipótesis con un grado de fiabilidad aceptable acerca de la causa de un error cuando éste se produce. En esta fiabilidad influye el hecho de que el software debe, por un lado, conocer los principios de arquitectura y diseño que se han seguido en la creación del software, así como tener un dominio bastante amplio de la tecnología con la que ha sido elaborado, del lenguaje, para poder "destripar" el código que tiene entre manos y también de los escenarios de uso posibles para dicho software, de modo que sepamos si el error observado corresponde a un caso de uso más o menos frecuente y, a su vez, crítico del sistema.

- Un tester es un explorador nato: No tienen ningún miedo por adentrarse en terrenos y situaciones desconocidas. Un buen tester está deseando obtener la última versión beta de un cierto producto para explorar sus entrañas y, a ser posible, ser el primero en encontrarle fallos.

- Un tester es incansable: Un tester SIGUE BUSCANDO. Estas palabras resumen la filosofía de explorador de un tester. Debo confesar que frente a mi mesa de trabajo tenía un folio clavado en un panel de corcho con dos palabras en inglés a tamaño 48, negrita y subrayadas: KEEP TRYING!

- Perfeccionistas con criterio: La perfección de un producto radica en el equilibrio perfecto entre fiabilidad y coste. De nada nos sirve un software desarrollado en tiempo récord si tiene muchos fallos; a su vez, tampoco nos resulta útil un software fiable al 99'9999% si el coste de su desarrollo es estratosférico y por sí solo supone un balance negativo superior a las pérdidas que un producto "parcialmente" imperfecto puede conllevar.

- Creatividad: Probar lo extraño no es suficiente para un tester. Probar únicamente lo obvio es pecado capital.

- Buen criterio economista: Un tester debe ser capaz de decidir qué tipo de bugs buscar, estimar cuánto tiempo debe dedicar a seguir el rastro de un determinado bug o saber distinguir un bug real de algo que tan sólo es un "comportamiento disperso" de la aplicación.

Hasta aquí, definiríamos las características necesarias para la caza de bugs. Ahora bien, una vez que han sido detectados por el tester: ¿Qué características son deseables en un tester para continuar con el proceso de testing (localización de bugs + reporte de bugs + establecer prioridad de la solución + asegurarse de que han sido resueltos) adecuadamente?

- Diplomacia y capacidad de expresarse con tacto, aún cuando lo que se está haciendo es criticar el trabajo de otros... A pesar de tratarse de una crítica constructiva y enfocada a mejorar el producto final, no es algo sencillo. Uno de mis compañeros de equipo con más experiencia en el rol, me resumió esta cualidad con la siguiente frase:

"Hay que saber cómo dirigirse a un developer para resaltar defectos de lo que él ha hecho. A nadie le gusta que le digan que un hijo suyo es feo..."

- Persuasividad: Hay que ser capaz de acotar bien el bug expuesto y, realmente, convencer al resto de miembros del equipo de que dicho fallo DEBE ser resuelto a la mayor brevedad posible.

Como véis, existen unas cuantas características que diferencian a un tester de un developer, discusión que previamente ya habíamos tenido por Geeks.

¿Qué características os parecen fundamentales en un tester a vosotros?

Posted: 12/2/2008 19:49 por Miguel LLopis | con 12 comment(s) |
Archivado en:
Comparte este post:

Comentarios

Jose ha opinado:

No me parece. Leyendo este post alguien pensaria que un tester es como un developer pero con mas cualidades. Y no creo, si fuera capaz de hacer lo mismo que el developer.. sería developer :)

"diplomacia" y "persuasividad" no es esto parte de un project leader, team leader o como le quieran llamar?

Me imagino a varios tester convenciendo al resto del equipo que arreglen el bug que cada uno acaba de encontrar.. y me produce dolor de cabeza.

# February 12, 2008 9:22 PM

Miguel LLopis ha opinado:

Tienes parte de razón, Jose, respecto a tu última frase, de ahí que otras de las cualidades que destaco en un buen tester son las de "perfeccionista con criterio" y "economista". El tester debe ser capaz de valorar la importancia REAL de un bug del sistema, y en base a dicha valoración, ser capaz de transmitir al resto del equipo la importancia y la urgencia por resolver dicho bug. De ahí que todo bug deba llevar asociada una prioridad, digamos "cualitativa", a la hora de elaborar el informe sobre el mismo.

Respecto a la persuasividad y diplomacia, es cierto que esos dos roles que comentas deben tenerla. De hecho, son los roles superiores al de tester en una escala jerárquica (no me quiero adelantar, puesto que es el siguiente post de la serie). Si bien, esas dos cualidades quizá no sean tan necesarias en un developer, cuya función es implementar lo que, sobre el papel, se ha decidido por parte del Developer Architect, el Project Leader... y ha sido minuciosamente redactado y revisado por parte del equipo de Program Management.

Como digo, me estoy adelantando un poquito al siguiente post... jeje

Respecto a tu comparativa tester/developer, me parece que no ha quedado del todo claro el concepto del rol de un SDET (ing. de software de pruebas).

Podríamos discernir entre el tester "a nivel de usuario" (el cual no tendría necesidad siquiera de ser una persona con background técnico), del tester encargado de realizar pruebas de otros tipos, encargarse de los procesos de V&V (verificación y validación) del software, y eventualmente automatizar dichas pruebas haciendo uso de herramientas y de frameworks de automatización específicos, los cuales por supuesto se realizan desarrollando... Así que en cierto modo, este segundo tipo de testers (que es al que yo me estoy refiriendo en esta serie, puesto que es el rol que yo he vivido en 1a persona) son desarrolladores... Desarrolladores de herramientas de prueba, de aplicaciones de prueba, inspectores de código y, a la vez, deben ponerse en la piel del usuario final para exigir que el software desarrollado cumpla con las expectativas y requerimientos para los que fue planificado.

# February 12, 2008 9:38 PM

Jose ha opinado:

Te entiendo. Igual no creo que lleguemos a un acuerdo.

Creo yo, que si el tester al que te refieres (que suena mas o menos como a un developer optimizado :P) es tan bueno desarrollando como inspeccionando código y que a la vez se pone en la piel del usuario, es decir tiene conocimientos de usability, entonces creo que esa persona deberia estar desarrollando.

Y quien pongo en lugar del tester? bueno, a otro desarrollador no-optimizado que vaya aprendiendo.. y cuando llegue a ese nivel, pasa a desarrollo.

# February 12, 2008 10:23 PM

Rodrigo Corral ha opinado:

Mira Jose... es bien simple, si tu vas a revisar a fondo mi trabajo lo mínimo que espero es que seas mejor que yo.

Simplificando, ese principio es el que guia a los equipos de desarrollo para seleccionar la gente más brillante como testers (en el sentido de tester del que Miguel habla).

Desde la prespectiva miope de quien no sabe lo que un tester puede hacer por sus proyectos (geeks.ms/.../Pon-un-tester-en-tus-proyectos.aspx) y la de que ve en el tester a un figura de segunda que hace clicks por la pantalla, es dificil de comprender.

Es un error de libro (Steve McConnell lo explica excelente en Rapid Application Development) el poner a un mal desarrollador o a uno que no tiene conocimientos suficientes ha hacer la labor de tester.

Saludos!

# February 12, 2008 10:42 PM

Miguel LLopis ha opinado:

De todas formas, yo no quiero llevarlo a un debate de quién es mejor o peor, ni mucho menos. Hay testers buenos y developers buenos, igual que hay gente que es un desastre en ambos roles.

La cuestión es: todo tester ha sido antes developer. ¿Por qué? Por lo que ya comentaba en un post anterior: como ingenieros, hemos sido educados en una perspectiva de "aprender a construir", y el rol del tester sería el de garantizar que lo que otro ha construído no se va a derrumbar.

Debo decir que todos los testers que conozco han sido antes developers, y es un tema del que he hablado largo y tendido tanto dentro como fuera de la oficina... "Es algo complicado cambiar de perspectiva developer a perspectiva tester".

Os pongo un ejemplo:

Imaginad que nuestro equipo de desarrolladores crea una cierta aplicación que ofrece servicios, nosotros como testers queremos probarla y para ello tenemos que desarrollar otra aplicación que los consuma. Nos montamos un escenario de uso, por así decirlo.

¿Cuál es la mentalidad del desarrollador, o del tester que está empezando todavía en dicho rol? Hacer que esa aplicación que consume servicios funcione sí o sí. Parece que estemos obligados a que funcione, cuando en realidad es todo lo contrario: Si conseguimos que funcione sin encontrar ni un solo fallo, es que hemos elegido un mal escenario de uso (partiendo de la hipótesis de que el software a probar no es perfecto, porque ningún software lo es)

# February 12, 2008 10:55 PM

Jose ha opinado:

Rodrigo: tu frase "si tu vas a revisar a fondo mi trabajo lo mínimo que espero es que seas mejor que yo" está bien y me es muy dificil intentar refutarla.

Ni tampoco busco hacerlo. Simplemente creo que el tester se centra en algunos aspectos distintos al desarrollador. El tester seguramente intentará romper algo, mientras que el desarrollador quizás estuvo pensando y leyendo sobre si convenía usar un int o un double para determinada variable. Si bien tienen mucho en común, cada uno se especializa en distintas cosas.

El error de libro que comentas se entiende bien, pero tambien me parece un error poner al mal desarrollador a desarrollar y al bueno en testing. (De hecho, si se tiene a un mal desarrollador hay que hecharlo a la calle y punto)

Porque con esa idea, lo próximo será: pongamos a todos estos malos desarrolladores en este proyecto porque tenemos a un project leader fenomenal!!

Me fuí de tema, pero yo hago mi propio resúmen y me quedo con:

Tester: ex-developer que dejando "un poco" de lado el desarrollo ahora se "especializa" en probar aplicaciones y tiene todas las cualidades que detalla este post excepto las ultimas dos :P

Saludos.

# February 13, 2008 1:10 AM

Paco Modestia ha opinado:

Creo que te falta (perdón...falta) una característica que se llama "Humildad".

Porque vamos, vaya manera de describir uno mismo su trabajo. Tio, eres perfecto!!!!!!!

# February 13, 2008 3:40 PM

Miguel LLopis ha opinado:

Para nada... Yo he enumerado las cualidades de un buen tester, y a mí me queda un largo camino por recorrer para llegar a considerarme realmente bueno en ello.

La suerte que tengo es que, con 23 años que tengo, aún me quedan muchos años para poder aprenderlo.

En ninguna frase del artículo me atribuí cualidades a mí mismo, hablo en todo momento acerca del rol de SDET...

Un saludo!

# February 13, 2008 4:38 PM

David Daniel Arroyo Zari "Ddaz" ha opinado:

Una caracteristica que falto al Tester... es que somos los mas odiados del equipo... muchos dicen "que nos pagan para hacer ver a los demas que estan mensos" (esa es una de las cosas que mas me han dicho..)

Salu2

Ddaz

# March 31, 2008 8:53 AM

Sakura ha opinado:

Me he leido las cualidades q debiera tener un tester al igual q las opiniones posteadas, muy interesante ambos, pero me pregunto, ¿Cuales son las habilidades (competencias) técnicas que debe tener un tester?....

Slds....

# September 23, 2009 10:14 PM

Erna Tercero ha opinado:

Yo si estoy de acuerdo con el articulo, el tester debe ser perfeccionista, tener muy claro los principios y conceptos de caldiad, para que el producto q el developer realizó sea lo que el usuario/cliente realmente necesita, asi se gana negocio, y se conservan clientes contentos cuando el software no tiene defectos.

# September 12, 2010 2:36 AM

Josefina ha opinado:

Hola:

No me parece que comparen al developer con el tester, el asunto aquí era definir las cualidades de un buen tester. Pero yo agregaría, de qué Tipo de Testing??? Tengo más de 8 años trabajando como Tester y existen más de 30 Tipos de Testing que se pueden aplicar a un sistema. También hay areas, Manual, Automatizado, de Performance, De código, etc. por lo que estariamos muy equivocados al tratar de describir un tester en general sin tomar en cuenta el tipo de testing para que lo necesitamos.

Un tester manual no necesita saber más que el developer puesto que no va a revisar su código. Un tester de automatización no necesita conocer la arquitectura de la aplicación por que le basta con que funcione.

Sugeriría que antes de dar un criterio tan generalizado tomar en cuenta ello. Pero en general, el sentido común es uno de las cualidades que más aplicarian para cualquier tester.

# March 10, 2011 6:43 PM